JP2004533190A - 双方向で開始する無線デバイスとのデータ通信のための方法およびシステム - Google Patents
双方向で開始する無線デバイスとのデータ通信のための方法およびシステム Download PDFInfo
- Publication number
- JP2004533190A JP2004533190A JP2003504622A JP2003504622A JP2004533190A JP 2004533190 A JP2004533190 A JP 2004533190A JP 2003504622 A JP2003504622 A JP 2003504622A JP 2003504622 A JP2003504622 A JP 2003504622A JP 2004533190 A JP2004533190 A JP 2004533190A
- Authority
- JP
- Japan
- Prior art keywords
- address
- public network
- network address
- computer
- wireless device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims abstract description 72
- 230000006854 communication Effects 0.000 title claims abstract description 66
- 238000004891 communication Methods 0.000 title claims abstract description 62
- 238000013507 mapping Methods 0.000 claims description 39
- 230000006870 function Effects 0.000 claims description 26
- 238000006243 chemical reaction Methods 0.000 claims description 8
- 230000008569 process Effects 0.000 claims description 4
- 238000010586 diagram Methods 0.000 abstract description 11
- IRLPACMLTUPBCL-KQYNXXCUSA-N 5'-adenylyl sulfate Chemical compound C1=NC=2C(N)=NC=NC=2N1[C@@H]1O[C@H](COP(O)(=O)OS(O)(=O)=O)[C@@H](O)[C@H]1O IRLPACMLTUPBCL-KQYNXXCUSA-N 0.000 abstract 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 48
- 238000007726 management method Methods 0.000 description 47
- 230000007246 mechanism Effects 0.000 description 19
- 238000013459 approach Methods 0.000 description 16
- 238000005516 engineering process Methods 0.000 description 14
- 238000012546 transfer Methods 0.000 description 12
- 230000006855 networking Effects 0.000 description 6
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000007175 bidirectional communication Effects 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 235000008694 Humulus lupulus Nutrition 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011982 device technology Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000003032 molecular docking Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000004936 stimulating effect Effects 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
- H04L61/2567—NAT traversal for reachability, e.g. inquiring the address of a correspondent behind a NAT server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
- H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4557—Directories for hybrid networks, e.g. including telephone numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5007—Internet protocol [IP] addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5007—Internet protocol [IP] addresses
- H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5038—Address allocation for local use, e.g. in LAN or USB networks, or in a controller area network [CAN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Radar Systems Or Details Thereof (AREA)
- Telephonic Communication Services (AREA)
Abstract
接続ベースまたは接続なしのプロトコル(例えばTCP/IPおよびUDP/IP等)を用いて、無線デバイスに双方向に開始される双方向通信を提供する方法およびシステムが提供される。例示の実施形態は、インターネット等のパブリックインターネットに接続されたデバイスおよびシステムが、無線デバイスのルーティングできないプライベートアドレスを曝すことなく、プライベート無線ネットワークに接続された無線デバイスに通信を開始し、無線デバイスにデータを送信することを可能にするアドレス管理プロキシシステム(「AMPS」)を提供する。
【選択図】図3
【選択図】図3
Description
【技術分野】
【0001】
(発明の背景)
(発明の分野)
本発明は、無線デバイスとの通信を開始するための方法およびシステムに関する。特に、仮想端末間接続を達成するためにパブリックネットワーク上のデバイスからプライベートネットワーク上のデバイスとの通信を開始するための方法およびシステムに関する。
【背景技術】
【0002】
(背景技術)
他のネットワークのコンピュータと共にネットワーク上のコンピュータを接続するための必要性は、グローバル社会がビジネスおよび個人的な理由のために国際的なレベルで通信するように努めるに伴ってますます重要になってきている。この必要性は、物理的に異なるネットワーク上でデバイスを相互接続するための方法を生み出す技術的共同体を刺激することにより、同種のネットワークおよび異種のネットワークが統一の(または標準的な)態様として互いに通信し得る。このような相互接続技術は、しばしば、「インターネットワーキング」、「インターネットワーク」、または単に「インターネット」と呼ばれる。1つのこのようなグローバルインターネットワーキングインプリメンテーションは、教育的および行政目的のためのARPA、NSF等によって、本来開発されたインターネット(Internet)(頭文字は、一般的に「インターネット」と区別するように大文字で書かれる)である。現在拡張されたバージョンのインターネット(Internet)は、世界中のネットワークに接続するネットワークバックボーンの複雑なインフラストラクチャとして存在する。他の(ローカル、広域、プライベート、またはパブリック)ネットワークは、ゲートウエイまたはルータ(ゲートウエイサーバ、ゲートウエイシステム、ルータサーバ、およびルータシステムとしても公知である)によってインターネットバックボーンに接続する。このドキュメントの目的のために、単独で使用されるかまたは別の名詞を修正するために、用語「ルータ」または「ゲートウエイ」は、交換可能に使用され、一般的に任意のハードウエアまたはソフトウエア、サブシステム、システム、あるいは、2つ以上の同種のまたは異種のマシン、システム、またはサブシステムの間で、特定のゲートウエイ/ルータマシンまたはサービスにかかわらず、(任意のレベルのネットワークまたは物理データ転送において)データパケットを転送することを可能にするコードを指す。インターネット(Internet)環境では、ルータまたはゲートウエイの存在は、典型的には、インターネットデータグラムを別のルータまたはマシンにルーティングする能力を示す。アプリケーションを走行することが意図されたマシンは、本明細書の目的のために、ネットワーキング用語を用いて、一般的に「ホスト」または「ホストマシン」と呼ばれ、ルータ/ゲートウエイは、ホストマシンの機能であってもよいし、別個のデバイスであってもよい。
【0003】
インターネット環境では、種々のネットワークおよびデバイスが、TCP/IP(またはUDP/IP)等の標準ネットワークプロトコルおよびモデルを用いて通信する。本ドキュメントの目的のために、読者は、ネットワーキング概念、プロトコル、および規格に精通していることが推定されるが、簡単な要旨が簡略化のために本明細書中で提供される。インターネットワーキング、インターネット、インターネット(Internet)の拡張バックグランド情報、ならびに関連用語および背景技術は、Tanenbaum,A.,による、Computer Networks,Prentice−Hall,N.J.,第3編、1996年、およびComer,D.,による、Internetworking with TCP/IP,Principles,Protocols,and Architectures,Prentice Hall,N.J.,第4編、2000年に見出され得る。
【0004】
TCP/IPおよびUDP/IP(または、しばしば「UDP」と呼ばれる)は、一般的なトランスポート層およびネットワーク層プロトコルの組み合わせを指し、これらは、インターネットワーキング環境(他のプロトコルは、これらの層の各々に対して同様に利用可能である)において通常見出される。TCP/IPの「IP」は、「インターネットプロトコル」を指し、そしてどのようにしてデータが構造化かつ提示されるか(データグラムのフォーマットおよび意味)を定義するネットワーク層プロトコル、ならびにデータをルーティングするために使用される通信トランザクションである。IPプロトコルの上位にインプリメントされ得るトランスポート層プロトコルであるTCP(「転送制御プロトコル」)およびUDP(「ユーザデータグラムプロトコル」)の両方は、それぞれコネクションベースのデータ転送およびコネクションレスデータ転送を支援する。コネクションベースのデータ転送は、ソースおよび宛先デバイスがコネクションをリクエストし、その後、シーケンス(および典型的には、ハンドシェイキングメカニズムを含む)態様で「仮想」コネクションを介して互いにデータを送信することを意味する。本明細書中で用語「仮想」は、コネクションが必ずしもハードワイヤードではないが、ソース(リクエスト側)と宛先(受信側)との間の直接コンジット(conduit)を提供するように見えることを意味する。データは、実際には、物理転送媒体を介して最終的には転送されるより低いプロトコル層を介して流れる。コネクションレスデータ転送は、ソースがデータグラムを宛先に送信するが、配信を保証しないか、またはデータが特定の順序で到着することを意味する。
【0005】
IPプロトコルはまた、統一のネットワークアドレシングメカニズムを定義することにより、IPを使用するプロトコル(TCPまたはUDP等)をインプリメントするマシンが、そのデータ転送のためのソースおよび宛先を特定することができる。ネットワークアドレシングメカニズムは、抽象(abstract)アドレスおよびこの抽象アドレスを物理ハードウエアアドレスにマッピングするためのバインディングプロトコルを特定する。本説明の目的のために、均一ネットワークアドレシングメカニズムは、一般的に「IPアドレス」と呼ばれる。しばしば、IPアドレスは、「ドット付き10進」表記で書かれ、この表記は、アドレスを「w.x.y.z」(例えば、32ビットのアドレスでは、各文字は、情報のバイトを表す)として特定する。例えば、「192.251.0.1」等のIPアドレスは、ネットワーク「192」、サブネット「251」、およびドメイン「0」におけるホストマシンを特定し得る。IPを用いると、典型的には、アドレスの範囲がプライベートネットワーク使用のために予約され、残りのIPアドレスは、他の使用または他のパブリック(ルート可能な(routable))アドレスのいずれかのために予約され、これらのアドレスは、管理機関(authority organization)によって割り当てられる。多数のプライベートネットワークは、同一の(ルート不可能)IPアドレスを内部に割り当てるが(現在では、Internet Corporation for Assigned Names and Numbers、ICANN)、固有のパブリックIPアドレスを使用してインターネット(Internet)に接続する。例えば、クラスBネットワーク(クラスベースのアドレシング規約を用いることは、それぞれ254までのホストマシンを可能にする)では、プライベートアドレスは、192.168.00〜192.168.255.0までの範囲にわたり得る。アドレシング規約は、当業者に周知であり、読者に公知であると推定される。この用途の目的にために、IPアドレスは、どんなアドレスであっても特定の内部ネットワーキング環境で意味を成す(そして定義されている)ことが理解されているが、インターネット(Internet)IPアドレシングを使用する例が参照され得る。
【0006】
IPを支援するネットワークは、IPアドレスに基づく別のルータまたはホストマシンにデータを転送するルータを提供することによって、別のTCP/IPベースまたはUDP/IPベースのインターネット、あるいはインターネット(Internet)に接続され得る。ルータ(またはルーティングサーバ/サービス)は、典型的には、ルーティングテーブルを含み、このルーティングテーブルは、宛先IPアドレスが与えられたどのマシン(そして任意にどのポートが)がデータグラムを送信するかを決定する。IPアドレスは、ルータ/ホストマシンを唯一に識別し、典型的なTCP/IPネットワークでは、例えば、より長いドメインの一部として特定のマシンを識別するストリング名にマッピングされ得る。(本明細書中では、しばしばTCP/IPベースのネットワークと呼ばれるが、当業者は、このネットワークもまたUDPベース(コネクションレス)であり、そして別のセッション管理システムを支援し得ることを認識する。)
典型的なTCP/IP(インター)ネットワークでは、マシンは、ネーミング(naming)階層に従って構造化される。1つのこのような階層は、Domein Name System(「DNS」)であり、これは、どのようにして特定のマシンが他のマシンに接続されているかを特定する。(用語DNSは、時には、DNSプロトコルをインプリメントするサーバまたはサービスを識別するためにさらに使用される。)例えば、ストリング「initial_machine.4thpass.service_provider.com」は、属しているマシンを特定するために使用され得、4thpass companyのLANに接続され、次いで、service_providerのWAN(ワイドエリアネットワーク)に接続される。TCP/IPおよびUDP/IPは、クライアントシステムのためのツール/ライブラリを定義し、特定のルータ/マシンのストリング名が与えられるIPアドレス(インターネット上の論理アドレス)を決定するために使用する。1つのこのようなツールは、DNSクエリ(query)と呼ばれ、例えば、「GetHostByName」と呼ばれるAPIを含む。GetHostByNameは、ストリングが与えられるIPアドレスを戻す。特定の構造、ネットワーク、またはサブネットワークのためのDNS規格をインプリメントするサーバマシンは、本明細書中では単にDNSと呼ばれるが、DNSサービスは、単一の物理マシン上の他のネットワーキングサービスと関連して提供され得る。
【0007】
図1は、TCP/IPまたはUDP/IPを用いてデータパケットを送信するための基礎的なインターネット(Internet)またはインターネットの例示的なブロック図である。図1では、ワイヤ102を介してインターネット(Internet)110に接続されたホストマシン101が示される。例えば、ローカルエリアネットワーク(LAN)であり得るプライベート(またはパブリック)ネットワーク130に接続されたホストマシン140および141等の他のワイヤードデバイスが示される。ネットワーク130上のデバイスは、さらなるマシン(ルータ21)によってインターネット110を介して通信し、ワイヤ(例えば電話回線)を介して接続されたルータが示される。ワイヤを介してさらにインターネット(Internet)110に接続されたDNSサーバ120が示される。基本的な典型的な動作では、データパケットをデバイス140に送信する(TCPまたはUDPを介して)ことを意図するソースデバイス(ホストマシン)101は、最初に、デバイス140を表すストリング名に対応するIPアドレスを取得するためにDNSクエリを実行する。例えば、「initials_machine.4thpass.service_provider.com」にデータを送信するために、DNS120は、「4thpass.com」のためのDNSサーバに対応し得る。このサーバは、どのようにしてその「ドメイン」(例えば「initials_machine」)のマシンを位置付けるかを知っており、その対応するパブリックIPアドレスを検索し得る。正確な(パブリック)IPアドレスを決定すると、DNS120は、このアドレスをソースデバイス101に戻す。次いで、ソースデバイス101は、宛先デバイス140との通信のためにTCP接続を開始するか、または戻されたパブリックIPアドレスを用いてコネクションレスプロトコルを介してパケットを送信するかのいずれかを行い得る。
【発明の開示】
【課題を解決するための手段】
【0008】
(発明の簡単な要旨)
本発明の実施形態は、例えば、TCP/IPおよびUDP/IP等の接続ベースまたはコネクションレスプロトコルを用いて、無線デバイスとの双方向で開始する双方向通信のためのコンピュータおよびネットワークベースの方法を提供する。例示的な実施形態は、これらの無線デバイスのルート不可能なプライベートアドレスを暴露することなく、パブリック内部ネットワークに接続されたデバイスおよびシステムが、プライベート無線ネットワークに接続された無線デバイスとの通信を開始し、無線デバイスにデータを送信することを可能にするアドレス管理プロキシシステム(「AMPS」)を提供する。AMPSは、プライベート無線ネットワーク上の無線デバイスと通信するために、外部パブリックネットワーク上のデバイスをリクエストすることによって、一時的使用のためのパブリック(ルート可能)ネットワークアドレスを割り当てる。一実施形態では、パブリックアドレスのプールは、例えば、パブリックIPアドレスが、必要とされる場合、AMPSによって保守され、そして無線ネットワークデバイスに動的に割り当てられる。一時的なパブリックアドレスの無線デバイスのプライベートアドレスへのマッピングが、ルーティングテーブルおよび他のマッピングデータ構造を用いて、AMPSによって容易に保守され、更新される。
【0009】
一実施形態では、AMPSは、1つ以上の修正されたDNS/APIサーバ、1つ以上のアドレスプロキシ/ルータ、アドレス管理データサーバ、1つ以上のアドレス管理データレポジトリ、および随意にロードバランサを含む。AMPS DNS’/APIサーバは、特定の無線デバイスのためのパブリックネットワーク上のデバイスからリクエストを受信し、無線デバイスのプライベートアドレスに内部にマッピングされる適切な一時的なパブリックアドレスを戻す。次いで、パブリックアドレスは、データを無線デバイスに送信するために外部パブリックネットワーク上のデバイスによって利用可能にされる。例えば、一時的なパブリックアドレスは、外部パブリックネットワークに接続され、プライベート無線ネットワーク上のプライベートアドレスへのアクセスを有するアドレスプロキシ/ルータの内の1つに関連付けられたアドレスである。いくつかの場合では、無線デバイスにデータを送信することを望むパブリックネットワーク上のデバイスが接続ベースのプロトコル(データを送信するためのTCP/IP等)を使用する。他の場合では、デバイスは、データを送信するためのUDP(UDP/IP)等のコネクションレスプロトコルを使用する。
【0010】
1つのアプローチに従って、AMPSは、標準クエリ機能(GetHostByName等)への呼び出しの結果として戻される修正されたDNSサーバを提供する。別のアプローチでは、AMPSは、パブリックネットワーク上のデバイスのための専用APIをインプリメントして、指定された無線デバイスのパブリックアドレスにクエリするために使用する。インターネット(Internet)プロトコルと共に専用APIインプリメンテーションを用いることによって、AMPSは、IPアドレスのみを含むアドレスにプライベートアドレスをマッピングしてもよいし、対(IPアドレス、ポート)にマッピングしてもよい。この後者のインプリメンテーションは、特定のパブリックアドレス空間の利用性を拡張し得る。
【0011】
AMPS技術は、プライベートまたはパブリックネットワーク上のワイヤードデバイスによって、ならびに、デバイスが、アドレスしそしてAMPSによってアドレスされ得るパブリックネットワークに接続される限り、ソースデバイスの能力で機能するネットワーク上の無線デバイスによって使用され得る。従って、AMPSメカニズムは、互いに通信するために異なるプライベート無線ネットワーク上のデバイスによって使用され得る。さらに、AMPSメカニズムは、ATMネットワーク等の他の内部ネットワーク、ならびにTCP/IPまたはUDP以外のデータ転送プロトコルと共に使用され得る。
【0012】
より大きい程度のセキュリティを保証するために、一実施形態によると、AMPSは、各アドレスマッピングを有するタイムツーライブ(Time to Live)(TTL)パラメータを保守する。この方法では、一旦TTL値がマッピングが終了したことを示す場合、AMPSは、マッピング、そしてさらに任意の接続を破壊し得る。さらにいくつかの実施形態では、AMPSはまた、マッピングテーブル自体にタイムスタンプを置く。タイムスタンプに基づくいくつかのタイムアウト期間の後、AMPSは、マッピングを破壊し得ることにより、新しいマッピングに期間ベースで開始させる。
【0013】
(発明の詳細な説明)
本発明の実施形態は、例えば、TCP/IPおよびUDP/IP等の接続ベースまたはコネクションレスプロトコルを用いて、無線デバイスとの双方向で開始する双方向通信のためのコンピュータおよびネットワークベースの方法を提供する。例示的な実施形態は、これらの無線デバイスのルート不可能なプライベートアドレスを暴露することなく、パブリックインターネットに接続されたデバイスおよびシステムが、プライベート無線ネットワークに接続された無線デバイスとの通信を開始し、無線デバイスにデータを送信することを可能にするアドレス管理プロキシシステム(「AMPS」)を提供する。
【0014】
既存のシステムでは、プライベートワイヤレスネットワークに接続される無線デバイスとパブリックワイヤードネットワーク(例えばインターネット(Internet))に接続されるワイヤードデバイスとの間のデータ通信が、無線デバイスのみによって開始され得る。いくつかのキャリアは、固定されたパブリックIPアドレスを無線デバイスに割り当てている。しかし、次いで無線デバイスは、入来する通信パケットを受信かつ処理するクライアントプログラム(例えばUDPスタック)能力を有することを必要とする。次いでさらに、これらの無線デバイスは、パブリック無線ネットワークの一部であるが、プライベート無線ネットワークではない。パブリックIPアドレスが、より不足した商品(commodity)となっており、現在、多重の数百万の(multi−million)デバイスのネットワークを提供するのに高価であるために、実際の意味では、キャリアは、そのネットワーク上の各デバイスに対する固定されたパブリックIPアドレスを有することを当てにはできない(IPv6への移動がより多くのアドレスを可能にするが、現在のIPv4定義が制限され、より多くのキャリアに加入している無線ユーザの潜在的な数は非常に多い。世界いくつかの地域では、現在のパブリックアドレス方式は、さらにより制限される)。さらに、このようなアドレシング能力は、さらなるセキュリティリスクに各デバイスを曝す。なぜなら、このようなデバイスの各々は、パブリックにアクセス可能なネットワークの一部であり、セキュリティ計測をインプリメントかつ実施することが困難になる。従って、固定されたパブリックIPアドレスをデバイスに割り当てることを介した既存の無線ネットワークにおいて、デバイスにプライベートIPアドレスを割り当てることが好ましい。無線ネットワークがプライベートである場合、無線デバイスの位置(アドレス)が、キャリアシステム(または、いくつかの国ではオペレータと呼ばれる)のインフラストラクチャによってパブリックな閲覧から意図的に隠される。
【0015】
プライベートネットワーク上の無線システムは、無線デバイスからパブリックネットワーキングワールドにデータを送信するためのネットワークアドレス変換(NAT)技術と同様の技術を使用する。プライベートネットワークを使用する典型的なキャリアインフラストラクチャでは、無線デバイスの電源をオンする場合(または他の環境では、デバイスがデータサービスを開始することを試みる場合)、無線デバイスは、それ自体をキャリアインフラストラクチャに「登録する」。キャリアは、DHCP(またはDHCPと同様の)サーバを用いてプライベートルート不可能なドレスに無線デバイスを動的に割り当てる。過渡的なプライベートIPアドレスのパブリックIPアドレスへのマッピングに関するン情報は、内部キャリアデータベースに格納され、RADIUSサーバ等のキャリアサービスによって管理される。
【0016】
プライベートネットワーク上の無線デバイスからインターネットに(またはインターネットからプライベートネットワーク上の無線デバイスに)送信された場合、データによって取られた実際の経路は、非常の多くのネットワークインフラストラクチャであり、キャリア技術に依存し、そして独自のものである。いくつかの規格が出現したが、本来非常に多様なものである。GPRSネットワークでは、例えば、SGSN(サービスGPRSノード)は、無線デバイスとの通信を管理する一方で、SGSNは、インターネット(Internet)ネットワークを接続するためにGGSN(ゲートウエイGPRSノード)を接続させる。使用されたモバイルネットワークにもかかわらず、無線デバイスとインターネットとの間のデータ通信は、GGSNと同様な種々のネットワークエレメント(GPRS、GSM、CDMA、または任意の他のネットワーク)、DNSサーバ、ルータ、およびゲートウエイを含む。
【0017】
再度、キャリアおよびネットワーク技術に依存して、パブリックネットワーク上のワイヤードデバイスから無線ネットワーク(プライベートアドレスを有する)上のモバイルデバイスに短い連続メッセージを送信するための制限された設備が存在する。SMS(ショートメッセージシステム)プロトコルは、このようなメッセージのためのフォーマットを定義するが、下位構造またはデータ転送についての任意のガイダンスを提供しない。さらに、このようなメッセージは、固定された(非常に短い)長さであり、データチャンネルではなく、制御情報(シグナリングチャンネル)を送信するための専用チャンネルを使用する。
【0018】
従って、標準アドレシング方式を用いるキャリアインフラストラクチャにプライベートネットワークを介して接続される無線デバイスと通信するための双方向通信チャンネルを構成するための既存のメカニズムが存在しない。あるいは、パブリックネットワークに接続されたデバイスから無線デバイス等との通信を開始するための任意のメカニズムが存在しない。従って、既存のシステムの実施形態は、キャリアのインフラストラクチャの倍部に常駐するワイヤードデバイスから無線デバイスへのデータの任意の種類のプログラム「プッシュ(push)」を支援することができない。さらに、無線デバイスからパブリック(ワイヤード)ネットワーク上のデバイスに送信されたメッセージは、ワイヤードデバイスによって直接応答できない。なぜなら、メッセージ内に含まれた無線デバイスのアドレスは、もはや価値がなくてもよいからである。さらに、これらのシステムを用いてアプリケーションを放送での取得を提供し、外部デバイスからキャリアインフラストラクチャに無線デバイスへの他のコードを送信することが不可能である。アプリケーションの動的取得およびダウンロードするための空気中での取得および関連した技術は、2001年11月28日に出願された、「Method and System for Maintaining and Distributing Wireless Application」と題された米国出願第09/997,402号に詳細に説明される。従って、パブリックIPアドレスを有する外部デバイスが、無線デバイスとの双方向通信を開始する可能にするためのメカニズムが非常に望ましい。
【0019】
アドレス管理プロキシシステムは、修正されたDNSサーバをインプリメントし、そしてパブリックワイヤードインターネットワーキングワールドとインターフェースをとるように、プライベート無線ネットワーク上のデバイスのためにプロキシ/ルータとして機能することによって、双方向で開始された双方向通信を達成する。要するに、パブリックアドレスのプールが保守され、AMPSによって必要とされた場合に、アクティブ無線デバイス間で動的に分散される。図2は、無線デバイスを有する双方向通信において使用された例示的なアドレス管理プロキシシステムのブロック図である。用語「双方向性」は、本明細書中で使用された場合、データパスおよび通信が2つのエンドポイントシステム間のいずれかの方向に流れ得ることを意味する。図2は、パブリックネットワーク210に接続されたワイヤードデバイス201、202、および203を示す。当業者は、これらのデバイスが別のプライベートまたはパブリックネットワークに接続され、次いで、パブリックネットワーク210に1つ以上のワイヤードデバイスによって接続され、本明細書中で説明された機能性をさらに達成することを認識する。任意のこのような改変は、等価な機能を提供し、本発明の一部であることが明示的に企図されかつ推定される。無線側では、無線デバイスについてのプロキシ(およびルータ)としてその能力で作用する、パブリックネットワーク210にワイヤを介しておよび無線ネットワーク230に標準キャリアインフラストラクチャエレメント(図示せず)を介して、両方に接続されたAMPS220が示される。読者は、キャリアのインフラストラクチャのエレメントおよびルーティングのための基本的なメカニズムおよびワイヤードネットワークから無線ネットワークにパケットを変換するメカニズムの動作知識を有することが推定される。これらは、物理データを送信し、そのデータを(例えば、衛星を介して、最終的には無線デバイスに)転送するために、プロトコル変換を必要とし得る無線技術および無線ルーティングメカニズムに関する詳細な背景情報が、Stalling,W.,によるWireless Communications and Network,Prentice Hall,N.J.2002において説明される。図2では、種々の無線エレメント(図示せず)を介して無線ネットワーク230に接続された無線デバイス240が示される。
【0020】
動作中では、ワイヤードデバイス201等のワイヤードデバイスは、データを無線デバイス240にデータを送信することを望む場合、ワイヤードデバイスは、まず、パブリックネットワーク210上の無線デバイス240のルート可能なアドレス位置を決定する必要がある。しかし、図2から観察されるように、無線デバイス240は、パブリックネットワーク210に直接接続されない。従って、無線デバイス240に向かうデータを送信するルート可能(パブリック)アドレスを決定するために、ワイヤードデバイスは、アドレス管理プロキシシステム220を使用しなければならない。このタスクを達成するためには、ワイヤードデバイス201は、無線デバイス240に対応するルート可能なパブリックアドレスを見つけるためにクエリ(例えば、修正されたDNSクエリ)を実行する。アドレス管理プロキシシステム220は、クエリを受信し、アドレスのプールからパブリック(ルート可能)アドレスを決定かつ割り当て、そのアドレスは、無線デバイス240に標的にされたデータパケットのための宛先アドレスとして使用され得る。本明細書中では、DNAクエリとして示されたが、さらに説明されるように、無線デバイス技術を処理するためにDNSクエリインプリメンテーションを修正し、および/または適切なルート可能アドレスを決定するために代替的なAPIを提供する。一旦、アドレス管理プロキシシステム220は、ワイヤードデバイス201へのルート可能なアドレスを戻すと、ワイヤードデバイス201は、データをそのアドレスに送信し得る。アドレス管理プロキシシステム220は、データを受信し、必要な場合、フォーマットおよびプロトコルを変換し、そして無線ネットワーク230を介して無線デバイス240に変換されたデータを送信する。
【0021】
図3は、例示的なアドレス管理プロキシシステムのコンポーネントの例示的なブロック図である。一実施形態では、アドレス管理プロキシシステム(AMPS)は、1つ以上の修正されたDNS’/APIサーバ302、1つ以上のアドレスプロキシ/ルータ305、アドレス管理データレポジトリ304等のデータベースまたは他のレポジトリを管理するアドレス管理データサーバ303、ならびに、随意にロードバランサ301を含む。DNS’/APIサーバ302は、パブリックネットワーク310に個々に接続されるか、または次いでパブリックネットワーク310に接続されるロードバランサ301に接続されるかのいずれかである。同様に、外部ネットワーク310からの、無線デバイスに向けられたデータが送信されるルート可能(パブリック)アドレスを介して、各アドレスプロキシ/ルータ305はまた、パブリックネットワーク310に接続される。DNS’/APIサーバ302は、無線デバイスと通信するために必要な機能性を加えるDNSサーバの修正されたインプリメンテーションであるか、または以下にさらに説明されるような1つ以上の専用APIをインプリメントするサーバであるかのいずれかである。DNS’/APIサーバ302は、無線デバイスに対する固有の識別子(例えばストリング名)をパブリックネットワーク310にマッピングする場合に支援するためにアドレス管理データサーバ303を使用する。パブリックアドレスのプールはまた、アドレス管理データサーバ303およびデータレポジトリ304によって保守される。アドレス管理データサーバ303およびデータレポジトリ304は、既存のデータベース技術(例えば、ODBC技術)を用いてインプリメントされてもよいし、簡単なテキストファイル等の構造としてインプリメントされてもよい。当業者は、テーブル、データ、リスト、またはマッピングを格納するための任意の実施形態が使用され得ることを認識する。各アドレスプロキシ/ルータ305はまた、アドレス管理データサーバ303またはその等化物を使用して、必要とされた場合、パブリックアドレスを無線デバイスに割り当て、そして無線デバイスのパブリックアドレスと、ルート不可能(プライベート)アドレスとの間に種々のマッピングを更新する一連のルーティングテーブルを作成かつ更新する。アドレス管理データサーバ303によって、DNS’/APIサーバ302およびアドレスプロキシ/ルータ305の代わりに保守されるテーブルおよびマッピングは、図6を参照しながら以下に説明される。
【0022】
AMPSの技術が一般的に無線デバイスと通信する任意のワイヤードデバイスに一般的に利用可能であるが、用語「パブリックネットワーク」(または「ワイヤードネットワーク」)は、一般的には、1つ以上のプライベートまたはパブリックネットワークに接続されたラインの下流(down)のいずれかにあるパブリックネットワークまたはバックボーンを含むインターネットワーク環境の任意のタイプを意味する。さらに、本明細書中で説明されたレイがしばしばインターネット(Internet)を指すが、当業者は、説明された概念および本発明が、例えばATMタイプのネットワークを含むインターネットワーキングの他の形態および実施形態に適用可能であることを認識する。従って、本発明の技術もまた、第2のネットワーク上の別の無線デバイスと通信する第1の無線ネットワーク上の1つのデバイスによって使用され得る。各デバイスは、他のネットワークのアドレスプロキシ/ルータとの通信を終了する。シナリオは実現可能である。なぜなら、各無線ネットワーク(またはキャリアインフラストラクチャ)は、パブリックネットワークにさらに接続されるプロキシ/ルータに接続されるためである。さらに、パブリックネットワークはまた、時には、本明細書中でワイヤードネットワークと呼ばれるが、当業者は、ルート可能な(パブリック)アドレスを露出する任意のネットワークが説明され得ることを認識する。従って、固有のパブリック(およびルート可能)アドレスを有する無線ネットワークもまた、双方向通信を実行するために本発明の技術を利用し得る。あるいは、当業者は、無線デバイス、電話、ハンドヘルド等の用語が、AMPSと共に動作することが可能である無線デバイスの任意のタイプを示すために交換可能に使用される。さらに、用語は、明示的に説明されてもされなくてもよい代替の綴りを有し得、当業者は、用語のこのような変更の全てが含まれるように意図されることを認識する。
【0023】
本明細書中で説明された例示的な実施形態は、双方向性通信のために使用される1つ以上のワイヤードネットワークおよび無線ネットワークを介して、プライベートアドレスからパブリックアドレスへのマッピングをインプリメントするために、アプリケーション、ツール、データ構造、および他のサポートを提供する。当業者は、本発明の方法およびシステムの他の実施形態が、情報および/またはデータ、あるいはコードを、パブリックネットワーク(インターネット(Internet)等)から無線デバイスにプッシュすることを含む多くの他の目的のために使用され得ることを理解する。さらに、この説明は、主にネットワークを介して送信される「データ」を指すが、当業者は、全てのタイプのデータが、以下に限定されないが、テキスト、グラフィックス、オーディオ、およびビデオを含む、本明細書中で説明された技術を用いて通信され得る。
【0024】
あるいは、以下の説明では、本発明の方法およびシステムの技術を理解することによって提供するために、データフォーマットおよびコード列等の複数の特定の詳細が以下に説明される。しかし、当業者は、本発明はまた、本明細書で説明されたいくつかの特定の詳細なしで、または他の特定の詳細(コードフローの順序に関する変化等)を用いて実施され得る。
【0025】
図4は、アドレス管理プロキシシステムの実施形態を実施するための汎用コンピュータシステムの例示的なブロック図である。汎用コンピュータシステム400は、1つ以上のサーバおよび/またはクライアントコンピューティングシステムを含み得、分散された位置に及び得る。さらに、各ブロックは、1つ以上のこのようなブロックを特定の実施形態に対して適切なように表わしてもよいし、他のブロックと組み合わせられてもよい。アドレス管理プロキシシステム410の種々のブロックは、互いに通信するために標準的なプロセス間通信メカニズムを使用する1つ以上のマシン上に物理的に常駐し得る。示された実施形態では、コンピュータシステム400は、コンピュータメモリ(「メモリ」)01、ディスプレイ402、中央処理装置(「CPU」)403、および入力/出力デバイス404を含む。メモリ401内に常駐するアドレス管理プロキシシステム410が示される。アドレス管理プロキシシステム410のコンポーネントは、好ましくは、CPU403上で実行し、前図で説明されたように、無線ネットワーク上の無線デバイスのアドレスマッピングを管理することによって、他のワイヤードシステムが無線デバイスと通信することを可能にする。他のダウンロードコード405および潜在的な他のデータレポジトリはまた、メモリ410に常駐し、好ましくは、1つ以上のCPU403上で実行する。典型的な実施形態では、AMPS410は、1つ以上のDNS’/APIサーバ411、1つ以上のアドレスプロキシ/ルータ412、アドレス管理データサーバ413、およびアドレス管理データレポジトリ414を含む。上述したように、AMPSは、特定のインプリメンテーションに依存するロードバランサ等の他のデータレポジトリおよびコンポーネントを含み得る。
【0026】
例示的実施形態では、AMPS410のコンポーネントは、DNSサーバおよびルータ等の既存のUDPベースの技術を修正することによってインプリメントされ、これらのコンポーネントは、典型的には、Cプログラミング言語で書かれたLinux/Unix(R)システム上でインプリメントされる。DNS’/APIサーバ411およびアドレスプロキシ/ルータ412へのインターフェースをプログラミングすることは、C、C++、C#、およびJava(R)APIおよびXML等のスクリプト言語、あるいはこれらを支援するウエブサーバを介して標準的な手段によって達成され得る。アドレス管理データサーバ413およびアドレス管理データレポジトリ414は、好ましくは、テキストファイルとしてではなく、データベースシステムとして拡張性の理由のために好ましくはインプリメントされ、SQL/ODBCデータベース管理システムを用いてインプリメントされ得る。DNS’/APIサーバ411およびアドレスプロキシ/ルータ412は、典型的には、Linux、UNIX(R)、あるいは他のUnix(R)ベースのまたはUnix(R)と同様のマシンを用いてインプリメントされる。当業者は、AMPS410が、複数の同種のコンピュータシステムおよびネットワークから構成される分散された環境においてインプリメントされ得ることを理解する。例えば、一実施形態では、DNS’/APIサーバ411、アドレスプロキシ/ルータコンポーネント412、アドレス管理データサーバ413、およびそのデータレポジトリ414は全て、物理的に異なるコンピュータシステムにおいて配置される。別の実施形態では、AMPS410の種々のコンポーネントは、別個のサーバマシン上の各々にホストされ、アドレス管理データレポジトリ414に格納されたテーブルからリモートに配置され得る。さらに、いくつかのシナリオにおいて、全体のAMPSシステム410は、キャリアインフラストラクチャ内部にホストされ、それに完全に組み込まれ得る。プログラムおよびデータの異なる構成および位置は、本発明の技術と共に使用するために企図される。例示的実施形態では、これらのコンポーネントは、同時にかつ非対称に実行し得、これにより、コンポーネントは、周知のメッセージ引渡し(passing)技術を用いて通信し得る。当業者は、等価な同時に起こる実施形態もまた、AMPSインプリメンテーションによって支援されることを認識する。あるいは、他のステップは、各ルーチンに対してインプリメントされ得、異なる順序および異なるルーチンでAMPSの機能をさらに達成する。
【0027】
アドレス管理プロキシシステムのコンポーネントに対するいくつかのインプリメンテーションアプローチが存在し、これらのアプローチの内の3つが、本明細書中で説明される。当業者は、種々の他のアプローチおよび組み合わせが可能であることを認識する。全ての3つのアプローチが、無線デバイスと通信するためにワイヤードデバイスによる一時的な使用に対してパブリック(ルート可能)ネットワークアドレスを割り当てる。一実施形態では、パブリックアドレスのプール(例えばパブリックIPアドレス)が保守され、必要に応じて無線ネットワークデバイスに動的に割り当てられる。例えば、典型的なクラスBインターネットネットワークアドレスブロックは、無線デバイスへの約65,000のシミュレーション接続を可能にする。この数は一見すると大きく見えるかもしれないが、携帯電話およびハンドセット(例えば、キャリアに接続された)の数を考慮すると、この数は、非常に制限され得る。
【0028】
第1のアプローチは、無線デバイスのためのパブリックアドレスマッピングを提供し、UDPプロトコルを用いてそれを利用可能にする。これは、格納および転送タイプのアプローチである。このアプローチの1つの利点は、このアプローチが無線接続を介して無線デバイスにUDPベースのトラフィックを容易にし、接続のパブリック側に接続されたデバイスがその接続を開始することを可能にする。しかし、欠点は、標準的なUDPプロトコルが修正を必要とするか、または追加のAPI呼び出しが追加されるかのいずれかにより、リクエストしているデバイスは、向けられた無線デバイスを識別し得る。これらの改変が必要である。なぜなら、UDPプロトコルは、IPアドレスの宛先を支援するだけであり、デバイスを固有に識別する代替的な手段(TCP/IPプロトコルと同様なストリング等)を提供しない。この(プライベート)アドレスを隠すことが望ましいために、標準UDPがデータを送信するための標準的なUDP呼び出しは、十分ではない。
【0029】
AMPSをインプリメントするために使用された第2のアプローチは、例えば、TCP/IPプロトコルを用いて、確立されたポイントツーポイント接続を介して完全な双方向通信を支援する(これらの同じ技術はまた、コネクションレスUDP双方向通信を支援することに留意すること)。第2のアプローチは、UDPまたはTCP/IP機能(GetHostByName)の修正されたインプリメンテーションを提供することによってインプリメントされ得る。GetHostByName APIは、ストリング指定が指定されたデバイスを識別することを可能にし、IPアドレスデータ構造を戻す。あるいは、提供されたセキュリティのレベルを増加させるために、AMPSは、特定されたAPIをインプリメントして、リクエストされた無線デバイスに(現在)対応している動的に割り当てられたパブリックアドレスを戻し得る。特定されたAPIアプローチの欠点は、パブリックネットワーク上のデバイス(または無線デバイスへの接続を取得することを望む他のデバイス)がリクエストしているデバイス上のアプリケーションにおける専用コードを含む。
【0030】
第3のアプローチは、第2のアプローチと同様であるが、「ポート」概念を使用するより大きい潜在的な同時接続を提供する。このアプローチを用いて、無線デバイス(アドレスプロキシ/ルータのパブリックアドレス)に対応するワイヤードネットワーク上のホストアドレスのみを戻す代わりに、AMPSはまた、ホストマシン(アドレスプロキシ/ルータ)上の特定のポート指定を戻す。ポートおよびそのインプリメンテーションは、当該分野において周知であり、一般的に、異なる場所に向けられたメッセージをトラッキングするために、データを受信するマシンによってインプリメントされたキューに対応する。データを受信するマシンは、ポート毎のベースで必要な順序付け、およびハンドシェーキング状態で、メッセージおよびハンドル中のポート指定に基づく異なる宛先にメッセージを転送する。
【0031】
ポートは、典型的には、単一の物理アドレス上に複数の仮想チャンネルを開くために使用され、潜在的に、単一の物理アドレスを別の約65,000の接続に拡張する。これは、AMPSが、例えばクラスC IPアドレスを使用することを可能にし、このアドレスは、典型的には、アドレスの他のタイプよりもはるかに安くかつ容易に利用可能であり、約1600万の無線デバイスへの同時接続を(UNIX(R)ベースのシステム)達成する。当業者は、利用可能なポートの数およびその特定のインプリメンテーションが、オペレーティングシステムに依存し、ポートアドレスを特定するために使用されたビット数に直接相関することを認識する。
【0032】
UDP(ならびにTCP/IP)プロトコルは、ポート抽象化(port abstraction)を支援するが、UDPおよびTCP/IPシステムを用いて使用された標準的なDNSクエリ(例えば、GetHostByName)は、ポート宛先の帰還を可能にせず、受信ルータの代わりに、リクエストデバイスまでポート宛先の制御を残す。従って、AMPSをインプリメントするための第3のアプローチに従って、ポートは、専用APIを用いてアドレスプロキシ/ルータによって好適に特定され、ホストマシン宛先を有するリクエストデバイスに戻される。
【0033】
一実施形態では、XML等のスクリプト言語インターフェースは、専用アドレスマッピング機能とインターフェースを取るように専用API(コードインターフェース)の代わりに使用され得る。XMLを用いると、DNS’/APIサーバは、XMLポストイベントとしてAPI呼び出しを受け取り、XMLフォーマットされた応答を戻す。他の言語モデルおよび/または他のプログラミング言語を用いるマッピング機能を呼び出すための同様な支援もまた企図され、本発明の技術と共に動作する。XMLタイプのインターフェースは、APIをそのソフトウエアに統合するリクエストデバイスのコストを最小化する。
【0034】
さらに、専用APIを用いると、リクエストデバイスは、必要とされたさらなるコーディング労力を有さないプライベート無線デバイスにさらなるデータをプッシュし得る。例えば、ワイヤードデバイスを用いて確立された接続のタイプの無線デバイスをビリングするために向けられるビリングコードがこの技術を用いて無線デバイスにプッシュされ得る。例示的なビリングコードメカニズムは、2002年2月26日に出願された、「Method and System for Transmission−Based Billing of Application」と題された米国特許出願第10/085,981号に開示される。
【0035】
UDPおよびTCP/IPの標準的なGetHostByName APIではなく専用APIを使用する願望をさらに示し得るいくつかのセキュリティに関連する理由が存在する。これらのセキュリティに関連する理由は、専用APIをさらに必要とするポートベースのメカニズムを使用する願望を示し得る。第1に、「GetHostByName」 APIおよびルータプロトコルを使用する任意の双方向通信は、そのホスト名に関連付けられたサービス(DOS)攻撃の拒否の影響を受ける。DOS攻撃は、利用可能である十分なパブリックアドレス(プロキシ/ルータマシンアドレスの)可能性を精算(close out)するように同じ入力パラメータを有する同じGetHostByNameを特定する1つ以上のマシンノ結果として発生し得る。第2に、GetHostByName(または任意の他の規格)の使用はまた、AMPSを、DNSゾーン転送の結果としてセキュリティ攻撃を受けやすくする。例えば、リクエストされたホスト名を見出すために、1つのDNSがDNSクエリを1つ以上の他のDNSサービスを転送する場合、DNSゾーン転送が発生する。1つの典型的なシナリオは、国から国への複数のDNSホップを含む。DNSゾーンのサーバ攻撃の考えは、不正なDNSサーバとして不正なコードを挿入することによって特定のDNSサーバ上に情報をキャプチャし、宛先アドレスを偽装することである。第3に、接続の継続時間に対する不注意は、権限のないリクエストデバイスに対してデータを利用可能にし得る。特に、パブリックデバイスと無線デバイスとの間にマッピングが確立されるために、パブリックデバイスは、パブリックデバイスよりも長く存在するマッピングが、誤ったデバイスとの通信を実際に行いかつ潜在的に終了する(不正にまたはそうでなく)ことを想定し得る。これは、いくつかのDNSサーバインプリメンテーションは、タイムツーライブ(Time to Live)セッティングを無視するためである。DNSサーバインプリメンテーションが修正されたDNSサーバインプリメンテーションを有するために、標準的なGetHostByName API、または専用APIをインプリメントするかしないかにかかわらず、プライベートアドレスとパブリックアドレスとの間の確立されたマッピングのTTL特性によって継続することによってこの問題を避ける。
【0036】
図5〜図8は、図2および図3を参照しながら説明された機能性を達成するために、DNS’/APIサーバおよびアドレスプロキシ/ルータによってインプリメントされた特定のルーチンの種々の例示的実施形態を説明する。図5は、アドレス管理プロキシシステムを用いるプライベート無線ネットワーク上に配置された無線デバイスにデータを送信するためのパブリックネットワーク上のデバイスによって実行されたプロセスの例示的なフローチャートである。ステップ501では、ソース(例えば、ワイヤード)デバイスは、AMPSから指定された無線デバイスのためのパブリック(ルート可能)アドレスを必要とする。上述のように、このようなアドレスを検索するための1つのメカニズムは、AMPSが、修正されたGetHostByNameルーチン等のDNSサービスのための修正されたインターフェースをインプリメントすることである。例えば、GetHostByNameルーチンは、ストリングの形態で、固有の無線デバイス指定を特定するために呼び出され得る。このストリング「personname.phone.wsp.com」は、省略された「wsp.com」である無線サービスプロバイダのウエブサイト(DNS)において配置された「phone」の電話番号を用いて、「person」の名前によって人に対応する無線デバイスを示す例示的なストリングである(例えば、susan.ph2065551212.sprint.comは、スプリントネットワーク上の電話番号206 555 1212を有する人Susanを指す)。AMPSによってインプリメントされ得る別のメカニズムは、別個の(特殊化された)API(「GetProxyIP」等)を提供することであり、APIは、指定された無線デバイスに対応するパブリック(ルート可能)アドレスの表示を戻す。別個のAPIを使用することは、セキュリティの理由のために使用可能である。例えば、違法なデバイスが詐欺(sppofing)によってルート可能なアドレスを傍受することが困難になる。別の理由は、アドレスプロキシ/ルータのホストアドレスに加えて、ポート宛先を提供することができるような、戻されたアドレス情報の実際のフォーマットを制御することである。GetHostByNameまたはGetProxyIP等の専用APIのいずれかのインプリメンテーションによって、図7を参照して以下にさらに説明される。
【0037】
ステップ502では、一旦、無線デバイスのパブリックアドレスがAMPSによって戻された場合、ソースデバイスは、表示されたアドレス情報から実際のアドレス位置(IPdata.jp)、タイムツーライブ(Time to Live)パラメータ(IPdata.TTL)、および、標準GetHostByName APIが使用されない場合、随意に、例えば、利用可能なポート宛先(IPdata.port)を抽出する。ステップ503では、ソースデバイスが無線デバイスとの接続ベースの通信を実行することを望む場合、ソースデバイスは接続(ソケット等)を開く。ステップ504では、タイムツーライブパラメータが無線デバイスの戻されたパブリックアドレスが終了したことを特定するかどうかをワイヤードデバイスが決定し、タイムツーライブパラメータが無線デバイスの戻されたパブリックアドレスが終了したことを特定するかどうかをワイヤードデバイスが決定する場合、異なるアドレスをリクエストするステップ501に戻り、タイムツーライブパラメータが無線デバイスの戻されたパブリックアドレスが終了したことを特定するかどうかをワイヤードデバイスが決定しない場合は、ステップ505を継続する。タイムツーライブパラメータは、無線デバイスのパブリックアドレスがその無線デバイスの有用性期間を超えないことを確実にするようにAMPSによって使用される(無線ネットワークに常時接続され、そして電源をオンされてもよいし、されなくてもよい)。いくつかの実施形態では、非常に短いTTLパラメータが使用されることによって、ワイヤードデバイスが特定のパブリックアドレス上の動作性(activity)をモニタし、次いで他の目的にためにそのアドレスを使用することを可能にするセキュリティ違反を回避する。ステップ505では、ワイヤードデバイスは、データパケット(接続を介するかまたは接続を介さずに)を無線デバイスに送信する。示されないが、ワイヤードデバイスおよび無線デバイスは、使用された転送プロトコル(例えばUDPまたはTCP/IP)において特定された標準的な呼び出しを使用して通信することが推定される。ステップ506では、データトランザクションが終了する場合、ワイヤードデバイスが処理され、データトランザクションが終了しない場合、ワイヤードデバイスが戻って、より多くのデータを送信するために、ステップ504においてTLパラメータをチェックする。
【0038】
以下の表1は、アドレス管理プロキシシステムを用いて電話番号「2065551212」によって識別されたユーザに対応するパブリックアドレスを取得するために、どのようにしてパブリック(リクエスト側)デバイスが、図5に説明されたような修正されたGetHostByNameクエリを使用し得るかを示す1つの例示的インプリメンテーションを説明する擬似コードを含む。パブリックデバイスの観点から、標準UDPおよびTCP/IP呼び出しは、標準的な態様で呼び出される。
【0039】
【表1】
以下の表2は、同じ電話番号によって識別されたユーザのアドレスを取得するためにパブリック(リクエスト側)デバイスによって使用されたような図5に示された専用APIメカニズムの例示的なインプリメンテーションを説明する擬似コードを含む。表2では、パブリックデバイスは、専用API(GetProxyIP)を呼び出し、アドレス/プロキシサーバの割り当てられたパブリックアドレスを含む必要な情報を含むデータ構造を獲得する。その後、パブリックデバイスは、データを送信するために同じ技術を使用し得る(標準的なUDPまたはTCP/IPプロトコル)。
【0040】
【表2】
図6は、DNS’/APIサーバおよびアドレスプロキシ/ルータのルーチンを支援するために使用されたアドレス管理プロキシシステムデータレポジトリテーブルのいくつかの例示的なブロックの図である。一実施形態では、アドレス管理データレポジトリは、3つのテーブルを含む。すなわち、プライベートアドレステーブル610への固有の識別子(固有のID)、パブリックからプライベートへのアドレステーブル630、プロキシ/ルータマシンテーブル620へのパブリックアドレスである。3つのテーブルが示されるが、当業者は、これらのテーブルが他のデータを含み、異なる数のテーブル、ならびに異なるカラムまたはフィールドを含むこれらのテーブルが異なって構造化され得ることを認識する。さらに、データのテーブルまたはリストを格納するための任意の技術が使用され得る。ポート指定者を加えたホストアドレスを無線デバイスにマッピングする実施形態を支援するために、テーブルはそれに従って修正される。
【0041】
固有のIDテーブル610は、無線デバイスの固有のストリング名をキャリアのインフラストラクチャに典型的に割り当てられるプライベート無線ネットワークアドレスにマッピングする。いくつかの実施形態では、キャリアインフラストラクチャは、DHCPプロトコルと同様の方法を用いて、無線デバイスが電源投入された場合、キャリアインフラストラクチャにデバイス自体を登録する場合、DHCPプロトコルと同様の方法を用いて、プライベートネットワークアドレスを動的に割り当てる。従って、固有のIDテーブル610が散在して満たされ、エントリが動的に作成され、次いで、キャリアインフラストラクチャシステムに登録および登録削除(unregister)する場合、動的に削除され得る。
【0042】
パブリックプライベートアドレステーブル630は、パブリックネットワークアドレス631、プライベート(無線)ネットワークアドレス602、フィールド631に格納されたパブリックアドレスが空いているか、または既に使用されているかを特定するフラグ632、タイムツーライブ(TTL)パラメータ633、および他の接続データ634を含むいくつかのフィールド/カラムを含む。一実施形態では、AMPSクエリテーブル630のDNS’/APIサーバは、指定されたプライベート無線ネットワークアドレスに対応するパブリックネットワークアドレスを決定するか、または未使用のパブリックネットワークアドレスを割り当て(フィールド632に示される)、そして決定された未使用のパブリックアドレスをフィールド602において格納されたプライベートネットワークアドレスにマッピングする。
【0043】
プロキシ/ルータマシンテーブル620へのパブリックアドレスは、パブリックネットワークアドレスフィールド631および機能プロキシ/ルータマシン621の表示を含む。このようなマッピングを保守することによって、AMPSは、プロキシ/ルータマシンを他のプロキシ/ルータマシンと置換することを可能にし、高い程度のロバスト性を提供する。各プロキシ/ルータマシンは、例えば、プロキシ/ルータマシンに挿入されたネットワークカードによって典型的に構成される、パブリックネットワークアドレスの予め構成されたセットを有する。これらのアドレスは、購入前を介してまたはアドレス認証局(adress authorizing authority)(現在では、Internet Corporation for Assigned Names and Numbers(ICANN))から得られる標準的な態様で割り当てられる。マシンが使用するためにAMPSに挿入される場合、これらのアドレスの表示は、フィールド631に格納される。
【0044】
一実施形態では、パブリックネットワークアドレスとプライベートアドレスとの間のマッピングのタイムスタンプもまた、テーブル630に示される。定義されたタイムアウトの後、このタイムスタンプに基づいて、アドレス管理データサーバは、パブリックからプライベートマッピングをマッピングしないマッピングに関連付けられたアドレスプロキシ/ルータにリクエストを送信し、それにより未使用のパブリックネットワークアドレスのプールに関連付けられたパブリックアドレスを戻す。
【0045】
図7は、指定された固有の識別子に対応するパブリックアドレスを戻すために、アドレス管理プロキシシステムのDNS’/APIサーバによって提供された例示的なルーチンの例示的なフローチャートである。本質的には、このルーチンは、図5を参照して示されたような修正されたGetHostByNameインターフェースまたは専用API(例えばGetProxyIP)を用いて、AMPSのDNSクエリまたはDNSと同様のクエリ能力をインプリメントする。要するに、ルーチンは、無線デバイスに関連付けるために適切なアドレスプロキシ/ルータマシンを動的に割り当て、そのマシン(TTLパラメータおよび潜在的に他のパラメータと共に)のパブリックアドレスを戻す。特に、ステップ701では、ルーチンは、ルーチンへの入力として通過されたストリングパラメータによって指定された無線デバイスのプライベート(ルート不可能)アドレスを決定する。例えば、ストリングパラメータは、「uniqueID.hostname.domain.tld」等のフィールドを使用し得、「org」、「com」、「edu」等の上位ドメイン上の会社のネットワーク等のドメイン上で「hostname」と命名されたマシン上の人/サービスの典型的な階層を特定する。当業者は、多くの他のストリングパラメータ指定が使用され得ることを理解する。このルーチンをインプリメントするための1つのメカニズムは、アドレス管理データレポジトリから情報をリクエストすることである。一実施形態では、データレポジトリは、固有のIDをプライベートネットワークアドレスにマッピングするテーブルを格納する(図6のテーブル610を参照)。好ましくは、AMPSによって使用される任意のメカニズムは、無線ネットワークアドレスを秘匿にするためにセキュアな態様でこのデータを格納する。ステップ702では、AMPSによってそのデバイスに既に割り当てられ、依然として有効である場合、ルーチンは、指定されたデバイスのプライベート無線ネットワークアドレスに対応するパブリックネットワークアドレスを検索する。一実施形態では、データレポジトリは、プライベートワイヤレスネットワークアドレスとパブリックネットワークアドレスとの間でこのマッピング情報を格納する(図6のテーブル630を参照)。パブリックネットワークアドレスは、既に割り当てられていないか、または有効でない場合、ルーチンは、新しいパブリックネットワークアドレスを割り当てさせ、新しいパブリックアドレスは、プライベート無線ネットワークアドレスに関連付けられる。次いで、データレポジトリにおける適切なテーブルが更新される。ステップ703では、ルーチンは、割り当てられたパブリックネットワークアドレスに関連付けられるアドレスプロキシ/ルータマシンを決定する(例えば、図6のテーブル620を用いて)。ステップ704では、ルーチンは、決定されたパブリックネットワークアドレスをプライベートワイヤレスネットワークアドレスにマッピングするためにそのルーティングテーブルを更新するように、決定されたパブリックネットワークアドレスに送信する。ステップ705では、ルーチンは、任意の他の接続連携情報(例えば、図6のテーブル630におけるフィールド634)を含むようにデータレポジトリ内の情報を更新し、パブリックプライベートアドレス関係のためのタイムツーライブ(TTL)パラメータ(例えば、図6のテーブル630におけるフィールド633)を含む。一旦、全てのテーブルがプロキシ/ルータおよびデータレポジトリの両方において更新されると、DNS’/APIサーバは、関連付けられたアドレスプロキシ/ルータマシンの決定されたパブリックネットワークアドレスを戻す。初期に説明されたように、ポートベースのインプリメンテーションが使用された場合、パブリックアドレスは、対(ホスト名、ポート)であり得る。
【0046】
図8は、データを受信する例示的なアドレス管理プロキシシステムのアドレスプロキシ/ルータ内部の例示的なルーチンの例示的なフローチャートである。このルーチンは、相対的なプロトコル(例えば、TCP/IP、UDP/IP等)を用いてワイヤードデバイスからデータを受信するためにアドレスプロキシ/ルータによってインプリメントされる(データは、特定のアドレスプロキシ/ルータに送信される。なぜなら、そのアドレスプロキシ/ルータのパブリック(ルート可能)アドレスは、AMPSのDNS’/APIサーバのクエリに応答してリクエスト/ソースデバイスに戻される)。プロキシ/ルータは、有線ネットワークから無線ネットワークにデータを送信するのに必要なデータの任意の変換の原因となる(例えば、キャリアインフラストラクチャは、このレベルで実行されるべき変換等を望む場合)。プロキシ/ルータはまた、プロキシ/ルータを呼び出すために使用されたパブリックアドレスに対応する無線デバイスのプライベート無線アドレスの無線ネットワークを介してデータを無線デバイスのプライベート無線アドレスに転送する原因となる。
【0047】
特に、ステップ801では、ルーチンは、呼び出されたパブリックアドレスに対応するプライベート無線アドレス、およびマッピングに関連付けられたTTLパラメータを(例えば、アドレス管理データレポジトリから)決定する。これらの値は、例えば、図6のパブリック/プライベートアドレステーブル630から獲得され得る。ステップ802では、ルーチンは、決定されたTTLパラメータの値は、マッピングが終了したかどうかを決定し、マッピングが終了した場合、エラーを戻し、マッピングが終了しない場合、ステップ803を継続する。ステップ803では、ルーチンは、ターゲットデバイスによって必要とされたフォーマットを決定する(無線ネットワークフォーマット)。ステップ804では、ルーチンは、任意のプロトコル変換が必要であるかどうかを決定し、任意のプロトコル変換が必要である場合、ステップ805を継続し、任意のプロトコル変換が必要でない場合、ステップ806を継続する。データの「HTTP」パケットへの変換等の特定の無線ネットワークに対するプロトコル変換は、プロキシ/ルータによってなされてもよいし、キャリアインフラストラクチャ内のいくつかの他のコンポーネントによってなされてもよいことに留意すること。当業者は、例示的なステップが存在し、異なるフォーマットまたは異なるプロトコル変換ルーチンが、環境に特有なものとして追加または削除され得る。ステップ806では、アドレスプロキシ/ルータルーチンは、データパケット(必要に応じて、データパケットがフォーマットされ、そのプロトコルが変換される)を無線デバイスの所定の関連したプライベートアドレスに送信し、そして戻す。
【0048】
上述から、説明する目的で本発明の特定の実施形態が説明されてきたが、種々の改変が本発明の精神および範囲から逸脱することなくなされ得る。例えば、当業者は、本明細書中で説明された双方向通信を確立するための方法およびシステムが、インターネット(Internet)、TCP/IP、およびUDP、あるいは、さらに複数のこのようなネットワーク以外のパブリックネットワークおよびプロトコルの他のタイプに適用可能である。例えば、パブリックアドレスマッピングへのプライベートアドレスはまた、無線デバイスを有するATMネットワーク上でデバイスを接続するATMに提供され得る。当業者はまた、本明細書中で説明された方法およびシステムが、異なるプロトコル、通信メディア(光、無線、ケーブル等)、無線デバイス(無線ハンドセット、電子オーガナイザー、パーソナルデジタルアシスタント、ポータブル電子メールマシン、ゲーム機、ポケットベル、GPS受信器等のナビゲーションデバイス等)、異なるワイヤードデバイス(キオスク、パーソナルコンピュータ、メインフレーム)、およびワイヤード接続能力(例えば、同期化目的のためのドッキングステーションに接続され得る無線電子メール、またはPDAデバイス)に適用可能である。
【0049】
以上のように、本発明の好ましい実施形態を用いて本発明を例示してきたが、本発明は、この実施形態に限定して解釈されるべきものではない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。当業者は、本発明の具体的な好ましい実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。本明細書において引用した特許、特許出願および文献は、その内容自体が具体的に本明細書に記載されているのと同様にその内容が本明細書に対する参考として援用されるべきであることが理解される。
【図面の簡単な説明】
【0050】
【図1】図1は、TCP/IPおよびUDP/IPを用いるデータパケットを送信するための基本的なインターネット(Internet)またはインターネット通信の例示的なブロック図である。
【図2】図2は、無線デバイスを用いる双方向通信において使用された例示的なアドレス管理プロキシシステムのブロック図である。
【図3】図3は、例示的なアドレス管理プロキシシステムのコンポーネントの例示的なブロック図である。
【図4】図4は、アドレス管理プロキシシステムの実施形態を実行するための汎用コンピュータシステムの例示的なブロック図である。
【図5】図5は、アドレス管理プロキシシステムを用いるプライベート無線ネットワーク上に配置された無線デバイスにデータを送信するために、パブリックネットワーク上のデバイスによって実行されたプロセスの例示的なフローチャートである。
【図6】図6は、DNS’/APIサーバおよびアドレスプロキシ/ルータのルーチンを支援するために使用されたいくつかのアドレス管理プロキシシステムデータレポジトリの例示的なブロック図である。
【図7】図7は、指定された固有の識別子に対応するパブリックアドレスを戻すために、アドレス管理プロキシシステムのDNS’/APIサーバによって提供された例示的なルーチンの例示的なフローチャートである。
【図8】図8は、データを受信する例示的なアドステップ管理プロキシシステムのアドレスプロキシ/ルータ内部の例示的なルーチンの例示的なフローチャートである。
【0001】
(発明の背景)
(発明の分野)
本発明は、無線デバイスとの通信を開始するための方法およびシステムに関する。特に、仮想端末間接続を達成するためにパブリックネットワーク上のデバイスからプライベートネットワーク上のデバイスとの通信を開始するための方法およびシステムに関する。
【背景技術】
【0002】
(背景技術)
他のネットワークのコンピュータと共にネットワーク上のコンピュータを接続するための必要性は、グローバル社会がビジネスおよび個人的な理由のために国際的なレベルで通信するように努めるに伴ってますます重要になってきている。この必要性は、物理的に異なるネットワーク上でデバイスを相互接続するための方法を生み出す技術的共同体を刺激することにより、同種のネットワークおよび異種のネットワークが統一の(または標準的な)態様として互いに通信し得る。このような相互接続技術は、しばしば、「インターネットワーキング」、「インターネットワーク」、または単に「インターネット」と呼ばれる。1つのこのようなグローバルインターネットワーキングインプリメンテーションは、教育的および行政目的のためのARPA、NSF等によって、本来開発されたインターネット(Internet)(頭文字は、一般的に「インターネット」と区別するように大文字で書かれる)である。現在拡張されたバージョンのインターネット(Internet)は、世界中のネットワークに接続するネットワークバックボーンの複雑なインフラストラクチャとして存在する。他の(ローカル、広域、プライベート、またはパブリック)ネットワークは、ゲートウエイまたはルータ(ゲートウエイサーバ、ゲートウエイシステム、ルータサーバ、およびルータシステムとしても公知である)によってインターネットバックボーンに接続する。このドキュメントの目的のために、単独で使用されるかまたは別の名詞を修正するために、用語「ルータ」または「ゲートウエイ」は、交換可能に使用され、一般的に任意のハードウエアまたはソフトウエア、サブシステム、システム、あるいは、2つ以上の同種のまたは異種のマシン、システム、またはサブシステムの間で、特定のゲートウエイ/ルータマシンまたはサービスにかかわらず、(任意のレベルのネットワークまたは物理データ転送において)データパケットを転送することを可能にするコードを指す。インターネット(Internet)環境では、ルータまたはゲートウエイの存在は、典型的には、インターネットデータグラムを別のルータまたはマシンにルーティングする能力を示す。アプリケーションを走行することが意図されたマシンは、本明細書の目的のために、ネットワーキング用語を用いて、一般的に「ホスト」または「ホストマシン」と呼ばれ、ルータ/ゲートウエイは、ホストマシンの機能であってもよいし、別個のデバイスであってもよい。
【0003】
インターネット環境では、種々のネットワークおよびデバイスが、TCP/IP(またはUDP/IP)等の標準ネットワークプロトコルおよびモデルを用いて通信する。本ドキュメントの目的のために、読者は、ネットワーキング概念、プロトコル、および規格に精通していることが推定されるが、簡単な要旨が簡略化のために本明細書中で提供される。インターネットワーキング、インターネット、インターネット(Internet)の拡張バックグランド情報、ならびに関連用語および背景技術は、Tanenbaum,A.,による、Computer Networks,Prentice−Hall,N.J.,第3編、1996年、およびComer,D.,による、Internetworking with TCP/IP,Principles,Protocols,and Architectures,Prentice Hall,N.J.,第4編、2000年に見出され得る。
【0004】
TCP/IPおよびUDP/IP(または、しばしば「UDP」と呼ばれる)は、一般的なトランスポート層およびネットワーク層プロトコルの組み合わせを指し、これらは、インターネットワーキング環境(他のプロトコルは、これらの層の各々に対して同様に利用可能である)において通常見出される。TCP/IPの「IP」は、「インターネットプロトコル」を指し、そしてどのようにしてデータが構造化かつ提示されるか(データグラムのフォーマットおよび意味)を定義するネットワーク層プロトコル、ならびにデータをルーティングするために使用される通信トランザクションである。IPプロトコルの上位にインプリメントされ得るトランスポート層プロトコルであるTCP(「転送制御プロトコル」)およびUDP(「ユーザデータグラムプロトコル」)の両方は、それぞれコネクションベースのデータ転送およびコネクションレスデータ転送を支援する。コネクションベースのデータ転送は、ソースおよび宛先デバイスがコネクションをリクエストし、その後、シーケンス(および典型的には、ハンドシェイキングメカニズムを含む)態様で「仮想」コネクションを介して互いにデータを送信することを意味する。本明細書中で用語「仮想」は、コネクションが必ずしもハードワイヤードではないが、ソース(リクエスト側)と宛先(受信側)との間の直接コンジット(conduit)を提供するように見えることを意味する。データは、実際には、物理転送媒体を介して最終的には転送されるより低いプロトコル層を介して流れる。コネクションレスデータ転送は、ソースがデータグラムを宛先に送信するが、配信を保証しないか、またはデータが特定の順序で到着することを意味する。
【0005】
IPプロトコルはまた、統一のネットワークアドレシングメカニズムを定義することにより、IPを使用するプロトコル(TCPまたはUDP等)をインプリメントするマシンが、そのデータ転送のためのソースおよび宛先を特定することができる。ネットワークアドレシングメカニズムは、抽象(abstract)アドレスおよびこの抽象アドレスを物理ハードウエアアドレスにマッピングするためのバインディングプロトコルを特定する。本説明の目的のために、均一ネットワークアドレシングメカニズムは、一般的に「IPアドレス」と呼ばれる。しばしば、IPアドレスは、「ドット付き10進」表記で書かれ、この表記は、アドレスを「w.x.y.z」(例えば、32ビットのアドレスでは、各文字は、情報のバイトを表す)として特定する。例えば、「192.251.0.1」等のIPアドレスは、ネットワーク「192」、サブネット「251」、およびドメイン「0」におけるホストマシンを特定し得る。IPを用いると、典型的には、アドレスの範囲がプライベートネットワーク使用のために予約され、残りのIPアドレスは、他の使用または他のパブリック(ルート可能な(routable))アドレスのいずれかのために予約され、これらのアドレスは、管理機関(authority organization)によって割り当てられる。多数のプライベートネットワークは、同一の(ルート不可能)IPアドレスを内部に割り当てるが(現在では、Internet Corporation for Assigned Names and Numbers、ICANN)、固有のパブリックIPアドレスを使用してインターネット(Internet)に接続する。例えば、クラスBネットワーク(クラスベースのアドレシング規約を用いることは、それぞれ254までのホストマシンを可能にする)では、プライベートアドレスは、192.168.00〜192.168.255.0までの範囲にわたり得る。アドレシング規約は、当業者に周知であり、読者に公知であると推定される。この用途の目的にために、IPアドレスは、どんなアドレスであっても特定の内部ネットワーキング環境で意味を成す(そして定義されている)ことが理解されているが、インターネット(Internet)IPアドレシングを使用する例が参照され得る。
【0006】
IPを支援するネットワークは、IPアドレスに基づく別のルータまたはホストマシンにデータを転送するルータを提供することによって、別のTCP/IPベースまたはUDP/IPベースのインターネット、あるいはインターネット(Internet)に接続され得る。ルータ(またはルーティングサーバ/サービス)は、典型的には、ルーティングテーブルを含み、このルーティングテーブルは、宛先IPアドレスが与えられたどのマシン(そして任意にどのポートが)がデータグラムを送信するかを決定する。IPアドレスは、ルータ/ホストマシンを唯一に識別し、典型的なTCP/IPネットワークでは、例えば、より長いドメインの一部として特定のマシンを識別するストリング名にマッピングされ得る。(本明細書中では、しばしばTCP/IPベースのネットワークと呼ばれるが、当業者は、このネットワークもまたUDPベース(コネクションレス)であり、そして別のセッション管理システムを支援し得ることを認識する。)
典型的なTCP/IP(インター)ネットワークでは、マシンは、ネーミング(naming)階層に従って構造化される。1つのこのような階層は、Domein Name System(「DNS」)であり、これは、どのようにして特定のマシンが他のマシンに接続されているかを特定する。(用語DNSは、時には、DNSプロトコルをインプリメントするサーバまたはサービスを識別するためにさらに使用される。)例えば、ストリング「initial_machine.4thpass.service_provider.com」は、属しているマシンを特定するために使用され得、4thpass companyのLANに接続され、次いで、service_providerのWAN(ワイドエリアネットワーク)に接続される。TCP/IPおよびUDP/IPは、クライアントシステムのためのツール/ライブラリを定義し、特定のルータ/マシンのストリング名が与えられるIPアドレス(インターネット上の論理アドレス)を決定するために使用する。1つのこのようなツールは、DNSクエリ(query)と呼ばれ、例えば、「GetHostByName」と呼ばれるAPIを含む。GetHostByNameは、ストリングが与えられるIPアドレスを戻す。特定の構造、ネットワーク、またはサブネットワークのためのDNS規格をインプリメントするサーバマシンは、本明細書中では単にDNSと呼ばれるが、DNSサービスは、単一の物理マシン上の他のネットワーキングサービスと関連して提供され得る。
【0007】
図1は、TCP/IPまたはUDP/IPを用いてデータパケットを送信するための基礎的なインターネット(Internet)またはインターネットの例示的なブロック図である。図1では、ワイヤ102を介してインターネット(Internet)110に接続されたホストマシン101が示される。例えば、ローカルエリアネットワーク(LAN)であり得るプライベート(またはパブリック)ネットワーク130に接続されたホストマシン140および141等の他のワイヤードデバイスが示される。ネットワーク130上のデバイスは、さらなるマシン(ルータ21)によってインターネット110を介して通信し、ワイヤ(例えば電話回線)を介して接続されたルータが示される。ワイヤを介してさらにインターネット(Internet)110に接続されたDNSサーバ120が示される。基本的な典型的な動作では、データパケットをデバイス140に送信する(TCPまたはUDPを介して)ことを意図するソースデバイス(ホストマシン)101は、最初に、デバイス140を表すストリング名に対応するIPアドレスを取得するためにDNSクエリを実行する。例えば、「initials_machine.4thpass.service_provider.com」にデータを送信するために、DNS120は、「4thpass.com」のためのDNSサーバに対応し得る。このサーバは、どのようにしてその「ドメイン」(例えば「initials_machine」)のマシンを位置付けるかを知っており、その対応するパブリックIPアドレスを検索し得る。正確な(パブリック)IPアドレスを決定すると、DNS120は、このアドレスをソースデバイス101に戻す。次いで、ソースデバイス101は、宛先デバイス140との通信のためにTCP接続を開始するか、または戻されたパブリックIPアドレスを用いてコネクションレスプロトコルを介してパケットを送信するかのいずれかを行い得る。
【発明の開示】
【課題を解決するための手段】
【0008】
(発明の簡単な要旨)
本発明の実施形態は、例えば、TCP/IPおよびUDP/IP等の接続ベースまたはコネクションレスプロトコルを用いて、無線デバイスとの双方向で開始する双方向通信のためのコンピュータおよびネットワークベースの方法を提供する。例示的な実施形態は、これらの無線デバイスのルート不可能なプライベートアドレスを暴露することなく、パブリック内部ネットワークに接続されたデバイスおよびシステムが、プライベート無線ネットワークに接続された無線デバイスとの通信を開始し、無線デバイスにデータを送信することを可能にするアドレス管理プロキシシステム(「AMPS」)を提供する。AMPSは、プライベート無線ネットワーク上の無線デバイスと通信するために、外部パブリックネットワーク上のデバイスをリクエストすることによって、一時的使用のためのパブリック(ルート可能)ネットワークアドレスを割り当てる。一実施形態では、パブリックアドレスのプールは、例えば、パブリックIPアドレスが、必要とされる場合、AMPSによって保守され、そして無線ネットワークデバイスに動的に割り当てられる。一時的なパブリックアドレスの無線デバイスのプライベートアドレスへのマッピングが、ルーティングテーブルおよび他のマッピングデータ構造を用いて、AMPSによって容易に保守され、更新される。
【0009】
一実施形態では、AMPSは、1つ以上の修正されたDNS/APIサーバ、1つ以上のアドレスプロキシ/ルータ、アドレス管理データサーバ、1つ以上のアドレス管理データレポジトリ、および随意にロードバランサを含む。AMPS DNS’/APIサーバは、特定の無線デバイスのためのパブリックネットワーク上のデバイスからリクエストを受信し、無線デバイスのプライベートアドレスに内部にマッピングされる適切な一時的なパブリックアドレスを戻す。次いで、パブリックアドレスは、データを無線デバイスに送信するために外部パブリックネットワーク上のデバイスによって利用可能にされる。例えば、一時的なパブリックアドレスは、外部パブリックネットワークに接続され、プライベート無線ネットワーク上のプライベートアドレスへのアクセスを有するアドレスプロキシ/ルータの内の1つに関連付けられたアドレスである。いくつかの場合では、無線デバイスにデータを送信することを望むパブリックネットワーク上のデバイスが接続ベースのプロトコル(データを送信するためのTCP/IP等)を使用する。他の場合では、デバイスは、データを送信するためのUDP(UDP/IP)等のコネクションレスプロトコルを使用する。
【0010】
1つのアプローチに従って、AMPSは、標準クエリ機能(GetHostByName等)への呼び出しの結果として戻される修正されたDNSサーバを提供する。別のアプローチでは、AMPSは、パブリックネットワーク上のデバイスのための専用APIをインプリメントして、指定された無線デバイスのパブリックアドレスにクエリするために使用する。インターネット(Internet)プロトコルと共に専用APIインプリメンテーションを用いることによって、AMPSは、IPアドレスのみを含むアドレスにプライベートアドレスをマッピングしてもよいし、対(IPアドレス、ポート)にマッピングしてもよい。この後者のインプリメンテーションは、特定のパブリックアドレス空間の利用性を拡張し得る。
【0011】
AMPS技術は、プライベートまたはパブリックネットワーク上のワイヤードデバイスによって、ならびに、デバイスが、アドレスしそしてAMPSによってアドレスされ得るパブリックネットワークに接続される限り、ソースデバイスの能力で機能するネットワーク上の無線デバイスによって使用され得る。従って、AMPSメカニズムは、互いに通信するために異なるプライベート無線ネットワーク上のデバイスによって使用され得る。さらに、AMPSメカニズムは、ATMネットワーク等の他の内部ネットワーク、ならびにTCP/IPまたはUDP以外のデータ転送プロトコルと共に使用され得る。
【0012】
より大きい程度のセキュリティを保証するために、一実施形態によると、AMPSは、各アドレスマッピングを有するタイムツーライブ(Time to Live)(TTL)パラメータを保守する。この方法では、一旦TTL値がマッピングが終了したことを示す場合、AMPSは、マッピング、そしてさらに任意の接続を破壊し得る。さらにいくつかの実施形態では、AMPSはまた、マッピングテーブル自体にタイムスタンプを置く。タイムスタンプに基づくいくつかのタイムアウト期間の後、AMPSは、マッピングを破壊し得ることにより、新しいマッピングに期間ベースで開始させる。
【0013】
(発明の詳細な説明)
本発明の実施形態は、例えば、TCP/IPおよびUDP/IP等の接続ベースまたはコネクションレスプロトコルを用いて、無線デバイスとの双方向で開始する双方向通信のためのコンピュータおよびネットワークベースの方法を提供する。例示的な実施形態は、これらの無線デバイスのルート不可能なプライベートアドレスを暴露することなく、パブリックインターネットに接続されたデバイスおよびシステムが、プライベート無線ネットワークに接続された無線デバイスとの通信を開始し、無線デバイスにデータを送信することを可能にするアドレス管理プロキシシステム(「AMPS」)を提供する。
【0014】
既存のシステムでは、プライベートワイヤレスネットワークに接続される無線デバイスとパブリックワイヤードネットワーク(例えばインターネット(Internet))に接続されるワイヤードデバイスとの間のデータ通信が、無線デバイスのみによって開始され得る。いくつかのキャリアは、固定されたパブリックIPアドレスを無線デバイスに割り当てている。しかし、次いで無線デバイスは、入来する通信パケットを受信かつ処理するクライアントプログラム(例えばUDPスタック)能力を有することを必要とする。次いでさらに、これらの無線デバイスは、パブリック無線ネットワークの一部であるが、プライベート無線ネットワークではない。パブリックIPアドレスが、より不足した商品(commodity)となっており、現在、多重の数百万の(multi−million)デバイスのネットワークを提供するのに高価であるために、実際の意味では、キャリアは、そのネットワーク上の各デバイスに対する固定されたパブリックIPアドレスを有することを当てにはできない(IPv6への移動がより多くのアドレスを可能にするが、現在のIPv4定義が制限され、より多くのキャリアに加入している無線ユーザの潜在的な数は非常に多い。世界いくつかの地域では、現在のパブリックアドレス方式は、さらにより制限される)。さらに、このようなアドレシング能力は、さらなるセキュリティリスクに各デバイスを曝す。なぜなら、このようなデバイスの各々は、パブリックにアクセス可能なネットワークの一部であり、セキュリティ計測をインプリメントかつ実施することが困難になる。従って、固定されたパブリックIPアドレスをデバイスに割り当てることを介した既存の無線ネットワークにおいて、デバイスにプライベートIPアドレスを割り当てることが好ましい。無線ネットワークがプライベートである場合、無線デバイスの位置(アドレス)が、キャリアシステム(または、いくつかの国ではオペレータと呼ばれる)のインフラストラクチャによってパブリックな閲覧から意図的に隠される。
【0015】
プライベートネットワーク上の無線システムは、無線デバイスからパブリックネットワーキングワールドにデータを送信するためのネットワークアドレス変換(NAT)技術と同様の技術を使用する。プライベートネットワークを使用する典型的なキャリアインフラストラクチャでは、無線デバイスの電源をオンする場合(または他の環境では、デバイスがデータサービスを開始することを試みる場合)、無線デバイスは、それ自体をキャリアインフラストラクチャに「登録する」。キャリアは、DHCP(またはDHCPと同様の)サーバを用いてプライベートルート不可能なドレスに無線デバイスを動的に割り当てる。過渡的なプライベートIPアドレスのパブリックIPアドレスへのマッピングに関するン情報は、内部キャリアデータベースに格納され、RADIUSサーバ等のキャリアサービスによって管理される。
【0016】
プライベートネットワーク上の無線デバイスからインターネットに(またはインターネットからプライベートネットワーク上の無線デバイスに)送信された場合、データによって取られた実際の経路は、非常の多くのネットワークインフラストラクチャであり、キャリア技術に依存し、そして独自のものである。いくつかの規格が出現したが、本来非常に多様なものである。GPRSネットワークでは、例えば、SGSN(サービスGPRSノード)は、無線デバイスとの通信を管理する一方で、SGSNは、インターネット(Internet)ネットワークを接続するためにGGSN(ゲートウエイGPRSノード)を接続させる。使用されたモバイルネットワークにもかかわらず、無線デバイスとインターネットとの間のデータ通信は、GGSNと同様な種々のネットワークエレメント(GPRS、GSM、CDMA、または任意の他のネットワーク)、DNSサーバ、ルータ、およびゲートウエイを含む。
【0017】
再度、キャリアおよびネットワーク技術に依存して、パブリックネットワーク上のワイヤードデバイスから無線ネットワーク(プライベートアドレスを有する)上のモバイルデバイスに短い連続メッセージを送信するための制限された設備が存在する。SMS(ショートメッセージシステム)プロトコルは、このようなメッセージのためのフォーマットを定義するが、下位構造またはデータ転送についての任意のガイダンスを提供しない。さらに、このようなメッセージは、固定された(非常に短い)長さであり、データチャンネルではなく、制御情報(シグナリングチャンネル)を送信するための専用チャンネルを使用する。
【0018】
従って、標準アドレシング方式を用いるキャリアインフラストラクチャにプライベートネットワークを介して接続される無線デバイスと通信するための双方向通信チャンネルを構成するための既存のメカニズムが存在しない。あるいは、パブリックネットワークに接続されたデバイスから無線デバイス等との通信を開始するための任意のメカニズムが存在しない。従って、既存のシステムの実施形態は、キャリアのインフラストラクチャの倍部に常駐するワイヤードデバイスから無線デバイスへのデータの任意の種類のプログラム「プッシュ(push)」を支援することができない。さらに、無線デバイスからパブリック(ワイヤード)ネットワーク上のデバイスに送信されたメッセージは、ワイヤードデバイスによって直接応答できない。なぜなら、メッセージ内に含まれた無線デバイスのアドレスは、もはや価値がなくてもよいからである。さらに、これらのシステムを用いてアプリケーションを放送での取得を提供し、外部デバイスからキャリアインフラストラクチャに無線デバイスへの他のコードを送信することが不可能である。アプリケーションの動的取得およびダウンロードするための空気中での取得および関連した技術は、2001年11月28日に出願された、「Method and System for Maintaining and Distributing Wireless Application」と題された米国出願第09/997,402号に詳細に説明される。従って、パブリックIPアドレスを有する外部デバイスが、無線デバイスとの双方向通信を開始する可能にするためのメカニズムが非常に望ましい。
【0019】
アドレス管理プロキシシステムは、修正されたDNSサーバをインプリメントし、そしてパブリックワイヤードインターネットワーキングワールドとインターフェースをとるように、プライベート無線ネットワーク上のデバイスのためにプロキシ/ルータとして機能することによって、双方向で開始された双方向通信を達成する。要するに、パブリックアドレスのプールが保守され、AMPSによって必要とされた場合に、アクティブ無線デバイス間で動的に分散される。図2は、無線デバイスを有する双方向通信において使用された例示的なアドレス管理プロキシシステムのブロック図である。用語「双方向性」は、本明細書中で使用された場合、データパスおよび通信が2つのエンドポイントシステム間のいずれかの方向に流れ得ることを意味する。図2は、パブリックネットワーク210に接続されたワイヤードデバイス201、202、および203を示す。当業者は、これらのデバイスが別のプライベートまたはパブリックネットワークに接続され、次いで、パブリックネットワーク210に1つ以上のワイヤードデバイスによって接続され、本明細書中で説明された機能性をさらに達成することを認識する。任意のこのような改変は、等価な機能を提供し、本発明の一部であることが明示的に企図されかつ推定される。無線側では、無線デバイスについてのプロキシ(およびルータ)としてその能力で作用する、パブリックネットワーク210にワイヤを介しておよび無線ネットワーク230に標準キャリアインフラストラクチャエレメント(図示せず)を介して、両方に接続されたAMPS220が示される。読者は、キャリアのインフラストラクチャのエレメントおよびルーティングのための基本的なメカニズムおよびワイヤードネットワークから無線ネットワークにパケットを変換するメカニズムの動作知識を有することが推定される。これらは、物理データを送信し、そのデータを(例えば、衛星を介して、最終的には無線デバイスに)転送するために、プロトコル変換を必要とし得る無線技術および無線ルーティングメカニズムに関する詳細な背景情報が、Stalling,W.,によるWireless Communications and Network,Prentice Hall,N.J.2002において説明される。図2では、種々の無線エレメント(図示せず)を介して無線ネットワーク230に接続された無線デバイス240が示される。
【0020】
動作中では、ワイヤードデバイス201等のワイヤードデバイスは、データを無線デバイス240にデータを送信することを望む場合、ワイヤードデバイスは、まず、パブリックネットワーク210上の無線デバイス240のルート可能なアドレス位置を決定する必要がある。しかし、図2から観察されるように、無線デバイス240は、パブリックネットワーク210に直接接続されない。従って、無線デバイス240に向かうデータを送信するルート可能(パブリック)アドレスを決定するために、ワイヤードデバイスは、アドレス管理プロキシシステム220を使用しなければならない。このタスクを達成するためには、ワイヤードデバイス201は、無線デバイス240に対応するルート可能なパブリックアドレスを見つけるためにクエリ(例えば、修正されたDNSクエリ)を実行する。アドレス管理プロキシシステム220は、クエリを受信し、アドレスのプールからパブリック(ルート可能)アドレスを決定かつ割り当て、そのアドレスは、無線デバイス240に標的にされたデータパケットのための宛先アドレスとして使用され得る。本明細書中では、DNAクエリとして示されたが、さらに説明されるように、無線デバイス技術を処理するためにDNSクエリインプリメンテーションを修正し、および/または適切なルート可能アドレスを決定するために代替的なAPIを提供する。一旦、アドレス管理プロキシシステム220は、ワイヤードデバイス201へのルート可能なアドレスを戻すと、ワイヤードデバイス201は、データをそのアドレスに送信し得る。アドレス管理プロキシシステム220は、データを受信し、必要な場合、フォーマットおよびプロトコルを変換し、そして無線ネットワーク230を介して無線デバイス240に変換されたデータを送信する。
【0021】
図3は、例示的なアドレス管理プロキシシステムのコンポーネントの例示的なブロック図である。一実施形態では、アドレス管理プロキシシステム(AMPS)は、1つ以上の修正されたDNS’/APIサーバ302、1つ以上のアドレスプロキシ/ルータ305、アドレス管理データレポジトリ304等のデータベースまたは他のレポジトリを管理するアドレス管理データサーバ303、ならびに、随意にロードバランサ301を含む。DNS’/APIサーバ302は、パブリックネットワーク310に個々に接続されるか、または次いでパブリックネットワーク310に接続されるロードバランサ301に接続されるかのいずれかである。同様に、外部ネットワーク310からの、無線デバイスに向けられたデータが送信されるルート可能(パブリック)アドレスを介して、各アドレスプロキシ/ルータ305はまた、パブリックネットワーク310に接続される。DNS’/APIサーバ302は、無線デバイスと通信するために必要な機能性を加えるDNSサーバの修正されたインプリメンテーションであるか、または以下にさらに説明されるような1つ以上の専用APIをインプリメントするサーバであるかのいずれかである。DNS’/APIサーバ302は、無線デバイスに対する固有の識別子(例えばストリング名)をパブリックネットワーク310にマッピングする場合に支援するためにアドレス管理データサーバ303を使用する。パブリックアドレスのプールはまた、アドレス管理データサーバ303およびデータレポジトリ304によって保守される。アドレス管理データサーバ303およびデータレポジトリ304は、既存のデータベース技術(例えば、ODBC技術)を用いてインプリメントされてもよいし、簡単なテキストファイル等の構造としてインプリメントされてもよい。当業者は、テーブル、データ、リスト、またはマッピングを格納するための任意の実施形態が使用され得ることを認識する。各アドレスプロキシ/ルータ305はまた、アドレス管理データサーバ303またはその等化物を使用して、必要とされた場合、パブリックアドレスを無線デバイスに割り当て、そして無線デバイスのパブリックアドレスと、ルート不可能(プライベート)アドレスとの間に種々のマッピングを更新する一連のルーティングテーブルを作成かつ更新する。アドレス管理データサーバ303によって、DNS’/APIサーバ302およびアドレスプロキシ/ルータ305の代わりに保守されるテーブルおよびマッピングは、図6を参照しながら以下に説明される。
【0022】
AMPSの技術が一般的に無線デバイスと通信する任意のワイヤードデバイスに一般的に利用可能であるが、用語「パブリックネットワーク」(または「ワイヤードネットワーク」)は、一般的には、1つ以上のプライベートまたはパブリックネットワークに接続されたラインの下流(down)のいずれかにあるパブリックネットワークまたはバックボーンを含むインターネットワーク環境の任意のタイプを意味する。さらに、本明細書中で説明されたレイがしばしばインターネット(Internet)を指すが、当業者は、説明された概念および本発明が、例えばATMタイプのネットワークを含むインターネットワーキングの他の形態および実施形態に適用可能であることを認識する。従って、本発明の技術もまた、第2のネットワーク上の別の無線デバイスと通信する第1の無線ネットワーク上の1つのデバイスによって使用され得る。各デバイスは、他のネットワークのアドレスプロキシ/ルータとの通信を終了する。シナリオは実現可能である。なぜなら、各無線ネットワーク(またはキャリアインフラストラクチャ)は、パブリックネットワークにさらに接続されるプロキシ/ルータに接続されるためである。さらに、パブリックネットワークはまた、時には、本明細書中でワイヤードネットワークと呼ばれるが、当業者は、ルート可能な(パブリック)アドレスを露出する任意のネットワークが説明され得ることを認識する。従って、固有のパブリック(およびルート可能)アドレスを有する無線ネットワークもまた、双方向通信を実行するために本発明の技術を利用し得る。あるいは、当業者は、無線デバイス、電話、ハンドヘルド等の用語が、AMPSと共に動作することが可能である無線デバイスの任意のタイプを示すために交換可能に使用される。さらに、用語は、明示的に説明されてもされなくてもよい代替の綴りを有し得、当業者は、用語のこのような変更の全てが含まれるように意図されることを認識する。
【0023】
本明細書中で説明された例示的な実施形態は、双方向性通信のために使用される1つ以上のワイヤードネットワークおよび無線ネットワークを介して、プライベートアドレスからパブリックアドレスへのマッピングをインプリメントするために、アプリケーション、ツール、データ構造、および他のサポートを提供する。当業者は、本発明の方法およびシステムの他の実施形態が、情報および/またはデータ、あるいはコードを、パブリックネットワーク(インターネット(Internet)等)から無線デバイスにプッシュすることを含む多くの他の目的のために使用され得ることを理解する。さらに、この説明は、主にネットワークを介して送信される「データ」を指すが、当業者は、全てのタイプのデータが、以下に限定されないが、テキスト、グラフィックス、オーディオ、およびビデオを含む、本明細書中で説明された技術を用いて通信され得る。
【0024】
あるいは、以下の説明では、本発明の方法およびシステムの技術を理解することによって提供するために、データフォーマットおよびコード列等の複数の特定の詳細が以下に説明される。しかし、当業者は、本発明はまた、本明細書で説明されたいくつかの特定の詳細なしで、または他の特定の詳細(コードフローの順序に関する変化等)を用いて実施され得る。
【0025】
図4は、アドレス管理プロキシシステムの実施形態を実施するための汎用コンピュータシステムの例示的なブロック図である。汎用コンピュータシステム400は、1つ以上のサーバおよび/またはクライアントコンピューティングシステムを含み得、分散された位置に及び得る。さらに、各ブロックは、1つ以上のこのようなブロックを特定の実施形態に対して適切なように表わしてもよいし、他のブロックと組み合わせられてもよい。アドレス管理プロキシシステム410の種々のブロックは、互いに通信するために標準的なプロセス間通信メカニズムを使用する1つ以上のマシン上に物理的に常駐し得る。示された実施形態では、コンピュータシステム400は、コンピュータメモリ(「メモリ」)01、ディスプレイ402、中央処理装置(「CPU」)403、および入力/出力デバイス404を含む。メモリ401内に常駐するアドレス管理プロキシシステム410が示される。アドレス管理プロキシシステム410のコンポーネントは、好ましくは、CPU403上で実行し、前図で説明されたように、無線ネットワーク上の無線デバイスのアドレスマッピングを管理することによって、他のワイヤードシステムが無線デバイスと通信することを可能にする。他のダウンロードコード405および潜在的な他のデータレポジトリはまた、メモリ410に常駐し、好ましくは、1つ以上のCPU403上で実行する。典型的な実施形態では、AMPS410は、1つ以上のDNS’/APIサーバ411、1つ以上のアドレスプロキシ/ルータ412、アドレス管理データサーバ413、およびアドレス管理データレポジトリ414を含む。上述したように、AMPSは、特定のインプリメンテーションに依存するロードバランサ等の他のデータレポジトリおよびコンポーネントを含み得る。
【0026】
例示的実施形態では、AMPS410のコンポーネントは、DNSサーバおよびルータ等の既存のUDPベースの技術を修正することによってインプリメントされ、これらのコンポーネントは、典型的には、Cプログラミング言語で書かれたLinux/Unix(R)システム上でインプリメントされる。DNS’/APIサーバ411およびアドレスプロキシ/ルータ412へのインターフェースをプログラミングすることは、C、C++、C#、およびJava(R)APIおよびXML等のスクリプト言語、あるいはこれらを支援するウエブサーバを介して標準的な手段によって達成され得る。アドレス管理データサーバ413およびアドレス管理データレポジトリ414は、好ましくは、テキストファイルとしてではなく、データベースシステムとして拡張性の理由のために好ましくはインプリメントされ、SQL/ODBCデータベース管理システムを用いてインプリメントされ得る。DNS’/APIサーバ411およびアドレスプロキシ/ルータ412は、典型的には、Linux、UNIX(R)、あるいは他のUnix(R)ベースのまたはUnix(R)と同様のマシンを用いてインプリメントされる。当業者は、AMPS410が、複数の同種のコンピュータシステムおよびネットワークから構成される分散された環境においてインプリメントされ得ることを理解する。例えば、一実施形態では、DNS’/APIサーバ411、アドレスプロキシ/ルータコンポーネント412、アドレス管理データサーバ413、およびそのデータレポジトリ414は全て、物理的に異なるコンピュータシステムにおいて配置される。別の実施形態では、AMPS410の種々のコンポーネントは、別個のサーバマシン上の各々にホストされ、アドレス管理データレポジトリ414に格納されたテーブルからリモートに配置され得る。さらに、いくつかのシナリオにおいて、全体のAMPSシステム410は、キャリアインフラストラクチャ内部にホストされ、それに完全に組み込まれ得る。プログラムおよびデータの異なる構成および位置は、本発明の技術と共に使用するために企図される。例示的実施形態では、これらのコンポーネントは、同時にかつ非対称に実行し得、これにより、コンポーネントは、周知のメッセージ引渡し(passing)技術を用いて通信し得る。当業者は、等価な同時に起こる実施形態もまた、AMPSインプリメンテーションによって支援されることを認識する。あるいは、他のステップは、各ルーチンに対してインプリメントされ得、異なる順序および異なるルーチンでAMPSの機能をさらに達成する。
【0027】
アドレス管理プロキシシステムのコンポーネントに対するいくつかのインプリメンテーションアプローチが存在し、これらのアプローチの内の3つが、本明細書中で説明される。当業者は、種々の他のアプローチおよび組み合わせが可能であることを認識する。全ての3つのアプローチが、無線デバイスと通信するためにワイヤードデバイスによる一時的な使用に対してパブリック(ルート可能)ネットワークアドレスを割り当てる。一実施形態では、パブリックアドレスのプール(例えばパブリックIPアドレス)が保守され、必要に応じて無線ネットワークデバイスに動的に割り当てられる。例えば、典型的なクラスBインターネットネットワークアドレスブロックは、無線デバイスへの約65,000のシミュレーション接続を可能にする。この数は一見すると大きく見えるかもしれないが、携帯電話およびハンドセット(例えば、キャリアに接続された)の数を考慮すると、この数は、非常に制限され得る。
【0028】
第1のアプローチは、無線デバイスのためのパブリックアドレスマッピングを提供し、UDPプロトコルを用いてそれを利用可能にする。これは、格納および転送タイプのアプローチである。このアプローチの1つの利点は、このアプローチが無線接続を介して無線デバイスにUDPベースのトラフィックを容易にし、接続のパブリック側に接続されたデバイスがその接続を開始することを可能にする。しかし、欠点は、標準的なUDPプロトコルが修正を必要とするか、または追加のAPI呼び出しが追加されるかのいずれかにより、リクエストしているデバイスは、向けられた無線デバイスを識別し得る。これらの改変が必要である。なぜなら、UDPプロトコルは、IPアドレスの宛先を支援するだけであり、デバイスを固有に識別する代替的な手段(TCP/IPプロトコルと同様なストリング等)を提供しない。この(プライベート)アドレスを隠すことが望ましいために、標準UDPがデータを送信するための標準的なUDP呼び出しは、十分ではない。
【0029】
AMPSをインプリメントするために使用された第2のアプローチは、例えば、TCP/IPプロトコルを用いて、確立されたポイントツーポイント接続を介して完全な双方向通信を支援する(これらの同じ技術はまた、コネクションレスUDP双方向通信を支援することに留意すること)。第2のアプローチは、UDPまたはTCP/IP機能(GetHostByName)の修正されたインプリメンテーションを提供することによってインプリメントされ得る。GetHostByName APIは、ストリング指定が指定されたデバイスを識別することを可能にし、IPアドレスデータ構造を戻す。あるいは、提供されたセキュリティのレベルを増加させるために、AMPSは、特定されたAPIをインプリメントして、リクエストされた無線デバイスに(現在)対応している動的に割り当てられたパブリックアドレスを戻し得る。特定されたAPIアプローチの欠点は、パブリックネットワーク上のデバイス(または無線デバイスへの接続を取得することを望む他のデバイス)がリクエストしているデバイス上のアプリケーションにおける専用コードを含む。
【0030】
第3のアプローチは、第2のアプローチと同様であるが、「ポート」概念を使用するより大きい潜在的な同時接続を提供する。このアプローチを用いて、無線デバイス(アドレスプロキシ/ルータのパブリックアドレス)に対応するワイヤードネットワーク上のホストアドレスのみを戻す代わりに、AMPSはまた、ホストマシン(アドレスプロキシ/ルータ)上の特定のポート指定を戻す。ポートおよびそのインプリメンテーションは、当該分野において周知であり、一般的に、異なる場所に向けられたメッセージをトラッキングするために、データを受信するマシンによってインプリメントされたキューに対応する。データを受信するマシンは、ポート毎のベースで必要な順序付け、およびハンドシェーキング状態で、メッセージおよびハンドル中のポート指定に基づく異なる宛先にメッセージを転送する。
【0031】
ポートは、典型的には、単一の物理アドレス上に複数の仮想チャンネルを開くために使用され、潜在的に、単一の物理アドレスを別の約65,000の接続に拡張する。これは、AMPSが、例えばクラスC IPアドレスを使用することを可能にし、このアドレスは、典型的には、アドレスの他のタイプよりもはるかに安くかつ容易に利用可能であり、約1600万の無線デバイスへの同時接続を(UNIX(R)ベースのシステム)達成する。当業者は、利用可能なポートの数およびその特定のインプリメンテーションが、オペレーティングシステムに依存し、ポートアドレスを特定するために使用されたビット数に直接相関することを認識する。
【0032】
UDP(ならびにTCP/IP)プロトコルは、ポート抽象化(port abstraction)を支援するが、UDPおよびTCP/IPシステムを用いて使用された標準的なDNSクエリ(例えば、GetHostByName)は、ポート宛先の帰還を可能にせず、受信ルータの代わりに、リクエストデバイスまでポート宛先の制御を残す。従って、AMPSをインプリメントするための第3のアプローチに従って、ポートは、専用APIを用いてアドレスプロキシ/ルータによって好適に特定され、ホストマシン宛先を有するリクエストデバイスに戻される。
【0033】
一実施形態では、XML等のスクリプト言語インターフェースは、専用アドレスマッピング機能とインターフェースを取るように専用API(コードインターフェース)の代わりに使用され得る。XMLを用いると、DNS’/APIサーバは、XMLポストイベントとしてAPI呼び出しを受け取り、XMLフォーマットされた応答を戻す。他の言語モデルおよび/または他のプログラミング言語を用いるマッピング機能を呼び出すための同様な支援もまた企図され、本発明の技術と共に動作する。XMLタイプのインターフェースは、APIをそのソフトウエアに統合するリクエストデバイスのコストを最小化する。
【0034】
さらに、専用APIを用いると、リクエストデバイスは、必要とされたさらなるコーディング労力を有さないプライベート無線デバイスにさらなるデータをプッシュし得る。例えば、ワイヤードデバイスを用いて確立された接続のタイプの無線デバイスをビリングするために向けられるビリングコードがこの技術を用いて無線デバイスにプッシュされ得る。例示的なビリングコードメカニズムは、2002年2月26日に出願された、「Method and System for Transmission−Based Billing of Application」と題された米国特許出願第10/085,981号に開示される。
【0035】
UDPおよびTCP/IPの標準的なGetHostByName APIではなく専用APIを使用する願望をさらに示し得るいくつかのセキュリティに関連する理由が存在する。これらのセキュリティに関連する理由は、専用APIをさらに必要とするポートベースのメカニズムを使用する願望を示し得る。第1に、「GetHostByName」 APIおよびルータプロトコルを使用する任意の双方向通信は、そのホスト名に関連付けられたサービス(DOS)攻撃の拒否の影響を受ける。DOS攻撃は、利用可能である十分なパブリックアドレス(プロキシ/ルータマシンアドレスの)可能性を精算(close out)するように同じ入力パラメータを有する同じGetHostByNameを特定する1つ以上のマシンノ結果として発生し得る。第2に、GetHostByName(または任意の他の規格)の使用はまた、AMPSを、DNSゾーン転送の結果としてセキュリティ攻撃を受けやすくする。例えば、リクエストされたホスト名を見出すために、1つのDNSがDNSクエリを1つ以上の他のDNSサービスを転送する場合、DNSゾーン転送が発生する。1つの典型的なシナリオは、国から国への複数のDNSホップを含む。DNSゾーンのサーバ攻撃の考えは、不正なDNSサーバとして不正なコードを挿入することによって特定のDNSサーバ上に情報をキャプチャし、宛先アドレスを偽装することである。第3に、接続の継続時間に対する不注意は、権限のないリクエストデバイスに対してデータを利用可能にし得る。特に、パブリックデバイスと無線デバイスとの間にマッピングが確立されるために、パブリックデバイスは、パブリックデバイスよりも長く存在するマッピングが、誤ったデバイスとの通信を実際に行いかつ潜在的に終了する(不正にまたはそうでなく)ことを想定し得る。これは、いくつかのDNSサーバインプリメンテーションは、タイムツーライブ(Time to Live)セッティングを無視するためである。DNSサーバインプリメンテーションが修正されたDNSサーバインプリメンテーションを有するために、標準的なGetHostByName API、または専用APIをインプリメントするかしないかにかかわらず、プライベートアドレスとパブリックアドレスとの間の確立されたマッピングのTTL特性によって継続することによってこの問題を避ける。
【0036】
図5〜図8は、図2および図3を参照しながら説明された機能性を達成するために、DNS’/APIサーバおよびアドレスプロキシ/ルータによってインプリメントされた特定のルーチンの種々の例示的実施形態を説明する。図5は、アドレス管理プロキシシステムを用いるプライベート無線ネットワーク上に配置された無線デバイスにデータを送信するためのパブリックネットワーク上のデバイスによって実行されたプロセスの例示的なフローチャートである。ステップ501では、ソース(例えば、ワイヤード)デバイスは、AMPSから指定された無線デバイスのためのパブリック(ルート可能)アドレスを必要とする。上述のように、このようなアドレスを検索するための1つのメカニズムは、AMPSが、修正されたGetHostByNameルーチン等のDNSサービスのための修正されたインターフェースをインプリメントすることである。例えば、GetHostByNameルーチンは、ストリングの形態で、固有の無線デバイス指定を特定するために呼び出され得る。このストリング「personname.phone.wsp.com」は、省略された「wsp.com」である無線サービスプロバイダのウエブサイト(DNS)において配置された「phone」の電話番号を用いて、「person」の名前によって人に対応する無線デバイスを示す例示的なストリングである(例えば、susan.ph2065551212.sprint.comは、スプリントネットワーク上の電話番号206 555 1212を有する人Susanを指す)。AMPSによってインプリメントされ得る別のメカニズムは、別個の(特殊化された)API(「GetProxyIP」等)を提供することであり、APIは、指定された無線デバイスに対応するパブリック(ルート可能)アドレスの表示を戻す。別個のAPIを使用することは、セキュリティの理由のために使用可能である。例えば、違法なデバイスが詐欺(sppofing)によってルート可能なアドレスを傍受することが困難になる。別の理由は、アドレスプロキシ/ルータのホストアドレスに加えて、ポート宛先を提供することができるような、戻されたアドレス情報の実際のフォーマットを制御することである。GetHostByNameまたはGetProxyIP等の専用APIのいずれかのインプリメンテーションによって、図7を参照して以下にさらに説明される。
【0037】
ステップ502では、一旦、無線デバイスのパブリックアドレスがAMPSによって戻された場合、ソースデバイスは、表示されたアドレス情報から実際のアドレス位置(IPdata.jp)、タイムツーライブ(Time to Live)パラメータ(IPdata.TTL)、および、標準GetHostByName APIが使用されない場合、随意に、例えば、利用可能なポート宛先(IPdata.port)を抽出する。ステップ503では、ソースデバイスが無線デバイスとの接続ベースの通信を実行することを望む場合、ソースデバイスは接続(ソケット等)を開く。ステップ504では、タイムツーライブパラメータが無線デバイスの戻されたパブリックアドレスが終了したことを特定するかどうかをワイヤードデバイスが決定し、タイムツーライブパラメータが無線デバイスの戻されたパブリックアドレスが終了したことを特定するかどうかをワイヤードデバイスが決定する場合、異なるアドレスをリクエストするステップ501に戻り、タイムツーライブパラメータが無線デバイスの戻されたパブリックアドレスが終了したことを特定するかどうかをワイヤードデバイスが決定しない場合は、ステップ505を継続する。タイムツーライブパラメータは、無線デバイスのパブリックアドレスがその無線デバイスの有用性期間を超えないことを確実にするようにAMPSによって使用される(無線ネットワークに常時接続され、そして電源をオンされてもよいし、されなくてもよい)。いくつかの実施形態では、非常に短いTTLパラメータが使用されることによって、ワイヤードデバイスが特定のパブリックアドレス上の動作性(activity)をモニタし、次いで他の目的にためにそのアドレスを使用することを可能にするセキュリティ違反を回避する。ステップ505では、ワイヤードデバイスは、データパケット(接続を介するかまたは接続を介さずに)を無線デバイスに送信する。示されないが、ワイヤードデバイスおよび無線デバイスは、使用された転送プロトコル(例えばUDPまたはTCP/IP)において特定された標準的な呼び出しを使用して通信することが推定される。ステップ506では、データトランザクションが終了する場合、ワイヤードデバイスが処理され、データトランザクションが終了しない場合、ワイヤードデバイスが戻って、より多くのデータを送信するために、ステップ504においてTLパラメータをチェックする。
【0038】
以下の表1は、アドレス管理プロキシシステムを用いて電話番号「2065551212」によって識別されたユーザに対応するパブリックアドレスを取得するために、どのようにしてパブリック(リクエスト側)デバイスが、図5に説明されたような修正されたGetHostByNameクエリを使用し得るかを示す1つの例示的インプリメンテーションを説明する擬似コードを含む。パブリックデバイスの観点から、標準UDPおよびTCP/IP呼び出しは、標準的な態様で呼び出される。
【0039】
【表1】
以下の表2は、同じ電話番号によって識別されたユーザのアドレスを取得するためにパブリック(リクエスト側)デバイスによって使用されたような図5に示された専用APIメカニズムの例示的なインプリメンテーションを説明する擬似コードを含む。表2では、パブリックデバイスは、専用API(GetProxyIP)を呼び出し、アドレス/プロキシサーバの割り当てられたパブリックアドレスを含む必要な情報を含むデータ構造を獲得する。その後、パブリックデバイスは、データを送信するために同じ技術を使用し得る(標準的なUDPまたはTCP/IPプロトコル)。
【0040】
【表2】
図6は、DNS’/APIサーバおよびアドレスプロキシ/ルータのルーチンを支援するために使用されたアドレス管理プロキシシステムデータレポジトリテーブルのいくつかの例示的なブロックの図である。一実施形態では、アドレス管理データレポジトリは、3つのテーブルを含む。すなわち、プライベートアドレステーブル610への固有の識別子(固有のID)、パブリックからプライベートへのアドレステーブル630、プロキシ/ルータマシンテーブル620へのパブリックアドレスである。3つのテーブルが示されるが、当業者は、これらのテーブルが他のデータを含み、異なる数のテーブル、ならびに異なるカラムまたはフィールドを含むこれらのテーブルが異なって構造化され得ることを認識する。さらに、データのテーブルまたはリストを格納するための任意の技術が使用され得る。ポート指定者を加えたホストアドレスを無線デバイスにマッピングする実施形態を支援するために、テーブルはそれに従って修正される。
【0041】
固有のIDテーブル610は、無線デバイスの固有のストリング名をキャリアのインフラストラクチャに典型的に割り当てられるプライベート無線ネットワークアドレスにマッピングする。いくつかの実施形態では、キャリアインフラストラクチャは、DHCPプロトコルと同様の方法を用いて、無線デバイスが電源投入された場合、キャリアインフラストラクチャにデバイス自体を登録する場合、DHCPプロトコルと同様の方法を用いて、プライベートネットワークアドレスを動的に割り当てる。従って、固有のIDテーブル610が散在して満たされ、エントリが動的に作成され、次いで、キャリアインフラストラクチャシステムに登録および登録削除(unregister)する場合、動的に削除され得る。
【0042】
パブリックプライベートアドレステーブル630は、パブリックネットワークアドレス631、プライベート(無線)ネットワークアドレス602、フィールド631に格納されたパブリックアドレスが空いているか、または既に使用されているかを特定するフラグ632、タイムツーライブ(TTL)パラメータ633、および他の接続データ634を含むいくつかのフィールド/カラムを含む。一実施形態では、AMPSクエリテーブル630のDNS’/APIサーバは、指定されたプライベート無線ネットワークアドレスに対応するパブリックネットワークアドレスを決定するか、または未使用のパブリックネットワークアドレスを割り当て(フィールド632に示される)、そして決定された未使用のパブリックアドレスをフィールド602において格納されたプライベートネットワークアドレスにマッピングする。
【0043】
プロキシ/ルータマシンテーブル620へのパブリックアドレスは、パブリックネットワークアドレスフィールド631および機能プロキシ/ルータマシン621の表示を含む。このようなマッピングを保守することによって、AMPSは、プロキシ/ルータマシンを他のプロキシ/ルータマシンと置換することを可能にし、高い程度のロバスト性を提供する。各プロキシ/ルータマシンは、例えば、プロキシ/ルータマシンに挿入されたネットワークカードによって典型的に構成される、パブリックネットワークアドレスの予め構成されたセットを有する。これらのアドレスは、購入前を介してまたはアドレス認証局(adress authorizing authority)(現在では、Internet Corporation for Assigned Names and Numbers(ICANN))から得られる標準的な態様で割り当てられる。マシンが使用するためにAMPSに挿入される場合、これらのアドレスの表示は、フィールド631に格納される。
【0044】
一実施形態では、パブリックネットワークアドレスとプライベートアドレスとの間のマッピングのタイムスタンプもまた、テーブル630に示される。定義されたタイムアウトの後、このタイムスタンプに基づいて、アドレス管理データサーバは、パブリックからプライベートマッピングをマッピングしないマッピングに関連付けられたアドレスプロキシ/ルータにリクエストを送信し、それにより未使用のパブリックネットワークアドレスのプールに関連付けられたパブリックアドレスを戻す。
【0045】
図7は、指定された固有の識別子に対応するパブリックアドレスを戻すために、アドレス管理プロキシシステムのDNS’/APIサーバによって提供された例示的なルーチンの例示的なフローチャートである。本質的には、このルーチンは、図5を参照して示されたような修正されたGetHostByNameインターフェースまたは専用API(例えばGetProxyIP)を用いて、AMPSのDNSクエリまたはDNSと同様のクエリ能力をインプリメントする。要するに、ルーチンは、無線デバイスに関連付けるために適切なアドレスプロキシ/ルータマシンを動的に割り当て、そのマシン(TTLパラメータおよび潜在的に他のパラメータと共に)のパブリックアドレスを戻す。特に、ステップ701では、ルーチンは、ルーチンへの入力として通過されたストリングパラメータによって指定された無線デバイスのプライベート(ルート不可能)アドレスを決定する。例えば、ストリングパラメータは、「uniqueID.hostname.domain.tld」等のフィールドを使用し得、「org」、「com」、「edu」等の上位ドメイン上の会社のネットワーク等のドメイン上で「hostname」と命名されたマシン上の人/サービスの典型的な階層を特定する。当業者は、多くの他のストリングパラメータ指定が使用され得ることを理解する。このルーチンをインプリメントするための1つのメカニズムは、アドレス管理データレポジトリから情報をリクエストすることである。一実施形態では、データレポジトリは、固有のIDをプライベートネットワークアドレスにマッピングするテーブルを格納する(図6のテーブル610を参照)。好ましくは、AMPSによって使用される任意のメカニズムは、無線ネットワークアドレスを秘匿にするためにセキュアな態様でこのデータを格納する。ステップ702では、AMPSによってそのデバイスに既に割り当てられ、依然として有効である場合、ルーチンは、指定されたデバイスのプライベート無線ネットワークアドレスに対応するパブリックネットワークアドレスを検索する。一実施形態では、データレポジトリは、プライベートワイヤレスネットワークアドレスとパブリックネットワークアドレスとの間でこのマッピング情報を格納する(図6のテーブル630を参照)。パブリックネットワークアドレスは、既に割り当てられていないか、または有効でない場合、ルーチンは、新しいパブリックネットワークアドレスを割り当てさせ、新しいパブリックアドレスは、プライベート無線ネットワークアドレスに関連付けられる。次いで、データレポジトリにおける適切なテーブルが更新される。ステップ703では、ルーチンは、割り当てられたパブリックネットワークアドレスに関連付けられるアドレスプロキシ/ルータマシンを決定する(例えば、図6のテーブル620を用いて)。ステップ704では、ルーチンは、決定されたパブリックネットワークアドレスをプライベートワイヤレスネットワークアドレスにマッピングするためにそのルーティングテーブルを更新するように、決定されたパブリックネットワークアドレスに送信する。ステップ705では、ルーチンは、任意の他の接続連携情報(例えば、図6のテーブル630におけるフィールド634)を含むようにデータレポジトリ内の情報を更新し、パブリックプライベートアドレス関係のためのタイムツーライブ(TTL)パラメータ(例えば、図6のテーブル630におけるフィールド633)を含む。一旦、全てのテーブルがプロキシ/ルータおよびデータレポジトリの両方において更新されると、DNS’/APIサーバは、関連付けられたアドレスプロキシ/ルータマシンの決定されたパブリックネットワークアドレスを戻す。初期に説明されたように、ポートベースのインプリメンテーションが使用された場合、パブリックアドレスは、対(ホスト名、ポート)であり得る。
【0046】
図8は、データを受信する例示的なアドレス管理プロキシシステムのアドレスプロキシ/ルータ内部の例示的なルーチンの例示的なフローチャートである。このルーチンは、相対的なプロトコル(例えば、TCP/IP、UDP/IP等)を用いてワイヤードデバイスからデータを受信するためにアドレスプロキシ/ルータによってインプリメントされる(データは、特定のアドレスプロキシ/ルータに送信される。なぜなら、そのアドレスプロキシ/ルータのパブリック(ルート可能)アドレスは、AMPSのDNS’/APIサーバのクエリに応答してリクエスト/ソースデバイスに戻される)。プロキシ/ルータは、有線ネットワークから無線ネットワークにデータを送信するのに必要なデータの任意の変換の原因となる(例えば、キャリアインフラストラクチャは、このレベルで実行されるべき変換等を望む場合)。プロキシ/ルータはまた、プロキシ/ルータを呼び出すために使用されたパブリックアドレスに対応する無線デバイスのプライベート無線アドレスの無線ネットワークを介してデータを無線デバイスのプライベート無線アドレスに転送する原因となる。
【0047】
特に、ステップ801では、ルーチンは、呼び出されたパブリックアドレスに対応するプライベート無線アドレス、およびマッピングに関連付けられたTTLパラメータを(例えば、アドレス管理データレポジトリから)決定する。これらの値は、例えば、図6のパブリック/プライベートアドレステーブル630から獲得され得る。ステップ802では、ルーチンは、決定されたTTLパラメータの値は、マッピングが終了したかどうかを決定し、マッピングが終了した場合、エラーを戻し、マッピングが終了しない場合、ステップ803を継続する。ステップ803では、ルーチンは、ターゲットデバイスによって必要とされたフォーマットを決定する(無線ネットワークフォーマット)。ステップ804では、ルーチンは、任意のプロトコル変換が必要であるかどうかを決定し、任意のプロトコル変換が必要である場合、ステップ805を継続し、任意のプロトコル変換が必要でない場合、ステップ806を継続する。データの「HTTP」パケットへの変換等の特定の無線ネットワークに対するプロトコル変換は、プロキシ/ルータによってなされてもよいし、キャリアインフラストラクチャ内のいくつかの他のコンポーネントによってなされてもよいことに留意すること。当業者は、例示的なステップが存在し、異なるフォーマットまたは異なるプロトコル変換ルーチンが、環境に特有なものとして追加または削除され得る。ステップ806では、アドレスプロキシ/ルータルーチンは、データパケット(必要に応じて、データパケットがフォーマットされ、そのプロトコルが変換される)を無線デバイスの所定の関連したプライベートアドレスに送信し、そして戻す。
【0048】
上述から、説明する目的で本発明の特定の実施形態が説明されてきたが、種々の改変が本発明の精神および範囲から逸脱することなくなされ得る。例えば、当業者は、本明細書中で説明された双方向通信を確立するための方法およびシステムが、インターネット(Internet)、TCP/IP、およびUDP、あるいは、さらに複数のこのようなネットワーク以外のパブリックネットワークおよびプロトコルの他のタイプに適用可能である。例えば、パブリックアドレスマッピングへのプライベートアドレスはまた、無線デバイスを有するATMネットワーク上でデバイスを接続するATMに提供され得る。当業者はまた、本明細書中で説明された方法およびシステムが、異なるプロトコル、通信メディア(光、無線、ケーブル等)、無線デバイス(無線ハンドセット、電子オーガナイザー、パーソナルデジタルアシスタント、ポータブル電子メールマシン、ゲーム機、ポケットベル、GPS受信器等のナビゲーションデバイス等)、異なるワイヤードデバイス(キオスク、パーソナルコンピュータ、メインフレーム)、およびワイヤード接続能力(例えば、同期化目的のためのドッキングステーションに接続され得る無線電子メール、またはPDAデバイス)に適用可能である。
【0049】
以上のように、本発明の好ましい実施形態を用いて本発明を例示してきたが、本発明は、この実施形態に限定して解釈されるべきものではない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。当業者は、本発明の具体的な好ましい実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。本明細書において引用した特許、特許出願および文献は、その内容自体が具体的に本明細書に記載されているのと同様にその内容が本明細書に対する参考として援用されるべきであることが理解される。
【図面の簡単な説明】
【0050】
【図1】図1は、TCP/IPおよびUDP/IPを用いるデータパケットを送信するための基本的なインターネット(Internet)またはインターネット通信の例示的なブロック図である。
【図2】図2は、無線デバイスを用いる双方向通信において使用された例示的なアドレス管理プロキシシステムのブロック図である。
【図3】図3は、例示的なアドレス管理プロキシシステムのコンポーネントの例示的なブロック図である。
【図4】図4は、アドレス管理プロキシシステムの実施形態を実行するための汎用コンピュータシステムの例示的なブロック図である。
【図5】図5は、アドレス管理プロキシシステムを用いるプライベート無線ネットワーク上に配置された無線デバイスにデータを送信するために、パブリックネットワーク上のデバイスによって実行されたプロセスの例示的なフローチャートである。
【図6】図6は、DNS’/APIサーバおよびアドレスプロキシ/ルータのルーチンを支援するために使用されたいくつかのアドレス管理プロキシシステムデータレポジトリの例示的なブロック図である。
【図7】図7は、指定された固有の識別子に対応するパブリックアドレスを戻すために、アドレス管理プロキシシステムのDNS’/APIサーバによって提供された例示的なルーチンの例示的なフローチャートである。
【図8】図8は、データを受信する例示的なアドステップ管理プロキシシステムのアドレスプロキシ/ルータ内部の例示的なルーチンの例示的なフローチャートである。
Claims (108)
- コンピュータネットワーク環境において、パブリックネットワークアドレスを用いて該コンピュータネットワーク環境に接続された第一のデバイスと無線通信ネットワークに接続され、プライベートアドレスを有する第二のデバイスとの間の双方向通信チャネルバーチャルチャネルを確立するための方法であって、
該第二のデバイスと通信するために該第一のデバイスからリクエストを受信するステップと、
パブリックネットワークアドレスのプールからパブリックネットワークアドレスを動的に決定するステップと、
該決定されたパブリックネットワークアドレスを該第二のデバイスの該プライベートアドレスと関連付けるステップと、
該第一のデバイスがその後に該決定されたパブリックネットワークアドレスを用いて該第二のデバイスにデータを送り得るように該決定されたパブリックネットワークアドレスの指標を該第一のデバイスに戻すステップと
を包含する、方法。 - 前記リクエストは、前記第二のデバイスの前記プライベートアドレスとは異なる前記第二のデバイスの固有の識別子を示し、前記決定されたパブリックアドレスを該第二のデバイスの前記プライベートアドレスに関連付けるステップは、該固有の識別子を用いて行われる、請求項1に記載の方法。
- 前記決定されたパブリックネットワークアドレスに指示された前記第一のデバイスからデータを受信するステップと、
該受信されたデータを、該決定されたパブリックネットワークアドレスと関連付けられた前記プライベートネットワークアドレスを用いて前記第二のデバイスに透明にルーティングするステップと
をさらに包含する、請求項1に記載の方法。 - 前記透明にルーティングするステップは、前記コンピュータネットワーク環境のパブリックネットワークアドレスによって前記コンピュータネットワーク環境に接続された仮面様のシステムによって行われる、請求項3に記載の方法。
- 前記第一のデバイスは、ワイヤードデバイスである、請求項1に記載の方法。
- 前記第一のデバイスは、無線デバイスである、請求項1に記載の方法。
- 前記第二のデバイスは、有線接続可能なデバイスである、請求項1に記載の方法。
- 前記第二のデバイスは、無線デバイスである、請求項1に記載の方法。
- 前記決定されたパブリックネットワークアドレスは、ホストシステムアドレスおよびポート仕様を特定する、請求項1に記載の方法。
- 前記決定されたパブリックネットワークアドレスは、インターネットプロトコール(IP)アドレスを特定する、請求項1に記載の方法。
- 前記方法は、変更されたDNSサーバによって行われる、請求項1に記載の方法。
- 前記受信されたリクエストは、前記コンピュータネットワーク環境の標準APIである、請求項1に記載の方法。
- 前記APIは、GetHostByName APIである、請求項12に記載の方法。
- 前記受信されたリクエストは、ホストマシンの名前およびポートの指標を特定する、前記コンピュータネットワーク環境の変更されたAPIである、請求項1に記載の方法。
- 前記決定されたパブリックネットワークアドレスを満了期間に関連付けるステップと、
該満了期間が満了した場合に該決定されたパブリックネットワークアドレスと前記第二のデバイスの前記プライベートアドレスとの間の関連を壊すステップと
をさらに包含する、請求項1に記載の方法。 - 前記満了期間は、タイムツーライブ(TTL)データとして特定される、請求項15に記載の方法。
- パブリックネットワークアドレスを用いてコンピュータネットワーク環境に接続された第一のデバイスと無線通信ネットワークに接続され、プライベートアドレスを有する第二のデバイス間にバーチャル通信チャネルを確立するために該コンピュータネットワーク環境に接続されたアドレスプロキシ管理システムであって、
ドメインネームサービス(DNS)であって、該ドメインサービス(DNS)は、
該第二のデバイスと通信するために該第一のデバイスからリクエストを受信し、
パブリックネットワークアドレスのプールからパブリックネットワークアドレスを動的に決定し、
該決定されたパブリックネットワークアドレスを該第二のデバイスの該プライベートアドレスに関連付け、
該第一のデバイスがその後に該決定されたパブリックネットワークアドレスを用いて該第二のデバイスにデータを送り得るように該決定されたパブリックネットワークアドレスの指標を該第一のデバイスに戻す
ように構造化される、ドメインネームサービス(DNS)を含む、アドレスプロキシ管理システム。 - 前記DNSは、UDPおよびTCP/IP標準の少なくとも一方によって滞留する変更されたDNSである、請求項17に記載のシステム。
- 前記コンピュータネットワーク環境は、インターネットである、請求項17に記載のシステム。
- 各パブリックネットワークアドレスは、インターネットプロトコル(IP)アドレッシングコンベンションにしたがって特定される、請求項17に記載のシステム。
- 前記DNSは、前記決定されたパブリックネットワークアドレスを前記第二のデバイスの前記プライベートアドレスに関連付けるために、データベースを使用する、請求項17に記載のシステム。
- 前記DNSは、パブリックネットワークアドレスのプールからパブリックネットワークを動的に決定するためにデータベースを使用する、請求項17に記載のシステム。
- 前記リクエストは、前記第二のデバイスの前記プライベートアドレスとは異なる、前記第二のデバイスの固有の識別子を示し、前記DNSは、該固有の識別子を用いて前記決定されたパブリックアドレスを該第二のデバイスの該プライベートアドレスと関連付ける、請求項17に記載のシステム。
- 前記決定されたパブリックネットワークアドレスに指示された前記第一のデバイスからデータを受信し、該決定されたパブリックネットワークアドレスと関連付けられた該プライベートネットワークアドレスを用いて該受信されたデータを前記第二のデバイスに透明にルーティングするように構造化されるプライベートアドレス管理ルータをさらに含む、請求項17に記載のシステム。
- 前記プライベートアドレス管理ルータは、前記コンピュータネットワーク環境のパブリックネットワークアドレスによって前記コンピュータネットワーク環境に接続され、前記受信されたデータと関連付けられた前記プライベートネットワークアドレスを決定することによって、前記受信されたデータを前記第二のデバイスの該パブリックアドレスに透明にルーティングし、該決定されたプライベートネットワークアドレスで該データが前記無線通信ネットワークを介して該第二のデバイスに転送されるようにする、請求項24に記載のシステム。
- 前記プライベートアドレス管理ルータは、前記受信されたデータを透明にルーティングするステップ前に適用可能な場合に前記受信されたデータのプロトコル変換が行われるようにする、請求項24に記載のシステム。
- 前記第一のデバイスは、ワイヤードデバイスである、請求項17に記載のシステム。
- 前記第一のデバイスは、無線デバイスである、請求項17に記載のシステム。
- 前記第二のデバイスは、有線接続可能なデバイスである、請求項17に記載のシステム。
- 前記第二のデバイスは、無線デバイスである、請求項17に記載のシステム。
- 前記決定されたパブリックネットワークアドレスは、ホストシステムアドレスおよびポート仕様を特定する、請求項17に記載のシステム。
- 前記決定されたパブリックネットワークアドレスは、インターネットプロトコル(IP)アドレスを特定する、請求項17に記載のシステム。
- 前記受信されたリクエストは、前記コンピュータネットワーク環境の標準APIである、請求項17に記載のシステム。
- 前記APIは、GetHostByName APIである、請求項33に記載のシステム。
- 前記受信されたリクエストは、ホストマシンの名前およびポートの指標を特定する新しいAPIである、請求項17に記載のシステム。
- 前記DNSは、
前記決定されたパブリックネットワークアドレスを満了期間に関連付け、
該満了期間が満了される場合に該決定されたパブリックネットワークアドレスと前記第二のデバイスのプライベートアドレスとの間の関連が壊されるようにする
ようにさらに構造化される、請求項17に記載のシステム。 - 前記満了期間は、タイムツーライブ(TTL)データとして特定される、請求項36に記載のシステム。
- パブリックネットワークアドレスを用いてコンピュータネットワーク環境に接続された第一のデバイスと無線通信ネットワークに接続され、プライベートアドレスを有する第二のデバイスとの間にバーチャル通信チャネルを確立するためにコンピュータネットワーク環境に接続されたアドレスプロキシ管理システムであって、
該第二のデバイスと通信するために該第一のデバイスからリクエストを受信するための手段と、
パブリックネットワークアドレスのプールからパブリックネットワークアドレスを動的に決定するための手段と、
該決定されたパブリックネットワークアドレスを該第二デバイスのプライベートアドレスに関連付けるための手段と、
該決定されたパブリックネットワークアドレスを用いて該第一のデバイスがその後データを該第二のデバイスに送り得るように該決定されたパブリックネットワークアドレスの指標を該第一のデバイスに戻すための手段と
を含む、システム。 - パブリックネットワークアドレスを用いてコンピュータネットワーク環境に接続された第一のデバイスと無線通信ネットワークに接続され、プライベートアドレスを有する第二のデバイスとの間の双方向通信チャネルバーチャル通信チャネルを確立するためにコンピュータシステムにおいてプロセッサを制御するための命令を含むコンピュータ読み出し可能メモリ媒体であって、
該第二のデバイスと通信するための該第一のデバイスからリクエストを受信するステップと、
パブリックネットワークアドレスのプールからパブリックネットワークアドレスを動的に決定するステップと、
該決定されたパブリックネットワークアドレスを該第二のデバイスのプライベートアドレスに関連付けるステップと、
該決定されたパブリックネットワークアドレスを用いて該第一のデバイスがその後データを該第二のデバイスに送り得るように該決定されたパブリックネットワークアドレスの指標を該第一のデバイスに戻すステップと
により、該双方向通信チャネルバーチャル通信チャネルを確立するためにコンピュータシステムにおいてプロセッサを制御するための命令を含むコンピュータ読み出し可能メモリ媒体システム。 - 前記リクエストは、前記第二のデバイスのプライベートアドレスとは異なる前記第二のデバイスの固有の識別子を示し、前記決定されたパブリックアドレスを該第二のデバイスのプライベートアドレスに関連付けるステップは、該固有の識別子を用いて行われる、請求項39に記載のコンピュータ読み出し可能メモリ媒体。
- 前記命令は、
該決定されたパブリックネットワークアドレスに指示された前記第一のデバイスからデータを受信するステップと、
該決定されたパブリックネットワークアドレスと関連付けられた該プライベートネットワークアドレスを用いて該受信されたデータを前記第二のデバイスに透明にルーティングするステップと
によって前記コンピュータプロセスをさらに制御する、請求項39に記載のコンピュータ読み出し可能メモリ媒体。 - 前記透明にルーティングするステップは、前記コンピュータネットワーク環境のパブリックネットワークアドレスによって前記コンピュータネットワーク環境に接続されたマスク化されたシステムによって行われる、請求項41に記載のコンピュータ読み出し可能メモリ媒体。
- 前記第一のデバイスは、ワイヤードデバイスである、請求項39に記載のコンピュータ読み出し可能メモリ媒体。
- 前記第一のデバイスは、無線デバイスである、請求項39に記載のコンピュータ読み出し可能メモリ媒体。
- 前記第二のデバイスは、有線接続可能なデバイスである、請求項39に記載のコンピュータ読み出し可能メモリ媒体。
- 前記第二のデバイスは、無線デバイスである、請求項39に記載のコンピュータ読み出し可能メモリ媒体。
- 前記決定されたパブリックネットワークアドレスは、ホストコンピュータアドレスおよびポート仕様を特定する、請求項39に記載のコンピュータ読み出し可能メモリ媒体。
- 前記決定されたパブリックネットワークアドレスは、インターネットプロトコル(IP)アドレスを特定する、請求項39に記載のコンピュータ読み出し可能メモリ媒体。
- 前記方法は、変更されたDNSサーバによって行われる、請求項39に記載のコンピュータ読み出し可能メモリ媒体。
- 前記受信されたリクエストは、前記コンピュータネットワーク環境の標準APIである、請求項39に記載のコンピュータ読み出し可能メモリ媒体。
- 前記APIは、GetHostByName APIである、請求項50に記載のコンピュータ読み出し可能メモリ媒体。
- 前記受信されたリクエストは、ホストマシンの名前およびポートの指標を特定する、前記コンピュータネットワーク環境の変更されたAPIである、請求項39に記載のコンピュータ読み出し可能メモリ媒体。
- 前記命令は、
前記決定されたパブリックネットワークアドレスを満了期間に関連付けるステップと、
該満了期間が満了した場合に該決定されたパブリックネットワークアドレスと前記第二のデバイスのプライベートアドレス間の関連を壊すステップと
により前記コンピュータプロセッサをさらに制御する、請求項39に記載のコンピュータ読み出し可能メモリ媒体。 - 前記満了期間は、タイムツーライブ(TTL)データとして特定される、請求項53に記載のコンピュータ読み出し可能メモリ媒体。
- 管理プロキシシステムを通じて無線通信ネットワークに接続されたコンピュータネットワーク環境における方法であって、該無線通信ネットワークは、該無線通信ネットワークのプライベートネットワークアドレスを用いて無線デバイスに接続され、該無線デバイスは、関連付けられた固有の識別子を有し、該アドレス管理プロキシシステムは、該コンピュータネットワーク環境のパブリックネットワークアドレスを有し、該コンピュータネットワーク環境は、該コンピュータネットワーク環境のパブリックネットワークアドレスを用いてワイヤードデバイスに接続される、コンピュータネットワーク環境における方法であって、
該ワイヤードデバイスの制御下に、
該アドレス管理プロキシシステムの該パブリックネットワークアドレスを用いて、該アドレス管理プロキシシステムに、該コンピュータネットワーク環境のパブリックネットワークアドレスの指標についてのリクエストを、該無線デバイスと通信するために、ユーザに送るステップであって、該リクエストは、該無線デバイスに関連付けられる固有の識別子を示す、ステップと、
該アドレス管理プロキシシステムの制御下に、
該パブリックネットワークアドレスの指標のために該リクエストを受信するステップと、
コンピュータネットワーク環境の複数の利用可能なパブリックネットワークアドレスからパブリックネットワークアドレスを決定するステップと、
該決定されたパブリックネットワークアドレスを、示された固有の識別子に対応する該無線デバイスのプライベートネットワークアドレスに関連付けるステップと、
該決定されたネットワークアドレスの指標を該ワイヤードデバイスに転送するステップと、
該ワイヤードデバイスの制御下に、
該示されたパブリックネットワークアドレスを受信するステップと、
該示されたパブリックネットワークアドレスを用いてデータを該無線デバイスに送り、その結果、該ワイヤードデバイスは、該ワイヤードデバイスは該無線デバイスと直接通信していることを認知するステップと
を包含する、方法。 - 前記アドレス管理プロキシシステムの制御下に、
前記ワイヤードデバイスから送信された前記データを受信するステップと、
該示されたパブリックネットワークアドレスに関連付けられる前記プライベートネットワークアドレスを決定するステップと、
該ワイヤードデバイスに対して透明な態様で無線通信ネットワークを介して、該プライベートネットワークアドレスに該受信されたデータをルーティングするステップと
をさらに包含する、請求項55に記載の方法。 - 前記コンピュータネットワーク環境は、インターネットであり、各パブリックネットワークアドレスは、インターネットプロトコル(IP)アドレッシングコンベンションにしたがって特定される、請求項55に記載の方法。
- 前記コンピュータネットワーク環境は、ATMネットワークである、請求項55に記載の方法。
- 前記示されたパブリックネットワークアドレスは、前記アドレス管理プロキシシステムのパブリックネットワークアドレスであり、前記ワイヤードデバイスから送られたデータは、前記無線デバイスの前記固有の識別子を示し、該アドレス管理プロキシシステムは、該データを管理し該データを該示された固有識別子に関連付けられた無線デバイスに転送する、請求項55に記載の方法。
- 前記示されたパブリックネットワークアドレスは、前記ワイヤードデバイスによる、前記コンピュータネットワーク環境のアドレスマッピング機能への呼び出しの結果として受信される、請求項55に記載の方法。
- 前記アドレスマッピング機能は、前記コンピュータネットワーク環境の標準機能である、請求項60に記載の方法。
- 前記アドレスマッピング機能は、GetHostByName機能である、請求項60に記載の方法。
- 前記示されたパブリックネットワークアドレスは、ワイヤードデバイスによる、ホストシステムアドレスおよびポート仕様を戻す機能への呼び出しの結果として受信される、請求項55に記載の方法。
- 前記機能は、カスタマイズされたAPIである、請求項63に記載の方法。
- 前記機能は、XMLインターフェースをサポートする、請求項63に記載の方法。
- 前記無線デバイスの制御下に、前記ワイヤードデバイスのパブリックネットワークアドレスを用いてデータをワイヤードデバイスに送り、これにより、双方向通信を行うステップをさらに含む、請求項55に記載の方法。
- バーチャル端間接続が、前記ワイヤードデバイスと前記無線デバイスとの間に確立される、請求項55に記載の方法。
- 接続なしの通信パスが、前記ワイヤードデバイスと前記無線デバイスとの間に確立される、請求項55に記載の方法。
- コンピュータネットワーク環境であって、
無線通信ネットワークのプライベートネットワークアドレスを用いて無線通信ネットワークに接続された無線デバイスであって、該無線デバイスは、関連付けられた固有の識別子を有する、無線デバイスと、
コンピュータネットワーク環境のパブリックネットワークアドレスを用いてコンピュータネットワーク環境に接続されたワイヤードデバイスであって、ワイヤードデバイスは、
該無線デバイスに通信するために使用するように該コンピュータネットワーク環境のパブリックネットワークアドレスの指標をリクエストし、ここで、該リクエストは、該無線デバイスに関連付けられた該固有の識別子を示し、
該示されたパブリックネットワークアドレスを受信し、
該示されたパブリックネットワークアドレスを用いてデータを該無線デバイスに送り、その結果、該ワイヤードデバイスは、端間接続を用いて該無線デバイスと直接通信する
ように構造化される、ワイヤードデバイスと、
該コンピュータネットワーク環境のパブリックネットワークアドレスを用いて該コンピュータネットワーク環境に接続されたアドレス管理プロキシシステムであって、該アドレス管理プロキシシステムは、
該ワイヤードデバイスから該リクエストを受信し、
コンピュータネットワーク環境の複数の利用可能なパブリックネットワークアドレスからパブリックネットワークアドレスを決定し、
該決定されたパブリックネットワークアドレスを、該示された固有の識別子に対応する該無線デバイスの該プライベートネットワークアドレスに関連付け、
該決定されたパブリックネットワークアドレスの指標を該ワイヤードデバイスに転送する
ように構造化された、アドレス管理プロキシシステムと
を含む、コンピュータネットワーク環境 - 前記アドレス管理プロキシシステムは、
前記ワイヤードデバイスから送信されたデータを受信し、
前記示されたパブリックネットワークアドレスに関連付けられる前記プライベートネットワークアドレスを決定し、
該プライベートネットワークアドレスへの該受信されたデータを、前記無線通信ネットワークを介して、透明な態様で、前記ワイヤードデバイスにルーティングするようにさらに構造化される、請求項69に記載のコンピュータネットワーク環境。 - 前記コンピュータネットワーク環境は、インターネットであり、各パブリックネットワークアドレスは、インターネットプロトコル(IP)アドレッシングコンヴェンションにしたがって特定される、請求項69に記載のコンピュータネットワーク環境。
- 前記コンピュータネットワーク環境は、ATMネットワークである、請求項69に記載のコンピュータネットワーク環境。
- 前記示されたパブリックネットワークアドレスは、前記アドレス管理プロキシシステムのパブリックネットワークアドレスであり、前記ワイヤードデバイスから送られたデータは、前記無線デバイスの固有の識別子を示し、前記アドレス管理プロキシシステムは、該データを格納し、該示された固有の識別子に関連付けられた無線デバイスに転送するように構造化される、請求項69に記載のコンピュータネットワーク環境。
- 前記示されたパブリックネットワークアドレスは、前記ワイヤードデバイスによる前記コンピュータネットワーク環境のアドレスマッピング機能への呼び出しの結果として受信される、請求項69に記載のコンピュータネットワーク環境。
- 前記アドレスマッピング機能は、前記コンピュータネットワーク環境の標準機能である、請求項74に記載のコンピュータネットワーク環境。
- 前記アドレスマッピング機能は、GetHostByName機能である、請求項74に記載のコンピュータネットワーク環境。
- 前記示されたパブリックネットワークアドレスは、前記ワイヤードデバイスによる、ホストシステムアドレスおよびポート仕様を戻す機能への呼び出しの結果として受信される、請求項69に記載のコンピュータネットワーク環境。
- 前記機能は、カスタマイズされたAPIである、請求項77に記載のコンピュータネットワーク環境。
- 前記機能は、XMLインターフェースをサポートする、請求項77に記載のコンピュータネットワーク環境。
- 前記無線デバイスは、前記ワイヤードデバイスのパブリックネットワークアドレスを用いてデータを前記ワイヤードデバイスに送り、これにより、双方向通信を行うようにさらに構造化される、請求項69に記載のコンピュータネットワーク環境。
- バーチャル端間接続が、前記ワイヤードデバイスと前記無線デバイスとの間に確立される、請求項69に記載のコンピュータネットワーク環境。
- 接続なしの通信パスが、前記ワイヤードデバイスと前記無線デバイスとの間に確立される、請求項69に記載のコンピュータネットワーク環境。
- コンピュータネットワーク環境において、プライベートネットワークアドレスを用いてアドレス管理プロキシシステムに接続された無線デバイスと通信するための方法であって、該無線デバイスは、プライベートネットワークではない関連付けられた固有の識別子を有し、該アドレス管理プロキシシステムは、該ネットワーク環境のパブリックネットワークアドレスを用いて該コンピュータネットワーク環境に接続され、
該アドレス管理プロキシシステムから、該無線デバイスに関連付けられた該固有の識別子に対応するパブリックネットワークアドレスをリクエストするステップと、
該無線デバイスの該パブリックネットワークアドレスの指標を受信するステップと、
データを該示されたパブリックネットワークアドレスに送るステップと
を包含する、方法。 - 前記コンピュータネットワーク環境は、インターネットである、請求項83に記載の方法。
- 前記示されたパブリックネットワークアドレスは、インターネットプロトコル(IP)アドレッシング標準にしたがって特定される、請求項83に記載の方法。
- 前記固有の識別子は、個人名および電話番号、MSISDN番号、およびISMI番号の少なくとも一つである、請求項83に記載の方法。
- 前記リクエストは、標準APIであり、その結果、前記無線デバイスとの通信は、前記コンピュータネットワーク環境に接続されたワイヤードデバイスとの通信と同一の態様で行われる、請求項83に記載の方法。
- 前記APIは、GetHostByName機能呼び出しである、請求項87に記載の方法。
- 前記無線デバイスの前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスである、請求項83に記載の方法。
- 前記無線デバイスの前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスおよびポート仕様である、請求項83に記載の方法。
- コンピュータネットワーク環境において、プライベートネットワークアドレスを用いてアドレス管理プロキシシステムに接続された無線デバイスと通信するためにコンピュータプロセッサを制御するための命令を含むコンピュータ読み出し可能メモリ媒体であって、該無線デバイスは、該プライベートネットワークアドレスではない関連付けられた固有の識別子を有し、該アドレス管理プロキシシステムは、該ネットワーク環境のパブリックネットワークアドレスを用いて該コンピュータネットワーク環境に接続され、
該アドレス管理プロキシシステムから、該無線デバイスに関連付けられる該固有の識別子に対応するパブリックネットワークアドレスをリクエストするステップと、
該無線デバイスの該パブリックネットワークアドレスの指標を受信するステップと、
データを示されたパブリックネットワークアドレスに送るするステップと
による、コンピュータ読み出し可能メモリ媒体。 - 前記コンピュータネットワーク環境は、インターネットである、請求項91に記載のコンピュータ読み出し可能メモリ媒体。
- 前記示されたパブリックネットワークアドレスは、インターネットプロトコル(IP)アドレッシング基準にしたがって特定される、請求項91に記載のコンピュータ読み出し可能メモリ媒体。
- 前記固有の識別子は、個人名および電話番号、MSISDN番号、およびISMI番号の少なくとも一つである、請求項91に記載のコンピュータ読み出し可能メモリ媒体。
- 前記リクエストは、標準APIであり、その結果、前記無線デバイスとの通信は、前記コンピュータネットワーク環境に接続されたワイヤードデバイスとの通信と同一の態様で行われる、請求項91に記載のコンピュータ読み出し可能メモリ媒体。
- 前記APIは、GetHostByName機能呼び出しである、請求項95に記載のコンピュータ読み出し可能メモリ媒体。
- 前記無線デバイスの前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスである、請求項91に記載のコンピュータ読み出し可能メモリ媒体。
- 前記無線デバイスの前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスおよびポート仕様である、請求項91に記載のコンピュータ読み出し可能メモリ媒体。
- コンピュータネットワーク環境のパブリックネットワークアドレスを用いてコンピュータネットワーク環境に接続されたワイヤードデバイスであって、該ネットワーク環境は、該ネットワーク環境のパブリックネットワークアドレスを用いてアドレス管理プロキシシステムに接続され、該アドレス管理プロキシシステムは、プライベートネットワークアドレスを用いて無線デバイスに接続され、該無線デバイスは、前記プライベートネットワークアドレスではない関連付けられた固有の識別子を有し、
通信コードモジュールであって、
該アドレス管理プロキシシステムから、該無線デバイスに関連付けられる該固有の識別子に対応するパブリックネットワークアドレスをリクエストし、
該無線デバイスの該パブリックネットワークアドレスの指標を受信し、
データを該示されたパブリックネットワークアドレスに送るように構造化された、通信コードモジュール
を含む、ワイヤードデバイス。 - 前記コンピュータネットワーク環境は、インターネットである、請求項99に記載のデバイス。
- 前記示されたパブリックネットワークアドレスは、インターネットプロトコル(IP)アドレッシング基準にしたがって特定される、請求項99に記載のデバイス。
- 前記固有の識別子は、個人名および電話番号、MSISDN番号、およびISMI番号の少なくとも一つである、請求項99に記載のデバイス。
- 前記リクエストは、標準APIであり、その結果、前記無線デバイスとの通信は、前記コンピュータネットワーク環境に接続されたワイヤードデバイスとの通信と同一の態様で行われる、請求項99に記載のデバイス。
- 前記APIは、GetHostByName機能呼び出しである、請求項103に記載のデバイス。
- 前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスである、請求項99に記載のデバイス。
- 前記無線デバイスの前記パブリックネットワークアドレスの前記指標は、ホストマシンアドレスおよびポート仕様である、請求項99に記載のデバイス。
- 前記通信コードモジュールは、UDPおよびTCP/IPの少なくとも一つの通信を前記無線デバイスとインプリメントする、請求項99に記載のデバイス。
- 前記通信コードモジュールは、UDP通信を前記無線デバイスとインプリメントする、請求項99に記載のデバイス。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US29690201P | 2001-06-08 | 2001-06-08 | |
PCT/US2002/018485 WO2002102012A2 (en) | 2001-06-08 | 2002-06-10 | Method and system for two-way initiated data communication with wireless devices |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004533190A true JP2004533190A (ja) | 2004-10-28 |
Family
ID=23144044
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003504622A Withdrawn JP2004533190A (ja) | 2001-06-08 | 2002-06-10 | 双方向で開始する無線デバイスとのデータ通信のための方法およびシステム |
Country Status (10)
Country | Link |
---|---|
US (1) | US20030028671A1 (ja) |
EP (1) | EP1400093B1 (ja) |
JP (1) | JP2004533190A (ja) |
KR (1) | KR20040034612A (ja) |
CN (1) | CN1528081A (ja) |
AT (1) | ATE328436T1 (ja) |
AU (1) | AU2002345633A1 (ja) |
DE (1) | DE60211897T2 (ja) |
ES (1) | ES2263791T3 (ja) |
WO (1) | WO2002102012A2 (ja) |
Families Citing this family (63)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6725264B1 (en) * | 2000-02-17 | 2004-04-20 | Cisco Technology, Inc. | Apparatus and method for redirection of network management messages in a cluster of network devices |
US7092390B2 (en) | 2000-09-07 | 2006-08-15 | Sbc Technology Resources, Inc. | Internal substitution bi-level addressing for compatible public networks |
EP1419641B1 (en) * | 2001-08-24 | 2007-08-01 | British Telecommunications Public Limited Company | System and method of coordinating network events |
US7187921B1 (en) * | 2001-12-10 | 2007-03-06 | Bellsouth Intellectual Property Corporation | Apparatus, system and method for forwarding data sent to a wireless device to another address |
US7069336B2 (en) * | 2002-02-01 | 2006-06-27 | Time Warner Cable | Policy based routing system and method for caching and VPN tunneling |
US7065092B2 (en) * | 2002-07-31 | 2006-06-20 | Sbc Properties, L.P. | Resource reservation protocol based guaranteed quality of service internet protocol (IP) connections over a switched network using newly assigned IP addresses |
US7272145B2 (en) | 2002-07-31 | 2007-09-18 | At&T Knowledge Ventures, L.P. | Resource reservation protocol based guaranteed quality of service internet protocol connections over a switched network through proxy signaling |
US7298750B2 (en) | 2002-07-31 | 2007-11-20 | At&T Knowledge Ventures, L.P. | Enhancement of resource reservation protocol enabling short-cut internet protocol connections over a switched network |
US7301951B2 (en) * | 2002-07-31 | 2007-11-27 | At&T Knowledge Ventures, L.P. | Resource reservation protocol based guaranteed quality of service internet protocol connections over a switched network |
US7379971B2 (en) * | 2002-11-19 | 2008-05-27 | Microsoft Corporation | Time-to-disconnect enforcement when communicating with wireless devices that have transient network addresses |
US20040103153A1 (en) * | 2002-11-21 | 2004-05-27 | Chang Tsung-Yen Dean | Apparatus and method for providing smart network appliances |
KR100511479B1 (ko) * | 2002-12-27 | 2005-08-31 | 엘지전자 주식회사 | Nat를 갖는 망에서의 sip 서비스 방법 |
US20040260801A1 (en) * | 2003-02-12 | 2004-12-23 | Actiontec Electronics, Inc. | Apparatus and methods for monitoring and controlling network activity using mobile communications devices |
US20040158630A1 (en) * | 2003-02-12 | 2004-08-12 | Chang Tsung-Yen Dean | Monitoring and controlling network activity in real-time |
US7926104B1 (en) * | 2003-04-16 | 2011-04-12 | Verizon Corporate Services Group Inc. | Methods and systems for network attack detection and prevention through redirection |
US7739394B2 (en) * | 2003-07-29 | 2010-06-15 | At&T Intellectual Property I, L.P. | Bi-level addressing for internet protocol broadband access |
US7447203B2 (en) | 2003-07-29 | 2008-11-04 | At&T Intellectual Property I, L.P. | Broadband access for virtual private networks |
US7944947B2 (en) * | 2003-09-05 | 2011-05-17 | Nokia Corporation | Providing address information for reaching a wireless terminal |
US20050076141A1 (en) * | 2003-09-19 | 2005-04-07 | Williams Aidan Michael | Use of an autoconfigured namespace for automatic protocol proxying |
US20050210508A1 (en) * | 2004-03-19 | 2005-09-22 | Lau Vincent W | System and method for managing time-go-live information of media content |
GB2418321A (en) * | 2004-09-17 | 2006-03-22 | Compal Communications Inc | Method for establishing a socket connection between a client and a mobile station through a wireless network |
US20060168225A1 (en) * | 2004-10-29 | 2006-07-27 | John Gunning | Network and a distributed electronic commerce system using the network |
US7580915B2 (en) * | 2004-12-14 | 2009-08-25 | Sap Ag | Socket-like communication API for C |
US7600217B2 (en) * | 2004-12-14 | 2009-10-06 | Sap Ag | Socket-like communication API for Java |
US7593930B2 (en) * | 2004-12-14 | 2009-09-22 | Sap Ag | Fast channel architecture |
US7562138B2 (en) * | 2004-12-28 | 2009-07-14 | Sap | Shared memory based monitoring for application servers |
US7539821B2 (en) * | 2004-12-28 | 2009-05-26 | Sap Ag | First in first out eviction implementation |
US20060143389A1 (en) * | 2004-12-28 | 2006-06-29 | Frank Kilian | Main concept for common cache management |
US7886294B2 (en) * | 2004-12-28 | 2011-02-08 | Sap Ag | Virtual machine monitoring |
US7523196B2 (en) * | 2004-12-28 | 2009-04-21 | Sap Ag | Session monitoring using shared memory |
US7552153B2 (en) * | 2004-12-28 | 2009-06-23 | Sap Ag | Virtual machine monitoring using shared memory |
US20060143256A1 (en) * | 2004-12-28 | 2006-06-29 | Galin Galchev | Cache region concept |
US7689989B2 (en) * | 2004-12-28 | 2010-03-30 | Sap Ag | Thread monitoring using shared memory |
US20060153118A1 (en) * | 2005-01-11 | 2006-07-13 | International Business Machines Corporation | System and method for wireless ip address capacity optimization |
US7436814B2 (en) * | 2005-04-22 | 2008-10-14 | Cisco Technology, Inc. | Selecting transport addresses to route streams between endpoints |
US7516277B2 (en) * | 2005-04-28 | 2009-04-07 | Sap Ag | Cache monitoring using shared memory |
US20070160034A1 (en) * | 2006-01-06 | 2007-07-12 | D.S.P. Group Ltd | Dual-protocol dual port telephone and method to connect another dual-protocol dual port telephone via IP network directly and without installation |
US8612556B2 (en) * | 2006-05-03 | 2013-12-17 | Comcast Cable Holdings, Llc | Method of provisioning network elements |
US20080069101A1 (en) * | 2006-09-15 | 2008-03-20 | Nokia Corporation | System and method of routing packets |
US8462628B2 (en) * | 2006-12-20 | 2013-06-11 | Integrated Device Technology, Inc. | Method of improving over protocol-required scheduling tables while maintaining same |
EP2105003B1 (en) * | 2006-12-28 | 2018-02-21 | Telecom Italia S.p.A. | Method and apparatus to control application messages between a client and a server having a private network address |
US8311042B2 (en) * | 2007-06-15 | 2012-11-13 | Mformation | System and method for automatic detection and reporting of the mapping between device identity and network address in wireless networks |
US7724707B2 (en) | 2007-06-26 | 2010-05-25 | Motorola, Inc. | Network for a cellular communication system and a method of operation therefor |
SE0702582L (sv) * | 2007-11-15 | 2009-05-16 | Klap Worldwide Corp Ltd | Nätverk för kommunikation |
US9455924B2 (en) * | 2008-01-02 | 2016-09-27 | Media Network Services As | Device and system for selective forwarding |
EP2294848B1 (en) * | 2008-04-02 | 2016-03-09 | Vodafone Group PLC | Telecommunications network |
US8509235B2 (en) * | 2008-07-30 | 2013-08-13 | Blue Coat Systems, Inc. | Layer-2 packet return in proxy-router communication protocol environments |
US8196155B2 (en) * | 2008-10-08 | 2012-06-05 | Oracle International Corporation | XML-based event driven interface for OPC data access |
US8073934B1 (en) * | 2008-10-20 | 2011-12-06 | Amazon Technologies, Inc. | Automated load balancing architecture |
US7987255B2 (en) * | 2008-11-07 | 2011-07-26 | Oracle America, Inc. | Distributed denial of service congestion recovery using split horizon DNS |
US7924832B2 (en) * | 2008-11-13 | 2011-04-12 | Blue Coat Systems, Inc. | Facilitating transition of network operations from IP version 4 to IP version 6 |
US8578055B2 (en) * | 2009-07-09 | 2013-11-05 | International Business Machines Corporation | Propogation of DNS server IP addresses in a private network |
US8103795B2 (en) * | 2009-07-09 | 2012-01-24 | International Business Machines Corporation | TCP/IP host name resolution on a private network |
US8140669B2 (en) * | 2009-08-31 | 2012-03-20 | International Business Machines Corporation | Resolving hostnames on a private network with a public internet server |
US8902743B2 (en) * | 2010-06-28 | 2014-12-02 | Microsoft Corporation | Distributed and scalable network address translation |
US20120131162A1 (en) * | 2010-11-24 | 2012-05-24 | Brandt Mark S | Using a web service to delete dns records in a server hosting system |
CN101986608B (zh) * | 2010-12-13 | 2012-08-15 | 武汉大学 | 一种异构覆盖网络负载均衡程度的评价方法 |
US9015021B2 (en) * | 2011-10-25 | 2015-04-21 | Cellco Partnership | Multiple client simulator for push engine |
CN104639564A (zh) * | 2015-03-03 | 2015-05-20 | 北京极科极客科技有限公司 | 一种udp协议的代理方法 |
US10567518B2 (en) | 2015-06-26 | 2020-02-18 | Western Digital Technologies, Inc. | Automatic discovery and onboarding of electronic devices |
CN106487864B (zh) * | 2015-09-02 | 2019-09-27 | 华为终端有限公司 | 数据连接的建立方法、服务端及移动终端 |
ES2726302T3 (es) * | 2015-09-21 | 2019-10-03 | Huawei Tech Co Ltd | Sistema informático y procedimiento para acceder a un dispositivo de punto extremo del mismo |
WO2019166081A1 (en) | 2018-02-28 | 2019-09-06 | Nokia Technologies Oy | Transparent integration of 3gpp network into tsn based industrial network |
Family Cites Families (53)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5634010A (en) * | 1994-10-21 | 1997-05-27 | Modulus Technologies, Inc. | Managing and distributing data objects of different types between computers connected to a network |
US6244758B1 (en) * | 1994-11-15 | 2001-06-12 | Absolute Software Corp. | Apparatus and method for monitoring electronic devices via a global network |
US6625652B1 (en) * | 1995-01-19 | 2003-09-23 | The Fantastic Corporation | System and method for host list pruning |
US6418324B1 (en) * | 1995-06-01 | 2002-07-09 | Padcom, Incorporated | Apparatus and method for transparent wireless communication between a remote device and host system |
US5812786A (en) * | 1995-06-21 | 1998-09-22 | Bell Atlantic Network Services, Inc. | Variable rate and variable mode transmission system |
US6041041A (en) * | 1997-04-15 | 2000-03-21 | Ramanathan; Srinivas | Method and system for managing data service systems |
US6134432A (en) * | 1997-06-17 | 2000-10-17 | Bulletin.Net, Inc. | System and process for allowing wireless messaging |
FI104668B (fi) * | 1997-07-14 | 2000-04-14 | Nokia Networks Oy | Liittymäpalvelun toteuttaminen |
US6023724A (en) * | 1997-09-26 | 2000-02-08 | 3Com Corporation | Apparatus and methods for use therein for an ISDN LAN modem that displays fault information to local hosts through interception of host DNS request messages |
US6377982B1 (en) * | 1997-10-14 | 2002-04-23 | Lucent Technologies Inc. | Accounting system in a network |
US6665718B1 (en) * | 1997-10-14 | 2003-12-16 | Lucent Technologies Inc. | Mobility management system |
US6675208B1 (en) * | 1997-10-14 | 2004-01-06 | Lucent Technologies Inc. | Registration scheme for network |
JPH11122301A (ja) * | 1997-10-20 | 1999-04-30 | Fujitsu Ltd | アドレス変換接続装置 |
GB2332288A (en) * | 1997-12-10 | 1999-06-16 | Northern Telecom Ltd | agent enabling technology |
JP3966598B2 (ja) * | 1998-03-04 | 2007-08-29 | 富士通株式会社 | サーバ選択システム |
US6233618B1 (en) * | 1998-03-31 | 2001-05-15 | Content Advisor, Inc. | Access control of networked data |
US6345304B1 (en) * | 1998-04-01 | 2002-02-05 | Xerox Corporation | Obtaining network addresses from identifiers |
US6058431A (en) * | 1998-04-23 | 2000-05-02 | Lucent Technologies Remote Access Business Unit | System and method for network address translation as an external service in the access server of a service provider |
US6011844A (en) * | 1998-06-19 | 2000-01-04 | Callnet Communications | Point-of-presence call center management system |
US6401128B1 (en) * | 1998-08-07 | 2002-06-04 | Brocade Communiations Systems, Inc. | System and method for sending and receiving frames between a public device and a private device |
US6421732B1 (en) * | 1998-08-27 | 2002-07-16 | Ip Dynamics, Inc. | Ipnet gateway |
US6317831B1 (en) * | 1998-09-21 | 2001-11-13 | Openwave Systems Inc. | Method and apparatus for establishing a secure connection over a one-way data path |
US6622157B1 (en) * | 1998-09-28 | 2003-09-16 | Certeon, Inc. | Extending network services using mobile agents |
JP3327225B2 (ja) * | 1998-10-29 | 2002-09-24 | 三菱マテリアル株式会社 | ネットワークアドレス変換装置およびその記録媒体 |
US6502135B1 (en) * | 1998-10-30 | 2002-12-31 | Science Applications International Corporation | Agile network protocol for secure communications with assured system availability |
US6161008A (en) * | 1998-11-23 | 2000-12-12 | Nortel Networks Limited | Personal mobility and communication termination for users operating in a plurality of heterogeneous networks |
US6657991B1 (en) * | 1998-12-21 | 2003-12-02 | 3Com Corporation | Method and system for provisioning network addresses in a data-over-cable system |
US6452920B1 (en) * | 1998-12-30 | 2002-09-17 | Telefonaktiebolaget Lm Ericsson | Mobile terminating L2TP using mobile IP data |
JP2000270007A (ja) * | 1999-03-12 | 2000-09-29 | Sony Corp | ネットワークシステム、ネットワークサーバ及び端末装置 |
US6731642B1 (en) * | 1999-05-03 | 2004-05-04 | 3Com Corporation | Internet telephony using network address translation |
US6769000B1 (en) * | 1999-09-08 | 2004-07-27 | Nortel Networks Limited | Unified directory services architecture for an IP mobility architecture framework |
US7934251B2 (en) * | 1999-12-02 | 2011-04-26 | Western Digital Technologies, Inc. | Managed peer-to-peer applications, systems and methods for distributed data access and storage |
US20040220926A1 (en) * | 2000-01-03 | 2004-11-04 | Interactual Technologies, Inc., A California Cpr[P | Personalization services for entities from multiple sources |
US20020091855A1 (en) * | 2000-02-02 | 2002-07-11 | Yechiam Yemini | Method and apparatus for dynamically addressing and routing in a data network |
US6714545B1 (en) * | 2000-03-03 | 2004-03-30 | Qwest Communications International, Inc. | VDSL data network, service and management architecture |
US6948003B1 (en) * | 2000-03-15 | 2005-09-20 | Ensim Corporation | Enabling a service provider to provide intranet services |
US6754709B1 (en) * | 2000-03-29 | 2004-06-22 | Microsoft Corporation | Application programming interface and generalized network address translator for intelligent transparent application gateway processes |
US6996628B2 (en) * | 2000-04-12 | 2006-02-07 | Corente, Inc. | Methods and systems for managing virtual addresses for virtual networks |
US6631416B2 (en) * | 2000-04-12 | 2003-10-07 | Openreach Inc. | Methods and systems for enabling a tunnel between two computers on a network |
US7181766B2 (en) * | 2000-04-12 | 2007-02-20 | Corente, Inc. | Methods and system for providing network services using at least one processor interfacing a base network |
US7181542B2 (en) * | 2000-04-12 | 2007-02-20 | Corente, Inc. | Method and system for managing and configuring virtual private networks |
US7085854B2 (en) * | 2000-04-12 | 2006-08-01 | Corente, Inc. | Methods and systems for enabling communication between a processor and a network operations center |
US6829654B1 (en) * | 2000-06-23 | 2004-12-07 | Cloudshield Technologies, Inc. | Apparatus and method for virtual edge placement of web sites |
US6772210B1 (en) * | 2000-07-05 | 2004-08-03 | Nortel Networks Limited | Method and apparatus for exchanging communications between telephone number based devices in an internet protocol environment |
US6910074B1 (en) * | 2000-07-24 | 2005-06-21 | Nortel Networks Limited | System and method for service session management in an IP centric distributed network |
WO2002015051A1 (en) * | 2000-08-16 | 2002-02-21 | Verisign, Inc. | A numeric/voice name internet access architecture and methodology |
US20020101859A1 (en) * | 2000-09-12 | 2002-08-01 | Maclean Ian B. | Communicating between nodes in different wireless networks |
KR20020027807A (ko) * | 2000-10-05 | 2002-04-15 | 이종석 | 인터넷을 이용한 전화서비스 방법 |
US20020078153A1 (en) * | 2000-11-02 | 2002-06-20 | Chit Chung | Providing secure, instantaneous, directory-integrated, multiparty, communications services |
US20020087722A1 (en) * | 2000-12-29 | 2002-07-04 | Ragula Systems D/B/A/ Fatpipe Networks | Domain name resolution making IP address selections in response to connection status when multiple connections are present |
US7164883B2 (en) * | 2001-02-14 | 2007-01-16 | Motorola. Inc. | Method and system for modeling and managing terrain, buildings, and infrastructure |
US20020138622A1 (en) * | 2001-03-21 | 2002-09-26 | Motorola, Inc. | Apparatus and method of using long lived addresses in a private network for push messaging to mobile devices |
US20060020688A1 (en) * | 2001-05-14 | 2006-01-26 | At&T Corp. | System having generalized client-server computing |
-
2002
- 2002-06-10 JP JP2003504622A patent/JP2004533190A/ja not_active Withdrawn
- 2002-06-10 DE DE60211897T patent/DE60211897T2/de not_active Expired - Fee Related
- 2002-06-10 EP EP02744283A patent/EP1400093B1/en not_active Expired - Lifetime
- 2002-06-10 KR KR10-2003-7016044A patent/KR20040034612A/ko not_active Application Discontinuation
- 2002-06-10 AU AU2002345633A patent/AU2002345633A1/en not_active Abandoned
- 2002-06-10 CN CNA028140311A patent/CN1528081A/zh active Pending
- 2002-06-10 ES ES02744283T patent/ES2263791T3/es not_active Expired - Lifetime
- 2002-06-10 US US10/167,240 patent/US20030028671A1/en not_active Abandoned
- 2002-06-10 AT AT02744283T patent/ATE328436T1/de not_active IP Right Cessation
- 2002-06-10 WO PCT/US2002/018485 patent/WO2002102012A2/en active IP Right Grant
Also Published As
Publication number | Publication date |
---|---|
WO2002102012A2 (en) | 2002-12-19 |
EP1400093B1 (en) | 2006-05-31 |
DE60211897D1 (de) | 2006-07-06 |
KR20040034612A (ko) | 2004-04-28 |
ES2263791T3 (es) | 2006-12-16 |
DE60211897T2 (de) | 2006-10-19 |
ATE328436T1 (de) | 2006-06-15 |
CN1528081A (zh) | 2004-09-08 |
EP1400093A2 (en) | 2004-03-24 |
US20030028671A1 (en) | 2003-02-06 |
WO2002102012A3 (en) | 2003-04-03 |
AU2002345633A1 (en) | 2002-12-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1400093B1 (en) | Method, memory medium, computer network and device for two-way initiated data communication with wireless devices | |
US7937471B2 (en) | Creating a public identity for an entity on a network | |
US7320027B1 (en) | System having generalized client-server computing | |
US7450585B2 (en) | Method and system in an IP network for using a network address translation (NAT) with any type of application | |
US7139828B2 (en) | Accessing an entity inside a private network | |
AU2009304186B2 (en) | NAT traversal method and apparatus | |
US7603410B1 (en) | System having generalized client-server computing | |
US7779158B2 (en) | Network device | |
US20070094411A1 (en) | Network communications system and method | |
WO2006011980A2 (en) | ARRANGEMENT FOR REACHING IPv4 PUBLIC NETWORK NODES BY A NODE IN AN IPv4 PRIVATE NETWORK VIA AN IPv6 ACCESS NETWORK | |
US8234358B2 (en) | Communicating with an entity inside a private network using an existing connection to initiate communication | |
JP2000201183A (ja) | デ―タ送信方法 | |
EP1187426B1 (en) | Method for using a unique IP address in a private IP address domain | |
US7440466B2 (en) | Method, apparatus and system for accessing multiple nodes on a private network | |
US20060031514A1 (en) | Initiating communication sessions from a first computer network to a second computer network | |
JP3893978B2 (ja) | 通信装置 | |
KR20030089305A (ko) | 임베디드 장치에 대한 아이피 주소 등록 및 참조 방법과그 시스템 | |
Fischer | OnionCat–An Anonymous Internet Overlay | |
JP2000101648A (ja) | ネットワ―ク接続装置 | |
KR20160057178A (ko) | Rmi 통신 방법 및 장치 | |
IES84430Y1 (en) | Network communications system and method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050531 |
|
A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20061114 |