JP2004533190A - 双方向で開始する無線デバイスとのデータ通信のための方法およびシステム - Google Patents

Abstract

接続ベースまたは接続なしのプロトコル（例えばＴＣＰ／ＩＰおよびＵＤＰ／ＩＰ等）を用いて、無線デバイスに双方向に開始される双方向通信を提供する方法およびシステムが提供される。例示の実施形態は、インターネット等のパブリックインターネットに接続されたデバイスおよびシステムが、無線デバイスのルーティングできないプライベートアドレスを曝すことなく、プライベート無線ネットワークに接続された無線デバイスに通信を開始し、無線デバイスにデータを送信することを可能にするアドレス管理プロキシシステム（「ＡＭＰＳ」）を提供する。
【選択図】図３

Description

【技術分野】
【０００１】
（発明の背景）
（発明の分野）
本発明は、無線デバイスとの通信を開始するための方法およびシステムに関する。特に、仮想端末間接続を達成するためにパブリックネットワーク上のデバイスからプライベートネットワーク上のデバイスとの通信を開始するための方法およびシステムに関する。
【背景技術】
【０００２】
（背景技術）
他のネットワークのコンピュータと共にネットワーク上のコンピュータを接続するための必要性は、グローバル社会がビジネスおよび個人的な理由のために国際的なレベルで通信するように努めるに伴ってますます重要になってきている。この必要性は、物理的に異なるネットワーク上でデバイスを相互接続するための方法を生み出す技術的共同体を刺激することにより、同種のネットワークおよび異種のネットワークが統一の（または標準的な）態様として互いに通信し得る。このような相互接続技術は、しばしば、「インターネットワーキング」、「インターネットワーク」、または単に「インターネット」と呼ばれる。１つのこのようなグローバルインターネットワーキングインプリメンテーションは、教育的および行政目的のためのＡＲＰＡ、ＮＳＦ等によって、本来開発されたインターネット（Ｉｎｔｅｒｎｅｔ）（頭文字は、一般的に「インターネット」と区別するように大文字で書かれる）である。現在拡張されたバージョンのインターネット（Ｉｎｔｅｒｎｅｔ）は、世界中のネットワークに接続するネットワークバックボーンの複雑なインフラストラクチャとして存在する。他の（ローカル、広域、プライベート、またはパブリック）ネットワークは、ゲートウエイまたはルータ（ゲートウエイサーバ、ゲートウエイシステム、ルータサーバ、およびルータシステムとしても公知である）によってインターネットバックボーンに接続する。このドキュメントの目的のために、単独で使用されるかまたは別の名詞を修正するために、用語「ルータ」または「ゲートウエイ」は、交換可能に使用され、一般的に任意のハードウエアまたはソフトウエア、サブシステム、システム、あるいは、２つ以上の同種のまたは異種のマシン、システム、またはサブシステムの間で、特定のゲートウエイ／ルータマシンまたはサービスにかかわらず、（任意のレベルのネットワークまたは物理データ転送において）データパケットを転送することを可能にするコードを指す。インターネット（Ｉｎｔｅｒｎｅｔ）環境では、ルータまたはゲートウエイの存在は、典型的には、インターネットデータグラムを別のルータまたはマシンにルーティングする能力を示す。アプリケーションを走行することが意図されたマシンは、本明細書の目的のために、ネットワーキング用語を用いて、一般的に「ホスト」または「ホストマシン」と呼ばれ、ルータ／ゲートウエイは、ホストマシンの機能であってもよいし、別個のデバイスであってもよい。
【０００３】
インターネット環境では、種々のネットワークおよびデバイスが、ＴＣＰ／ＩＰ（またはＵＤＰ／ＩＰ）等の標準ネットワークプロトコルおよびモデルを用いて通信する。本ドキュメントの目的のために、読者は、ネットワーキング概念、プロトコル、および規格に精通していることが推定されるが、簡単な要旨が簡略化のために本明細書中で提供される。インターネットワーキング、インターネット、インターネット（Ｉｎｔｅｒｎｅｔ）の拡張バックグランド情報、ならびに関連用語および背景技術は、Ｔａｎｅｎｂａｕｍ，Ａ．，による、Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋｓ，Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ，Ｎ．Ｊ．，第３編、１９９６年、およびＣｏｍｅｒ，Ｄ．，による、Ｉｎｔｅｒｎｅｔｗｏｒｋｉｎｇ ｗｉｔｈ ＴＣＰ／ＩＰ，Ｐｒｉｎｃｉｐｌｅｓ，Ｐｒｏｔｏｃｏｌｓ，ａｎｄ Ａｒｃｈｉｔｅｃｔｕｒｅｓ，Ｐｒｅｎｔｉｃｅ Ｈａｌｌ，Ｎ．Ｊ．，第４編、２０００年に見出され得る。
【０００４】
ＴＣＰ／ＩＰおよびＵＤＰ／ＩＰ（または、しばしば「ＵＤＰ」と呼ばれる）は、一般的なトランスポート層およびネットワーク層プロトコルの組み合わせを指し、これらは、インターネットワーキング環境（他のプロトコルは、これらの層の各々に対して同様に利用可能である）において通常見出される。ＴＣＰ／ＩＰの「ＩＰ」は、「インターネットプロトコル」を指し、そしてどのようにしてデータが構造化かつ提示されるか（データグラムのフォーマットおよび意味）を定義するネットワーク層プロトコル、ならびにデータをルーティングするために使用される通信トランザクションである。ＩＰプロトコルの上位にインプリメントされ得るトランスポート層プロトコルであるＴＣＰ（「転送制御プロトコル」）およびＵＤＰ（「ユーザデータグラムプロトコル」）の両方は、それぞれコネクションベースのデータ転送およびコネクションレスデータ転送を支援する。コネクションベースのデータ転送は、ソースおよび宛先デバイスがコネクションをリクエストし、その後、シーケンス（および典型的には、ハンドシェイキングメカニズムを含む）態様で「仮想」コネクションを介して互いにデータを送信することを意味する。本明細書中で用語「仮想」は、コネクションが必ずしもハードワイヤードではないが、ソース（リクエスト側）と宛先（受信側）との間の直接コンジット（ｃｏｎｄｕｉｔ）を提供するように見えることを意味する。データは、実際には、物理転送媒体を介して最終的には転送されるより低いプロトコル層を介して流れる。コネクションレスデータ転送は、ソースがデータグラムを宛先に送信するが、配信を保証しないか、またはデータが特定の順序で到着することを意味する。
【０００５】
ＩＰプロトコルはまた、統一のネットワークアドレシングメカニズムを定義することにより、ＩＰを使用するプロトコル（ＴＣＰまたはＵＤＰ等）をインプリメントするマシンが、そのデータ転送のためのソースおよび宛先を特定することができる。ネットワークアドレシングメカニズムは、抽象（ａｂｓｔｒａｃｔ）アドレスおよびこの抽象アドレスを物理ハードウエアアドレスにマッピングするためのバインディングプロトコルを特定する。本説明の目的のために、均一ネットワークアドレシングメカニズムは、一般的に「ＩＰアドレス」と呼ばれる。しばしば、ＩＰアドレスは、「ドット付き１０進」表記で書かれ、この表記は、アドレスを「ｗ．ｘ．ｙ．ｚ」（例えば、３２ビットのアドレスでは、各文字は、情報のバイトを表す）として特定する。例えば、「１９２．２５１．０．１」等のＩＰアドレスは、ネットワーク「１９２」、サブネット「２５１」、およびドメイン「０」におけるホストマシンを特定し得る。ＩＰを用いると、典型的には、アドレスの範囲がプライベートネットワーク使用のために予約され、残りのＩＰアドレスは、他の使用または他のパブリック（ルート可能な（ｒｏｕｔａｂｌｅ））アドレスのいずれかのために予約され、これらのアドレスは、管理機関（ａｕｔｈｏｒｉｔｙ ｏｒｇａｎｉｚａｔｉｏｎ）によって割り当てられる。多数のプライベートネットワークは、同一の（ルート不可能）ＩＰアドレスを内部に割り当てるが（現在では、Ｉｎｔｅｒｎｅｔ Ｃｏｒｐｏｒａｔｉｏｎ ｆｏｒ Ａｓｓｉｇｎｅｄ Ｎａｍｅｓ ａｎｄ Ｎｕｍｂｅｒｓ、ＩＣＡＮＮ）、固有のパブリックＩＰアドレスを使用してインターネット（Ｉｎｔｅｒｎｅｔ）に接続する。例えば、クラスＢネットワーク（クラスベースのアドレシング規約を用いることは、それぞれ２５４までのホストマシンを可能にする）では、プライベートアドレスは、１９２．１６８．００〜１９２．１６８．２５５．０までの範囲にわたり得る。アドレシング規約は、当業者に周知であり、読者に公知であると推定される。この用途の目的にために、ＩＰアドレスは、どんなアドレスであっても特定の内部ネットワーキング環境で意味を成す（そして定義されている）ことが理解されているが、インターネット（Ｉｎｔｅｒｎｅｔ）ＩＰアドレシングを使用する例が参照され得る。
【０００６】
ＩＰを支援するネットワークは、ＩＰアドレスに基づく別のルータまたはホストマシンにデータを転送するルータを提供することによって、別のＴＣＰ／ＩＰベースまたはＵＤＰ／ＩＰベースのインターネット、あるいはインターネット（Ｉｎｔｅｒｎｅｔ）に接続され得る。ルータ（またはルーティングサーバ／サービス）は、典型的には、ルーティングテーブルを含み、このルーティングテーブルは、宛先ＩＰアドレスが与えられたどのマシン（そして任意にどのポートが）がデータグラムを送信するかを決定する。ＩＰアドレスは、ルータ／ホストマシンを唯一に識別し、典型的なＴＣＰ／ＩＰネットワークでは、例えば、より長いドメインの一部として特定のマシンを識別するストリング名にマッピングされ得る。（本明細書中では、しばしばＴＣＰ／ＩＰベースのネットワークと呼ばれるが、当業者は、このネットワークもまたＵＤＰベース（コネクションレス）であり、そして別のセッション管理システムを支援し得ることを認識する。）
典型的なＴＣＰ／ＩＰ（インター）ネットワークでは、マシンは、ネーミング（ｎａｍｉｎｇ）階層に従って構造化される。１つのこのような階層は、Ｄｏｍｅｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ（「ＤＮＳ」）であり、これは、どのようにして特定のマシンが他のマシンに接続されているかを特定する。（用語ＤＮＳは、時には、ＤＮＳプロトコルをインプリメントするサーバまたはサービスを識別するためにさらに使用される。）例えば、ストリング「ｉｎｉｔｉａｌ＿ｍａｃｈｉｎｅ．４ｔｈｐａｓｓ．ｓｅｒｖｉｃｅ＿ｐｒｏｖｉｄｅｒ．ｃｏｍ」は、属しているマシンを特定するために使用され得、４ｔｈｐａｓｓ ｃｏｍｐａｎｙのＬＡＮに接続され、次いで、ｓｅｒｖｉｃｅ＿ｐｒｏｖｉｄｅｒのＷＡＮ（ワイドエリアネットワーク）に接続される。ＴＣＰ／ＩＰおよびＵＤＰ／ＩＰは、クライアントシステムのためのツール／ライブラリを定義し、特定のルータ／マシンのストリング名が与えられるＩＰアドレス（インターネット上の論理アドレス）を決定するために使用する。１つのこのようなツールは、ＤＮＳクエリ（ｑｕｅｒｙ）と呼ばれ、例えば、「ＧｅｔＨｏｓｔＢｙＮａｍｅ」と呼ばれるＡＰＩを含む。ＧｅｔＨｏｓｔＢｙＮａｍｅは、ストリングが与えられるＩＰアドレスを戻す。特定の構造、ネットワーク、またはサブネットワークのためのＤＮＳ規格をインプリメントするサーバマシンは、本明細書中では単にＤＮＳと呼ばれるが、ＤＮＳサービスは、単一の物理マシン上の他のネットワーキングサービスと関連して提供され得る。
【０００７】
図１は、ＴＣＰ／ＩＰまたはＵＤＰ／ＩＰを用いてデータパケットを送信するための基礎的なインターネット（Ｉｎｔｅｒｎｅｔ）またはインターネットの例示的なブロック図である。図１では、ワイヤ１０２を介してインターネット（Ｉｎｔｅｒｎｅｔ）１１０に接続されたホストマシン１０１が示される。例えば、ローカルエリアネットワーク（ＬＡＮ）であり得るプライベート（またはパブリック）ネットワーク１３０に接続されたホストマシン１４０および１４１等の他のワイヤードデバイスが示される。ネットワーク１３０上のデバイスは、さらなるマシン（ルータ２１）によってインターネット１１０を介して通信し、ワイヤ（例えば電話回線）を介して接続されたルータが示される。ワイヤを介してさらにインターネット（Ｉｎｔｅｒｎｅｔ）１１０に接続されたＤＮＳサーバ１２０が示される。基本的な典型的な動作では、データパケットをデバイス１４０に送信する（ＴＣＰまたはＵＤＰを介して）ことを意図するソースデバイス（ホストマシン）１０１は、最初に、デバイス１４０を表すストリング名に対応するＩＰアドレスを取得するためにＤＮＳクエリを実行する。例えば、「ｉｎｉｔｉａｌｓ＿ｍａｃｈｉｎｅ．４ｔｈｐａｓｓ．ｓｅｒｖｉｃｅ＿ｐｒｏｖｉｄｅｒ．ｃｏｍ」にデータを送信するために、ＤＮＳ１２０は、「４ｔｈｐａｓｓ．ｃｏｍ」のためのＤＮＳサーバに対応し得る。このサーバは、どのようにしてその「ドメイン」（例えば「ｉｎｉｔｉａｌｓ＿ｍａｃｈｉｎｅ」）のマシンを位置付けるかを知っており、その対応するパブリックＩＰアドレスを検索し得る。正確な（パブリック）ＩＰアドレスを決定すると、ＤＮＳ１２０は、このアドレスをソースデバイス１０１に戻す。次いで、ソースデバイス１０１は、宛先デバイス１４０との通信のためにＴＣＰ接続を開始するか、または戻されたパブリックＩＰアドレスを用いてコネクションレスプロトコルを介してパケットを送信するかのいずれかを行い得る。
【発明の開示】
【課題を解決するための手段】
【０００８】
（発明の簡単な要旨）
本発明の実施形態は、例えば、ＴＣＰ／ＩＰおよびＵＤＰ／ＩＰ等の接続ベースまたはコネクションレスプロトコルを用いて、無線デバイスとの双方向で開始する双方向通信のためのコンピュータおよびネットワークベースの方法を提供する。例示的な実施形態は、これらの無線デバイスのルート不可能なプライベートアドレスを暴露することなく、パブリック内部ネットワークに接続されたデバイスおよびシステムが、プライベート無線ネットワークに接続された無線デバイスとの通信を開始し、無線デバイスにデータを送信することを可能にするアドレス管理プロキシシステム（「ＡＭＰＳ」）を提供する。ＡＭＰＳは、プライベート無線ネットワーク上の無線デバイスと通信するために、外部パブリックネットワーク上のデバイスをリクエストすることによって、一時的使用のためのパブリック（ルート可能）ネットワークアドレスを割り当てる。一実施形態では、パブリックアドレスのプールは、例えば、パブリックＩＰアドレスが、必要とされる場合、ＡＭＰＳによって保守され、そして無線ネットワークデバイスに動的に割り当てられる。一時的なパブリックアドレスの無線デバイスのプライベートアドレスへのマッピングが、ルーティングテーブルおよび他のマッピングデータ構造を用いて、ＡＭＰＳによって容易に保守され、更新される。
【０００９】
一実施形態では、ＡＭＰＳは、１つ以上の修正されたＤＮＳ／ＡＰＩサーバ、１つ以上のアドレスプロキシ／ルータ、アドレス管理データサーバ、１つ以上のアドレス管理データレポジトリ、および随意にロードバランサを含む。ＡＭＰＳ ＤＮＳ’／ＡＰＩサーバは、特定の無線デバイスのためのパブリックネットワーク上のデバイスからリクエストを受信し、無線デバイスのプライベートアドレスに内部にマッピングされる適切な一時的なパブリックアドレスを戻す。次いで、パブリックアドレスは、データを無線デバイスに送信するために外部パブリックネットワーク上のデバイスによって利用可能にされる。例えば、一時的なパブリックアドレスは、外部パブリックネットワークに接続され、プライベート無線ネットワーク上のプライベートアドレスへのアクセスを有するアドレスプロキシ／ルータの内の１つに関連付けられたアドレスである。いくつかの場合では、無線デバイスにデータを送信することを望むパブリックネットワーク上のデバイスが接続ベースのプロトコル（データを送信するためのＴＣＰ／ＩＰ等）を使用する。他の場合では、デバイスは、データを送信するためのＵＤＰ（ＵＤＰ／ＩＰ）等のコネクションレスプロトコルを使用する。
【００１０】
１つのアプローチに従って、ＡＭＰＳは、標準クエリ機能（ＧｅｔＨｏｓｔＢｙＮａｍｅ等）への呼び出しの結果として戻される修正されたＤＮＳサーバを提供する。別のアプローチでは、ＡＭＰＳは、パブリックネットワーク上のデバイスのための専用ＡＰＩをインプリメントして、指定された無線デバイスのパブリックアドレスにクエリするために使用する。インターネット（Ｉｎｔｅｒｎｅｔ）プロトコルと共に専用ＡＰＩインプリメンテーションを用いることによって、ＡＭＰＳは、ＩＰアドレスのみを含むアドレスにプライベートアドレスをマッピングしてもよいし、対（ＩＰアドレス、ポート）にマッピングしてもよい。この後者のインプリメンテーションは、特定のパブリックアドレス空間の利用性を拡張し得る。
【００１１】
ＡＭＰＳ技術は、プライベートまたはパブリックネットワーク上のワイヤードデバイスによって、ならびに、デバイスが、アドレスしそしてＡＭＰＳによってアドレスされ得るパブリックネットワークに接続される限り、ソースデバイスの能力で機能するネットワーク上の無線デバイスによって使用され得る。従って、ＡＭＰＳメカニズムは、互いに通信するために異なるプライベート無線ネットワーク上のデバイスによって使用され得る。さらに、ＡＭＰＳメカニズムは、ＡＴＭネットワーク等の他の内部ネットワーク、ならびにＴＣＰ／ＩＰまたはＵＤＰ以外のデータ転送プロトコルと共に使用され得る。
【００１２】
より大きい程度のセキュリティを保証するために、一実施形態によると、ＡＭＰＳは、各アドレスマッピングを有するタイムツーライブ（Ｔｉｍｅ ｔｏ Ｌｉｖｅ）（ＴＴＬ）パラメータを保守する。この方法では、一旦ＴＴＬ値がマッピングが終了したことを示す場合、ＡＭＰＳは、マッピング、そしてさらに任意の接続を破壊し得る。さらにいくつかの実施形態では、ＡＭＰＳはまた、マッピングテーブル自体にタイムスタンプを置く。タイムスタンプに基づくいくつかのタイムアウト期間の後、ＡＭＰＳは、マッピングを破壊し得ることにより、新しいマッピングに期間ベースで開始させる。
【００１３】
（発明の詳細な説明）
本発明の実施形態は、例えば、ＴＣＰ／ＩＰおよびＵＤＰ／ＩＰ等の接続ベースまたはコネクションレスプロトコルを用いて、無線デバイスとの双方向で開始する双方向通信のためのコンピュータおよびネットワークベースの方法を提供する。例示的な実施形態は、これらの無線デバイスのルート不可能なプライベートアドレスを暴露することなく、パブリックインターネットに接続されたデバイスおよびシステムが、プライベート無線ネットワークに接続された無線デバイスとの通信を開始し、無線デバイスにデータを送信することを可能にするアドレス管理プロキシシステム（「ＡＭＰＳ」）を提供する。
【００１４】
既存のシステムでは、プライベートワイヤレスネットワークに接続される無線デバイスとパブリックワイヤードネットワーク（例えばインターネット（Ｉｎｔｅｒｎｅｔ））に接続されるワイヤードデバイスとの間のデータ通信が、無線デバイスのみによって開始され得る。いくつかのキャリアは、固定されたパブリックＩＰアドレスを無線デバイスに割り当てている。しかし、次いで無線デバイスは、入来する通信パケットを受信かつ処理するクライアントプログラム（例えばＵＤＰスタック）能力を有することを必要とする。次いでさらに、これらの無線デバイスは、パブリック無線ネットワークの一部であるが、プライベート無線ネットワークではない。パブリックＩＰアドレスが、より不足した商品（ｃｏｍｍｏｄｉｔｙ）となっており、現在、多重の数百万の（ｍｕｌｔｉ−ｍｉｌｌｉｏｎ）デバイスのネットワークを提供するのに高価であるために、実際の意味では、キャリアは、そのネットワーク上の各デバイスに対する固定されたパブリックＩＰアドレスを有することを当てにはできない（ＩＰｖ６への移動がより多くのアドレスを可能にするが、現在のＩＰｖ４定義が制限され、より多くのキャリアに加入している無線ユーザの潜在的な数は非常に多い。世界いくつかの地域では、現在のパブリックアドレス方式は、さらにより制限される）。さらに、このようなアドレシング能力は、さらなるセキュリティリスクに各デバイスを曝す。なぜなら、このようなデバイスの各々は、パブリックにアクセス可能なネットワークの一部であり、セキュリティ計測をインプリメントかつ実施することが困難になる。従って、固定されたパブリックＩＰアドレスをデバイスに割り当てることを介した既存の無線ネットワークにおいて、デバイスにプライベートＩＰアドレスを割り当てることが好ましい。無線ネットワークがプライベートである場合、無線デバイスの位置（アドレス）が、キャリアシステム（または、いくつかの国ではオペレータと呼ばれる）のインフラストラクチャによってパブリックな閲覧から意図的に隠される。
【００１５】
プライベートネットワーク上の無線システムは、無線デバイスからパブリックネットワーキングワールドにデータを送信するためのネットワークアドレス変換（ＮＡＴ）技術と同様の技術を使用する。プライベートネットワークを使用する典型的なキャリアインフラストラクチャでは、無線デバイスの電源をオンする場合（または他の環境では、デバイスがデータサービスを開始することを試みる場合）、無線デバイスは、それ自体をキャリアインフラストラクチャに「登録する」。キャリアは、ＤＨＣＰ（またはＤＨＣＰと同様の）サーバを用いてプライベートルート不可能なドレスに無線デバイスを動的に割り当てる。過渡的なプライベートＩＰアドレスのパブリックＩＰアドレスへのマッピングに関するン情報は、内部キャリアデータベースに格納され、ＲＡＤＩＵＳサーバ等のキャリアサービスによって管理される。
【００１６】
プライベートネットワーク上の無線デバイスからインターネットに（またはインターネットからプライベートネットワーク上の無線デバイスに）送信された場合、データによって取られた実際の経路は、非常の多くのネットワークインフラストラクチャであり、キャリア技術に依存し、そして独自のものである。いくつかの規格が出現したが、本来非常に多様なものである。ＧＰＲＳネットワークでは、例えば、ＳＧＳＮ（サービスＧＰＲＳノード）は、無線デバイスとの通信を管理する一方で、ＳＧＳＮは、インターネット（Ｉｎｔｅｒｎｅｔ）ネットワークを接続するためにＧＧＳＮ（ゲートウエイＧＰＲＳノード）を接続させる。使用されたモバイルネットワークにもかかわらず、無線デバイスとインターネットとの間のデータ通信は、ＧＧＳＮと同様な種々のネットワークエレメント（ＧＰＲＳ、ＧＳＭ、ＣＤＭＡ、または任意の他のネットワーク）、ＤＮＳサーバ、ルータ、およびゲートウエイを含む。
【００１７】
再度、キャリアおよびネットワーク技術に依存して、パブリックネットワーク上のワイヤードデバイスから無線ネットワーク（プライベートアドレスを有する）上のモバイルデバイスに短い連続メッセージを送信するための制限された設備が存在する。ＳＭＳ（ショートメッセージシステム）プロトコルは、このようなメッセージのためのフォーマットを定義するが、下位構造またはデータ転送についての任意のガイダンスを提供しない。さらに、このようなメッセージは、固定された（非常に短い）長さであり、データチャンネルではなく、制御情報（シグナリングチャンネル）を送信するための専用チャンネルを使用する。
【００１８】
従って、標準アドレシング方式を用いるキャリアインフラストラクチャにプライベートネットワークを介して接続される無線デバイスと通信するための双方向通信チャンネルを構成するための既存のメカニズムが存在しない。あるいは、パブリックネットワークに接続されたデバイスから無線デバイス等との通信を開始するための任意のメカニズムが存在しない。従って、既存のシステムの実施形態は、キャリアのインフラストラクチャの倍部に常駐するワイヤードデバイスから無線デバイスへのデータの任意の種類のプログラム「プッシュ（ｐｕｓｈ）」を支援することができない。さらに、無線デバイスからパブリック（ワイヤード）ネットワーク上のデバイスに送信されたメッセージは、ワイヤードデバイスによって直接応答できない。なぜなら、メッセージ内に含まれた無線デバイスのアドレスは、もはや価値がなくてもよいからである。さらに、これらのシステムを用いてアプリケーションを放送での取得を提供し、外部デバイスからキャリアインフラストラクチャに無線デバイスへの他のコードを送信することが不可能である。アプリケーションの動的取得およびダウンロードするための空気中での取得および関連した技術は、２００１年１１月２８日に出願された、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｍａｉｎｔａｉｎｉｎｇ ａｎｄ Ｄｉｓｔｒｉｂｕｔｉｎｇ Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ」と題された米国出願第０９／９９７，４０２号に詳細に説明される。従って、パブリックＩＰアドレスを有する外部デバイスが、無線デバイスとの双方向通信を開始する可能にするためのメカニズムが非常に望ましい。
【００１９】
アドレス管理プロキシシステムは、修正されたＤＮＳサーバをインプリメントし、そしてパブリックワイヤードインターネットワーキングワールドとインターフェースをとるように、プライベート無線ネットワーク上のデバイスのためにプロキシ／ルータとして機能することによって、双方向で開始された双方向通信を達成する。要するに、パブリックアドレスのプールが保守され、ＡＭＰＳによって必要とされた場合に、アクティブ無線デバイス間で動的に分散される。図２は、無線デバイスを有する双方向通信において使用された例示的なアドレス管理プロキシシステムのブロック図である。用語「双方向性」は、本明細書中で使用された場合、データパスおよび通信が２つのエンドポイントシステム間のいずれかの方向に流れ得ることを意味する。図２は、パブリックネットワーク２１０に接続されたワイヤードデバイス２０１、２０２、および２０３を示す。当業者は、これらのデバイスが別のプライベートまたはパブリックネットワークに接続され、次いで、パブリックネットワーク２１０に１つ以上のワイヤードデバイスによって接続され、本明細書中で説明された機能性をさらに達成することを認識する。任意のこのような改変は、等価な機能を提供し、本発明の一部であることが明示的に企図されかつ推定される。無線側では、無線デバイスについてのプロキシ（およびルータ）としてその能力で作用する、パブリックネットワーク２１０にワイヤを介しておよび無線ネットワーク２３０に標準キャリアインフラストラクチャエレメント（図示せず）を介して、両方に接続されたＡＭＰＳ２２０が示される。読者は、キャリアのインフラストラクチャのエレメントおよびルーティングのための基本的なメカニズムおよびワイヤードネットワークから無線ネットワークにパケットを変換するメカニズムの動作知識を有することが推定される。これらは、物理データを送信し、そのデータを（例えば、衛星を介して、最終的には無線デバイスに）転送するために、プロトコル変換を必要とし得る無線技術および無線ルーティングメカニズムに関する詳細な背景情報が、Ｓｔａｌｌｉｎｇ，Ｗ．，によるＷｉｒｅｌｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｎｅｔｗｏｒｋ，Ｐｒｅｎｔｉｃｅ Ｈａｌｌ，Ｎ．Ｊ．２００２において説明される。図２では、種々の無線エレメント（図示せず）を介して無線ネットワーク２３０に接続された無線デバイス２４０が示される。
【００２０】
動作中では、ワイヤードデバイス２０１等のワイヤードデバイスは、データを無線デバイス２４０にデータを送信することを望む場合、ワイヤードデバイスは、まず、パブリックネットワーク２１０上の無線デバイス２４０のルート可能なアドレス位置を決定する必要がある。しかし、図２から観察されるように、無線デバイス２４０は、パブリックネットワーク２１０に直接接続されない。従って、無線デバイス２４０に向かうデータを送信するルート可能（パブリック）アドレスを決定するために、ワイヤードデバイスは、アドレス管理プロキシシステム２２０を使用しなければならない。このタスクを達成するためには、ワイヤードデバイス２０１は、無線デバイス２４０に対応するルート可能なパブリックアドレスを見つけるためにクエリ（例えば、修正されたＤＮＳクエリ）を実行する。アドレス管理プロキシシステム２２０は、クエリを受信し、アドレスのプールからパブリック（ルート可能）アドレスを決定かつ割り当て、そのアドレスは、無線デバイス２４０に標的にされたデータパケットのための宛先アドレスとして使用され得る。本明細書中では、ＤＮＡクエリとして示されたが、さらに説明されるように、無線デバイス技術を処理するためにＤＮＳクエリインプリメンテーションを修正し、および／または適切なルート可能アドレスを決定するために代替的なＡＰＩを提供する。一旦、アドレス管理プロキシシステム２２０は、ワイヤードデバイス２０１へのルート可能なアドレスを戻すと、ワイヤードデバイス２０１は、データをそのアドレスに送信し得る。アドレス管理プロキシシステム２２０は、データを受信し、必要な場合、フォーマットおよびプロトコルを変換し、そして無線ネットワーク２３０を介して無線デバイス２４０に変換されたデータを送信する。
【００２１】
図３は、例示的なアドレス管理プロキシシステムのコンポーネントの例示的なブロック図である。一実施形態では、アドレス管理プロキシシステム（ＡＭＰＳ）は、１つ以上の修正されたＤＮＳ’／ＡＰＩサーバ３０２、１つ以上のアドレスプロキシ／ルータ３０５、アドレス管理データレポジトリ３０４等のデータベースまたは他のレポジトリを管理するアドレス管理データサーバ３０３、ならびに、随意にロードバランサ３０１を含む。ＤＮＳ’／ＡＰＩサーバ３０２は、パブリックネットワーク３１０に個々に接続されるか、または次いでパブリックネットワーク３１０に接続されるロードバランサ３０１に接続されるかのいずれかである。同様に、外部ネットワーク３１０からの、無線デバイスに向けられたデータが送信されるルート可能（パブリック）アドレスを介して、各アドレスプロキシ／ルータ３０５はまた、パブリックネットワーク３１０に接続される。ＤＮＳ’／ＡＰＩサーバ３０２は、無線デバイスと通信するために必要な機能性を加えるＤＮＳサーバの修正されたインプリメンテーションであるか、または以下にさらに説明されるような１つ以上の専用ＡＰＩをインプリメントするサーバであるかのいずれかである。ＤＮＳ’／ＡＰＩサーバ３０２は、無線デバイスに対する固有の識別子（例えばストリング名）をパブリックネットワーク３１０にマッピングする場合に支援するためにアドレス管理データサーバ３０３を使用する。パブリックアドレスのプールはまた、アドレス管理データサーバ３０３およびデータレポジトリ３０４によって保守される。アドレス管理データサーバ３０３およびデータレポジトリ３０４は、既存のデータベース技術（例えば、ＯＤＢＣ技術）を用いてインプリメントされてもよいし、簡単なテキストファイル等の構造としてインプリメントされてもよい。当業者は、テーブル、データ、リスト、またはマッピングを格納するための任意の実施形態が使用され得ることを認識する。各アドレスプロキシ／ルータ３０５はまた、アドレス管理データサーバ３０３またはその等化物を使用して、必要とされた場合、パブリックアドレスを無線デバイスに割り当て、そして無線デバイスのパブリックアドレスと、ルート不可能（プライベート）アドレスとの間に種々のマッピングを更新する一連のルーティングテーブルを作成かつ更新する。アドレス管理データサーバ３０３によって、ＤＮＳ’／ＡＰＩサーバ３０２およびアドレスプロキシ／ルータ３０５の代わりに保守されるテーブルおよびマッピングは、図６を参照しながら以下に説明される。
【００２２】
ＡＭＰＳの技術が一般的に無線デバイスと通信する任意のワイヤードデバイスに一般的に利用可能であるが、用語「パブリックネットワーク」（または「ワイヤードネットワーク」）は、一般的には、１つ以上のプライベートまたはパブリックネットワークに接続されたラインの下流（ｄｏｗｎ）のいずれかにあるパブリックネットワークまたはバックボーンを含むインターネットワーク環境の任意のタイプを意味する。さらに、本明細書中で説明されたレイがしばしばインターネット（Ｉｎｔｅｒｎｅｔ）を指すが、当業者は、説明された概念および本発明が、例えばＡＴＭタイプのネットワークを含むインターネットワーキングの他の形態および実施形態に適用可能であることを認識する。従って、本発明の技術もまた、第２のネットワーク上の別の無線デバイスと通信する第１の無線ネットワーク上の１つのデバイスによって使用され得る。各デバイスは、他のネットワークのアドレスプロキシ／ルータとの通信を終了する。シナリオは実現可能である。なぜなら、各無線ネットワーク（またはキャリアインフラストラクチャ）は、パブリックネットワークにさらに接続されるプロキシ／ルータに接続されるためである。さらに、パブリックネットワークはまた、時には、本明細書中でワイヤードネットワークと呼ばれるが、当業者は、ルート可能な（パブリック）アドレスを露出する任意のネットワークが説明され得ることを認識する。従って、固有のパブリック（およびルート可能）アドレスを有する無線ネットワークもまた、双方向通信を実行するために本発明の技術を利用し得る。あるいは、当業者は、無線デバイス、電話、ハンドヘルド等の用語が、ＡＭＰＳと共に動作することが可能である無線デバイスの任意のタイプを示すために交換可能に使用される。さらに、用語は、明示的に説明されてもされなくてもよい代替の綴りを有し得、当業者は、用語のこのような変更の全てが含まれるように意図されることを認識する。
【００２３】
本明細書中で説明された例示的な実施形態は、双方向性通信のために使用される１つ以上のワイヤードネットワークおよび無線ネットワークを介して、プライベートアドレスからパブリックアドレスへのマッピングをインプリメントするために、アプリケーション、ツール、データ構造、および他のサポートを提供する。当業者は、本発明の方法およびシステムの他の実施形態が、情報および／またはデータ、あるいはコードを、パブリックネットワーク（インターネット（Ｉｎｔｅｒｎｅｔ）等）から無線デバイスにプッシュすることを含む多くの他の目的のために使用され得ることを理解する。さらに、この説明は、主にネットワークを介して送信される「データ」を指すが、当業者は、全てのタイプのデータが、以下に限定されないが、テキスト、グラフィックス、オーディオ、およびビデオを含む、本明細書中で説明された技術を用いて通信され得る。
【００２４】
あるいは、以下の説明では、本発明の方法およびシステムの技術を理解することによって提供するために、データフォーマットおよびコード列等の複数の特定の詳細が以下に説明される。しかし、当業者は、本発明はまた、本明細書で説明されたいくつかの特定の詳細なしで、または他の特定の詳細（コードフローの順序に関する変化等）を用いて実施され得る。
【００２５】
図４は、アドレス管理プロキシシステムの実施形態を実施するための汎用コンピュータシステムの例示的なブロック図である。汎用コンピュータシステム４００は、１つ以上のサーバおよび／またはクライアントコンピューティングシステムを含み得、分散された位置に及び得る。さらに、各ブロックは、１つ以上のこのようなブロックを特定の実施形態に対して適切なように表わしてもよいし、他のブロックと組み合わせられてもよい。アドレス管理プロキシシステム４１０の種々のブロックは、互いに通信するために標準的なプロセス間通信メカニズムを使用する１つ以上のマシン上に物理的に常駐し得る。示された実施形態では、コンピュータシステム４００は、コンピュータメモリ（「メモリ」）０１、ディスプレイ４０２、中央処理装置（「ＣＰＵ」）４０３、および入力／出力デバイス４０４を含む。メモリ４０１内に常駐するアドレス管理プロキシシステム４１０が示される。アドレス管理プロキシシステム４１０のコンポーネントは、好ましくは、ＣＰＵ４０３上で実行し、前図で説明されたように、無線ネットワーク上の無線デバイスのアドレスマッピングを管理することによって、他のワイヤードシステムが無線デバイスと通信することを可能にする。他のダウンロードコード４０５および潜在的な他のデータレポジトリはまた、メモリ４１０に常駐し、好ましくは、１つ以上のＣＰＵ４０３上で実行する。典型的な実施形態では、ＡＭＰＳ４１０は、１つ以上のＤＮＳ’／ＡＰＩサーバ４１１、１つ以上のアドレスプロキシ／ルータ４１２、アドレス管理データサーバ４１３、およびアドレス管理データレポジトリ４１４を含む。上述したように、ＡＭＰＳは、特定のインプリメンテーションに依存するロードバランサ等の他のデータレポジトリおよびコンポーネントを含み得る。
【００２６】
例示的実施形態では、ＡＭＰＳ４１０のコンポーネントは、ＤＮＳサーバおよびルータ等の既存のＵＤＰベースの技術を修正することによってインプリメントされ、これらのコンポーネントは、典型的には、Ｃプログラミング言語で書かれたＬｉｎｕｘ／Ｕｎｉｘ（Ｒ）システム上でインプリメントされる。ＤＮＳ’／ＡＰＩサーバ４１１およびアドレスプロキシ／ルータ４１２へのインターフェースをプログラミングすることは、Ｃ、Ｃ＋＋、Ｃ＃、およびＪａｖａ（Ｒ）ＡＰＩおよびＸＭＬ等のスクリプト言語、あるいはこれらを支援するウエブサーバを介して標準的な手段によって達成され得る。アドレス管理データサーバ４１３およびアドレス管理データレポジトリ４１４は、好ましくは、テキストファイルとしてではなく、データベースシステムとして拡張性の理由のために好ましくはインプリメントされ、ＳＱＬ／ＯＤＢＣデータベース管理システムを用いてインプリメントされ得る。ＤＮＳ’／ＡＰＩサーバ４１１およびアドレスプロキシ／ルータ４１２は、典型的には、Ｌｉｎｕｘ、ＵＮＩＸ（Ｒ）、あるいは他のＵｎｉｘ（Ｒ）ベースのまたはＵｎｉｘ（Ｒ）と同様のマシンを用いてインプリメントされる。当業者は、ＡＭＰＳ４１０が、複数の同種のコンピュータシステムおよびネットワークから構成される分散された環境においてインプリメントされ得ることを理解する。例えば、一実施形態では、ＤＮＳ’／ＡＰＩサーバ４１１、アドレスプロキシ／ルータコンポーネント４１２、アドレス管理データサーバ４１３、およびそのデータレポジトリ４１４は全て、物理的に異なるコンピュータシステムにおいて配置される。別の実施形態では、ＡＭＰＳ４１０の種々のコンポーネントは、別個のサーバマシン上の各々にホストされ、アドレス管理データレポジトリ４１４に格納されたテーブルからリモートに配置され得る。さらに、いくつかのシナリオにおいて、全体のＡＭＰＳシステム４１０は、キャリアインフラストラクチャ内部にホストされ、それに完全に組み込まれ得る。プログラムおよびデータの異なる構成および位置は、本発明の技術と共に使用するために企図される。例示的実施形態では、これらのコンポーネントは、同時にかつ非対称に実行し得、これにより、コンポーネントは、周知のメッセージ引渡し（ｐａｓｓｉｎｇ）技術を用いて通信し得る。当業者は、等価な同時に起こる実施形態もまた、ＡＭＰＳインプリメンテーションによって支援されることを認識する。あるいは、他のステップは、各ルーチンに対してインプリメントされ得、異なる順序および異なるルーチンでＡＭＰＳの機能をさらに達成する。
【００２７】
アドレス管理プロキシシステムのコンポーネントに対するいくつかのインプリメンテーションアプローチが存在し、これらのアプローチの内の３つが、本明細書中で説明される。当業者は、種々の他のアプローチおよび組み合わせが可能であることを認識する。全ての３つのアプローチが、無線デバイスと通信するためにワイヤードデバイスによる一時的な使用に対してパブリック（ルート可能）ネットワークアドレスを割り当てる。一実施形態では、パブリックアドレスのプール（例えばパブリックＩＰアドレス）が保守され、必要に応じて無線ネットワークデバイスに動的に割り当てられる。例えば、典型的なクラスＢインターネットネットワークアドレスブロックは、無線デバイスへの約６５，０００のシミュレーション接続を可能にする。この数は一見すると大きく見えるかもしれないが、携帯電話およびハンドセット（例えば、キャリアに接続された）の数を考慮すると、この数は、非常に制限され得る。
【００２８】
第１のアプローチは、無線デバイスのためのパブリックアドレスマッピングを提供し、ＵＤＰプロトコルを用いてそれを利用可能にする。これは、格納および転送タイプのアプローチである。このアプローチの１つの利点は、このアプローチが無線接続を介して無線デバイスにＵＤＰベースのトラフィックを容易にし、接続のパブリック側に接続されたデバイスがその接続を開始することを可能にする。しかし、欠点は、標準的なＵＤＰプロトコルが修正を必要とするか、または追加のＡＰＩ呼び出しが追加されるかのいずれかにより、リクエストしているデバイスは、向けられた無線デバイスを識別し得る。これらの改変が必要である。なぜなら、ＵＤＰプロトコルは、ＩＰアドレスの宛先を支援するだけであり、デバイスを固有に識別する代替的な手段（ＴＣＰ／ＩＰプロトコルと同様なストリング等）を提供しない。この（プライベート）アドレスを隠すことが望ましいために、標準ＵＤＰがデータを送信するための標準的なＵＤＰ呼び出しは、十分ではない。
【００２９】
ＡＭＰＳをインプリメントするために使用された第２のアプローチは、例えば、ＴＣＰ／ＩＰプロトコルを用いて、確立されたポイントツーポイント接続を介して完全な双方向通信を支援する（これらの同じ技術はまた、コネクションレスＵＤＰ双方向通信を支援することに留意すること）。第２のアプローチは、ＵＤＰまたはＴＣＰ／ＩＰ機能（ＧｅｔＨｏｓｔＢｙＮａｍｅ）の修正されたインプリメンテーションを提供することによってインプリメントされ得る。ＧｅｔＨｏｓｔＢｙＮａｍｅ ＡＰＩは、ストリング指定が指定されたデバイスを識別することを可能にし、ＩＰアドレスデータ構造を戻す。あるいは、提供されたセキュリティのレベルを増加させるために、ＡＭＰＳは、特定されたＡＰＩをインプリメントして、リクエストされた無線デバイスに（現在）対応している動的に割り当てられたパブリックアドレスを戻し得る。特定されたＡＰＩアプローチの欠点は、パブリックネットワーク上のデバイス（または無線デバイスへの接続を取得することを望む他のデバイス）がリクエストしているデバイス上のアプリケーションにおける専用コードを含む。
【００３０】
第３のアプローチは、第２のアプローチと同様であるが、「ポート」概念を使用するより大きい潜在的な同時接続を提供する。このアプローチを用いて、無線デバイス（アドレスプロキシ／ルータのパブリックアドレス）に対応するワイヤードネットワーク上のホストアドレスのみを戻す代わりに、ＡＭＰＳはまた、ホストマシン（アドレスプロキシ／ルータ）上の特定のポート指定を戻す。ポートおよびそのインプリメンテーションは、当該分野において周知であり、一般的に、異なる場所に向けられたメッセージをトラッキングするために、データを受信するマシンによってインプリメントされたキューに対応する。データを受信するマシンは、ポート毎のベースで必要な順序付け、およびハンドシェーキング状態で、メッセージおよびハンドル中のポート指定に基づく異なる宛先にメッセージを転送する。
【００３１】
ポートは、典型的には、単一の物理アドレス上に複数の仮想チャンネルを開くために使用され、潜在的に、単一の物理アドレスを別の約６５，０００の接続に拡張する。これは、ＡＭＰＳが、例えばクラスＣ ＩＰアドレスを使用することを可能にし、このアドレスは、典型的には、アドレスの他のタイプよりもはるかに安くかつ容易に利用可能であり、約１６００万の無線デバイスへの同時接続を（ＵＮＩＸ（Ｒ）ベースのシステム）達成する。当業者は、利用可能なポートの数およびその特定のインプリメンテーションが、オペレーティングシステムに依存し、ポートアドレスを特定するために使用されたビット数に直接相関することを認識する。
【００３２】
ＵＤＰ（ならびにＴＣＰ／ＩＰ）プロトコルは、ポート抽象化（ｐｏｒｔ ａｂｓｔｒａｃｔｉｏｎ）を支援するが、ＵＤＰおよびＴＣＰ／ＩＰシステムを用いて使用された標準的なＤＮＳクエリ（例えば、ＧｅｔＨｏｓｔＢｙＮａｍｅ）は、ポート宛先の帰還を可能にせず、受信ルータの代わりに、リクエストデバイスまでポート宛先の制御を残す。従って、ＡＭＰＳをインプリメントするための第３のアプローチに従って、ポートは、専用ＡＰＩを用いてアドレスプロキシ／ルータによって好適に特定され、ホストマシン宛先を有するリクエストデバイスに戻される。
【００３３】
一実施形態では、ＸＭＬ等のスクリプト言語インターフェースは、専用アドレスマッピング機能とインターフェースを取るように専用ＡＰＩ（コードインターフェース）の代わりに使用され得る。ＸＭＬを用いると、ＤＮＳ’／ＡＰＩサーバは、ＸＭＬポストイベントとしてＡＰＩ呼び出しを受け取り、ＸＭＬフォーマットされた応答を戻す。他の言語モデルおよび／または他のプログラミング言語を用いるマッピング機能を呼び出すための同様な支援もまた企図され、本発明の技術と共に動作する。ＸＭＬタイプのインターフェースは、ＡＰＩをそのソフトウエアに統合するリクエストデバイスのコストを最小化する。
【００３４】
さらに、専用ＡＰＩを用いると、リクエストデバイスは、必要とされたさらなるコーディング労力を有さないプライベート無線デバイスにさらなるデータをプッシュし得る。例えば、ワイヤードデバイスを用いて確立された接続のタイプの無線デバイスをビリングするために向けられるビリングコードがこの技術を用いて無線デバイスにプッシュされ得る。例示的なビリングコードメカニズムは、２００２年２月２６日に出願された、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｔｒａｎｓｍｉｓｓｉｏｎ−Ｂａｓｅｄ Ｂｉｌｌｉｎｇ ｏｆ Ａｐｐｌｉｃａｔｉｏｎ」と題された米国特許出願第１０／０８５，９８１号に開示される。
【００３５】
ＵＤＰおよびＴＣＰ／ＩＰの標準的なＧｅｔＨｏｓｔＢｙＮａｍｅ ＡＰＩではなく専用ＡＰＩを使用する願望をさらに示し得るいくつかのセキュリティに関連する理由が存在する。これらのセキュリティに関連する理由は、専用ＡＰＩをさらに必要とするポートベースのメカニズムを使用する願望を示し得る。第１に、「ＧｅｔＨｏｓｔＢｙＮａｍｅ」 ＡＰＩおよびルータプロトコルを使用する任意の双方向通信は、そのホスト名に関連付けられたサービス（ＤＯＳ）攻撃の拒否の影響を受ける。ＤＯＳ攻撃は、利用可能である十分なパブリックアドレス（プロキシ／ルータマシンアドレスの）可能性を精算（ｃｌｏｓｅ ｏｕｔ）するように同じ入力パラメータを有する同じＧｅｔＨｏｓｔＢｙＮａｍｅを特定する１つ以上のマシンノ結果として発生し得る。第２に、ＧｅｔＨｏｓｔＢｙＮａｍｅ（または任意の他の規格）の使用はまた、ＡＭＰＳを、ＤＮＳゾーン転送の結果としてセキュリティ攻撃を受けやすくする。例えば、リクエストされたホスト名を見出すために、１つのＤＮＳがＤＮＳクエリを１つ以上の他のＤＮＳサービスを転送する場合、ＤＮＳゾーン転送が発生する。１つの典型的なシナリオは、国から国への複数のＤＮＳホップを含む。ＤＮＳゾーンのサーバ攻撃の考えは、不正なＤＮＳサーバとして不正なコードを挿入することによって特定のＤＮＳサーバ上に情報をキャプチャし、宛先アドレスを偽装することである。第３に、接続の継続時間に対する不注意は、権限のないリクエストデバイスに対してデータを利用可能にし得る。特に、パブリックデバイスと無線デバイスとの間にマッピングが確立されるために、パブリックデバイスは、パブリックデバイスよりも長く存在するマッピングが、誤ったデバイスとの通信を実際に行いかつ潜在的に終了する（不正にまたはそうでなく）ことを想定し得る。これは、いくつかのＤＮＳサーバインプリメンテーションは、タイムツーライブ（Ｔｉｍｅ ｔｏ Ｌｉｖｅ）セッティングを無視するためである。ＤＮＳサーバインプリメンテーションが修正されたＤＮＳサーバインプリメンテーションを有するために、標準的なＧｅｔＨｏｓｔＢｙＮａｍｅ ＡＰＩ、または専用ＡＰＩをインプリメントするかしないかにかかわらず、プライベートアドレスとパブリックアドレスとの間の確立されたマッピングのＴＴＬ特性によって継続することによってこの問題を避ける。
【００３６】
図５〜図８は、図２および図３を参照しながら説明された機能性を達成するために、ＤＮＳ’／ＡＰＩサーバおよびアドレスプロキシ／ルータによってインプリメントされた特定のルーチンの種々の例示的実施形態を説明する。図５は、アドレス管理プロキシシステムを用いるプライベート無線ネットワーク上に配置された無線デバイスにデータを送信するためのパブリックネットワーク上のデバイスによって実行されたプロセスの例示的なフローチャートである。ステップ５０１では、ソース（例えば、ワイヤード）デバイスは、ＡＭＰＳから指定された無線デバイスのためのパブリック（ルート可能）アドレスを必要とする。上述のように、このようなアドレスを検索するための１つのメカニズムは、ＡＭＰＳが、修正されたＧｅｔＨｏｓｔＢｙＮａｍｅルーチン等のＤＮＳサービスのための修正されたインターフェースをインプリメントすることである。例えば、ＧｅｔＨｏｓｔＢｙＮａｍｅルーチンは、ストリングの形態で、固有の無線デバイス指定を特定するために呼び出され得る。このストリング「ｐｅｒｓｏｎｎａｍｅ．ｐｈｏｎｅ．ｗｓｐ．ｃｏｍ」は、省略された「ｗｓｐ．ｃｏｍ」である無線サービスプロバイダのウエブサイト（ＤＮＳ）において配置された「ｐｈｏｎｅ」の電話番号を用いて、「ｐｅｒｓｏｎ」の名前によって人に対応する無線デバイスを示す例示的なストリングである（例えば、ｓｕｓａｎ．ｐｈ２０６５５５１２１２．ｓｐｒｉｎｔ．ｃｏｍは、スプリントネットワーク上の電話番号２０６ ５５５ １２１２を有する人Ｓｕｓａｎを指す）。ＡＭＰＳによってインプリメントされ得る別のメカニズムは、別個の（特殊化された）ＡＰＩ（「ＧｅｔＰｒｏｘｙＩＰ」等）を提供することであり、ＡＰＩは、指定された無線デバイスに対応するパブリック（ルート可能）アドレスの表示を戻す。別個のＡＰＩを使用することは、セキュリティの理由のために使用可能である。例えば、違法なデバイスが詐欺（ｓｐｐｏｆｉｎｇ）によってルート可能なアドレスを傍受することが困難になる。別の理由は、アドレスプロキシ／ルータのホストアドレスに加えて、ポート宛先を提供することができるような、戻されたアドレス情報の実際のフォーマットを制御することである。ＧｅｔＨｏｓｔＢｙＮａｍｅまたはＧｅｔＰｒｏｘｙＩＰ等の専用ＡＰＩのいずれかのインプリメンテーションによって、図７を参照して以下にさらに説明される。
【００３７】
ステップ５０２では、一旦、無線デバイスのパブリックアドレスがＡＭＰＳによって戻された場合、ソースデバイスは、表示されたアドレス情報から実際のアドレス位置（ＩＰｄａｔａ．ｊｐ）、タイムツーライブ（Ｔｉｍｅ ｔｏ Ｌｉｖｅ）パラメータ（ＩＰｄａｔａ．ＴＴＬ）、および、標準ＧｅｔＨｏｓｔＢｙＮａｍｅ ＡＰＩが使用されない場合、随意に、例えば、利用可能なポート宛先（ＩＰｄａｔａ．ｐｏｒｔ）を抽出する。ステップ５０３では、ソースデバイスが無線デバイスとの接続ベースの通信を実行することを望む場合、ソースデバイスは接続（ソケット等）を開く。ステップ５０４では、タイムツーライブパラメータが無線デバイスの戻されたパブリックアドレスが終了したことを特定するかどうかをワイヤードデバイスが決定し、タイムツーライブパラメータが無線デバイスの戻されたパブリックアドレスが終了したことを特定するかどうかをワイヤードデバイスが決定する場合、異なるアドレスをリクエストするステップ５０１に戻り、タイムツーライブパラメータが無線デバイスの戻されたパブリックアドレスが終了したことを特定するかどうかをワイヤードデバイスが決定しない場合は、ステップ５０５を継続する。タイムツーライブパラメータは、無線デバイスのパブリックアドレスがその無線デバイスの有用性期間を超えないことを確実にするようにＡＭＰＳによって使用される（無線ネットワークに常時接続され、そして電源をオンされてもよいし、されなくてもよい）。いくつかの実施形態では、非常に短いＴＴＬパラメータが使用されることによって、ワイヤードデバイスが特定のパブリックアドレス上の動作性（ａｃｔｉｖｉｔｙ）をモニタし、次いで他の目的にためにそのアドレスを使用することを可能にするセキュリティ違反を回避する。ステップ５０５では、ワイヤードデバイスは、データパケット（接続を介するかまたは接続を介さずに）を無線デバイスに送信する。示されないが、ワイヤードデバイスおよび無線デバイスは、使用された転送プロトコル（例えばＵＤＰまたはＴＣＰ／ＩＰ）において特定された標準的な呼び出しを使用して通信することが推定される。ステップ５０６では、データトランザクションが終了する場合、ワイヤードデバイスが処理され、データトランザクションが終了しない場合、ワイヤードデバイスが戻って、より多くのデータを送信するために、ステップ５０４においてＴＬパラメータをチェックする。
【００３８】
以下の表１は、アドレス管理プロキシシステムを用いて電話番号「２０６５５５１２１２」によって識別されたユーザに対応するパブリックアドレスを取得するために、どのようにしてパブリック（リクエスト側）デバイスが、図５に説明されたような修正されたＧｅｔＨｏｓｔＢｙＮａｍｅクエリを使用し得るかを示す１つの例示的インプリメンテーションを説明する擬似コードを含む。パブリックデバイスの観点から、標準ＵＤＰおよびＴＣＰ／ＩＰ呼び出しは、標準的な態様で呼び出される。
【００３９】
【表１】

以下の表２は、同じ電話番号によって識別されたユーザのアドレスを取得するためにパブリック（リクエスト側）デバイスによって使用されたような図５に示された専用ＡＰＩメカニズムの例示的なインプリメンテーションを説明する擬似コードを含む。表２では、パブリックデバイスは、専用ＡＰＩ（ＧｅｔＰｒｏｘｙＩＰ）を呼び出し、アドレス／プロキシサーバの割り当てられたパブリックアドレスを含む必要な情報を含むデータ構造を獲得する。その後、パブリックデバイスは、データを送信するために同じ技術を使用し得る（標準的なＵＤＰまたはＴＣＰ／ＩＰプロトコル）。
【００４０】
【表２】

図６は、ＤＮＳ’／ＡＰＩサーバおよびアドレスプロキシ／ルータのルーチンを支援するために使用されたアドレス管理プロキシシステムデータレポジトリテーブルのいくつかの例示的なブロックの図である。一実施形態では、アドレス管理データレポジトリは、３つのテーブルを含む。すなわち、プライベートアドレステーブル６１０への固有の識別子（固有のＩＤ）、パブリックからプライベートへのアドレステーブル６３０、プロキシ／ルータマシンテーブル６２０へのパブリックアドレスである。３つのテーブルが示されるが、当業者は、これらのテーブルが他のデータを含み、異なる数のテーブル、ならびに異なるカラムまたはフィールドを含むこれらのテーブルが異なって構造化され得ることを認識する。さらに、データのテーブルまたはリストを格納するための任意の技術が使用され得る。ポート指定者を加えたホストアドレスを無線デバイスにマッピングする実施形態を支援するために、テーブルはそれに従って修正される。
【００４１】
固有のＩＤテーブル６１０は、無線デバイスの固有のストリング名をキャリアのインフラストラクチャに典型的に割り当てられるプライベート無線ネットワークアドレスにマッピングする。いくつかの実施形態では、キャリアインフラストラクチャは、ＤＨＣＰプロトコルと同様の方法を用いて、無線デバイスが電源投入された場合、キャリアインフラストラクチャにデバイス自体を登録する場合、ＤＨＣＰプロトコルと同様の方法を用いて、プライベートネットワークアドレスを動的に割り当てる。従って、固有のＩＤテーブル６１０が散在して満たされ、エントリが動的に作成され、次いで、キャリアインフラストラクチャシステムに登録および登録削除（ｕｎｒｅｇｉｓｔｅｒ）する場合、動的に削除され得る。
【００４２】
パブリックプライベートアドレステーブル６３０は、パブリックネットワークアドレス６３１、プライベート（無線）ネットワークアドレス６０２、フィールド６３１に格納されたパブリックアドレスが空いているか、または既に使用されているかを特定するフラグ６３２、タイムツーライブ（ＴＴＬ）パラメータ６３３、および他の接続データ６３４を含むいくつかのフィールド／カラムを含む。一実施形態では、ＡＭＰＳクエリテーブル６３０のＤＮＳ’／ＡＰＩサーバは、指定されたプライベート無線ネットワークアドレスに対応するパブリックネットワークアドレスを決定するか、または未使用のパブリックネットワークアドレスを割り当て（フィールド６３２に示される）、そして決定された未使用のパブリックアドレスをフィールド６０２において格納されたプライベートネットワークアドレスにマッピングする。
【００４３】
プロキシ／ルータマシンテーブル６２０へのパブリックアドレスは、パブリックネットワークアドレスフィールド６３１および機能プロキシ／ルータマシン６２１の表示を含む。このようなマッピングを保守することによって、ＡＭＰＳは、プロキシ／ルータマシンを他のプロキシ／ルータマシンと置換することを可能にし、高い程度のロバスト性を提供する。各プロキシ／ルータマシンは、例えば、プロキシ／ルータマシンに挿入されたネットワークカードによって典型的に構成される、パブリックネットワークアドレスの予め構成されたセットを有する。これらのアドレスは、購入前を介してまたはアドレス認証局（ａｄｒｅｓｓ ａｕｔｈｏｒｉｚｉｎｇ ａｕｔｈｏｒｉｔｙ）（現在では、Ｉｎｔｅｒｎｅｔ Ｃｏｒｐｏｒａｔｉｏｎ ｆｏｒ Ａｓｓｉｇｎｅｄ Ｎａｍｅｓ ａｎｄ Ｎｕｍｂｅｒｓ（ＩＣＡＮＮ））から得られる標準的な態様で割り当てられる。マシンが使用するためにＡＭＰＳに挿入される場合、これらのアドレスの表示は、フィールド６３１に格納される。
【００４４】
一実施形態では、パブリックネットワークアドレスとプライベートアドレスとの間のマッピングのタイムスタンプもまた、テーブル６３０に示される。定義されたタイムアウトの後、このタイムスタンプに基づいて、アドレス管理データサーバは、パブリックからプライベートマッピングをマッピングしないマッピングに関連付けられたアドレスプロキシ／ルータにリクエストを送信し、それにより未使用のパブリックネットワークアドレスのプールに関連付けられたパブリックアドレスを戻す。
【００４５】
図７は、指定された固有の識別子に対応するパブリックアドレスを戻すために、アドレス管理プロキシシステムのＤＮＳ’／ＡＰＩサーバによって提供された例示的なルーチンの例示的なフローチャートである。本質的には、このルーチンは、図５を参照して示されたような修正されたＧｅｔＨｏｓｔＢｙＮａｍｅインターフェースまたは専用ＡＰＩ（例えばＧｅｔＰｒｏｘｙＩＰ）を用いて、ＡＭＰＳのＤＮＳクエリまたはＤＮＳと同様のクエリ能力をインプリメントする。要するに、ルーチンは、無線デバイスに関連付けるために適切なアドレスプロキシ／ルータマシンを動的に割り当て、そのマシン（ＴＴＬパラメータおよび潜在的に他のパラメータと共に）のパブリックアドレスを戻す。特に、ステップ７０１では、ルーチンは、ルーチンへの入力として通過されたストリングパラメータによって指定された無線デバイスのプライベート（ルート不可能）アドレスを決定する。例えば、ストリングパラメータは、「ｕｎｉｑｕｅＩＤ．ｈｏｓｔｎａｍｅ．ｄｏｍａｉｎ．ｔｌｄ」等のフィールドを使用し得、「ｏｒｇ」、「ｃｏｍ」、「ｅｄｕ」等の上位ドメイン上の会社のネットワーク等のドメイン上で「ｈｏｓｔｎａｍｅ」と命名されたマシン上の人／サービスの典型的な階層を特定する。当業者は、多くの他のストリングパラメータ指定が使用され得ることを理解する。このルーチンをインプリメントするための１つのメカニズムは、アドレス管理データレポジトリから情報をリクエストすることである。一実施形態では、データレポジトリは、固有のＩＤをプライベートネットワークアドレスにマッピングするテーブルを格納する（図６のテーブル６１０を参照）。好ましくは、ＡＭＰＳによって使用される任意のメカニズムは、無線ネットワークアドレスを秘匿にするためにセキュアな態様でこのデータを格納する。ステップ７０２では、ＡＭＰＳによってそのデバイスに既に割り当てられ、依然として有効である場合、ルーチンは、指定されたデバイスのプライベート無線ネットワークアドレスに対応するパブリックネットワークアドレスを検索する。一実施形態では、データレポジトリは、プライベートワイヤレスネットワークアドレスとパブリックネットワークアドレスとの間でこのマッピング情報を格納する（図６のテーブル６３０を参照）。パブリックネットワークアドレスは、既に割り当てられていないか、または有効でない場合、ルーチンは、新しいパブリックネットワークアドレスを割り当てさせ、新しいパブリックアドレスは、プライベート無線ネットワークアドレスに関連付けられる。次いで、データレポジトリにおける適切なテーブルが更新される。ステップ７０３では、ルーチンは、割り当てられたパブリックネットワークアドレスに関連付けられるアドレスプロキシ／ルータマシンを決定する（例えば、図６のテーブル６２０を用いて）。ステップ７０４では、ルーチンは、決定されたパブリックネットワークアドレスをプライベートワイヤレスネットワークアドレスにマッピングするためにそのルーティングテーブルを更新するように、決定されたパブリックネットワークアドレスに送信する。ステップ７０５では、ルーチンは、任意の他の接続連携情報（例えば、図６のテーブル６３０におけるフィールド６３４）を含むようにデータレポジトリ内の情報を更新し、パブリックプライベートアドレス関係のためのタイムツーライブ（ＴＴＬ）パラメータ（例えば、図６のテーブル６３０におけるフィールド６３３）を含む。一旦、全てのテーブルがプロキシ／ルータおよびデータレポジトリの両方において更新されると、ＤＮＳ’／ＡＰＩサーバは、関連付けられたアドレスプロキシ／ルータマシンの決定されたパブリックネットワークアドレスを戻す。初期に説明されたように、ポートベースのインプリメンテーションが使用された場合、パブリックアドレスは、対（ホスト名、ポート）であり得る。
【００４６】
図８は、データを受信する例示的なアドレス管理プロキシシステムのアドレスプロキシ／ルータ内部の例示的なルーチンの例示的なフローチャートである。このルーチンは、相対的なプロトコル（例えば、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰ等）を用いてワイヤードデバイスからデータを受信するためにアドレスプロキシ／ルータによってインプリメントされる（データは、特定のアドレスプロキシ／ルータに送信される。なぜなら、そのアドレスプロキシ／ルータのパブリック（ルート可能）アドレスは、ＡＭＰＳのＤＮＳ’／ＡＰＩサーバのクエリに応答してリクエスト／ソースデバイスに戻される）。プロキシ／ルータは、有線ネットワークから無線ネットワークにデータを送信するのに必要なデータの任意の変換の原因となる（例えば、キャリアインフラストラクチャは、このレベルで実行されるべき変換等を望む場合）。プロキシ／ルータはまた、プロキシ／ルータを呼び出すために使用されたパブリックアドレスに対応する無線デバイスのプライベート無線アドレスの無線ネットワークを介してデータを無線デバイスのプライベート無線アドレスに転送する原因となる。
【００４７】
特に、ステップ８０１では、ルーチンは、呼び出されたパブリックアドレスに対応するプライベート無線アドレス、およびマッピングに関連付けられたＴＴＬパラメータを（例えば、アドレス管理データレポジトリから）決定する。これらの値は、例えば、図６のパブリック／プライベートアドレステーブル６３０から獲得され得る。ステップ８０２では、ルーチンは、決定されたＴＴＬパラメータの値は、マッピングが終了したかどうかを決定し、マッピングが終了した場合、エラーを戻し、マッピングが終了しない場合、ステップ８０３を継続する。ステップ８０３では、ルーチンは、ターゲットデバイスによって必要とされたフォーマットを決定する（無線ネットワークフォーマット）。ステップ８０４では、ルーチンは、任意のプロトコル変換が必要であるかどうかを決定し、任意のプロトコル変換が必要である場合、ステップ８０５を継続し、任意のプロトコル変換が必要でない場合、ステップ８０６を継続する。データの「ＨＴＴＰ」パケットへの変換等の特定の無線ネットワークに対するプロトコル変換は、プロキシ／ルータによってなされてもよいし、キャリアインフラストラクチャ内のいくつかの他のコンポーネントによってなされてもよいことに留意すること。当業者は、例示的なステップが存在し、異なるフォーマットまたは異なるプロトコル変換ルーチンが、環境に特有なものとして追加または削除され得る。ステップ８０６では、アドレスプロキシ／ルータルーチンは、データパケット（必要に応じて、データパケットがフォーマットされ、そのプロトコルが変換される）を無線デバイスの所定の関連したプライベートアドレスに送信し、そして戻す。
【００４８】
上述から、説明する目的で本発明の特定の実施形態が説明されてきたが、種々の改変が本発明の精神および範囲から逸脱することなくなされ得る。例えば、当業者は、本明細書中で説明された双方向通信を確立するための方法およびシステムが、インターネット（Ｉｎｔｅｒｎｅｔ）、ＴＣＰ／ＩＰ、およびＵＤＰ、あるいは、さらに複数のこのようなネットワーク以外のパブリックネットワークおよびプロトコルの他のタイプに適用可能である。例えば、パブリックアドレスマッピングへのプライベートアドレスはまた、無線デバイスを有するＡＴＭネットワーク上でデバイスを接続するＡＴＭに提供され得る。当業者はまた、本明細書中で説明された方法およびシステムが、異なるプロトコル、通信メディア（光、無線、ケーブル等）、無線デバイス（無線ハンドセット、電子オーガナイザー、パーソナルデジタルアシスタント、ポータブル電子メールマシン、ゲーム機、ポケットベル、ＧＰＳ受信器等のナビゲーションデバイス等）、異なるワイヤードデバイス（キオスク、パーソナルコンピュータ、メインフレーム）、およびワイヤード接続能力（例えば、同期化目的のためのドッキングステーションに接続され得る無線電子メール、またはＰＤＡデバイス）に適用可能である。
【００４９】
以上のように、本発明の好ましい実施形態を用いて本発明を例示してきたが、本発明は、この実施形態に限定して解釈されるべきものではない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。当業者は、本発明の具体的な好ましい実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。本明細書において引用した特許、特許出願および文献は、その内容自体が具体的に本明細書に記載されているのと同様にその内容が本明細書に対する参考として援用されるべきであることが理解される。
【図面の簡単な説明】
【００５０】
【図１】図１は、ＴＣＰ／ＩＰおよびＵＤＰ／ＩＰを用いるデータパケットを送信するための基本的なインターネット（Ｉｎｔｅｒｎｅｔ）またはインターネット通信の例示的なブロック図である。
【図２】図２は、無線デバイスを用いる双方向通信において使用された例示的なアドレス管理プロキシシステムのブロック図である。
【図３】図３は、例示的なアドレス管理プロキシシステムのコンポーネントの例示的なブロック図である。
【図４】図４は、アドレス管理プロキシシステムの実施形態を実行するための汎用コンピュータシステムの例示的なブロック図である。
【図５】図５は、アドレス管理プロキシシステムを用いるプライベート無線ネットワーク上に配置された無線デバイスにデータを送信するために、パブリックネットワーク上のデバイスによって実行されたプロセスの例示的なフローチャートである。
【図６】図６は、ＤＮＳ’／ＡＰＩサーバおよびアドレスプロキシ／ルータのルーチンを支援するために使用されたいくつかのアドレス管理プロキシシステムデータレポジトリの例示的なブロック図である。
【図７】図７は、指定された固有の識別子に対応するパブリックアドレスを戻すために、アドレス管理プロキシシステムのＤＮＳ’／ＡＰＩサーバによって提供された例示的なルーチンの例示的なフローチャートである。
【図８】図８は、データを受信する例示的なアドステップ管理プロキシシステムのアドレスプロキシ／ルータ内部の例示的なルーチンの例示的なフローチャートである。

Claims (108)

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. 前記決定されたパブリックネットワークアドレスは、インターネットプロトコル（ＩＰ）アドレスを特定する、請求項１７に記載のシステム。
33. 前記受信されたリクエストは、前記コンピュータネットワーク環境の標準ＡＰＩである、請求項１７に記載のシステム。
34. 前記ＡＰＩは、ＧｅｔＨｏｓｔＢｙＮａｍｅ ＡＰＩである、請求項３３に記載のシステム。
35. 前記受信されたリクエストは、ホストマシンの名前およびポートの指標を特定する新しいＡＰＩである、請求項１７に記載のシステム。
36. 前記ＤＮＳは、
    前記決定されたパブリックネットワークアドレスを満了期間に関連付け、
    該満了期間が満了される場合に該決定されたパブリックネットワークアドレスと前記第二のデバイスのプライベートアドレスとの間の関連が壊されるようにする
    ようにさらに構造化される、請求項１７に記載のシステム。
37. 前記満了期間は、タイムツーライブ（ＴＴＬ）データとして特定される、請求項３６に記載のシステム。
38. パブリックネットワークアドレスを用いてコンピュータネットワーク環境に接続された第一のデバイスと無線通信ネットワークに接続され、プライベートアドレスを有する第二のデバイスとの間にバーチャル通信チャネルを確立するためにコンピュータネットワーク環境に接続されたアドレスプロキシ管理システムであって、
    該第二のデバイスと通信するために該第一のデバイスからリクエストを受信するための手段と、
    パブリックネットワークアドレスのプールからパブリックネットワークアドレスを動的に決定するための手段と、
    該決定されたパブリックネットワークアドレスを該第二デバイスのプライベートアドレスに関連付けるための手段と、
    該決定されたパブリックネットワークアドレスを用いて該第一のデバイスがその後データを該第二のデバイスに送り得るように該決定されたパブリックネットワークアドレスの指標を該第一のデバイスに戻すための手段と
    を含む、システム。
39. パブリックネットワークアドレスを用いてコンピュータネットワーク環境に接続された第一のデバイスと無線通信ネットワークに接続され、プライベートアドレスを有する第二のデバイスとの間の双方向通信チャネルバーチャル通信チャネルを確立するためにコンピュータシステムにおいてプロセッサを制御するための命令を含むコンピュータ読み出し可能メモリ媒体であって、
    該第二のデバイスと通信するための該第一のデバイスからリクエストを受信するステップと、
    パブリックネットワークアドレスのプールからパブリックネットワークアドレスを動的に決定するステップと、
    該決定されたパブリックネットワークアドレスを該第二のデバイスのプライベートアドレスに関連付けるステップと、
    該決定されたパブリックネットワークアドレスを用いて該第一のデバイスがその後データを該第二のデバイスに送り得るように該決定されたパブリックネットワークアドレスの指標を該第一のデバイスに戻すステップと
    により、該双方向通信チャネルバーチャル通信チャネルを確立するためにコンピュータシステムにおいてプロセッサを制御するための命令を含むコンピュータ読み出し可能メモリ媒体システム。
40. 前記リクエストは、前記第二のデバイスのプライベートアドレスとは異なる前記第二のデバイスの固有の識別子を示し、前記決定されたパブリックアドレスを該第二のデバイスのプライベートアドレスに関連付けるステップは、該固有の識別子を用いて行われる、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
41. 前記命令は、
    該決定されたパブリックネットワークアドレスに指示された前記第一のデバイスからデータを受信するステップと、
    該決定されたパブリックネットワークアドレスと関連付けられた該プライベートネットワークアドレスを用いて該受信されたデータを前記第二のデバイスに透明にルーティングするステップと
    によって前記コンピュータプロセスをさらに制御する、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
42. 前記透明にルーティングするステップは、前記コンピュータネットワーク環境のパブリックネットワークアドレスによって前記コンピュータネットワーク環境に接続されたマスク化されたシステムによって行われる、請求項４１に記載のコンピュータ読み出し可能メモリ媒体。
43. 前記第一のデバイスは、ワイヤードデバイスである、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
44. 前記第一のデバイスは、無線デバイスである、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
45. 前記第二のデバイスは、有線接続可能なデバイスである、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
46. 前記第二のデバイスは、無線デバイスである、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
47. 前記決定されたパブリックネットワークアドレスは、ホストコンピュータアドレスおよびポート仕様を特定する、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
48. 前記決定されたパブリックネットワークアドレスは、インターネットプロトコル（ＩＰ）アドレスを特定する、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
49. 前記方法は、変更されたＤＮＳサーバによって行われる、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
50. 前記受信されたリクエストは、前記コンピュータネットワーク環境の標準ＡＰＩである、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
51. 前記ＡＰＩは、ＧｅｔＨｏｓｔＢｙＮａｍｅ ＡＰＩである、請求項５０に記載のコンピュータ読み出し可能メモリ媒体。
52. 前記受信されたリクエストは、ホストマシンの名前およびポートの指標を特定する、前記コンピュータネットワーク環境の変更されたＡＰＩである、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
53. 前記命令は、
    前記決定されたパブリックネットワークアドレスを満了期間に関連付けるステップと、
    該満了期間が満了した場合に該決定されたパブリックネットワークアドレスと前記第二のデバイスのプライベートアドレス間の関連を壊すステップと
    により前記コンピュータプロセッサをさらに制御する、請求項３９に記載のコンピュータ読み出し可能メモリ媒体。
54. 前記満了期間は、タイムツーライブ（ＴＴＬ）データとして特定される、請求項５３に記載のコンピュータ読み出し可能メモリ媒体。
55. 管理プロキシシステムを通じて無線通信ネットワークに接続されたコンピュータネットワーク環境における方法であって、該無線通信ネットワークは、該無線通信ネットワークのプライベートネットワークアドレスを用いて無線デバイスに接続され、該無線デバイスは、関連付けられた固有の識別子を有し、該アドレス管理プロキシシステムは、該コンピュータネットワーク環境のパブリックネットワークアドレスを有し、該コンピュータネットワーク環境は、該コンピュータネットワーク環境のパブリックネットワークアドレスを用いてワイヤードデバイスに接続される、コンピュータネットワーク環境における方法であって、
    該ワイヤードデバイスの制御下に、
    該アドレス管理プロキシシステムの該パブリックネットワークアドレスを用いて、該アドレス管理プロキシシステムに、該コンピュータネットワーク環境のパブリックネットワークアドレスの指標についてのリクエストを、該無線デバイスと通信するために、ユーザに送るステップであって、該リクエストは、該無線デバイスに関連付けられる固有の識別子を示す、ステップと、
    該アドレス管理プロキシシステムの制御下に、
    該パブリックネットワークアドレスの指標のために該リクエストを受信するステップと、
    コンピュータネットワーク環境の複数の利用可能なパブリックネットワークアドレスからパブリックネットワークアドレスを決定するステップと、
    該決定されたパブリックネットワークアドレスを、示された固有の識別子に対応する該無線デバイスのプライベートネットワークアドレスに関連付けるステップと、
    該決定されたネットワークアドレスの指標を該ワイヤードデバイスに転送するステップと、
    該ワイヤードデバイスの制御下に、
    該示されたパブリックネットワークアドレスを受信するステップと、
    該示されたパブリックネットワークアドレスを用いてデータを該無線デバイスに送り、その結果、該ワイヤードデバイスは、該ワイヤードデバイスは該無線デバイスと直接通信していることを認知するステップと
    を包含する、方法。
56. 前記アドレス管理プロキシシステムの制御下に、
    前記ワイヤードデバイスから送信された前記データを受信するステップと、
    該示されたパブリックネットワークアドレスに関連付けられる前記プライベートネットワークアドレスを決定するステップと、
    該ワイヤードデバイスに対して透明な態様で無線通信ネットワークを介して、該プライベートネットワークアドレスに該受信されたデータをルーティングするステップと
    をさらに包含する、請求項５５に記載の方法。
57. 前記コンピュータネットワーク環境は、インターネットであり、各パブリックネットワークアドレスは、インターネットプロトコル（ＩＰ）アドレッシングコンベンションにしたがって特定される、請求項５５に記載の方法。
58. 前記コンピュータネットワーク環境は、ＡＴＭネットワークである、請求項５５に記載の方法。
59. 前記示されたパブリックネットワークアドレスは、前記アドレス管理プロキシシステムのパブリックネットワークアドレスであり、前記ワイヤードデバイスから送られたデータは、前記無線デバイスの前記固有の識別子を示し、該アドレス管理プロキシシステムは、該データを管理し該データを該示された固有識別子に関連付けられた無線デバイスに転送する、請求項５５に記載の方法。
60. 前記示されたパブリックネットワークアドレスは、前記ワイヤードデバイスによる、前記コンピュータネットワーク環境のアドレスマッピング機能への呼び出しの結果として受信される、請求項５５に記載の方法。
61. 前記アドレスマッピング機能は、前記コンピュータネットワーク環境の標準機能である、請求項６０に記載の方法。
62. 前記アドレスマッピング機能は、ＧｅｔＨｏｓｔＢｙＮａｍｅ機能である、請求項６０に記載の方法。
63. 前記示されたパブリックネットワークアドレスは、ワイヤードデバイスによる、ホストシステムアドレスおよびポート仕様を戻す機能への呼び出しの結果として受信される、請求項５５に記載の方法。
64. 前記機能は、カスタマイズされたＡＰＩである、請求項６３に記載の方法。
65. 前記機能は、ＸＭＬインターフェースをサポートする、請求項６３に記載の方法。
66. 前記無線デバイスの制御下に、前記ワイヤードデバイスのパブリックネットワークアドレスを用いてデータをワイヤードデバイスに送り、これにより、双方向通信を行うステップをさらに含む、請求項５５に記載の方法。
67. バーチャル端間接続が、前記ワイヤードデバイスと前記無線デバイスとの間に確立される、請求項５５に記載の方法。
68. 接続なしの通信パスが、前記ワイヤードデバイスと前記無線デバイスとの間に確立される、請求項５５に記載の方法。
69. コンピュータネットワーク環境であって、
    無線通信ネットワークのプライベートネットワークアドレスを用いて無線通信ネットワークに接続された無線デバイスであって、該無線デバイスは、関連付けられた固有の識別子を有する、無線デバイスと、
    コンピュータネットワーク環境のパブリックネットワークアドレスを用いてコンピュータネットワーク環境に接続されたワイヤードデバイスであって、ワイヤードデバイスは、
    該無線デバイスに通信するために使用するように該コンピュータネットワーク環境のパブリックネットワークアドレスの指標をリクエストし、ここで、該リクエストは、該無線デバイスに関連付けられた該固有の識別子を示し、
    該示されたパブリックネットワークアドレスを受信し、
    該示されたパブリックネットワークアドレスを用いてデータを該無線デバイスに送り、その結果、該ワイヤードデバイスは、端間接続を用いて該無線デバイスと直接通信する
    ように構造化される、ワイヤードデバイスと、
    該コンピュータネットワーク環境のパブリックネットワークアドレスを用いて該コンピュータネットワーク環境に接続されたアドレス管理プロキシシステムであって、該アドレス管理プロキシシステムは、
    該ワイヤードデバイスから該リクエストを受信し、
    コンピュータネットワーク環境の複数の利用可能なパブリックネットワークアドレスからパブリックネットワークアドレスを決定し、
    該決定されたパブリックネットワークアドレスを、該示された固有の識別子に対応する該無線デバイスの該プライベートネットワークアドレスに関連付け、
    該決定されたパブリックネットワークアドレスの指標を該ワイヤードデバイスに転送する
    ように構造化された、アドレス管理プロキシシステムと
    を含む、コンピュータネットワーク環境
70. 前記アドレス管理プロキシシステムは、
    前記ワイヤードデバイスから送信されたデータを受信し、
    前記示されたパブリックネットワークアドレスに関連付けられる前記プライベートネットワークアドレスを決定し、
    該プライベートネットワークアドレスへの該受信されたデータを、前記無線通信ネットワークを介して、透明な態様で、前記ワイヤードデバイスにルーティングするようにさらに構造化される、請求項６９に記載のコンピュータネットワーク環境。
71. 前記コンピュータネットワーク環境は、インターネットであり、各パブリックネットワークアドレスは、インターネットプロトコル（ＩＰ）アドレッシングコンヴェンションにしたがって特定される、請求項６９に記載のコンピュータネットワーク環境。
72. 前記コンピュータネットワーク環境は、ＡＴＭネットワークである、請求項６９に記載のコンピュータネットワーク環境。
73. 前記示されたパブリックネットワークアドレスは、前記アドレス管理プロキシシステムのパブリックネットワークアドレスであり、前記ワイヤードデバイスから送られたデータは、前記無線デバイスの固有の識別子を示し、前記アドレス管理プロキシシステムは、該データを格納し、該示された固有の識別子に関連付けられた無線デバイスに転送するように構造化される、請求項６９に記載のコンピュータネットワーク環境。
74. 前記示されたパブリックネットワークアドレスは、前記ワイヤードデバイスによる前記コンピュータネットワーク環境のアドレスマッピング機能への呼び出しの結果として受信される、請求項６９に記載のコンピュータネットワーク環境。
75. 前記アドレスマッピング機能は、前記コンピュータネットワーク環境の標準機能である、請求項７４に記載のコンピュータネットワーク環境。
76. 前記アドレスマッピング機能は、ＧｅｔＨｏｓｔＢｙＮａｍｅ機能である、請求項７４に記載のコンピュータネットワーク環境。
77. 前記示されたパブリックネットワークアドレスは、前記ワイヤードデバイスによる、ホストシステムアドレスおよびポート仕様を戻す機能への呼び出しの結果として受信される、請求項６９に記載のコンピュータネットワーク環境。
78. 前記機能は、カスタマイズされたＡＰＩである、請求項７７に記載のコンピュータネットワーク環境。
79. 前記機能は、ＸＭＬインターフェースをサポートする、請求項７７に記載のコンピュータネットワーク環境。
80. 前記無線デバイスは、前記ワイヤードデバイスのパブリックネットワークアドレスを用いてデータを前記ワイヤードデバイスに送り、これにより、双方向通信を行うようにさらに構造化される、請求項６９に記載のコンピュータネットワーク環境。
81. バーチャル端間接続が、前記ワイヤードデバイスと前記無線デバイスとの間に確立される、請求項６９に記載のコンピュータネットワーク環境。
82. 接続なしの通信パスが、前記ワイヤードデバイスと前記無線デバイスとの間に確立される、請求項６９に記載のコンピュータネットワーク環境。
83. コンピュータネットワーク環境において、プライベートネットワークアドレスを用いてアドレス管理プロキシシステムに接続された無線デバイスと通信するための方法であって、該無線デバイスは、プライベートネットワークではない関連付けられた固有の識別子を有し、該アドレス管理プロキシシステムは、該ネットワーク環境のパブリックネットワークアドレスを用いて該コンピュータネットワーク環境に接続され、
    該アドレス管理プロキシシステムから、該無線デバイスに関連付けられた該固有の識別子に対応するパブリックネットワークアドレスをリクエストするステップと、
    該無線デバイスの該パブリックネットワークアドレスの指標を受信するステップと、
    データを該示されたパブリックネットワークアドレスに送るステップと
    を包含する、方法。
84. 前記コンピュータネットワーク環境は、インターネットである、請求項８３に記載の方法。
85. 前記示されたパブリックネットワークアドレスは、インターネットプロトコル（ＩＰ）アドレッシング標準にしたがって特定される、請求項８３に記載の方法。
86. 前記固有の識別子は、個人名および電話番号、ＭＳＩＳＤＮ番号、およびＩＳＭＩ番号の少なくとも一つである、請求項８３に記載の方法。
87. 前記リクエストは、標準ＡＰＩであり、その結果、前記無線デバイスとの通信は、前記コンピュータネットワーク環境に接続されたワイヤードデバイスとの通信と同一の態様で行われる、請求項８３に記載の方法。
88. 前記ＡＰＩは、ＧｅｔＨｏｓｔＢｙＮａｍｅ機能呼び出しである、請求項８７に記載の方法。
89. 前記無線デバイスの前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスである、請求項８３に記載の方法。
90. 前記無線デバイスの前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスおよびポート仕様である、請求項８３に記載の方法。
91. コンピュータネットワーク環境において、プライベートネットワークアドレスを用いてアドレス管理プロキシシステムに接続された無線デバイスと通信するためにコンピュータプロセッサを制御するための命令を含むコンピュータ読み出し可能メモリ媒体であって、該無線デバイスは、該プライベートネットワークアドレスではない関連付けられた固有の識別子を有し、該アドレス管理プロキシシステムは、該ネットワーク環境のパブリックネットワークアドレスを用いて該コンピュータネットワーク環境に接続され、
    該アドレス管理プロキシシステムから、該無線デバイスに関連付けられる該固有の識別子に対応するパブリックネットワークアドレスをリクエストするステップと、
    該無線デバイスの該パブリックネットワークアドレスの指標を受信するステップと、
    データを示されたパブリックネットワークアドレスに送るするステップと
    による、コンピュータ読み出し可能メモリ媒体。
92. 前記コンピュータネットワーク環境は、インターネットである、請求項９１に記載のコンピュータ読み出し可能メモリ媒体。
93. 前記示されたパブリックネットワークアドレスは、インターネットプロトコル（ＩＰ）アドレッシング基準にしたがって特定される、請求項９１に記載のコンピュータ読み出し可能メモリ媒体。
94. 前記固有の識別子は、個人名および電話番号、ＭＳＩＳＤＮ番号、およびＩＳＭＩ番号の少なくとも一つである、請求項９１に記載のコンピュータ読み出し可能メモリ媒体。
95. 前記リクエストは、標準ＡＰＩであり、その結果、前記無線デバイスとの通信は、前記コンピュータネットワーク環境に接続されたワイヤードデバイスとの通信と同一の態様で行われる、請求項９１に記載のコンピュータ読み出し可能メモリ媒体。
96. 前記ＡＰＩは、ＧｅｔＨｏｓｔＢｙＮａｍｅ機能呼び出しである、請求項９５に記載のコンピュータ読み出し可能メモリ媒体。
97. 前記無線デバイスの前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスである、請求項９１に記載のコンピュータ読み出し可能メモリ媒体。
98. 前記無線デバイスの前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスおよびポート仕様である、請求項９１に記載のコンピュータ読み出し可能メモリ媒体。
99. コンピュータネットワーク環境のパブリックネットワークアドレスを用いてコンピュータネットワーク環境に接続されたワイヤードデバイスであって、該ネットワーク環境は、該ネットワーク環境のパブリックネットワークアドレスを用いてアドレス管理プロキシシステムに接続され、該アドレス管理プロキシシステムは、プライベートネットワークアドレスを用いて無線デバイスに接続され、該無線デバイスは、前記プライベートネットワークアドレスではない関連付けられた固有の識別子を有し、
    通信コードモジュールであって、
    該アドレス管理プロキシシステムから、該無線デバイスに関連付けられる該固有の識別子に対応するパブリックネットワークアドレスをリクエストし、
    該無線デバイスの該パブリックネットワークアドレスの指標を受信し、
    データを該示されたパブリックネットワークアドレスに送るように構造化された、通信コードモジュール
    を含む、ワイヤードデバイス。
100. 前記コンピュータネットワーク環境は、インターネットである、請求項９９に記載のデバイス。
101. 前記示されたパブリックネットワークアドレスは、インターネットプロトコル（ＩＰ）アドレッシング基準にしたがって特定される、請求項９９に記載のデバイス。
102. 前記固有の識別子は、個人名および電話番号、ＭＳＩＳＤＮ番号、およびＩＳＭＩ番号の少なくとも一つである、請求項９９に記載のデバイス。
103. 前記リクエストは、標準ＡＰＩであり、その結果、前記無線デバイスとの通信は、前記コンピュータネットワーク環境に接続されたワイヤードデバイスとの通信と同一の態様で行われる、請求項９９に記載のデバイス。
104. 前記ＡＰＩは、ＧｅｔＨｏｓｔＢｙＮａｍｅ機能呼び出しである、請求項１０３に記載のデバイス。
105. 前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスである、請求項９９に記載のデバイス。
106. 前記無線デバイスの前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスおよびポート仕様である、請求項９９に記載のデバイス。
107. 前記通信コードモジュールは、ＵＤＰおよびＴＣＰ／ＩＰの少なくとも一つの通信を前記無線デバイスとインプリメントする、請求項９９に記載のデバイス。
108. 前記通信コードモジュールは、ＵＤＰ通信を前記無線デバイスとインプリメントする、請求項９９に記載のデバイス。

Images