JP2016006982A - 割り当てられたネットワークアドレスを有するデバイスにアクセスするクライアントローカルプロキシサーバを使用したシステムおよび方法 - Google Patents

Abstract

【課題】割り当てられたネットワークアドレスを有するデバイスにアクセスするクライアントローカルプロキシサーバを使用したシステムおよび方法を提供する。【解決手段】モバイルコンピューティングデバイスにアクセスするためのウェブクライアントからの要求を受信することに応じて、クライアントローカルプロキシサーバは、ウェブクライアントとモバイルコンピューティングデバイスの割り当てられたアドレスとの間で通信パスを開く仲介者として動作する。モバイルコンピューティングデバイスは、クライアントローカルプロキシサーバにそのアドレスの現在のバージョンを繰り返して登録する。モバイルコンピューティングデバイスとプロキシサーバソフトウェアは、中間的ルーティング動作を実行するために、ターゲット化された構成変更のみを要求する。【選択図】図２

Description

関連出願

米国特許法の下の優先権主張
本特許協力条約による特許出願は次の優先権を主張する。
「REMOTE MOBILE ADMINISTRATION AND LOGGING USING HTTP PROTOCOL」と題され、２０１１年３月１１日に出願され、ここでの譲受人に対して譲渡され、ここにおける参照によりここによって明示的に組み込まれた仮出願第６１／４５２，０３１号、および
「REMOTE ACCESS AND ADMINISTRATION OF DEVICE CONTENT AND CONFIGURATION USING HTTP PROTOCOL」と題され、２０１２年１月１８日に出願され、ここでの譲受人に対して譲渡され、ここにおける参照によりここによって明示的に組み込まれた仮出願第６１／５８８，００７号、および
「SYSTEM AND METHOD USING A CLIENT-LOCAL PROXY-SERVER TO ACCESS A DEVICE HAVING AN ASSIGNED ADDRESS」と題され、２０１２年１月１８日に出願され、ここでの譲受人に対して譲渡され、ここにおける参照によりここによって明示的に組み込まれた仮出願第６１／５８８，０３０号、および
「SYSTEM AND METHOD USING A WEB PROXY-SERVER TO ACCESS A DEVICE HAVING AN ASSIGNED NETWORK ADDRESS」と題され、２０１２年３月８日に出願され、ここでの譲受人に対して譲渡され、ここにおける参照によりここによって明示的に組み込まれた同時係属中の仮出願ではない出願第１３／４１５，６１４号。

同時係属中の特許出願への参照
本特許出願は、下記の同時係属中の米国特許出願に関する：
ここで同時に出願され、ここでの譲受人に対して譲渡され、ここにおける参照により明示的に組み込まれた、代理人整理番号１０３２３４を有する、Yuval Corey HershkoおよびNir Strauss著「REMOTE ACCESS AND ADMINISTRATION OF DEVICE CONTENT AND CONFIGURATION USING HTTP PROTOCOL」および、
ここで同時に出願され、ここでの譲受人に対して譲渡され、ここにおける参照により明示的に組み込まれた、代理人整理番号１１０５２５を有する、Yuval Corey HershkoおよびNir Strauss著「SYSTEM AND METHOD USING A WEB PROXY-SERVER TO ACCESS A DEVICE HAVING AN ASSIGNED NETWORK ADDRESS」および、
ここで同時に出願され、ここでの譲受人に対して譲渡され、ここにおける参照により明示的に組み込まれた、代理人整理番号１１０５２６を有するYuval Corey HershkoおよびNir Strauss著「SYSTEM AND METHOD USING FOR ACCESSING A DEVICE HAVING AN ASSIGNED NETWORK ADDRESS」。

開示された実施形態は、一般的に、通信ネットワークで動作しているデバイスにアクセスすることを対象としている。より具体的には、開示された実施形態は、インターネットプロトコル（ＩＰ）ネットワークにわたってデバイスを位置づけ、ルート指定し、アクセスするためのシステムおよび方法を対象としており、ここにおいて、デバイスアドレスは変更できる。

通信ネットワークにおいて、アドレスは、ネットワーク上で各デバイスに割り当てられた識別子である。インターネットに適用されるように、デバイスのアドレスは、その「インターネットプロトコルアドレス」（ＩＰアドレス）として一般的には知られており、それは、インターネット上のデバイスの仮想ロケーションの数値表現である。デバイスがウェブサイトをホストする場合には、ホストデバイスのＩＰアドレスは、ホストデバイスを位置づけ、ウェブサイトからのコンテンツへのアクセスを提供するために使用される。例えば、ウェブドメインｇｏｏｇｌｅ．ｃｏｍは、実際には数値ＩＰアドレスを表しており、例えば７３．１４．２１３．９９であることができる。ウェブクライアントがそれらのウェブブラウザにおいてドメイン名でタイプする場合、ダウンストリームＤＮＳシステムは、ＩＰアドレスに対し入力されたドメイン名に一致するまたはルート指定し、そのあとで、数値ＩＰアドレスを使用して、そのアドレスと関連づけられたホストサーバを位置づけ、アクセスを提供する。

デバイスのＩＰアドレスは、ネットワーク内のエンティティによってそれに一般的に割り当てられる。例えば、ＣＤＭＡネットワークでは、アドレス割り当てエンティティは、パケットデータサービングノード（ＰＤＳＮ）である。ＩＰアドレスは、静的にまたは動的に割り当てられうる。静的なＩＰアドレッシングスキームは１つの顧客／デバイスにつき１つのＩＰアドレスを割り当て、動的なＩＰアドレッシングスキームは、選択されたまたはランダムな間隔において、所与の顧客／デバイスに異なるＩＰアドレスを割り当てる。例えば、いくつかのインターネットサービスプロバイダ（ＩＳＰ）は、顧客が自身のコンピュータにログインするたびに、所与の顧客に異なるＩＰアドレスを割り当てる。静的で固有ＩＰアドレスを有するホストデバイス上のウェブサイトは、信頼してアクセスされ、安定したクライアントサーバセッションを維持する。対照的に、動的に割り当てられたＩＰアドレッシングスキーム下では、コンピュータは、そのネットワーク上で他のコンピュータとＩＰアドレスを共有する可能性があることになる。したがって、動的に割り当てられたＩＰアドレスでウェブサイトをホストすることは、ウェブクライアントが動的に割り当てられたアドレスにどの程度信頼してアクセスできるか、と同様に、ウェブクライアントと動的に割り当てられたアドレスとの間で確立されたクライアントサーバセッションの安定性を妥協する傾向がある。

ウェブクライアントをより幅広いウェブ対応コンピューティングデバイスへルート指定する方法を提供することが望ましい、それによって、より多数のデバイスからのコンテンツおよび特徴への遠隔ウェブベースのアクセスを許容する。より具体的には、動的にアドレス指定された、モバイルコンピューティングデバイス（例えば、携帯電話、ＰＤＡ、タブレットおよび同様なもの）を、１つが静的にアドレス指定されたウェブサーバにおいてウェブサイトコンテンツにルート指定しアクセスする可能性がある同じ簡易性、安定性および信頼性を有するＩＰネットワーク上でウェブクライアントに対しアクセス可能であるウェブサーバとして利用することは有利であるであろう。例えば、ＰＤＡおよびスマートフォンの技術が改良されると、ユーザは、これらのデバイス上にますます多くの情報を格納する。増加は、情報の量とそのタイプの範囲の両方に関する。例えば、タイプは、限定されていないが、過去および現在の物理的ロケーション、ビデオ、ミュージック、および他のマルチメディアファイル、ワード処理ドキュメント、および連絡先、ならびに、さまざまなインタラクティブゲームを含むことができる。

しかしながら、モバイルデバイスアプリケーション分野の当業者およびユーザに対して既知であるように、自身のモバイルデバイス上の情報を共有したいユーザは、限定オプションセットを有する。ユーザは、例えば、意図した受信者に選択したファイルを電子メール送信できる。添付ファイル（複数含む）を伴う電子メールはモバイルデバイスのリンクのうち１つまたは複数を通じてインターネットへ、例えばセルラワイヤレスアップリンクを通じてセルラワイヤレスネットワークへ、送信されることができ、そのあとで、そのインタフェースを通じてインターネット、またはＷｉ−Ｆｉリンク、ローカルアクセスポイント、インターネットへ送信されることができる。しかしながら、ファイルを共有する電子メール添付手段は、実質的な制限を有することができる。１つのこのような制限は、ユーザがモバイルデバイスの物理的所有を有することを要すること、そしてさらに、一般的にユーザによる直接的なアクションを要すること、例えば、ファイルを選択し添付すること、また、電子メールメッセージのアドレスリストを記入すること、を要すること、である。

あるいは、ユーザは、ユーザのモバイルデバイスからユーザのソーシャルネットワークページ（例えばＦａｃｅｂｏｏｋ（登録商標）またはＭｙＳｐａｃｅ（登録商標））に選択されたファイルを投稿することができる。しかしながら、ユーザのモバイルデバイス上でファイルを共有するための手段としてこれらのソーシャルネットワークを利用することは、電子メール共有手段と、同じ要件、および制限、の多くを有する。例えば、ユーザが彼／または彼女のモバイルデバイス上にのみあるファイルを共有すると決定するたびに、ユーザは、そのデバイスの物理的所有物を有さなくてはならない。また、ユーザがファイルのアップロードおよび投稿を手動で実行することを要する。さらに、ソーシャルネットワークは、アクセスされることができるファイルの種類に対し、ならびに、ヒューマンインタフェースメカニズムに対し、制限を課すことができる。モバイルデバイスユーザがデバイス上で格納されたファイルを共有するための１つの従来の方法は、例えばソーシャルネットワーク投稿について説明された同じリンクを使用して、Ａｐｐｌｅ（登録商標）社のＭｏｂｉｌｅ ＭｅまたはＡｐｐｌｅ社のｉＣｌｏｕｄ（登録商標）のような「クラウド」ディスクに選択されたファイルをアップロードすることである。しかしながら、この方法もまた、彼または彼女がファイルを共有したいと思うたびに、ユーザがモバイルデバイスの物理的所有物を有することを要する。

動的アドレッシングスキームの存在は、モバイル電話およびワイヤレスＰＤＡのようなモバイルコンピューティングデバイスからＩＰネットワーク上でアクセスすることに対する著しい障害である。前述されるように、ＣＤＭＡ、ＵＭＴＳ、ＧＰＲＳ、Ｗｉ−Ｆｉおよび同様なもののようなネットワークでは、モバイル電話およびワイヤレスＰＤＡは静的でルート指定可能なＩＰアドレスを割り当てられない。代わりに、それらのアドレスは動的に割り当てられ、ネットワークの要件およびデバイスのモビリティおよびワイヤレス接続に主に関連するいくつもの理由について通常またはランダムの時間で変更しうる。ＩＰおよびプライベートネットワークにおける多くの複雑かつ独自仕様システムのため、動的にアドレス指定されたデバイスにおいて位置づけられたコンテンツにアクセスし検索するためのこのようなネットワーク上でのまたはその内の試みは、かなりの費用、エンジニアリングマンアワー（engineering man-hours）および設計の複雑さ、ならびに、ＤＮＳサーバ、従来のゲートウェイおよび複雑なトンネリング構成のような独自仕様システムへのアクセスおよび変更を必要とすることが予期される。

本開示は、他の特徴および利点のうち、変更できる割り当てられたアドレスを有するデバイスにスタンダードな既製のウェブクライアントを信頼してルート指定するためのシステムおよび方法を提供するさまざまな例示的な実施形態を説明する。開示された実施形態はまた、他のさらなる特徴および利点のうち、商業的に利用可能な既製のシステムを使用し、そしてこれらの商業的に利用可能な既製のシステム内でターゲット化され相対的に簡易に実装された構成を行うことによって、費用、エンジニアリングマンアワー、設計の複雑さ、独自仕様システムへのアクセスの必要性を最小化することを支援できる。

本発明の例示的な実施形態は、割り当てられたアドレスを有するデバイスにアクセスするためのシステムおよび方法を対象とし、それらは、メモリロケーションに割り当てられたアドレスを格納することと、デバイスにアクセスするための要求をクライアントローカルプロキシサーバにおいて受信することとを備える。要求は、デバイスを固有に識別するデバイス識別子を備える。デバイスにアクセスするための要求に応じて、デバイスの格納されたアドレスがデバイス識別子に基づいて識別され、クライアントローカルプロキシサーバは、要求の送信者と格納されたアドレスとの間のデータパスを確立するために仲介者として動作する。

開示されたシステムは、モバイルコンピューティングデバイスにおいてモバイルウェブサーバソフトウェアの使用を容易にするので、モバイルコンピューティングデバイスアドレスが動的で変更することができたとしても、送信者は、モバイルウェブサーバソフトウェアに信頼してアクセスすることができる。開示された実施形態は、商業的に利用可能なコンポーネント（例えば、モバイルウェブサーバソフトウェアおよびウェブクライアント）を使用することと、あるコンポーネントに対しターゲットにする構成タイプ変更を行うことと（例えば、スクリプト、拡張子および同様なものを追加すること）を開示したシステムを実装する。

図面は、開示された実施形態の説明を支援するために提示されており、実施形態の制限ではなく、実施形態の単なる説明のために提供されている。
図１は、開示された実施形態の図である。 図２は、図１に示されるモバイルコンピューティングデバイス２８、３０、およびクライアントローカルプロキシサーバ３２、３４に提供される方法を例証するフローチャートである。 図３は、図１に示される実施形態によって実行される動作ステップの具体的な例である。

本発明の態様は、本発明の具体的な実施形態を対象とする下記の説明および関連図面において開示されている。代替的な実施形態は、本発明の範囲を逸脱することなく、考案される。さらに、本発明の周知エレメントは、本発明の関連詳細を不明瞭にしないように、詳述されない、または、省略されるであろう。

用語「例示的な(exemplary)」は、「例(example)、インスタンス(instance)、または例証(illustration)として機能している」を意味するように、ここでは使用されている。「例示的(exemplary)」としてここに記載されるいずれの実施形態も、他の実施形態よりも好まれるまたは有利であると必ずしも解釈されない。同様に、「本発明の実施形態」という用語は、本発明のすべての実施形態が記載される特徴、利益、または動作モードを含むということを必要としない。

ここで使用される用語は、特定の実施形態を説明する目的だけのためであり、本発明の実施形態を制限することを意図していない。ここにおいて使用されているように、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、明示的に文脈が他のものを示していないかぎり、複数形も含むように意図されている。用語「備える(comprises)」、「備えている(comprising)」「含む(includes)」および／または「含んでいる(including)」は、ここにおいて使用されるとき、述べられた特徴、整数、ステップ、動作、エレメントおよび／またはコンポーネントの存在を特定しているが、１つまたは複数の他の特徴、整数、ステップ、動作、エレメント、コンポーネント、および／または、そのグループの存在または追加を除外しない。

さらに、多くの実施形態は、例えばコンピューティングデバイスのエレメントによって実行されるべきアクションのシーケンスの観点から説明されている。ここにおいて説明される様々なアクションは、特定の回路（例えば、特定用途集積回路（ＡＳＩＣＳ））によって、１つまたは複数のプロセッサによって実行されるプログラム命令によって、または、それらの組み合わせによって、実行されることができるということが認識されるであろう。さらに、これらのここにおいて記載されているアクションのシーケンスは、実行時に、関連プロセッサにここにおいて記載されている機能を実行させる対応するセットのコンピュータ命令を格納したいずれの形態のコンピュータ可読媒体内で全体的に具現化されるとみなされることができる。したがって、本発明の様々な態様は、多数の異なる形式で具現化され、それらのすべては、特許請求された主題の事柄の範囲内にあるように予期される。さらに、ここにおいて記載された実施形態のそれぞれについて、いずれのそのような実施形態の対応する形態は、例えば記載されたアクションを実行するように「構成された論理」としてここに記載されうる。

関連の動作環境の概要に戻ると、開示された実施形態は、パブリックインターネットおよびプライベートネットワークの両方にわたるまたはその内のメッセージ／情報転送を含む従来の通信システムにおいて機能する。ＴＣＰ（送信制御プロトコル）およびＩＰ（インターネットプロトコル）は、総称的にＴＣＰ／ＩＰとして知られており、インターネットの基本通信プロトコルである。ＴＣＰ／ＩＰはしばしば「下位レイヤ」プロトコルと呼ばれる、なぜならば、他のいわゆる「高位レイヤ」アプリケーションプロトコルは、インターネットをできるようにするために、ＴＣＰ／ＩＰを一般的に使用するからである。このような高位レイヤアプリケーションプロトコルはワールドワイドウェブのハイパーテキスト転送プロトコル（ＨＴＴＰ）ｈｔｔｐ：／／ｗｈａｔｉｓ．ｔｅｃｈｔａｒｇｅｔ．ｃｏｍ／ｄｅｆｉｎｉｔｉｏｎ／０，２８９８９３，ｓｉｄ９＿ｇｃｉ２１４００４，００．ｈｔｍｌ、ファイル転送プロトコル（ＦＴＰ）、テルネット（Ｔｅｌｎｅｔ）、そしてそれはユーザに遠隔コンピュータにログオンさせる、および簡易メール転送プロトコル（ＳＭＴＰ）を含む。これらおよび他のプロトコルはしばしば、「スイート」としてＴＣＰ／ＩＰと一緒にパッケージされる。ＴＣＰ／ＩＰはパブリックインターネットおよびプライベートネットワークの両方において通信プロトコルとして使用されることができるので、仮想的にパブリックインターネットへのダイレクトアクセスを有するすべてのコンピュータおよび他の同様なデバイスはＴＣＰ／ＩＰプログラムを使用してメッセージ／情報を通信し交換する。

ＴＣＰ／ＩＰは二次レイヤプロトコルとして動作する。最上位レイヤである、ＴＣＰは、インターネット上で送信され、オリジナルメッセージにパケットをリアセンブルするＴＣＰレイヤによって受信された小さいパケットにメッセージまたはファイルをアセンブルすることを扱う(manages)。下位レイヤである、ＩＰは、それが正しい仮想目的地に着くように、各パケットのアドレス部分を扱う(handles)。ネットワーク上の各ゲートウェイコンピュータはこのアドレスをチェックして、メッセージをどこに転送するかを決定する。同じメッセージからのいくつかのパケットが他とは異なってルート指定されたとしても、パケットのすべては仮想目的地でリアセンブルされる。

高位レイヤアプリケーション（例えば、ＨＴＴＰ、ＦＴＰ等）は、コンピュータユーザ（すなわち、クライアント）が要求し、ネットワーク内の別のコンピュータ（例えば、サーバ）によってサービスを提供する（例えば、ウェブページを送信すること）通信のクライアント／サーバモデルにおいてＴＣＰ／ＩＰを利用する。ＴＣＰ／ＩＰ通信は主にポイントツーポイントである、そしてそれは、各通信がネットワーク内の１つのポイント（またはホストコンピュータ）からネットワーク内の別のポイント（またはホストコンピュータ）までであることを意味する。ＴＣＰ／ＩＰおよびそれを使用する高位レイヤアプリケーション（例えば、ＨＴＴＰ、ＦＴＰ等）は、総称的に「ステートレス」と呼ばれる、なぜならば、各クライアント要求は、（呼び出し持続時間の間専用接続を要する通常の電話の会話とは異なり）前のものと関連のない新規要求とみなされるためである。ステートレスであることは、クライアントおよびサーバがそれらを継続して使用することができるように、ネットワークパスを解放する。ＴＣＰレイヤ自体は、個々のメッセージについてステートレスではない、なぜならば、接続は、少なくともメッセージ内のすべてのパケットが受信されるのに必要な間、依然として有効でなくてはならないためである（must remain in place）。

上述の動作環境において、ＰＤＡおよびモバイルスマートフォンのようなモバイルコンピューティングデバイスは一般的に、ウェブサーバからのコンテンツにアクセスし要求し受信するウェブクライアントとしてパブリックインターネットとインタフェース接続する。しかしながら、モバイルコンピューティングデバイスの技術が向上すると、ユーザはこのようなデバイス上により多くの情報を格納し、ＩＰネットワーク上でモバイルコンピューティングデバイスにウェブクライアントをルート指定する方法を提供することがより望ましくなっている。モバイルスマートフォン、ＰＤＡ、ラップトップおよびタブレットに加え、一般的に人間ユーザによって物理的にアクセスされない他のモバイルコンピューティングデバイスがある。このようなモバイルコンピューティングデバイスの例は、家庭でヒータおよび同様なものを自動的にオンまたはオフにするトラッキングデバイス、自動メータリーダ、および制御装置を含む。これらのモバイル／遠隔コンピューティングデバイスとの通信は一般的には、マシンツーマシン（Ｍ２Ｍ）と呼ばれる、なぜならば、データを検索するためのインタフェースは一般的に別の遠隔マシンであるためである。ＩＰネットワークで動作しているモバイル／遠隔コンピューティングデバイスはいくつもの理由について通常またはランダムな時間で変更する動的に割り当てられたアドレスを一般的に有するので、パブリックインターネット上でこのようなコンピューティングデバイスからのコンテンツにルート指定しアクセスするいずれの試みも、動的に割り当てられたアドレスへのクライアントサーバインターネット接続は不安定で信頼性がない可能性があるという制約を克服しなくてはならない。

開示された実施形態は、変更できる動的に割り当てられたアドレスを有するモバイルコンピューティングデバイス（例えば、モバイルスマートフォン、ＰＤＡ、ラップトップ、タブレット、トラッキングデバイス等）へウェブクライアントを信頼してルート指定する仲介ルーティングシステムおよび方法を提供することにより、簡潔でコストパフォーマンスのよい方法で上述された限定に取り組む。開示された実施形態は、商業的に利用可能なシステムを使用し、そして既存のソフトウェアプロセッサにターゲット化され相対的に簡易に実装された構成タイプ変更を行うことによって、費用、エンジニアリングマンアワー、設計の複雑さを最小化することを支援できる。したがって、開示された仲介ルーティングシステムおよび方法は、動的にアドレス指定されたデバイスの機能およびコンテンツの両方の使用およびアクセスを許容するさまざまな有用なシステムの実装を容易にする。例えば、開示された仲介ルーティングシステムの実装は、ユーザが、ユーザの動的にアドレス指定されたデバイスに対して、ユーザ構成可能な制約にしたがって、信頼性のある遠隔アクセスをユーザに提供する。このような遠隔アクセスは、他に特別なハードウェアまたはソフトウェアを有することを要求せずに、代わりにＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）、Ｓａｆａｒｉ（登録商標）、Ｆｉｒｅｆｏｘ（登録商標）またはＣｈｒｏｍｅ（登録商標）のような従来のウェブブラウザ程度のものを要求して、達成されうる。

１つの例示的な実施形態によれば、開示された仲介ルーティングシステムおよび方法は、プライベートＩＰネットワーク内のモバイルコンピューティングデバイスがファイアウォールを通じてパブリックインターネットにワイヤレスに接続される通信システムにおいて実装される。ファイアウォールネットワークサーバは、プライベートＩＰネットワークのための従来のセキュリティ機能を実行する。開示された実施形態に関して、ファイアウォールネットワークサーバは、ここに記述される通信がパブリックインターネットにおけるコンポーネントとプライベートＩＰネットワークにおけるコンポーネントとの間に生じることを許容する従来の方法で構成される。望ましくは、ファイアウォールネットワークサーバは、モバイルコンピューティングデバイスにアクセスすることを希望するウェブクライアントによってアクセス可能な安定し信頼できる静的にアドレスされたＵＲＬを含む。一般的には従来のコンピュータ（例えば、ＰＣ、Ｍａｃまたは別のプラットフォーム）であるウェブクライアントは、パブリックインターネットに接続され、クライアントサーバセッションにおけるクライアントとしてＨＴＴＰプロトコルを介して参加するためのウェブブラウザを有する。ウェブクライアントは、ウェブクライアントに組み込まれる、またはウェブクライアントから離れたクライアントプロキシサーバを含む。クライアントローカルプロキシサーバがウェブクライアントに組み込まれる場合、単一のデバイス（例えばＰＣ、Ｍａｃ、または別のプラットフォーム）は、上述したウェブクライアント機能性および上述したクライアントローカルプロキシサーバ機能性の両方を格納する。いずれか一方のシナリオの下で、クライアントローカルプロキシサーバは、プロキシサーバソフトウェアを含み、パブリックインターネットに接続される。クライアントローカルプロキシサーバソフトウェアは、好ましくは、インターネットの基本通信プロトコルを利用する、ＴＣＰ／ＩＰ プロキシサーバソフトウェアである。好ましくは、プロキシサーバソフトウェアの機能性は、プロキシサーバソフトウェアに拡張子、スクリプト等を加えることによって容易にそして比較的安価に構成されることができる。モバイルコンピューティングデバイスは、例えば、プロセッサ、汎用動作ソフトウェア、命令メモリおよびデータメモリを有するｉＰｈｏｎｅ（登録商標）またはＢｌａｃｋｂｅｒｒｙ（登録商標）でありうる。モバイルコンピューティングデバイス、変更することができる動的に割り当てられたアドレスを有する。前に記述した汎用動作ソフトウェアに加えて、モバイルコンピューティングデバイスはさらに、モバイルコンピューティングデバイスがＨＴＭＬウェブサイトをホストし、いったん確立されるとクライアントローカルプロキシサーバを介するクライアントウェブブラウザとのクライアントサーバセッションにおいてサーバとして参加することを許容する従来のハードウェアおよびモバイルウェブサーバソフトウェア（例えば、Ａｐａｃｈｅ（登録商標））を含む。好ましくは、モバイルサーバソフトウェアは、実質的に非独自仕様である。実質的に非独自仕様という用語は、モバイルウェブサーバソフトウェアの機能がモバイルウェブサーバのソフトウェアに拡張子、スクリプトおよび同様なものを付加することによって容易にかつ相対的に安価で構成されうるということを説明するためにここでは使用される。好ましくは、モバイルウェブサーバソフトウェアはさらに、ウェブクライアントがモバイルコンピューティングデバイスコンテンツにアクセスすることを許容する十分な機能を含む。モバイルコンピューティングデバイスのモバイルウェブサーバソフトウェアとモバイルコンピューティングデバイスの汎用動作ソフトウェアとの間のインタフェースのさらなる詳細は、上記で参照されている「REMOTE MOBILE ADMINISTRATION AND LOGGING USING HTTP PROTOCOL」と題され、２０１１年３月１１日に出願され、ここでの譲受人に対して譲渡され、ここにおける参照によりここによって明示的に組み込まれた仮出願第６１／４５２，０３１号、および「REMOTE ACCESS AND ADMINISTRATION OF DEVICE CONTENT AND CONFIGURATION USING HTTP PROTOCOL」と題され、２０１２年１月１８日に出願され、ここでの譲受人に対して譲渡され、ここにおける参照によりここによって明示的に組み込まれた仮出願第６１／５８８，００７号、およびここで同時に出願され、ここでの譲受人に対して譲渡され、ここにおける参照により明示的に組み込まれた、Ａｔｔｏｒｎｅｙ Ｄｏｃｋｅｔ Ｎｏ．１０３２３４を有する、「REMOTE ACCESS AND ADMINISTRATION OF DEVICE CONTENT AND CONFIGURATION USING HTTP PROTOCOL」と題された同時係属中の米国特許出願において開示されている。

開示された仲介ルーティングシステムおよび方法によれば、次の構成は、上述された通信システムのウェブサーバソフトウェアおよびクライアントローカルプロキシサーバで実装される。開示された実施形態の特徴は、ここにおいて説明された構成が新規モバイルウェブサーバソフトウェアまたは新規プロキシサーバソフトウェアの生成を要求しない、ということである。代わりに、構成は、既存のモバイルウェブサーバソフトウェアおよび既存のプロキシサーバソフトウェアに適用される従来の拡張子、スクリプトおよび同様なものによって実装される。モバイルウェブサーバソフトウェアは、クライアントローカルプロキシサーバに対するパブリックインターネット上にモバイルコンピューティングデバイスの仮想ロケーションを固有に識別することになるデバイス識別データ（ＤＩＤ）を生成し格納し送信するように構成される。動作において、ＤＩＤは、一方（「サーチキー」）が他方（「サーチ結果」）を見つけるために使用される識別子のペアである。したがって、最低でも、ＤＩＤは、スマートフォンであるモバイルコンピューティングデバイスの場合、１０桁電話番号でありうる、デバイス識別子（すなわち、サーチキー）とともに、デバイスのＩＰアドレスのようなアドレスデータ（すなわち、サーチ結果）を含む。したがって、モバイルコンピューティングデバイスがモバイルスマートフォンである場合、モバイルデバイスＤＩＤは、モバイルデバイスの動的アドレスの現行バージョンと一緒にスマートフォンの１０桁の電話番号であることができる。デバイス識別子の他の例は、「モバイルＩＤ番号」（ＭＩＮ）、「国際モバイル加入者アイデンティティ」（ＭＤＮ）、「国際モバイル機器アイデンティティ」（ＩＭＥＩ）、またはモバイルネットワークを共有する各モバイルコンピューティングデバイスに固有であるいずれの他のＩＤを含む。開示された仲介ルーティングシステムおよび方法の下で、モバイルコンピューティングデバイスは、クライアントローカルプロキシサーバにそのＤＩＤを登録し、所定の間隔で、または、そのＤＩＤの動的アドレスコンポーネントが変更するとき、クライアントローカルプロキシサーバにそのＤＩＤの更新を送信するように構成される。

さらに開示された仲介ルーティングシステムおよび方法によれば、クライアントローカルプロキシサーバは、とくにモバイルコンピューティングデバイスＤＩＤのアドレスコンポーネントへのいずれの更新も含む、モバイルコンピューティングデバイスから受信されたＤＩＤを受信および格納するように構成される。クライアントローカルプロキシサーバは、仲介機能を実行するようにさらに構成され、それによって、モバイルコンピューティングデバイスにアクセスするためのクライアントローカルプロキシサーバにおいて受信された要求は、クライアントローカルプロキシサーバにおいて格納されたＤＩＤを使用して現在のモバイルコンピューティングデバイスアドレスへクライアントローカルプロキシサーバを通じてルート指定される。クライアントローカルプロキシサーバは、ウェブクライアントから上述された要求を一般的に受信し、そしてそれは好ましくは、通信システム上でクライアントサーバセッションのクライアント側としてサービス提供することができるいずれのハードウェア／ソフトウェアコンポーネントまたは従来のウェブブラウザ（図示されず）である。ウェブクライアントは、好ましくは、ウェブクライアントからの要求を送信するためにプロキシサーバを使用するようにそのウェブブラウザを構成することによって、クライアントローカルプロキシサーバに達する。あるいは、プロキシサーバは、モバイルコンピューティングデバイスにアクセスすることを望むウェブクライアントによってアクセス可能な静的にアドレス指定されたＵＲＬを含むように構成されることができる。プロキシサーバは、いずれの要求も取り、それをクライアントローカルプロキシサーバへ自動的に転送し（好ましくはユーザ認証後等）、そして、クライアントローカルプロキシサーバは、開示された実施形態のメカニズムを利用して、さらにモバイルコンピューティングデバイスへ要求を転送する。クライアントローカルプロキシサーバは、ウェブクライアントがＨＴＭＬ通信に使用する、並列または直接バス接続を介してそのＵＲＬ上でリッスンするようにさらに構成される。

一般に、通信ネットワークは、ウェブクライアントが他のネットワークサービスへの間接ネットワーク接続を行うことを許容することを望むとき、プロキシサーバを利用する。ウェブクライアントは、プロキシサーバへ接続し、そのあとで接続、ファイル、または異なるサーバ上で利用可能な他のリソースを要求する。そしてそれは、開示された実施形態では、モバイルコンピューティングデバイスである。ここにおいて開示されたクライアントローカルプロキシサーバは、好ましくは、拡張エンジニアリングマンアワーを必要とすることなく、（例えば、既存のプロキシサーバソフトウェアにスクリプト、拡張子等を付加することを通じて）構成されることができる。開示されたクライアントローカルプロキシサーバは、格納されたＤＩＤを使用することによってその仲介接続機能を実行するように構成され、それによって、モバイルコンピューティングデバイスにアクセスするためのクライアントローカルプロキシサーバにおいて受信された要求は、クライアントローカルプロキシサーバにおいて格納された現在のＤＩＤを使用して現在のモバイルコンピューティングデバイスアドレスへ中継される。クライアントローカルプロキシサーバは、モバイルコンピューティングデバイスウェブサーバに接続すること、または、キャッシュから要求されたリソースにサービス提供することのいずれかによって要求されたリソースを提供する。いくつかの場合では、クライアントローカルロキシサーバは、ウェブクライアントの要求またはサーバの応答をさまざまな目的のために変更しうる。

したがって、開示された実施形態のクライアントローカルプロキシサーバは、ウェブクライアントからモバイルコンピューティングデバイスへの要求の仲介者として動作する。クライアントローカルプロキシサーバは、通常変更しない少なくとも１つの静的なアドレスを含む。したがって、クライアントローカルプロキシサーバハードウェアは、さらにパブリックインターネットに接続された別のデバイス（例えば、ウェブクライアント）によって信頼してアクセスすることができる従来のウェブサーバホストデバイスの機能性を含む。上述されるように、クライアントローカルプロキシサーバは、プロキシサーバハードウェアに組み込まれたまたは別個のデバイスでありうるデータベースに沿った、プロキシサーバソフトウェアを含む。上述されるように、ウェブクライアントは、好ましくは、通信システム上のクライアントサーバセッションのクライアント側としてサービス提供することができるいずれのハードウェア／ソフトウェアコンポーネントまたは従来のウェブブラウザ（図示されず）である。ウェブクライアントは、ユーザによって動作されうる、または、それは、ＨＴＴＰ（または他の）サーバに自動的にアクセスするためにＨＴＴＰプロトコル（または他）を使用する自動化ツール／スクリプト／マシンによって動作されうる。このような自動化ツールは、「ＨＴＴＰエージェント」と通常呼ばれる。さまざまなデータフローパスは、矢印４４および４６によって図１で図示される。それらは、モバイルコンピューティングデバイス、ネットワークファイアウォールサーバ、クライアントローカルプロキシサーバ、データベースおよびウェブクライアントの間での通信を表す。

開示された実施形態による仲介ルーティングシステムおよび方法の全体の動作がこれから説明されることになる。仲介ルーティングシステムおよび方法の動作をより良く理解するために、３つのＩＰアドレスの跡を追うことは有用である。１つ目は、ＩＰアドレスが動的に割り当てられ変更することができる、モバイルコンピューティングデバイスのＩＰアドレスである。２つ目は、プライベートＩＰネットワークおよびモバイルコンピューティングデバイスにアクセスを提供するファイアウォールサーバのＩＰアドレスである。好ましくは、プライベートネットワークのファイアウォールサーバのＩＰアドレスは、モバイルデバイスにアクセスすることを望むウェブクライアントによって信頼してアクセスすることができる静的に割り当てられたＩＰアドレスである。３つ目は、ウェブクライアントにおけるクライアントローカルプロキシサーバ機能性のＩＰアドレスである。クライアントローカルプロキシサーバＩＰアドレスは、好ましくは、モバイルコンピューティングデバイスにアクセスすることを望むウェブクライアントによって信頼してアクセスすることができる静的に割り当てられたＩＰアドレスである。

開示される仲介ルーティングシステムおよび方法の全体の動作を続けて、モバイルコンピューティングデバイスにアクセスすることを望むウェブクライアントは、クライアントローカルプロキシサーバを通じて、モバイルコンピューティングデバイスを有するクライアントサーバセッションにクライアントとして参加する（好ましくは、ＨＴＴＰプロトコルを介して）要求を通信する。クライアントローカルプロキシサーバ機能性は、好ましくは、ウェブクライアントに対してローカルである。さらに、リモートウェブクライアントは、リモートウェブクライアントのウェブブラウザおよびローカルクライアントローカルプロキシサーバＩＰアドレスをリモートに使用して、クライアントローカルプロキシサーバ機能性にアクセスすることができる。ウェブクライアントの要求は、上述された「デバイス識別子」を含む。それは、クライアントローカルプロキシサーバが特定のモバイルコンピューティングデバイスを固有に識別することを許容する。例えば、モバイルコンピューティングデバイスがモバイル電話である場合、デバイス識別子は、モバイル電話の固有の１０桁の電話番号を含むことができる。要求を満たすために、クライアントローカルプロキシサーバは、モバイルコンピューティングデバイスの仮想ロケーションをただちに識別しなくてはならない。モバイルコンピューティングデバイスの仮想ロケーションを識別することは、モバイルコンピューティングデバイスのＩＰアドレスが動的であるという事実によってより複雑になるので、主に、デバイスのモビリティ、ワイヤレス接続およびその通信ネットワークの要件に関連したさまざまな理由のために任意の時間で変更することに従う。したがって、開示された仲介ルーティングシステムおよび方法によれば、モバイルコンピューティングデバイスは、モバイルコンピューティングデバイスＩＰアドレスが変更するとき、それがプライベートファイアウォールサーバを介して、またはいくつかの他の通信パスを介してクライアントローカルプロキシサーバに、そのサーチキー（すなわち、上述されたデバイス識別子）に沿って、その現在のＩＰアドレス（すなわち上述されたデバイスアドレス）の更新を送るように構成される。あるいは、モバイルコンピューティングデバイスは、ＤＩＤのＩＰアドレスコンポーネントが実際に変更したかどうかに関わらず、選択間隔でその現在のＤＩＤを送ることができる。いずれの手法の下でも、クライアントローカルプロキシサーバは、モバイルコンピューティングデバイスの現在のＩＰアドレスをＤＩＤとして受信し、格納し、そして維持する。

クライアントローカルプロキシサーバに参加するための要求を受信すると、クライアントローカルプロキシサーバは、クライアントローカルプロキシサーバに格納されたＤＩＤを要求と従来の方法で比較する。要求と格納されたＤＩＤとの間で一致がある（すなわち、要求の「サーチキー」が格納されたＤＩＤの「キー」部分に一致する）場合、クライアントローカルプロキシサーバは、格納されたＤＩＤから現在のモバイルコンピューティングデバイスアドレスを抽出し、クライアントサーバセッションの要求およびプライベートネットワークファイアウォールサーバＩＰアドレスに現在のモバイルコンピューティングデバイスＩＰアドレスを転送する。プライベートネットワークファイアウォールサーバは、モバイルコンピューティングデバイスを見つけ、モバイルコンピューティングデバイスアドレスにクライアントローカルプロキシサーバおよびウェブクライアント（それはローカルであるかリモートであるかのいずれかである）を接続するために現在のモバイルコンピューティングデバイスＩＰアドレスを使用することによって、クライアントサーバセッションを開始する。一旦クライアントサーバセッションが確立されれば、クライアントローカルプロキシサーバは、クライアントローカルプロキシサーバおよびプライベートネットワークファイアウォールサーバ通じてウェブクライアントとモバイルコンピューティングデバイスとの間の間接的なクライアントサーバセッションを行なうために従来のプロキシの仲介ルーティング技術を使用する。

従来のネットワーク動作の下で、ネットワークは、上記したようにクライアントサーバセッションがアクティブである限り、モバイルコンピューティングデバイスの動的アドレスを普通に変更するべきでない。何らかの理由で、ネットワークがクライアントサーバセッションの間にモバイルコンピューティングデバイスの動的アドレスを変更する場合、クライアントサーバセッションの再接続は、新規要求を送信するウェブクライアントを通じて開始されなくてはならない。しかしながら、このような再接続を容易にするために、現在のモバイルコンピューティングデバイスＤＩＤは、クライアントローカルプロキシサーバにおいて利用可能であるので、クライアントローカルプロキシサーバは、次の再接続要求に迅速に反応する。

したがって、開示された実施形態の仲介ルーティングシステムおよび方法は、動的にアドレス指定されたデバイスのコンテンツおよび機能の両方の使用およびアクセスを提供するためのさまざまな有用なシステムの実装を容易にする。例えば、開示された仲介ルーティングシステムの実装時に、ユーザの動的にアドレス指定されたモバイルコンピューティングデバイス（例えば、モバイルスマートフォン、ＰＤＡ、ラップトップ、タブレット等）への信頼性のある遠隔アクセスを、ユーザ構成可能な制約にしたがって、潜在的に無制限数の他のものにユーザが提供することができる幅広いシステムが実装されうる。このような遠隔アクセスは、他に特別なハードウェアまたはソフトウェアを有することを要求しないが、代わりにＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）、Ｓａｆａｒｉ（登録商標）、Ｆｉｒｅｆｏｘ（登録商標）またはＣｈｒｏｍｅ（登録商標）のような従来のウェブブラウザ程度のものを要求して、達成されうる。例示的な実施形態によるプロセスの一例では、モバイルコンピューティングデバイス上でホストされたモバイルウェブページは、例えば休暇に撮った写真のセットのような特定のコンテンツをモバイルウェブページで閲覧するブラウザにアクセス可能にする従来の方法で構成されることができる。例えば、モバイルウェブページは、「Rob’s Beach Vacation, 2010」とあらわされる従来のＨＴＭＬコーディングにしたがったテキストまたはグラフィクスを有するクリックフィールドを含むことができるであろう。モバイルコンピューティングデバイスの、この「Rob’s Beach Vacation, 2010」コンテンツにアクセスすることを願うパブリックインターネットに接続されたＰＣまたはモバイルコンピューティングデバイスにおけるユーザまたはウェブクライアントは、クライアントローカルプロキシサーバＵＲＬを、彼／彼女のウェブブラウザフィールドにタイプし、「入力」または「送信」をヒットする。クライアントローカルプロキシサーバは、ユーザによって要求された任意の認証データをウェブクライアントが入力する特定のウェブページにウェブクライアントを連れて行き、認証時に例えばモバイルコンピューティングデバイスと関連づけられた１０桁の電話番号を提供することによってモバイルコンピューティングデバイスのアクセスを要求する。クライアントローカルプロキシサーバは、上述された仲介ルーティングシステムおよび方法にしたがい、１０桁の電話番号を使用して、クライアントローカルウェブプロキシサーバで現在格納されたモバイルコンピューティングデバイスＩＰアドレスをサーチしフェッチする、そのあとで、モバイルコンピューティングデバイスと間接的なまたはバーチャルな通信にウェブクライアントＵＲＬをルート指定する。ウェブクライアントは、モバイルウェブページ「Rob’s Beach Vacation, 2010」を通じてモバイルコンピューティングデバイス上に格納された写真にすぐにアクセスしうる。

前述の概要および例から、仲介ルーティングシステムおよび方法の開示された実施形態は、他の特徴および利点のうち、仲介ルーティングシステムおよび方法を商業的に利用可能な、実質的に非独自仕様コンポーネント（例えば、モバイルコンピューティングデバイス、ウェブクライアント、ウェブブラウザなど）で実装し、これらのコンポーネントに対してターゲット化され、相対的に簡易に実装された構成を行うこと（例えば、上述されるように構成されたモバイルコンピューティングデバイスおよびプロキシサーバ機能）によって、費用、エンジニアリングマンアワー、設計の複雑さおよび独自仕様システムへのアクセスの必要を最小化することを支援することができる。

次に開示された実施形態の仲介ルーティングシステムおよび方法のより詳細な説明に戻ると、図１は、ファイアウォールサーバ３１を通じてパブリックインターネット２４と通信するプライベートＩＰネットワーク２２を含む通信システム２０を図示する。ファイアウォールサーバ３１は、プライベートＩＰネットワーク２２のための従来のセキュリティ機能をサービス提供する。開示された実施形態に関して、ファイアウォールサーバ３１は、ここに記述された通信がパブリックインターネット２４におけるコンポーネントとプライベートＩＰネットワーク２２におけるコンポーネントとの間に生じることを許容する従来の方法で構成される。ファイアウォールサーバ３１、好ましくは、変更しない静的なＩＰアドレスを有する。モバイルコンピューティングデバイス２８は、システム２０に接続し、通信する。モバイルコンピューティングデバイス２８は、セルラ電話、ハンドヘルドＰＤＡ、タブレット、ラップトップコンピュータ、トラッキングデバイスまたは同様なものでありうる、また、ワイヤレスおよび／またはハードワイヤまたはケーブルを通じて、システム２０と通信しうる。モバイルコンピューティングデバイス２８は、いったんウェブクライアント４０とモバイルコンピューティングデバイス２８との間でクライアントサーバセッションが確立されると、ウェブクライアント４０がモバイルコンピューティングデバイスのコンテンツおよび特徴に遠隔でアクセスすること（例えば、イメージ、グラフィクスおよび他の情報をモバイルコンピューティングデバイス２８から検索すること）を許容する十分な機能を有する。このようなデバイス機能の一例は、インターネットウェブサイトおよび従来のホストデバイスの機能をモバイルコンピューティングデバイス２８に提供するモバイルコンピューティングデバイスウェブサーバソフトウェア３０を含む。一般に、ウェブサイトは、ウェブサーバハードウェア上でホストされ、ウェブサーバソフトウェアはウェブサーバハードウェア上に存在する。ウェブサーバソフトウェアは、外部クライアントウェブブラウザがウェブサーバハードウェアからイメージ、グラフィクスおよび他の情報を検索するためのメカニズムを提供する。モバイルコンピューティングデバイス２８のアドレスは、動的に割り当てられうる。

図１は、単一のプライベートＩＰネットワーク２２を示すが、開示される実施形態は、パブリックインターネット２４とのインターフェースがあるいくつかのプライベートＩＰネットワーク（例えばベライゾン（踏力商標）、ＡＴ＆Ｔ（登録商標）など）を有する通信システムで実施されることができる。さらに、単一のモバイルコンピューティングデバイス２８ｈが示されるが、各プライベートＩＰネットワーク２２が多数のモバイルコンピューティングデバイスを含むことが理解される。モバイルコンピューティングデバイス２８のデバイス識別子（つまりＤＩＤの「サーチキー」コンポーネント）は、グローバルにユニークであり、モバイルコンピューティングデバイス２８のＩＰアドレス（つまり、ＤＩＤの「サーチ結果」コンポーネント）は、プライベートＩＰネットワーク２２内の全体で固有である。開示された実施形態は、通信システムで実施される。ここで、コンポーネント（モバイルコンピューティングデバイス、クライアントローカルプロキシサーバ、ウェブクライアントなど）の全ては、パブリックインターネット２４内にある。

通信システム２０は、ウェブクライアントサーバ４０でローカルに実装される、クライアントローカルプロキシサーバ機能性３２をさらに含む。クライアントローカルプロキシサーバ３２は、プロキシサーバソフトウェア３４およびデータベース３６を含む。クライアントローカルプロキシサーバ３２およびクライアントローカルプロキシサーバソフトウェア３４は、ウェブクライアント４０に組み込まれる、またはウェブクライアント４０とクライアントローカルプロキシサーバ３２、３４との間のローカル通信パス４２を有するスタンドアロンとして実装されることができる。データベース３６は、クライアントローカルプロキシサーバ３２に組み込まれる、またはクライアントローカルプロキシサーバ３２と分離されることができる。好ましくは、クライアントローカルプロキシサーバ３２は、普通変化しない静的アドレスを有する。リモートウェブクライアント４１は、通信パス４２ａによって図に示されたその静的なアドレスでクライアントローカルプロキシサーバ３２にアクセスするためにそのウェブブラウザを使用することができる。したがって、クライアントローカルプロキシサーバ３２は、パブリックインターネット２４に接続された別のデバイス（例えば、ウェブクライアント４０またはリモートウェブクライアント４１）によって信頼してアクセスすることができる従来のサーバホストデバイスの機能性を有する。さらに、クライアントローカルプロキシサーバ３２は、従来プロキシサーバの機能性を提供する。一般に、プロキシサーバは、クライアントが他のネットワークサービスに対する間接的ネットワーク接続行うことを可能にする。クライアントは、プロキシサーバに接続し、その後、接続、ファイルまたは異なるサーバ上で利用可能な他のリソースを要求する。プロキシサーバは指定されたサーバに接続すること、または、キャッシュからそれにサービス提供することのいずれかによってリソースを提供する。いくつかの場合では、プロキシサーバは、クライアントの要求またはサーバの応答をさまざまな目的のために変更しうる。

ウェブクライアント４０は、好ましくは、通信システム２０上のクライアントサーバセッションのクライアント側としてサービス提供することができるいずれのハードウェア／ソフトウェアコンポーネントまたは従来のウェブブラウザ（図示である）である。ウェブクライアント４０は、ユーザによって動作されうる、または、それは、ＨＴＴＰ（または他の）サーバに自動的にアクセスするためにＨＴＴＰプロトコル（または他）を使用する自動化ツール／スクリプト／マシンによって動作されうる。このような自動化ツールは、「ＨＴＴＰエージェント」と通常呼ばれる。さまざまなデータフローパスは、矢印４２、４４および４６によって図１で図示され、そしてそれらは、モバイルコンピューティングデバイス２８、３０、クライアントローカルプロキシサーバ３２、３４、データベース３６、ウェブクライアント４０、およびリモートウェブクライアント４１の間での通信を表す。

開示された実施形態のシステムおよび方法は、ウェブクライアント４０（またはリモートウェブクライアント４１）と動的に割り当てられたアドレスを有するモバイルコンピューティングデバイス（例えば、モバイルコンピューティングデバイス２８）との間のデータパスを信頼して開く。開示されたシステムおよび方法の重要な態様は、コンポーネント（例えば、モバイルコンピューティングデバイス、モバイルウェブサーバソフトウェア、データベース、ウェブクライアントブラウザ等）の多くが商業的に利用可能な既製のアイテムであるということである。開示された実施形態は、コンポーネントを選択するためにある構成タイプ変更を必要とし、そのような構成（例えば、方法５０、７０）の例は、図２および図３で図示化される。しかしながら、開示された構成変更によって提供される追加された機能は、ターゲット化され、関連技術分野の当業者の能力の内にある既知の設計技法（例えば、既存ソフトウェアに拡張子、スクリプト、および同様なものを付加すること）を通じて実装されうる。

開示された実施形態によれば、モバイルコンピューティングデバイスウェブサーバソフトウェア３０は、図２のモバイルコンピューティングデバイス方法５０によって図示された機能を含むように構成され、それによって、モバイルコンピューティングデバイス２８は、モバイルコンピューティングデバイスの現在のＩＰアドレスおよびデバイス識別子を含むＤＩＤ（「デバイス識別データ」と前述される）をクライアントローカルプロキシサーバハードウェア３２へ通信する。クライアントローカルプロキシサーバハードウェア３２はクライアントローカルプロキシサーバ方法７０（図２でも図示されている）によって図示された機能を提供するように構成されたクライアントローカルプロキシサーバソフトウェア３４を含み、それによって、クライアントローカルプロキシサーバハードウェア３２は、モバイルコンピューティングデバイスのＩＰアドレスを含む周期的に更新されたＤＩＤをモバイルコンピューティングデバイス２８から受信する。クライアントローカルプロキシサーバハードウェア３２は、データベース３６にモバイルコンピューティングデバイス２８の現在のＤＩＤを格納する。上述されるように、ＤＩＤはまた、デバイス識別子（または「サーチキー」）を含み、そしてそれは簡単に覚えられタイプされる従来の識別子であることができ（例えば、「ｊｏｈｎｄｏｅｐｈｏｎｅ」、または「５５５−１２３−４５６７」）、ウェブサイトドメイン名と同様に機能する。クライアントローカルプロキシサーバ３２は、パブリックインターネット２４内のウェブクライアント４０とプライベートＩＰネットワーク２２内のモバイルコンピューティングデバイス２８（ならびに他のプライベートＩＰネットワーク内の他のモバイルコンピューティングデバイス‐図示されず）の間でインタフェース接続するので、デバイス識別子はグローバルに固有である。クライアントローカルプロキシサーバ３２は、ウェブクライアント４０またはリモートウェブクライアント４１からアクセス・デバイス２８に対して要求（典型的にウェブクライアントブラウザによる）を受信することができるＵＲＬ（図示せず）を含んでいる。クライアントローカルプロキシサーバ３２は、ウェブクライアント４０に組み込まれる、または（ワイヤードまたはワイヤレスである）ローカルデータ通信パス４２を介してウェブクライアントと通信するように、ウェブクライアント４０にローカルに位置することができる。さらに、クライアントローカルプロキシサーバ３２は、静的なアドレスを有し、そしてそれは、リモートウェブクライアント４１がクライアントローカルプロキシサーバに対する信頼できるインターネット接続を確立することを可能にする。

次に図２に戻ると、モバイルコンピューティングデバイス方法５０およびクライアントローカルプロキシサーバ方法７０のインタラクションおよび動作を図示する説明のためのフローチャートがある。方法５０、７０は、直接ハードウェアで、プロセッサによって実行されるソフトウェアモジュールで（例えば、仮想マシンまたはスクリプトインタプリタで実行しているスクリプト）、またはそれらのいずれの組み合わせで具現化されうる。方法５０は、モバイルコンピューティングデバイス２８内のモバイルコンピューティングデバイスウェブサーバソフトウェア３０によって実装され、方法７０は、クライアントローカルプロキシサーバ３２内のクライアントローカルプロキシサーバソフトウェア３４によって実装される。図２で図示されるように、方法５０のブロック５２で、モバイルコンピューティングデバイス２８は、図１で図示される通信システム２０内のネットワークエンティティからデバイスアドレス（ＤＡ）を従来の方法で受信する。例えばシステム２０がＣＤＭＡネットワークを含む場合、ＤＡは、パケットデータサービングノード（ＰＤＳＮ）（図示されず）によって割り当てられたデバイスＩＰアドレスであるであろう。ブロック５４における方法５０は、そのデバイスについての固有デバイス識別子（ＤＩ）とデバイスアドレス（ＤＡ）を含むＤＩＤを生成する。固有デバイス識別子（「サーチキー」と前述されている）は簡単に覚えられタイプされる従来の識別子であることができ（例えば、「ｊｏｈｎｄｏｅｐｈｏｎｅ」または「５５５−１２３−４５６７」）、ウェブサイトドメイン名と同様に機能することができる。ブロック５６は、クライアントローカルプロキシサーバ３２へ通信パス５８を介してＤＩＤを送信する。図２の通信パス５８は、モバイルコンピューティングデバイス２８、３０からクライアントローカルプロキシサーバ３２、３４へとＤＩＤをパスするためのさまざまな方法の仮想表示である。例えば、通信パス５８は図１で図示されたデータフローパス４４によって確立された通信リンクを介して実装されることができるであろう。あるいは、通信パス５８は、小さい「自動化」ウェブクライアントをモバイルコンピューティングデバイスに実行させることによって、また、クライアントローカルプロキシサーバにＤＩＤを通信するためにその自動化ウェブクライアントを使用して、達成されることができるであろう。自動化ウェブクライアントはクライアントローカルプロキシサーバにおいて指定されたページにブラウズすることができ、そのページは、「あなたのＤＩＤを提出し、提出（ＳＵＢＭＩＴ）ボタンを押してください」とモバイルコンピューティングデバイスに尋ねるフォームを含む。自動化ウェブクライアントはそのフォームに「記入」して提出を押す。クライアントローカルプロキシサーバは、そのあとでＤＩＤを受信しそれを格納する。方法５０は、モバイルコンピューティングデバイス２８、３０が更新されたデバイスアドレスを受信したかを決定ブロック６０で問い合わせる。方法５０が、新規デバイスアドレスが受信しなかったということを決定ブロック６０で決定する場合、方法はブロック６０への入力に戻り、問い合わせを繰り返す。方法５０が、新規デバイスアドレスが受信されたということを決定ブロック６０で決定するとき、方法は、ブロック５４への入力に戻り、更新されたデバイスアドレスを含む新規ＩＤを生成し、クライアントローカルプロキシサーバ３２、３４へ更新されたＤＩＤを、通信パス５８を介して送信する。決定ブロック６０は、ＤＡが実際に変更したかを検出する、または、ＤＩＤのＤＡコンポーネントが実際に変更されなかったとしても、クライアントローカルプロキシサーバ３２、３４にＤＩＤを周期的に更新し送信するタイマ機能に基づく、のようなさまざまな方法でトリガされうる。

次にクライアントローカルプロキシサーバ方法７０に戻ると、方法７０は、見出し「ＤＩＤを格納する」および「位置づけおよびリダイレクト」の下に図で識別された２つの主要コンポーネントを含む。方法７０の格納ＤＩＤコンポーネントでは、ブロック７２は、モバイルコンピューティングデバイス２８からのＤＩＤを含むさまざまなモバイルコンピューティングデバイスから現在および更新されたＤＩＤを、通信パス５８を介して受信する。ブロック７２で受信されたＤＩＤは、クライアントローカルプロキシサーバ３２、３４と通信するさまざまなモバイルコンピューティングデバイスの各々のための現在のおよび更新されたアドレス（ＤＡ）および固有のデバイス識別子（ＤＩ）を含む。ブロック７４は、データベース３６に受信されたＤＩＤを格納し、そのあとで、ブロック７６で任意のＤＩＤ更新を受信するために待機する。決定ブロック７８は、更新されたＤＩＤが受信されたかを決定するためにチェックする。更新されたＤＩＤが受信されなかった場合には、方法７０は、ブロック７６への入力に戻り、ＤＩＤ更新を待機する。決定ブロック７８で更新されたＤＩＤが受信された場合、方法７０は、ブロック７４への入力に戻り、データベース３６に受信された更新されたＤＩＤを格納する。

次に方法７０の「位置づけおよび転送」部分に戻ると、クライアントローカルプロキシサーバ３２、３４は、モバイルコンピューティングデバイスにアクセスするためウェブクライアントから（一般的にはウェブクライアントのブラウザを介して）要求を受信するためにポータルまたは仮想ロケーションまたはＵＲＬとして機能する「スタート」または「ホーム」ウェブページ（図示されず）を含む。クライアントローカルプロキシサーバスタートページは、静的アドレスを有し、そしてそれは、ウェブクライアント４０がクライアントローカルプロキシサーバへのインターネット接続を信頼して一貫して確立することを許容する。方法７０は、モバイルコンピューティングデバイスにアクセスするための要求がクライアントローカルプロキシサーバスタートページにおいて受信されたかどうかを決定ブロック８０で評価する。要求が受信されなかった場合には、決定ブロック８０は、その入力に戻り、問い合わせを繰り返す。モバイルコンピューティングデバイスにアクセスするための要求が決定ブロック８０で受信された場合、開示された実施形態によるブロック８２は、要求からデバイス識別子を抽出し、データベース３６をサーチして、（データベース３６を介して）クライアントローカルプロキシサーバ３２に格納されたＤＩＤと抽出されたデバイス識別子を比較する。方法７０は、抽出されたデバイス識別子が格納されたＤＩＤエントリに一致するかどうかを決定ブロック８４で評価する。一致が見つからない場合には、ブロック８６は、失敗報告を生成し、決定ブロック８０への入力に戻る。決定ブロック８４で、抽出されたデバイス識別子が格納されたＤＩＤエントリに一致する場合には、ブロック８８は、ファイアウォールを介して要求者（例えば、ウェブクライアントと４０またはリモートウェブクライアント４１）からモバイルコンピューティングデバイスウェブサーバ２８、３０への通信パスを開くために、一致したＤＩＤのデバイスアドレスコンポーネントを使用する。仲介の、クライアントローカルプロキシサーバとして動作することは、クライアントローカルプロキシサーバＵＲＬ「スタート」または「ホーム」ページの静的なアドレスからモバイルコンピューティングデバイス２８の現在格納されるアドレスに要求を中継する。したがって、方法５０および７０はともに機能して、プライベートＩＰネットワーク２２内のモバイルコンピューティングデバイス（例えば、モバイルコンピューティングデバイス２８）の各割り当てられたアドレスの現行バージョンは、データベース３６で利用可能であるということを確実にする。

ブロック８８における仲介動作は、開示される実施形態の下で新規の方法で適用され、限定されないが以下の方法を含む、様々な方法で実施される。

ａ．クライアントローカルプロキシサーバは、「現状のまま」でという要求を通過（pass）させることができる（したがって「トランスペアレントな」プロキシである）。

ｂ．クライアントローカルプロキシサーバは、そのコンテンツに依存して要求を翻訳することができる：例えば、「ｍｙ＿ｌｏｎｇ＿ｕｒｌ＿ｎａｍｅ．ｈｔｍｌ」から「ｐ１２．ｈｔｍ」へ。そのような翻訳は、応答コンテンツのさらなる編集を要求することがある。

ｃ．クライアントローカルプロキシサーバは、それらのコンテンツに依存する要求をフィルタに掛けることができる：例えば、「ｉｎｄｅｘ．ｈｔｍｌ」の要求を許可するが、「ｄａｔａ．ｔｘｔ」の要求を拒否する。

ｄ．クライアントローカルプロキシサーバは、それらのコンテンツに依存する要求をルート指定することができる：例えば、異なるエンドウェブサーバに要求を送るがモバイルウェブサーバに送る必要がない。これは、要求がモバイルウェブサーバからのみ応答されるように見えることをもたらすのだが、実際にはいくつかのソースから応答される。このアプローチを使用する利点は、以下のものを含む：

（ｉ） より下位のネットワーク使用：モバイル特有ではないデータ、またはまれに変更されるデータは、任意のウェブサーバにおいて格納され、例えば、画像およびクライアント側のスクリプトのための、モバイル帯域幅を使用しないで検索される。

（ｉｉ） 履歴データまたはオフラインデータを格納する：あるデータは、モバイルメモリからセブ（ｓｅｂ）サーバに移動することができる（例えば、古い記録）。要求された場合、このデータは、オフラインサーバから検索され、ウェブサーバから検索されないことができる。さらに、そのような記録は、モバイルコンピューティングデバイスが電源を切られるまたはネットワークカバレージ内にいない場合でさえも利用可能である。

図３は、図１に示される実施形態によって実行される動作ステップのより詳細な例である。この例において、クライアントローカルプロキシサーバは、ＴＣＰ／ＩＰ プロキシサーバである。図３に示される動作ステップは、１乃至１５の番号が付されている。

ステップ１ − モバイルデバイスはＩＰアドレスを割り当てられる。このことは、特定のネットワークの必要性によって決定されるときに、さまざまな時間で、そしてモバイルデバイスが電源を入れられた後で行われる。したがって、ＩＰアドレスは、時間ごとに変更できる。図３では、ＩＰアドレスは、「１．２．３．４」と表わされる。これは実際のＩＰアドレスではなく、説明の目的のためだけにこの例において使用される。ここにおいて開示された例がＩＰｖ４アドレスフォーマットを使用しているにも関わらず、開示された実施形態もまた、ＩＰｖ６のような他のアドレッシングスキームに適用する。

ステップ２ − モバイルデバイスは図２で示されている方法（５０）を実装して、モバイルデバイスのＤＩＤ（「デバイス識別データ」と前述されている）の更新をクライアントローカルＴＣＰ／ＩＰプロキシサーバに送る。この例では、モバイルデバイスＤＩＤは、モバイルＩＤ（「デバイス識別子」と前述されている）および新規ＩＰアドレスを含む。ステップ２は、いくつかの方法で達成されうる。例えば、モバイルデバイスは、ＨＴＴＰプロトコルを使用してクライアントローカルＴＣＰ／ＩＰプロキシサーバと通信することができる、したがって、ＨＴＴＰ「ＰＯＳＴ」または「ＧＥＴ」の方法を使用して情報を提出することができるであろう。ウェブサーバ側スクリプティングを使用するクライアントローカルＴＣＰ／ＩＰプロキシサーバは、データベース（ＤＢ）にこの情報を格納するであろう。あるいは、モバイルデバイスは、ＩＰ通信に基づいて独自仕様プロトコルを使用してＤＢと通信することができるであろう。

ステップ３ − パブリックインターネットのユーザは、ウェブブラウザをアクティブ化し、モバイルＩＤ、例えば、「５５５１２３１２３５４」と同様に、クライアントローカルＴＣＰ／ＩＰプロキシサーバの「プロキシポート」（例えば、「ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｉｃｅ．ｃｏｍ」）をタイプし、「入力」をクリックする。

ステップ４ − （ウェブブラウザの内、の下で、または関連して起動しプロキシポートをリッスンする）クライアントローカルＴＣＰ／ＩＰプロキシサーバは、ユーザ入力を検出する。クライアントローカルＴＣＰ／ＩＰプロキシサーバがウェブクライアントに組み込まれる場合、プロキシサーバの機能性は、ウェブブラウザ自身の修正を必要としないようにインストールされ、ＴＣＰ／ＩＰプロキシサーバがローカルであることを知る必要がないことに注意すべきである。

ステップ５ − ウェブブラウザとＴＣＰ／ＩＰプロキシサーバとの間の「接続」が確立される。

ステップ６ − ウェブブラウザは、ＴＣＰ／ＩＰプロキシサーバにＨＴＴＰ ＧＥＴ要求を「送る」。クライアントローカルＴＣＰ／ＩＰプロキシサーバは、ＨＴＴＰ ＧＥＴ要求からモバイルＩＤを抽出し、ＤＢにクエリするためにそれを使用し、モバイルＩＤをモバイルＩＤアドレスに変換する。

ステップ７、８、９および１０ − クライアントローカルプロキシサーバは、ＨＴＴＰ ＧＥＴ要求をモバイルウェブサーバに送り、要求されたコンテンツは、モバイルウェブサーバからクライアントローカルＴＣＰ／ＩＰプロキシサーバに送られる。これは、いくつかの従来の方法で行われることができるであろう。

ａ．クライアントローカルプロキシサーバは、要求を「そのまま（ａｓ−ｉｓ）」通過（pass）させることができる：したがって、「トランスパレント」プロキシとして動作する。

ｂ．クライアントローカルプロキシサーバは、要求をそのコンテンツに依存して変換することができる：例えば「ｍｙ＿ｌｏｎｇ＿ｕｒｌ＿ｎａｍｅ．ｈｔｍｌ」から「ｐ１２．ｈｔｍ」に変換することができる。このような変換は、返答コンテンツのさらなる編集を要求することがある。

ｃ．クライアントローカルプロキシサーバは、要求をそれらのコンテンツに依存してフィルタすることができる：例えば、「ｉｎｄｅｘ．ｈｔｍｌ」についての要求を許可し、「ｄａｔａ．ｔｘｔ」に関する要求を拒否する。

ｄ．クライアントローカルプロキシサーバは、要求をそれらのコンテンツに依存してルート指定することができる：例えば、異なるエンドウェブサーバに要求を送信し、必ずしもモバイルウェブサーバに送信しない。このことは、要求がモバイルウェブサーバのみから返答されることをもたらし、実際にはそれはいくつかのソースから返答されている。このアプローチを使用する利点は以下のものを含む：
（ｉ）より低いネットワーク使用量： モバイル−特有でないデータ、またはまれに変更されるデータは、任意のウェブサーバにおいて格納されることができ、例えばピクチャおよびクライアント側スクリプトのようなモバイル帯域幅を使用することなく検索されることができる。

（ｉｉ）履歴またはオフラインデータを格納する：いくらかのデータは、モバイルメモリからウェブサーバ（例えば、古い記録）へ移動されることができる。要求されたとき、このデータは、モバイルのウェブサーバではなくオフラインサーバから検索されることができる。また、このような記録は、モバイルデバイスが電源が入れられていない、または、ネットワークカバレッジ内にない場合でさえも利用可能であることになる。

ステップ１１ − ＴＣＰ／ＩＰ プロキシサーバは、ウェブクライアントに要求されたコンテンツ（「そのまま」あるいは変更されたのいずれか）を返送する。ウェブクライアントのユーザにとって、エクスペリエンスは、シームレスである。

ステップ１２、１３、１４および１５−ウェブクライアントは、ＴＣＰ／ＩＰプロキシサーバがモバイルウェブサーバに転送するという別のＨＴＴＰ要求を発行する。モバイルウェブサーバからの返答は、その後で、ウェブクライアントへ転送される。

上述された特定のステップ２および７乃至１０は、ユーザが「シームレス」な方法で動的に変更することができるＩＰアドレスを有するモバイルウェブサーバにコンタクトすることを可能にするということに留意されたい。ウェブクライアントは、（プロキシサーバ機能性以外の）特別なカスタム化を必要とせず、また、ユーザのモバイルウェブサーバとのインタラクションは静的ウェブサイトにおける一般的な経験とまったく変わりはないので、ユーザエクスペリエンスは「ナチュラル」である。

前述の開示は、本発明の説明のための実施形態を示しており、様々な変更および修正は、特許請求の範囲によって規定されているような本発明の範囲から逸脱することなくここにおいてなされることができるということに留意されるべきである。例えば、ここにおいて記載される本発明の実施形態による方法の請求項の機能、ステップ、および／またはアクションは、いずれの特定の順序で実行される必要はない。さらに、本発明の構成要素は、単数形で説明または特許請求されているが、単数形の限定が明示的に述べられていない限り、複数形が意図されている。

さらに、ここにおいて説明される「ユーザ」は、人間のオペレータ、および、ＨＴＴＰ（または他の）サーバに自動的にアクセスするためにＨＴＴＰプロトコル（または他）を使用する自動化ツール／スクリプト／マシンの両方を含む。このような自動化されたツールは、「ＨＴＴＰエージェント」と通常呼ばれる。

「ＩＰアドレス」という用語は、どのようにパブリックインターネットがホストデバイスを識別するかを説明するためにその最も広い意味で使用される。したがって、ＩＰアドレスという用語は、現在知られているインターネット上でデバイスを識別する方法、ならびに、今後開発および／または使用されうるデバイス識別方法を含む。また、覚えやすいＤＩＤを有するデバイス識別子を含むことが有益である一方で、デバイスアドレスがデバイス識別子で結合されることは必要要件ではない。

モバイルコンピューティングデバイスのＩＰアドレスが割り当てられるまたは変更されるときに、モバイルコンピューティングデバイス２８は、クライアントローカルプロキシサーバ３２を更新する。あるいは、デバイスアドレスが割り当てられるまたは変更されるとき、アドレスを割り当てるネットワークエンティティは、クライアントローカルプロキシサーバ３２を更新することができる。

図３の具体的な例は、デバイス識別子としてモバイルｉｄ番号（例えば、「５５５−１２３−１２３４」）を使用する。デバイスＩＤのより複雑なスキームは、２つ（またはそれより多い）の階層で使用されることができる。システムにおいてデータベース（例えば、データベース３６）を使用して、次のスキームが実装されることができるであろう：
１．モバイルモバイルコンピューティングデバイスは、そのアドレスおよびデバイス識別子でデータベースを更新する、そしてそれは「モバイルＩＤ番号」（ＭＩＮ）；「国際モバイル加入者アイデンティティ」（ＭＤＮ）；「国際モバイル機器アイデンティティ」（ＩＭＥＩ）；モバイルネットワークを共有するモバイルデバイスに固有であるいずれの他のＩＤであることができる、または、

２．ユーザが、いずれの種類のＩＤ（例えば、「ユーザ名」および「パスワード」）を使用して、クライアントローカルプロキシサーバＵＲＬに接続するとき、そのＩＤは、モバイルデバイスのＩＰアドレスに変換されることができる。

さらに当業者は、情報と信号が様々な異なる方法および技法のうちのいずれかを使用して表わされうるということを理解するであろう。例えば、上記の説明の全体にわたって参照されうる、データ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場あるいは磁粒子、光場あるいは光学粒子、あるいはそれらのいずれの組み合わせ、によって表わされうる。

当業者は、ここに開示された実施形態に関連して説明された、様々な説明のための論理ブロック、モジュール、回路、および、アルゴリズムステップは、電子ハードウェア、コンピュータソフトウェアあるいは両方の組合せとして実装されうる、ということをさらに理解するであろう。このハードウェアとソフトウェアの互換性を明瞭に説明するために、様々な説明のためのコンポーネント、ブロック、モジュール、回路およびステップが、一般に、それらの機能性という観点から、上述されてきた。そのような機能が、ハードウェアまたはソフトウェアとして実装されるかどうかは、特定のアプリケーションと全体のシステムに課された設計制約によって決まる。当業者は、各特定のアプリケーションについての様々な方法で、説明された機能性を実装しうるが、そのような実装の決定は、本発明の範囲からの逸脱を生じさせるものとして解釈されるべきでない。

ここにおいて開示された実施形態に関して記載された方法、シーケンスおよび／またはアルゴリズムは、直接ハードウェアにおいて、プロセッサによって実行されるソフトウェアモジュールにおいて、または、それらの２つの組み合わせにおいて、具現化されうる。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭあるいは当技術分野において知られているいずれの他の形態の記憶媒体、において存在しうる。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取ることができ、また記憶媒体に情報を書き込むことができるように、プロセッサに結合される。あるいは、記憶媒体は、プロセッサに一体化されうる。したがって、本発明の実施形態は、開示され、特許請求された実施形態を実行するための方法を具現化するコンピュータ可読媒体を含むことができる。したがって、本発明は、説明された例に限定されておらず、ここにおいて説明された機能を実行するためのいずれの手段も本発明の実施形態に含まれる。

ここにおいて開示された実施形態に関して記載された方法、シーケンスおよび／またはアルゴリズムは、直接ハードウェアにおいて、プロセッサによって実行されるソフトウェアモジュールにおいて、または、それらの２つの組み合わせにおいて、具現化されうる。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭあるいは当技術分野において知られているいずれの他の形態の記憶媒体、において存在しうる。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取ることができ、また記憶媒体に情報を書き込むことができるように、プロセッサに結合される。あるいは、記憶媒体は、プロセッサに一体化されうる。したがって、本発明の実施形態は、開示され、特許請求された実施形態を実行するための方法を具現化するコンピュータ可読媒体を含むことができる。したがって、本発明は、説明された例に限定されておらず、ここにおいて説明された機能を実行するためのいずれの手段も本発明の実施形態に含まれる。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
割り当てられたアドレスを有するデバイスにアクセスする方法であって、
メモリロケーションに前記割り当てられたアドレスを格納することと、
前記デバイスにアクセスするための要求をクライアントローカルプロキシサーバにおいて受信することと、
ここで、前記要求は、前記デバイスを固有に識別するデバイス識別子を備える、
前記デバイスにアクセスするための前記要求に応じて、前記デバイス識別子に基づいて前記デバイスの格納されたアドレスを識別することと
を備え、前記プロキシサーバは、前記要求の送信者と前記格納されたアドレスとの間のデータパスを確立するために仲介者として動作する、方法。
［Ｃ２］
前記割り当てられたアドレスは、動的に割り当てられたアドレスを備え、
更新された動的に割り当てられたアドレスを受信し、前記メモリロケーションに格納することをさらに備える、Ｃ１に記載の方法。
［Ｃ３］
前記デバイス識別子は、電話番号、モバイルＩＤ番号、国際モバイル加入者アイデンティティ、または国際モバイル機器アイデンティティを備える、Ｃ２に記載の方法。
［Ｃ４］
前記クライアントプロキシサーバは、ＴＣＰ／ＩＰプロキシサーバを備える、Ｃ１に記載の方法。
［Ｃ５］
前記クライアントローカルプロキシサーバは、静的なアドレスを有するＵＲＬを備え、
前記要求は、前記ＵＲＬにおいて受信される、Ｃ１に記載の方法。
［Ｃ６］
前記デバイスは、ウェブサーバソフトウェアを有するモバイルデバイスを備え、
前記データパスは、クライアントサーバセッションを備える、Ｃ１に記載の方法。
［Ｃ７］
ネットワーク上の前記デバイスの仮想ロケーションを識別する割り当てられたアドレスをデバイスにおいて受信することと、
ここで、前記デバイスは、ウェブクライアントから前記デバイスにアクセスする要求を受信するクライアントローカルプロキシサーバに前記受信した割り当てられたアドレスを送信するように構成され、
前記要求は、前記デバイスを固有に識別するデバイス識別子を備える、
前記ウェブクライアントと前記デバイスとの間の仲介者として動作する、前記割り当てられたアドレスを使用する前記クライアントプロキシサーバによって確立された通信パスを通じて前記デバイスから前記ウェブクライアントへデータを配信することとを備える、方法。
［Ｃ８］
前記割り当てられたアドレスは、動的に割り当てられたアドレスを備え、
前記割り当てられたアドレスに応じて更新された割り当てられたアドレスを前記クライアントローカルプロキシサーバに送信することを備える、Ｃ７に記載の方法。
［Ｃ９］
電話番号、モバイルＩＤ番号、国際モバイル加入者アイデンティティまたは国際モバイル機器アイデンティティを備える、Ｃ２に記載の方法。
［Ｃ１０］
前記デバイスは、ウェブソフトウェアを有するモバイルデバイスを備え、
前記通信パスは、クライアントサーバセッションを備える、Ｃ７に記載の方法。
［Ｃ１１］
デバイスに通信パスを開けるための装置であって、
前記デバイスに割り当てられたアドレスを受信し、メモリロケーションに前記割り当てられたアドレスを格納するクライアントローカルプロキシサーバを備え、
前記クライアントローカルサーバは、前記デバイスにアクセスするための要求を受信するＵＲＬを含み、
前記要求は、前記デバイスを固有に識別するデバイス識別子を備え、
前記デバイスにアクセスするための前記要求に応じて、前記クライアントローカルプロキシサーバは、前記デバイス識別子に基づいて前記デバイスの格納されたアドレスを識別し、前記要求の送信者と前記格納された割り当てられたアドレスとの間の通信パスを開くために仲介者として動作する、装置。
［Ｃ１２］
前記デバイスは、ウェブサーバソフトウェアを有するモバイルデバイスを備え、
前記通信パスは、クライアントサーバセッションを備える、Ｃ１１に記載の装置。
［Ｃ１３］
前記クライアントローカルプロキシサーバは、ウェブプロキシサーバソフトウェアを備え、
前記ウェブプロキシサーバソフトウェアは、前記デバイス識別子に基づいて前記デバイスの格納された割り当てられたアドレスを識別し、前記要求の送信者と前記格納され割り当てられたアドレスとの間の前記通信パスを開くように構成される、Ｃ１１に記載の装置。
［Ｃ１４］
ネットワーク上の前記デバイスの仮想位置を識別する割り当てられたアドレスを受信するデバイスを備え、
前記デバイスは、ウェブクライアントから前記デバイスにアクセスするための要求を受信するクライアントローカルプロキシサーバに前記割り当てられたアドレスを送信するように構成された商業的に利用可能な、実質的に非独自仕様モバイルウェブサーバを備え、
前記要求は、前記デバイスを固有に識別するデバイス識別子を備え、
前記モバイルウェブサーバソフトウェアは、前記割り当てられたアドレスに基づいて前記ウェブクライアントと前記デバイスとの間の仲介者として動作する前記クライアントローカルプロキシサーバによって確立された通信パスを通じて前記デバイスから前記クライアントへのデータを配信するようにさらに構成される、システム。
［Ｃ１５］
前記モバイルウェブサーバソフトウェアは、前記割り当てられたアドレスを変更することに応じて前記割り当てられたアドレスの更新を前記クライアントローカルプロキシサーバに送信するようにさらに構成される、Ｃ１４に記載のシステム。
［Ｃ１６］
前記モバイルウェブサーバソフトウェアは、
前記割り当てられたアドレスを前記デバイス識別子と結び付け、
前記クライアントローカルプロキシサーバに前記デバイス識別子および前記割り当てられたアドレスを送信するようにさらに構成される、Ｃ１５に記載のシステム。
［Ｃ１７］
前記通信リンクは、クライアントサーバセッションを備える、Ｃ１６に記載のシステム。
［Ｃ１８］
前記ウェブクライアントは、前記クライアントサーバセッションからリモートに位置付けられたリモートウェブクライアントを備える、Ｃ１６に記載のシステム。

Claims (18)

1. 割り当てられたアドレスを有するデバイスにアクセスする方法であって、
   メモリロケーションに前記割り当てられたアドレスを格納することと、
   前記デバイスにアクセスするための要求をクライアントローカルプロキシサーバにおいて受信することと、
   ここで、前記要求は、前記デバイスを固有に識別するデバイス識別子を備える、
   前記デバイスにアクセスするための前記要求に応じて、前記デバイス識別子に基づいて前記デバイスの格納されたアドレスを識別することと
   を備え、前記プロキシサーバは、前記要求の送信者と前記格納されたアドレスとの間のデータパスを確立するために仲介者として動作する、
   方法。
2. 前記割り当てられたアドレスは、動的に割り当てられたアドレスを備え、
   更新された動的に割り当てられたアドレスを受信し、前記メモリロケーションに格納することをさらに備える、
   請求項１に記載の方法。
3. 前記デバイス識別子は、電話番号、モバイルＩＤ番号、国際モバイル加入者アイデンティティ、または国際モバイル機器アイデンティティを備える、
   請求項２に記載の方法。
4. 前記クライアントプロキシサーバは、ＴＣＰ／ＩＰプロキシサーバを備える、
   請求項１に記載の方法。
5. 前記クライアントローカルプロキシサーバは、静的なアドレスを有するＵＲＬを備え、
   前記要求は、前記ＵＲＬにおいて受信される、
   請求項１に記載の方法。
6. 前記デバイスは、ウェブサーバソフトウェアを有するモバイルデバイスを備え、
   前記データパスは、クライアントサーバセッションを備える、
   請求項１に記載の方法。
7. ネットワーク上の前記デバイスの仮想ロケーションを識別する割り当てられたアドレスをデバイスにおいて受信することと、
   ここで、前記デバイスは、ウェブクライアントから前記デバイスにアクセスする要求を受信するクライアントローカルプロキシサーバに前記受信した割り当てられたアドレスを送信するように構成され、
   前記要求は、前記デバイスを固有に識別するデバイス識別子を備える、
   前記ウェブクライアントと前記デバイスとの間の仲介者として動作する、前記割り当てられたアドレスを使用する前記クライアントプロキシサーバによって確立された通信パスを通じて前記デバイスから前記ウェブクライアントへデータを配信することと
   を備える、方法。
8. 前記割り当てられたアドレスは、動的に割り当てられたアドレスを備え、
   前記割り当てられたアドレスに応じて更新された割り当てられたアドレスを前記クライアントローカルプロキシサーバに送信することを備える、
   請求項７に記載の方法。
9. 電話番号、モバイルＩＤ番号、国際モバイル加入者アイデンティティまたは国際モバイル機器アイデンティティを備える、
   請求項２に記載の方法。
10. 前記デバイスは、ウェブソフトウェアを有するモバイルデバイスを備え、
    前記通信パスは、クライアントサーバセッションを備える、
    請求項７に記載の方法。
11. デバイスに通信パスを開けるための装置であって、
    前記デバイスに割り当てられたアドレスを受信し、メモリロケーションに前記割り当てられたアドレスを格納するクライアントローカルプロキシサーバを備え、
    前記クライアントローカルサーバは、前記デバイスにアクセスするための要求を受信するＵＲＬを含み、
    前記要求は、前記デバイスを固有に識別するデバイス識別子を備え、
    前記デバイスにアクセスするための前記要求に応じて、前記クライアントローカルプロキシサーバは、前記デバイス識別子に基づいて前記デバイスの格納されたアドレスを識別し、前記要求の送信者と前記格納された割り当てられたアドレスとの間の通信パスを開くために仲介者として動作する、
    装置。
12. 前記デバイスは、ウェブサーバソフトウェアを有するモバイルデバイスを備え、
    前記通信パスは、クライアントサーバセッションを備える、
    請求項１１に記載の装置。
13. 前記クライアントローカルプロキシサーバは、ウェブプロキシサーバソフトウェアを備え、
    前記ウェブプロキシサーバソフトウェアは、前記デバイス識別子に基づいて前記デバイスの格納された割り当てられたアドレスを識別し、前記要求の送信者と前記格納され割り当てられたアドレスとの間の前記通信パスを開くように構成される、
    請求項１１に記載の装置。
14. ネットワーク上の前記デバイスの仮想位置を識別する割り当てられたアドレスを受信するデバイスを備え、
    前記デバイスは、ウェブクライアントから前記デバイスにアクセスするための要求を受信するクライアントローカルプロキシサーバに前記割り当てられたアドレスを送信するように構成された商業的に利用可能な、実質的に非独自仕様モバイルウェブサーバを備え、
    前記要求は、前記デバイスを固有に識別するデバイス識別子を備え、
    前記モバイルウェブサーバソフトウェアは、前記割り当てられたアドレスに基づいて前記ウェブクライアントと前記デバイスとの間の仲介者として動作する前記クライアントローカルプロキシサーバによって確立された通信パスを通じて前記デバイスから前記クライアントへのデータを配信するようにさらに構成される、
    システム。
15. 前記モバイルウェブサーバソフトウェアは、前記割り当てられたアドレスを変更することに応じて前記割り当てられたアドレスの更新を前記クライアントローカルプロキシサーバに送信するようにさらに構成される、
    請求項１４に記載のシステム。
16. 前記モバイルウェブサーバソフトウェアは、
    前記割り当てられたアドレスを前記デバイス識別子と結び付け、
    前記クライアントローカルプロキシサーバに前記デバイス識別子および前記割り当てられたアドレスを送信する
    ようにさらに構成される、請求項１５に記載のシステム。
17. 前記通信リンクは、クライアントサーバセッションを備える、
    請求項１６に記載のシステム。
18. 前記ウェブクライアントは、前記クライアントサーバセッションからリモートに位置付けられたリモートウェブクライアントを備える、
    請求項１６に記載のシステム。

Images