JP2008538883A - リソースアドレスリクエスト管理方法及び関連するゲートウェイ装置 - Google Patents

Abstract

本発明は、第１装置に接続するための手段と、第１装置により提供されるネットワークリソース識別子の関数としてリアルネットワークアドレスを取得するため、第２装置に接続するための手段と、リアルネットワークアドレスが提供不可である場合、第１装置により提供される偽のリソース識別子に応答して偽のネットワークアドレスを提供する手段とを有するゲートウェイ装置に関する。偽のネットワークアドレスを提供する手段は、異なるネットワークリソース識別子に対して異なる偽のネットワークアドレスを提供するよう適応され、リアルアドレスが利用可能になると、偽のアドレスに対してなされたリクエストは、第１装置が対応するリアルネットワークアドレスを取得することを可能にする。本発明はまた、関連する方法に関する。

Description

発明の詳細な説明

本発明は、ウェブアプリケーションなどからネットワークリソースアドレスリクエストを管理する方法と、当該方法を実現するためのゲートウェイ装置とに関する。本発明は、ＩＰネットワークとＬＡＮを接続するゲートウェイにおいて使用可能であるが、このようなコンテクストに限定されるものでない。

ブラウザアプリケーションを備えたクライアントコンピュータが、いわゆる“ウェブページ”などを取得するため、インターネットサーバにアクセスする必要があるとき、それは、当該ページを提供するサーバに対応するＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを知っている必要がある。通常、ブラウザは初期的に、いわゆるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）又はＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）を知っている。

ＵＲＬ又はＦＱＤＮの実際のＩＰアドレスへの変換は、クライアントコンピュータによって提供されたＵＲＬ又はＦＱＤＮに基づき、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバなどの装置によって実行される。

ブラウザがウェブページをホストする装置、すなわち、ウェブサーバのＩＰアドレスを知ると、当該ＩＰアドレスとの接続を設定し、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）プロトコルなどを利用して必要とされる情報に対するリクエストを送信する。ウェブサーバは、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ウェブページ、ピクチャ又は他のデータにより応答する。

このアドレス変換は、例えば、クライアントコンピュータがローカルエリアネットワークや他のタイプのネットワークに接続され、ゲートウェイ装置を介しインターネットに接続されるときなど、ゲートウェイ装置を介し実行されるかもしれない。

問題が生ずるのは、ＤＮＳサーバとの接続が不可能であるとき、例えば、ゲートウェイ装置とインターネットとの間の接続が中断されるときなどであるかもしれない。この場合、ブラウザはＩＰアドレスを取得することができない。このことは、例えば、“ホスト名が決定できない”などのエラーメッセージをブラウザに表示させることとなる。ユーザが問題の本質を通知し、最終的に解決策を示唆するようにするため、いわゆる“スプーフィング（ｓｐｏｏｆｉｎｇ）”をゲートウェイ装置に実行させることが知られている。この機構は、ゲートウェイ装置に誤ったＩＰアドレスをブラウザに返すようにさせ、ブラウザにＤＮＳサーバとの接続が確立されたことを信じさせることからなる。その後、ゲートウェイ装置は、スプーフされたアドレスとの接続のためのリクエストを傍受し、それがあたかもウェブサーバであるかのように振る舞う。ブラウザからリクエストを受信すると、ゲートウェイは、例えば、誤ったパスワードが提供されたため、又は他の理由のためにインターネット接続がないなど、問題の性質を説明するＨＴＭＬページを返すことができる。

また、ＤＮＳサーバがＵＲＬ又はＦＱＤＮが知られていないことを宣言すると、スプーフされたアドレスを生成することが知られている。これを実行する目的は、クライアントにウェブサーバにリクエストを送信させることである。それは、アドレスを取得していない場合、当該リクエストを送信するための接続を確立しない。

ブラウザ若しくは他のアプリケーション、又はオペレーティングシステムなどの他のクライアントコンポーネントは、いわゆるＤＮＳキャッシュを実現するかもしれない。ＤＮＳキャッシュは、ＵＲＬ又はＦＱＤＮとＩＰアドレスとの間の関連付けを保持する。その後、アプリケーションはＩＰアドレスを２回リクエストする必要はなく、対応する情報へのより高速なアクセスが可能となる。しかしながら、ＤＮＳキャッシュの存在は、上述されたスプーフィング機構と組み合わされる際に問題を生じさせるかもしれない。実際、ＤＮＳサーバとの接続がリストアされると、アプリケーションはスプーフされたＩＰアドレスの使用を中止し、再びＤＮＳサーバからＵＲＬに対する実際のＩＰアドレスをリクエストするようにする。アプリケーションがスプーフされた／偽のＩＰアドレスを記憶しているという事実は、実際のアドレスを再度リクエストしないため、ユーザがもはや初期的にリクエストされたウェブサイトにアクセス不可となる結果をもたらす。

特定のアプリケーションでは、アプリケーションをクローズすることはＤＮＳキャッシュを消去させることが知られている。

本発明は、第１装置と接続するための手段と、第１ネットワーク上に設けられた第１装置に接続するための手段と、前記第１装置により提供されるネットワークリソース識別子の関数としてリアルネットワークアドレスを取得するため、第２ネットワーク上に設けられる第２装置に接続するための手段とを有するゲートウェイ装置であって、さらに、リアルネットワークアドレスが提供不可である場合、前記第１装置により提供されるネットワークリソース識別子に応答して、偽のネットワークアドレスを提供する手段を有し、該偽のネットワークアドレスを提供する手段は、異なるネットワークリソース識別子に異なる偽のネットワークアドレスを提供するよう構成されるゲートウェイ装置に関する。

上記偽のアドレスは、初期的なリソース識別子に対応するリアルアドレスが利用可能になると、該リアルアドレスを提供するのに利用可能である。

本発明の実施例によると、本装置は、偽のネットワークアドレスに基づき、前記第１装置によりなされるリクエストに対するレスポンスを提供するサーバコンポーネントをさらに有する。

本発明の実施例によると、前記レスポンスは、リアルネットワークアドレスの欠落の理由を記述する情報を有する。

本発明の実施例によると、本装置は、偽のネットワークアドレスが以前に提供されたネットワークリソース識別子のリアルネットワークアドレスを決定するようさらに構成される。

本発明の実施例によると、本装置は、リアルネットワークアドレスが決定された偽のネットワークアドレスに基づき、前記第１装置からのリクエストにより、前記第１装置を前記リアルネットワークアドレスにリダイレクトする手段をさらに有する。

本発明の実施例によると、本装置は、偽のネットワークアドレスと自らのネットワークリソース識別子とを格納するメモリをさらに有する。

本発明の実施例によると、前記メモリはさらに、ネットワークリソース識別子に対応するリアルネットワークアドレスが決定されると、該リアルネットワークアドレスをさらに格納する。

本発明はまた、第１ネットワークに設けられる第１装置から第２ネットワークに設けられる第２装置へのネットワークリソースアドレスリクエストを管理する方法であって、当該方法は、前記第１装置と前記第２装置との間に接続されるゲートウェイ装置により実行され、当該方法は、前記第１装置からリソース識別子を受信するステップと、前記第２装置が前記リソース識別子に対応するリアルネットワークリソースアドレスを提供可能か判断するステップと、肯定されると、前記リソースネットワークリソースアドレスを提供し、否定されると、偽のネットワークリソースアドレスを提供するステップとを有し、前記提供される偽のネットワークリソースアドレスは、前記受信したリソース識別子に一意的に関連付けされる方法に関する。

本発明の実施例によると、本方法は、前記第１装置からの偽のネットワークアドレスに基づくリクエストを受信するステップと、これに応答して、前記第１装置によりアクセス可能なサーバに前記第１装置をリダイレクトするステップとをさらに有する。

本発明の実施例によると、前記アクセス可能なサーバは、リアルネットワークアドレスの欠落を生じさせるエラー状態に関する情報を提供する。

本発明の実施例によると、本方法は、リアルネットワークアドレスが取得可能になると、偽のネットワークアドレスが提供された以前に受信したリソース識別子に対するリアルネットワークアドレスを取得するステップをさらに有する。

本発明の実施例によると、本方法は、前記第１装置からの偽のネットワークアドレスに基づくリクエストを受信すると、前記偽のネットワークアドレスに対応する前記リアルネットワークアドレスにより特定される装置と前記ゲートウェイとの間の接続を設定するステップをさらに有する。

本発明の実施例によると、本方法は、受信した識別子を、それに係る偽のネットワークリソースアドレスと、取得されると、前記対応するリアルネットワークアドレスと共に格納するステップをさらに有する。

本発明が、図面を利用して説明される具体的な実施例により詳細に説明される。本発明は、実施例の詳細な説明に限定されるべきでない。

図１は、ローカルエリアネットワーク１０８をインターネット１０４に接続する本実施例のゲートウェイ１０２のオブジェクトを示す。ウェブブラウザなどのインターネットアクセス１０７を要求するアプリケーションを備えたクライアントコンピュータ１０１が、ローカルエリアネットワークと接続される。図１は、インターネットに接続された１つのウェブサーバ１０５と１つのＤＮＳサーバ１０６を示す。もちろん、より多くのＤＮＳサーバ及びウェブサーバが接続可能であり、これら２つのタイプのサーバ以外の装置もまたインターネットに接続される。ゲートウェイ１０２は、その目的が後述されるメモリ１０３を有する。本例によると、メモリは半導体又は等価なタイプである。インターネットアプリケーション１０７はまた、ブラウザと異なるものであってもよく、コンピュータ以外の装置上で実行されるかもしれない。例えば、それは電子番組ガイドアプリケーションを有するＩＰ対応オーディオ／ビデオデコーダであってもよい。ゲートウェイ１０２はまた、装置１０２に直接設けられてもよく、この場合、ローカルエリアネットワークは存在しないことに留意されたい。

図２は、ゲートウェイ装置をローカルエリアネットワークとインターネットにそれぞれ接続するインタフェース２０９及び２１０を含むゲートウェイ装置１０２の各機能コンポーネントを示す。例えば、ローカルエリアネットワークは、イーサネット（登録商標）ネットワーク又はワイヤレスＩＥＥＥ８０２．１１ｂタイプネットワークであってもよい。ゲートウェイ装置１０２はさらに、ウェブサーバに類似したアプリケーションであって、ゲートウェイ装置の内部コンフィギュレーションなどに対応するウェブページを管理及び提供するＨＴＴＰサーバ２１２を有する。

本実施例によると、ＨＴＴＰサーバ２１２はまた、スプーフされたＩＰアドレスにリクエストする装置に情報を提供する。ＨＴＴＰプロキシ２１３は、ネットワーク１０８上のクライアントアプリケーションに対するプロキシサーバとして機能する。それは、クライアントアプリケーションにより策定されたリクエストを受信し、必要に応じてサーバ１０５などのリアルサーバにこれらのリクエストを転送し、リアルサーバのレスポンスをクライアントアプリケーションに送り返す。ＨＴＴＰプロキシは、ウェブサーバに関する限り、クライアントアプリケーションとして機能する。ＤＮＳ転送装置２１４は、クライアントアプリケーション１０７から受信したＤＮＳクエリを処理し、それらをインターネットを介し１以上のＤＮＳサーバに転送するコンポーネントである。当該コンポーネントは、ＤＮＳサーバから有効なレスポンスが受信されるか検出し、レスポンスをクライアントアプリケーションに送り返す。ＤＮＳ転送装置はまた、様々な理由により適切なＤＮＳサーバレスポンスが取得できないときに本実施例による“スプーフされた”又は“偽の”ＩＰアドレスを生成し、それらをクライアントアプリケーションに送信するコンポーネントである。ＤＮＳリクエストに応答するため１つのみのスプーフされた／偽のＩＰアドレスを使用する代わりに、このようなスプーフされたアドレスが必要とされるとき、ゲートウェイ装置のＤＮＳ転送装置は、それがＤＮＳリクエストにより受信した新たな各ＵＲＬ又はＦＱＤＮについて異なるスプーフされたＩＰアドレスを送信する。ＩＰルータコンポーネント２１１は、ローカルエリアネットワーク、ゲートウェイの他のコンポーネント及びインターネットとの間でＩＰパケットを転送する。ゲートウェイ装置１０２はまた、図１に関してすでに簡単に説明されたメモリ１０３を有する。メモリ１０３は、送信されたものに応答して各自のＵＲＬ又はＦＱＤＮと共に、ＤＮＳ転送装置２１４により決定されたスプーフされたＩＰアドレスを格納する。このため、ゲートウェイは、所与の受信したＵＲＬ／ＦＱＤＮに対して何れのスプーフされたＩＰアドレスが送信また受信したか決定することが可能である。

以下において、ゲートウェイ装置は、インターネット接続が存在しないことを検出すると、スプーフされたアドレスを送信することが提案される。もちろん、他の条件もまた考慮されるかもしれない。

図４は、クライアントアプリケーション１０７からの２つのリクエストの受信後のメモリ１０３のコンテンツの一例を与える。ＤＮＳ転送装置は、これら２つのリクエストに適したＤＮＳサーバレスポンスが受信されず、この結果、２つの異なるスプーフされたＩＰアドレスがクライアントアプリケーション１０７に送り返されると判断したと仮定される。クライアントアプリケーションが予想する実際のアドレスを示すカラム“実際のＩＰアドレス”は、この段階ではエンプティなままである。ＤＮＳサーバとの接続がゲートウェイ装置によって確立可能になると、それはメモリ１０３のコンテンツをチェックし、実際のＩＰアドレスが以前に決定可能でなく、それのメモリのスプーフされたＩＰアドレス及びＵＲＬ又はＦＱＤＮの各ペアについてＤＮＳサーバに実際のＩＰアドレスに対するリクエストを送信する。図５は、実際のＩＰアドレスが決定されると、メモリの状態を示す。本実施例では、メモリは３２個までのエントリを格納する。ラウンドロビン機構は、リストがフルであるとき、最も古いエントリを削除する。変形の実施例によると、ＴＴＬ（Ｔｉｍｅ−Ｔｏ−Ｌｉｖｅ）パラメータが各エントリに関連付けされる。

ゲートウェイ装置がデスティネーションアドレスとしてスプーフされたＩＰアドレスの１つを含むリクエストをクライアントアプリケーションから受信すると（すなわち、クライアントアプリケーションは、接続を設定しようとすると）、当該スプーフされたアドレスについて、実際のＩＰアドレスがキャッシュされたか否か、それのキャッシュメモリ１０３において確認する。

このような実際のＩＰアドレスが存在する場合、リクエストのスプーフされたＩＰアドレスが実際のＩＰアドレスと交換され、ゲートウェイ装置は、実際のＩＰアドレスにより特定される正しいサーバとの接続を確立し、もとのリクエストを当該サーバに転送する。

キャッシュメモリにこのような実際のＩＰアドレスが存在しない場合、ゲートウェイ装置は、ＨＴＭＬウェブページなどの適切なメッセージをクライアントアプリケーションに返す。当該メッセージ又はページは、好ましくは、ゲートウェイ装置が確認できる限り、実際のＩＰアドレスの欠落の理由の識別を有する。例えば、ゲートウェイ装置は、エラー状態の原因を決定するためテストを行ってもよい。すなわち、ＨＴＴＰプロトコルは、サーバが新たなＵＲＬを利用してクライアントを他の位置にリダイレクトすることを可能にする。

図３は、クライアントアプリケーション、ゲートウェイ装置のコンポーネント、ＤＮＳサーバ及びウェブサーバのメッセージ交換及びアクションの詳細なチャートである。

各ステップが後述される。

ステップ１：クライアント装置のウェブブラウザ（及びより正確には、ブラウザのためのオペレーティングシステム）が、ウェブサイトＵＲＬ（ｗｗｗ．ｘｙｚ．ｃｏｍなど）に対応するＩＰアドレスを要求するＤＮＳ転送装置にＤＮＳクエリを送信する。

ステップ２：ゲートウェイ装置のＤＮＳ転送装置は、インターネット（このため、実際のＤＮＳサーバ）との接続がないことを検出する。

ステップ３：ＤＮＳ転送装置は、スプーフされた／偽のＩＰアドレスにより応答することを決定する。それは、スプーフされたＩＰアドレスとＵＲＬ／ＦＱＤＮとの間の一意的な関連付けによりそれのキャッシュ／テーブルを更新する。

ステップ４：ウェブブラウザは、ウェブサイトのアドレスがスプーフされた／偽のＩＰアドレスであると考えるため、それとの接続を確立する。ゲートウェイ装置１０２は、この接続リクエストを“傍受”し、ゲートウェイのＨＴＴＰプロキシモジュールとの接続が確立される。ウェブブラウザは、ウェブサイトに対するＨＴＴＰリクエストを送信する。

ステップ５：ＨＴＴＰプロキシは、スプーフされた／偽のＩＰアドレスを検出する。当該コンポーネントは、このスプーフされたＩＰアドレスに対応する実際のＩＰアドレスが存在するか学習するため、ＤＮＳ転送装置にクエリする。

ステップ６：ＤＮＳ転送装置は、それのキャッシュ／テーブルをチェックし、当該スプーフされたＩＰアドレスに関するＵＲＬ／ＦＱＤＮが実際のＩＰアドレスでは決定されていなかったことを学習する。それは、ＨＴＴＰプロキシに実際のＩＰアドレスが存在しないことを通知する。

ステップ７：このスプーフされたＩＰアドレスに関連する実際のＩＰアドレスが存在しないことを知ると、ＨＴＴＰプロキシは、ゲートウェイ装置のＨＴＴＰサーバによりホストされるウェブページにウェブブラウザをリダイレクトする。それは、ウェブブラウザに新たなＵＲＬを示す。

ステップ８：ウェブブラウザは、ここでゲートウェイ装置との接続を確立し、ウェブページに対するＨＴＴＰリクエストをゲートウェイのローカルサーバに送信する。

ステップ９：ＨＴＴＰサーバウェブページは、インターネット接続が存在しないことを検出するか、又は他の診断テストを実行することができる。

ステップ１０：ＨＴＴＰサーバは、この問題を説明し、例えば、ゲートウェイ装置により実行された診断テストに基づきインターネット接続問題に対する可能な解決策を含むＨＴＭＬページにより応答する。

ステップ１１：ユーザは、訂正アクションを行い（例えば、ケーブルの再接続やインターネット接続パスワードの訂正など）、スクリーン上のボタン又はリンクのクリックを押下する。これにより、例えば、訂正されたパスワードのＨＴＴＰサーバへの送信がトリガーされる。

ステップ１２：ＨＴＴＰサーバはここで、インターネット接続が再び確立されていることを検出する。ＤＮＳサーバのアドレスは、インターネット接続が確立されると、ゲートウェイにより動的に抽出される。インターネットアドレスと共に、ゲートウェイはまた、１以上のＤＮＳサーバのアドレスを受信する。

ステップ１３：インターネット接続の確率は、“スプーフされた”／偽のＩＰアドレスが送信されたＵＲＬに対するＤＮＳクエリを送出するため、ゲートウェイ装置のＤＮＳ転送コンポーネントをトリガーする。それは、これらのクエリをインターネットを介しＤＮＳサーバのアドレスに送信する。

ステップ１４：ＤＮＳサーバは、ＵＲＬに対応する実際の又は“リアル”ＩＰアドレスにより応答する。

ステップ１５：ＤＮＳ転送装置は、スプーフされたＩＰアドレス、ＵＲＬ（ＦＱＤＮ）及び実際のＩＰアドレスによりそれのキャッシュ／テーブルを更新する。

ステップ１６：インターネット接続が再び確立されたことを知ると、インターネットゲートウェイＨＴＴＰサーバは、ウェブブラウザを当初要求されたウェブサイトに再びリダイレクトする。ＨＴＴＰサーバは、ＨＴＴＰプロキシとＨＴＴＰサーバとの間で以前に交換された当初リクエストされたウェブサイトのＵＲＬを記憶する。

ステップ１７：ウェブブラウザはここで、もとのウェブサイトとスプーフされた／偽のＩＰアドレスとの間のキャッシュされている関係を利用し、スプーフされた／偽のＩＰアドレスに再び接続する。ゲートウェイ装置は、当該接続を“傍受し”、これにより、実際にゲートウェイ装置のＨＴＴＰプロキシモジュールとの接続が確立される。

ステップ１８：ＨＴＴＰプロキシコンポーネントは、スプーフされたＩＰアドレスに対応する実際のＩＰアドレスが存在するか学習するため、ＤＮＳ転送コンポーネントをクエリする。

ステップ１９：ＤＮＳ転送コンポーネントは、ステップ１４においてＤＮＳサーバから受信した実際のＩＰアドレスにより応答する。

ステップ２０：ＨＴＴＰプロキシは、スプーフされたＩＰアドレスを実際のＩＰアドレスと交換し、ウェブページを要求するウェブサーバとの接続を確立する。

ステップ２１：ウェブサーバは、要求されたＨＴＭＬウェブページにより応答する。

ステップ２２：ＨＴＴＰプロキシはここで、ウェブサーバから受信されたレスポンスをクライアントコンピュータのウェブブラウザに転送する。クライアントコンピュータ上のユーザは、要求されたウェブサイトを自動的に受信する。これにより、クライアントアプリケーションは、それがスプーフされたＩＰアドレスを使用し続けるが、正しいサーバにアクセスする。ほとんどのオペレーティングシステムは自らのＤＮＳキャッシュを有していることに留意されたい。これは、ＤＮＳ結果であるＩＰアドレスとのＵＲＬ／ＦＱＤＮ対応をＴＴＬパラメータにより記憶するモジュールである。ウェブブラウザなどのオペレーティングシステム上で実行されるアプリケーションはまた、自らのキャッシュを有する。しかし、それらはＴＴＬパラメータを考慮していない。

変形となる実施例では、リアルアドレスがメモリ１０３のスプーフされたアドレスに対して利用可能であるかチェックするステップが、ＨＴＴＰプロキシ２１３の代わりにＩＰルータ２１１により実行される。また、スプーフされたＩＰアドレスをリアルＩＰアドレスと置換するステップは、ＩＰルータにより実行されてもよい（ステップ２０）。ＨＴＴＰプロキシは、スプーフされたＩＰアドレスの存在をチェックし、このようなアドレスが検出されると、クライアントアプリケーションをローカルＨＴＴＰサーバにリダイレクトする。それは、メモリ１０３のテーブルをクエリしない。本実施例は、ウェブブラウザが（偽の）アドレスを誤って記憶する一般的な問題に対する解決策を提供するだけでなく、自らのＤＮＳキャッシュにアドレスを記憶する他のプログラムに対しても適用可能である。

実施例の説明はインターネットプロトコルネットワーク実現形態に基づくものであるが、本発明は、識別子がアドレスにより置換される必要があり、当該フレームにおけるレスポンスのキャッシュが問題を生じさせる可能性のある他のコンテクストに適用可能である。

図１は、本実施例において説明されるゲートウェイ装置を利用して接続されるローカルエリアネットワーク及びインターネットの概略図である。 図２は、ゲートウェイ装置の機能コンポーネントの概略図である。 図３は、本実施例によるＤＮＳサーバ、ゲートウェイ装置の各コンポーネント及びクライアントアプリケーションの間の通信を説明するメッセージシーケンスチャートである。 図４は、ＤＮＳサーバと接続していない期間にゲートウェイ装置によりリクエストが受信された後、本発明によるゲートウェイ装置のアドレスキャッシュメモリのコンテンツを示すテーブルを示す。 図５は、接続が再確立され、“リアル”又は実際のＩＰアドレスが決定された際の図４のテーブルを示す。

Claims (13)

1. 第１ネットワーク上に設けられた第１装置に接続するための手段と、前記第１装置により提供されるネットワークリソース識別子の関数としてリアルネットワークアドレスを取得するため、第２ネットワーク上に設けられる第２装置に接続するための手段とを有するゲートウェイ装置であって、
   さらに、リアルネットワークアドレスが提供不可である場合、前記第１装置により提供されるネットワークリソース識別子に応答して、偽のネットワークアドレスを提供する手段を有し、
   該偽のネットワークアドレスを提供する手段は、異なるネットワークリソース識別子に異なる偽のネットワークアドレスを提供するよう構成されるゲートウェイ装置。
2. 偽のネットワークアドレスに基づき、前記第１装置によりなされるリクエストに対するレスポンスを提供するサーバコンポーネントをさらに有する、請求項１記載の装置。
3. 前記レスポンスは、リアルネットワークアドレスの欠落の理由を記述する情報を有する、請求項２記載の装置。
4. 偽のネットワークアドレスが以前に提供されたネットワークリソース識別子のリアルネットワークアドレスを決定するようさらに構成される、請求項１乃至３何れか一項記載の装置。
5. リアルネットワークアドレスが決定された偽のネットワークアドレスに基づき、前記第１装置からのリクエストにより、前記第１装置を前記リアルネットワークアドレスにリダイレクトする手段をさらに有する、請求項４記載の装置。
6. 偽のネットワークアドレスと自らのネットワークリソース識別子とを格納するメモリをさらに有する、請求項１乃至５何れか一項記載の装置。
7. 前記メモリはさらに、ネットワークリソース識別子に対応するリアルネットワークアドレスが決定されると、該リアルネットワークアドレスをさらに格納する、請求項４及び６記載の装置。
8. 第１ネットワークに設けられる第１装置から第２ネットワークに設けられる第２装置へのネットワークリソースアドレスリクエストを管理する方法であって、当該方法は、前記第１装置と前記第２装置との間に接続されるゲートウェイ装置により実行され、
   当該方法は、
   前記第１装置からリソース識別子を受信するステップと、
   前記第２装置が前記リソース識別子に対応するリアルネットワークリソースアドレスを提供可能か判断するステップと、
   肯定されると、前記リソースネットワークリソースアドレスを提供し、否定されると、偽のネットワークリソースアドレスを提供するステップと、
   を有し、
   前記提供される偽のネットワークリソースアドレスは、前記受信したリソース識別子に一意的に関連付けされる方法。
9. 前記第１装置からの偽のネットワークアドレスに基づくリクエストを受信するステップと、
   これに応答して、前記第１装置によりアクセス可能なサーバに前記第１装置をリダイレクトするステップと、
   をさらに有する方法。
10. 前記アクセス可能なサーバは、リアルネットワークアドレスの欠落を生じさせるエラー状態に関する情報を提供する、請求項９記載の方法。
11. リアルネットワークアドレスが取得可能になると、偽のネットワークアドレスが提供された以前に受信したリソース識別子に対するリアルネットワークアドレスを取得するステップをさらに有する、請求項８乃至１０何れか一項記載の方法。
12. 前記第１装置からの偽のネットワークアドレスに基づくリクエストを受信すると、前記偽のネットワークアドレスに対応する前記リアルネットワークアドレスにより特定される装置と前記ゲートウェイとの間の接続を設定するステップをさらに有する、請求項１１記載の方法。
13. 受信した識別子を、それに係る偽のネットワークリソースアドレスと、取得されると、前記対応するリアルネットワークアドレスと共に格納するステップをさらに有する、請求項１１記載の方法。

Images