JP2003524309A - 地理空間的なインターネットプロトコルのアドレッシング - Google Patents

Abstract

(57)【要約】 【課題】本発明は、現在のＴＣＰ／ＩＰ（ｖ４）の要求、および将来のアドレス付け（ｖ６／ｎｇ）の要求をサポートするアドレス付け機構へ、緯度と経度を変換する方法を提供する。 【解決手段】具体的には、これにより、ホストされたネットワーク上の装置へのユニキャスト・ポイントの分散化が可能になる。地理的インターネット・プロトコル（ＧｅｏＩＰ）アドレッシングは、エニイキャストのルーティング機構（この機構においては、最も近いノードが静的に割り当てられたＧｅｏＩＰを持っている）を容易にする。地理的ルーティング（Geo routing）やネットワーク管理は、ＧｅｏＩＰアドレスの機能により行われる。

Description

【発明の詳細な説明】

【０００１】

【従来の技術】

［インターネット］ 今日知られているインターネット・プロトコル（ＩＰ）は１９７０年代の後半
に設計されたものであり、３２ビットのメッセージ（２の３２乗のメッセージ、
すなわち、後にＩＰｖ４と呼ばれる４個の８ビットメッセージ（例：255.255.25
5.255）によって表現されるメッセージ）によって、およそ４２億５千万個の固
有のアドレスが許容されている。その当時においては、これは、将来の要求を満
たすのに十二分なアドレス空間であると考えられていた。そして、ＩＰはまだ試
験的なものであって、しかも、研究者によって注目され、研究者のために注目さ
れていたのである。また、その当時においては、パーソナルコンピュータはまだ
予言的なものであった。

【０００２】 そして、１９９０年代までにはＩＰｖ４に基づくアドレス付けが底を尽きてし
まうということが明らかになり、中には、早ければ１９９５年までには尽きてし
まうと考える者もいた。その結果、ＩＥＴＦ（インターネット技術標準化委員会
／Internet Engineering Task Force）とよばれる委員会が発足されて、ＩＰｖ
６が検討されることとなった。この委員会のキーとなる宣言は、相互運用性、前
方互換性、および後方互換性にあった。

【０００３】 新しいアドレス付け（アドレッシング）体系の基本的な構造は、コロンで区切
られた８個の１６ビットメッセージとして表現されるとともに、１６進数の形式
で表現される１２８ビットのメッセージである（例えば、１６進でFFFF:FFFF:..
.、１０進で65535:65535:...、２進で1111111111111111:1111111111111111:...
）。利用可能なアドレスの組み合わせはおよそ３．４×１０³⁸個の固有のアドレ
スであり、これは、将来的に予測し得なかった事態が生じない限りは、次の千年
間におけるネットワークのアドレス付けを確実に処理するのに十分なものである
。

【０００４】 ＩＥＴＦが提案する体系の一部として、利用可能なネットワークアドレッシン
グの１／８を表す２進のプレフィックス（１００）が取り除かれる。これは取り
除かれて、地理に基づくアドレス付け（Geographicベースのアドレス付け）に利
用される。ユニキャスト（unicast）は、決定されたアドレス（または、割り当
てられたアドレス）、あるいは、単一のインタフェースに対する固有の識別子と
して定義される。すなわち、ユニキャスト・アドレスに送られたパケットは、こ
のアドレスによって特定されるインタフェースに送られる。

【０００５】 ＴＣＰ／ＩＰは、ＯＳＩ参照モデル（Open Systems Interconnect Reference
Model）のコネクション／コネクションレス・プロトコルを表す。ＯＳＩは、ネ
ットワークにおける２つのエンドユーザ間の通信のための標準参照モデルである
。これは、製品の開発やネットワークの理解に利用される。ＯＳＩ参照モデルは
関連した機能からなる７つの層を記述しており、これらは、ネットワークにおけ
るある一群から別の一群にデータが送られるときに、それぞれのユーザ側で必要
とされるものである。既存のネットワーク製品やプログラムは、この製品やプロ
グラムが当てはまる層によって、部分的に説明することが可能である。例えば、
通常、ＴＣＰ／ＩＰは、インターネット上での通信を支援する製品として、他の
インターネットプログラムとともにパッケージングされている。この製品は、フ
ァイル転送プロトコル（ＦＴＰ／File Transfer Protocol）、Ｔｅｌｎｅｔ、ハ
イパーテキスト転送プロトコル（ＨＴＴＰ／Hyper Transfer Protocol）、電子
メールプロトコルなどを含んでいる。

【０００６】 ＯＳＩモデルは、ネットワークやあらゆるＩＰネットワーク、最も下位の層（
携帯電話などによる物理的接続）からユーザのアプリケーションを含んだ層に至
るまでのデータの流れを記述している。ネットワークを行き交うデータは層から
層へと通過する。各層は、直ぐ上の層と（あるいは直下の層と）通信することが
可能である。

【０００７】 上述したＯＳＩ参照モデルは、以下の７つの層を含んでいる。

【０００８】 １．アプリケーション層は、アプリケーションがネットワークサービスにアク
セスするレベルを表す。この層は、アプリケーションを直接支援するサービスを
表す。

【０００９】 ２．プレゼンテーション層は、アプリケーション層からのデータを、中間のフ
ォーマットに変換する。また、この層はデータの暗号化のようなサービスを提供
することによってセキュリティの問題を管理したり、ネットワーク上でより少な
いビット数で転送できるようにデータを圧縮したりする。

【００１０】 ３．セッション層は、異なるシステム上の２つのアプリケーションがセッショ
ンを確立し、使用し、終了することを可能にする。この層は、セッション内の２
つのコンピュータのダイアログ制御を確立し、どちらのコンピュータが送信を行
うのか、いつ送信を行うのか、また、どのくらいの間送信を行うのかを調整する
ようになっている。

【００１１】 ４．トランスポート層は、エラー認識と回復を取り扱う。また、必要であれば
、長いメッセージを、送信のために小さなパケットに再パッケージ化し、さらに
、受信側において、これらのパケットをオリジナルメッセージに再構築する。さ
らに、受信側のトランスポート層は、受信確認通知を送信するようになっている
。

【００１２】 ５．ネットワーク層は、メッセージに対してアドレス付けを行い、また、論理
アドレスや論理名を物理アドレスに変換する。また、送信元のコンピュータから
送信先のコンピュータへの経路を決定するとともに、トラフィックに関する問題
（音声信号やデータの切り替え、ルーティング、制御など）を管理する。

【００１３】 ６．データリンク層は、物理層からの未加工のビットを、フレーム（データの
ために構造化された論理パケット）にパッケージ化する。この層は、エラーを生
ずることなく、あるコンピュータから別のコンピュータに、フレームを送る役割
を担っている。フレームを送信した後においては、受信側のコンピュータからの
確認通知を待つ。

【００１４】 ７．物理層は、あるシステムから別のシステムにデータを送り、物理的な媒体
上でのデータの送信を調整するようになっている。この層は、どのようにしてケ
ーブルが装置に取り付けられているか、及び、システム上でデータを送信するた
めにどのような送信技術が使用されているのかを定義する。

【００１５】 ２つの装置がネットワーク上で通信する際には、一方のシステムにおける各層
のソフトウェアは、他方のシステムにおける同じ層と通信しているものと仮定す
る。例えば、一方のシステムのトランスポート層は、他方のシステムのトランス
ポート層と通信する。第１のシステムのトランスポート層にとってみれば、通信
が実際にはどのようにして、第１のシステムの下位側の層を通り、物理的な媒体
を経由し、第２のシステムの下位側の層を通るのかは、関係がないことである。

【００１６】 ＴＣＰはＯＳＩ参照モデルのトランスポート層に完全に当てはまり、ＩＰはネ
ットワーク層に完全に当てはまるが、他のプログラムは、ある程度大ざっぱに、
セッション層、プレゼンテーション層、アプリケーション層に当てはまる（しか
し、１つの層の範囲内にはきちんと当てはまらない）。このＯＳＩ参照モデルに
おいて、ネットワーク層および該ネットワーク層よりも上位の層においては、イ
ンターネットに関連するプログラムだけが含まれている。また、ＯＳＩ参照モデ
ルは、音声を含めるために他のネットワーク環境に適用することも可能である。
ＯＳＩ参照モデルに完全に従った通信製品は、適切に各層に当てはまるようにな
っている。

【００１７】 ＩＰｖ６（Internet Protocol Version 6）やＩｐｎｇ（IP Next Generation
）の出現により、ネットワーク・インタフェースの数は、ネットワークを越えて
個々の装置にまで拡張することが可能である。リアルタイムで安全なユニキャス
トのポイントは、エニイキャスト（anycast）（これは、ある単一の送信者と、
グループ内の送信者に最も近い（最寄の）数人の受信者との間における通信とし
て定義される）と称されるコンセプトによって、本質的に個々のユーザにまで拡
張されることが可能である。このエニイキャストという用語は、マルチキャスト
（単一の送信者と複数の受信者との間における通信）、およびユニキャスト（ネ
ットワークにおける、単一の送信者と単一の受信者との間における通信）に対向
する用語として存在する。エニイキャストは、単一のホストが、複数のホストの
グループに関するルーティング・テーブルの効率的な更新(Update)を開始させる
ように設計されている。

【００１８】 Ｉｐｖ６は、どのゲートウェイ・ホスト（gateway host）が最も近いかを決定
することがさ可能であり、このホストに、あたかもユニキャスト通信であるかの
ようにパケットを送信する。一方、このホストは、すべてのルーティング・テー
ブルがアップデートされるまで、グループ内の別のホストにエニイキャスト通信
を行うことが可能である。

【００１９】 エニイキャストは、ユニキャストのインタフェースが、装置に対してユニキャ
スト・リンク（unicast link）として機能することを可能とする。この場合、そ
のアドレスは、ユニークな（固有の）ものであって、また、そのインタフェース
は、インターネットのバックボーンに対して仮想的なものである。このコンセプ
トを古典的なインターフェース装置以外の装置（例えば、コンピュータやネット
ワークなど）に拡張し、さらに、アドレス付け機構を拡張することによって、ほ
とんどリアルタイムで安全なデータ送信方法（すべての意図、目的のためのデー
タ送信方法）を考案した。ＩＰｖ６、ユニキャスト・リンク及びエニイキャスト
は、トンネリング・プロトコル（データ送信におけるネットワークの待ち時間を
減少させるために必要とされるプロトコル）にとって重要な要素である。

【００２０】 インターネットと関連して、トンネリング（tunneling）とは、プライベート
で安全なネットワークの一部としてインターネットを使用することである。ここ
でいう“トンネル（tunnel）”とは、与えられたメッセージやファイルがインタ
ーネットを介して移動し得る特定の経路である。ポイント・ツー・ポイント・ト
ンネリング・プロトコル（ＰＰＴＰ／Point-to-Point Tunneling Protocol）と
称されるプロトコル（あるいは、通信ルールのセット）は、インターネット上の
“トンネル”を介して仮想的なプライベートネットワークを創造することができ
るように提案されたものである。これは、装置がもはや広域通信のために独立サ
ービス・プロバイダー（ＩＳＰ／Independent Service Provider）のサポートを
必要としないことを意味するとともに、ほとんどリアルタイムで安全にプライベ
ート・ネットワークを使うことができることを意味する。マイクロソフトや他の
企業に支持されているＰＰＴＰや、シスコシステムズによって提案されたLayer
2 Forwardingは、新しいＩＥＴＦ標準（インターネット技術標準化委員会の標準
）に対する主な提案である。インターネットのポイント・ツー・ポイント・プロ
トコル（ＰＰＰ）の延長であるＰＰＴＰにより、ＰＰＰクライアントの支援のあ
る通信装置のいずれのユーザも、ＩＳＰを利用して、当該ドメイン内のどこかの
装置に安全に接続することができる。

【００２１】 ＰＰＰは二つの装置間の通信のためのプロトコルであり、種々の物理媒体上（
ツイスト・ペア線、光ファイバー線、衛星通信を含む）で使用することが可能な
全二重プロトコル（full-duplex protocol）である。ＰＰＰは、パケットのカプ
セル化のために、ＨＤＬＣ（高速データリンク制御手順／High Speed Data Link
Control）の変形版を使用する。ＰＰＰは、非同期通信のみならず同期通信を扱
うことができるので、通常、早い段階からデファクトスタンダードであったＳＬ
ＩＰ（Serial Line Internet Protocol）より好まれる。ＰＰＰは他のユーザと
回線を共有することができ、また、ＳＬＩＰにはないエラー検出機能を持ってい
る。従って、選択できるのであれば、ＰＰＰが好ましい。

【００２２】 仮想私設網（ＶＰＮ／Virtual Private Network）は、公衆遠距離通信基盤を
用いる私設のデータ・ネットワークであり、トンネリング・プロトコル処理やセ
キュリティ処理を利用することによってプライバシーを維持するようになってい
る。仮想私設網は、単一の企業だけが使用することができるような自己所有の回
線システム（又はリースされた回線システム）と対比することができる。仮想私
設網の考え方は、公衆基盤を共有することにより、ユーザにはるかに低いコスト
で同じ能力を与えることにある。電話会社は、音声メッセージのための安全な共
有資源をすでに提供しているのである。

【００２３】 仮想私設網は、データに対して同じ公衆資源を安全に共有することを可能にす
る。今日のユーザは、仮想私設網を、エクストラネット(extranets)と広域イン
トラネットの両方のために使用することに注目している。仮想私設網を使用する
ということは、公衆通信回線を介してデータを送信する前にこのデータを暗号化
し、また、受信側でそれを復号化することを意味する。補足的なセキュリティの
レベルには、データだけでなく、発信元と受信側のネットワーク・アドレスも暗
号化することが含まれている。今のところまだ標準プロトコルは存在しないが、
マイクロソフトや３Ｃｏｍ、その他の企業が、ポイント・ツー・ポイント・トン
ネリング・プロトコル（ＰＰＴＰ）という標準プロトコルを提案しており、マイ
クロソフトは、そのプロトコルをウィンドウズＮＴ（登録商標）サーバに組み込
んでいる。マイクロソフトのＰＰＴＰサポート等のＶＰＮソフトウェアやセキュ
リティソフトウェアは、たいていそのようになっている。

【００２４】 ［ＧＰＳ］ グローバル・ポジショニング・システム、すなわち、ＧＰＳは、ベトナム戦争
中に米軍が経験した問題の結果として生まれた。地上軍にとっての主要な難点の
１つは、いかにして連絡を取り続けるかということにあった（これは、特に、厳
しいジャングル地形であるという理由で）。局所的なＬＯＲＡＮシステムが用い
られたが、これは、すべての無線システムに共通したエラー（地上波のゆがみに
よるエラー、夜間や悪天候下での不良無線の受信によるエラーなど）に影響され
やすかった。そこで、米国は、当初ＴＲＡＮＳＩＴと呼ばれた４つの衛星からな
るシステムで実験を行った。これらは、上空の高軌道上にあり、軍隊のみならず
船舶のユーザも利用可能であった。しかしながら、位置決定が良くても２時間毎
にだけ行われるだけということから、そのシステムは、かなり不正確なものであ
った。

【００２５】 次にＮａｖＳｔａｒシステムが開発され、１９８６年から一定の制限の下で利
用できたが、軌道内の衛星の数が少なかったため、使用可能な時間は１日のうち
のほんの３〜４時間だけであった。１９９０年に戦争がペルシャ湾で始まったと
きには、ＧＰＳシステムは“部分的に使用可能”なものとなった。ここにきて、
すでに使用されていた複数のＢｌｏｃｋ２衛星に加えて、実験的な複数のＢｌｏ
ｃｋ２衛星が用いられ、これによって、使用可能な一群の２１個の衛星が与えら
れた。国防総省は、１９９０年にそのシステムを民間ユーザが利用できるように
した。これが、今日我々が使用しているものと同じＧＰＳシステムである。

【００２６】 ＧＰＳ衛星は、地上１１，０００マイル上空で、１日に２周地球を周回してお
り、その正確な位置と高度を送信している。ＧＰＳレシーバは、ＧＰＳ衛星から
の信号を受信し、さらに、信号の送信時と受信時の間隔を測定して、ＧＰＳレシ
ーバと衛星との間の距離を決定するようになっている。ＧＰＳレシーバがこのデ
ータを少なくとも３つの衛星との関係で計算すると、地球表面上でのＧＰＳレシ
ーバの位置を決定することができる。

【００２７】 すべての衛星は、暦（almanac）と天体暦（ephemeris）のデータを送信する。
暦のデータは、一群の衛星の中の各衛星の位置および状態に関する共通情報であ
り、このデータは各衛星が受信できるようになっている。ＧＰＳレシーバはメモ
リ内に現在の暦データを格納しており、上空のどの方向において衛星を探すべき
かを知っている（この情報は、最後に測定された位置と日時によって与えられる
）。天体暦のデータは衛星の正確な位置を決定するための情報であり、この情報
は、衛星の位置を計算するためにＧＰＳレシーバによって用いられる。各衛星は
、自身の天体暦のデータを送信するようになっている。

【００２８】 また、衛星から送られる信号のタイプには、ＣＡ（Coarse Acquisition）とＰ
ＰＳ（Precise Positioning System）の２つの異なったタイプの信号がある。Ｃ
Ａで符号化された信号は、１５メートルのＲＭＳ（Root Mean Square／根二乗平
均）の精度を与える。しかしながら、国防総省が、選択的な利用可能性（Select
ive Availability）として知られるランダム・エラーを、システムに導入した。
これは、衛星がランダムにエラー信号を送り出し、それによって、表向きには、
衛星から送信される信号の精度を１００メートル程度にまで下げることを意味す
る（しかし、精度は通常５０メートル程度である）。ＰＰＳは、主に、許可を受
けたユーザ（主に、軍隊）だけが利用可能であり、１メートル以下の精度を提供
することが可能である。

【００２９】 この技術の出現、その後の商業化、サイズ、コストおよび精度の革新により、
ＧＰＳは、つい最近まで互換性（あるいは、利用可能性または必要性）が考慮さ
れていなかったシステムに利用可能な技術として表面化しつつある。

【００３０】 ［ワイヤレス通信（無線通信）］ セルラ通信（ワイヤレス通信）は、過去数年の間に、アナログからデジタルに
進化した。これらのデータの流れは、テレコミュニケーション産業において標準
化されたプロトコルを利用して送られる。それらはＧＳＭ、ＣＤＭＡ、ＴＤＭＡ
等と呼ばれ、これらは、それぞれ独自ものであるが、データの概念による音声（
voice under data concept）として開発されたものである。いくつかは純粋にデ
ジタル化へと発展していったが、テレコミュニケーション・ネットワークは、全
体的には、依然としてボイス・オン・ボイス・ネットワーク（Voice on Voice N
etwork）のままである。これらの高速デジタル通信は、純粋なデジタル環境にお
いては、ＴＣＰ／ＩＰで支援することが可能な能力を備えている。

【００３１】 これまで、「インターネット・データ通信」、「グローバル・ポジショニング
・システム（ＧＰＳ）」、「ワイヤレス通信」の３つの異なる技術分野は、それ
ぞれ、独自の発展を遂げてきており、各技術分野は、自らの挑戦および商業市場
に注目してきた。現在のアプリケーションは、より広い視野でこれらの技術を見
直したことの結果であって、また、新たな機能性や効率性を与えるために、これ
らの技術が共通し合う方法（あるいは、これらの技術が共通し合う可能性がある
方法）を模索したことの結果でもある。ニーズは影響力があるものと認識され、
これらの種々の技術のうちの選択された要素に融合された。具体的には、ますま
す増える多数のモバイルユーザの便宜を図るニーズがある一方、同時に高いレベ
ルのデータ通信サービスを提供しなければならない。

【００３２】 具体的なニーズとしては、モバイル・コンピューティング装置同士の間でデー
タ通信を行う方法がある。コンピュータやその他のモバイル装置は予測し得なか
った方法で惑星上を移動することがあるかもしれないが、そのような場合であっ
ても、データ通信は、高速で信頼できるものである必要がある。また、大きなパ
ラダイムシフトは商業的には実現可能ではないので、モバイルデータ通信は、既
存のネットワーク及びプロトコルと互換性がなければならない。

【００３３】

【発明が解決しようとする課題】

本発明は、ラップトップコンピュータや無線電話（携帯電話）のようなモバイ
ル装置を用いたデータ通信用の方法及び装置に関する。

【００３４】

【課題を解決するための手段】

この発明は、非常に多くのモバイル装置にアドレスを割り当てるとともに、それ
らのアドレスがすべてユニークな（固有なあるいは独特な）ものであることを保
証する新しい方法を提供する。モバイルタイプでない固定された装置に対しても
同じ方法を効果的に用いることができる。（実際、モバイル装置は、静止状態で
用いられることもあり、また固定タイプの装置も再配置さえることがある。）こ
のグローバルな位置決めシステムは、ユニークなフォーマットを有する何らかの
装置と惑星上の基準位置を提供する。地球上の二つの場所が同じ位置を有するこ
とはない。６フィート毎に緯度(latitude)及び経度(longitude)を表した場合（
例えば、-122 30.1255, 45 28.3478）のユニークなアドレスの人数の合計を計算
すると、約２・１６×１０⁶のユニークなアドレスを得ることができる。本発明
の主要な点は、世界中の位置を用いて、全世界にわたるユニークなインターネッ
トプロトコル（IPv4, IPv6）互換のアドレス設計を生成することにある。製品に
おけるGPS受信器を含む無線通信の送受話器のプロバイダによる最近の報告では
、必要なグローバルな位置データは携帯電話で直ちに利用することができ、同様
なやり方で仮想的に電子機器に組み込むこともできる。本発明は、ユニークなア
プリケーションをシステム設計のトランスポートやネットワーク層に組み込むこ
とを可能にする。

【００３５】 本発明の第２の特徴は、ネットワーク設計におけるパラダイムシフト(paradig
m shift)である。この発明は、既存のネットワークやプロトコルと互換性がある
。従来、携帯電話やラップトップコンピュータなどのモバイル装置は、ネットワ
ーク構造における“クライアント”のようなものだと考えられており、通信ソフ
トウェアや“スタックス”はそのようなものになっていた。クライアントはサー
バーとまたはサーバーを介して交信する。当初は、サーバーまたはホストは、ク
ライアントに対してＩＰアドレスを割り当てるようになっていた。（通常は、DH
CP、Dynamic Host Configuration Protocolを用いている。）クライアントは、
世界の他の部分と、割り当てられたアドレスを用いてそのサーバーを介して交信
することができた。サーバーは、ゲートウェイとして働き、クライアントからの
パケットを受信し、それを再パッケージ（encapsulate）し、それを広いネット
ワーク上に送出する。

【００３６】 本発明は、この従来のやり方を覆すものである。本発明によれば、それ自体の
IPアドレスを割り当てるのは、携帯電話やラップトップコンピュータなどの“ク
ライアント”すなわちエンドユーザーの装置であって、サーバーやホストではな
い。そのため、新しいDCCP（Dynamic Client Configuration Protocol）を考案
した。このクライアントは、インターネットのような大きなネットワークに直接
通信できるサーバーのように機能し、中間に介在する装置の数を減らすことがで
きる。そのため、この（全世界的な位置に基づく）独自のIPアドレスが割り当て
られた新しい独立したクライアントは、ゲートウェイやルーターをエミュレート
(emulate)することができ、それ独自のパケットを選択に従って包含する。アド
レスは、従来例のようにホストダウンではなくクライアントアップで決定される
。この新たなパラダイムは、従来のシステムより早くインターネットを横断する
ための特別なポテンシャルを有しており、現在のレベルよりもはるかに下の通信
呼び出し時間及びオーバーヘッド(communication latency and overhead)を行う
。

【００３７】 このプロトコルスタックスをエンドユーザーに操作させることによって、無線
のキャリアのネットワークにおける基地局とは反対に、音声は、データを超える
音声("voice over data")の地位まで発展する。本発明のこのコンセプトは、ス
マートな無線装置の統合に対する基礎をなすものであり、ユニークなＩＰアドレ
スのアドレッシング体系を作ることがきる。このアドレッシング体系は、反面、
エニイキャスト及びユニキャスト分散化(anycast and unicast decentralizatio
n)に対するＳＬＩＰ又はＰＰＰや、ＶＲＮ‘ｓをサポートするＰＰＴＰのような
トンネリングプロトコルや、ネットワークへのセッションからのトランスポート
に対する接続並列プロトコル(TCP)をサポートする。我々が判断した欠如したキ
ーは、前述したすべてのものをユニークな方法でサポートするアドレス体系であ
り、そのように解決されたコンフリクトする（抵触する）アドレスは、規則より
むしろ例外的なものである。知識と制御は、効果的なルーティングのリアルタイ
ムのデータ転送を達成するために、通信装置に対してなされなければならない。

【００３８】 本発明の他の目的及び利点は、図面を参照してなされる以下の好適実施例の説
明からより明らかとなるであろう。

【００３９】

【実施形態】

ＴＣＰ／ＩＰ（Transfer Control Protocol / Internet Protocol）は、古典
的に定義されているか、あるいは、少なくともコンピュータネットワークのため
だけのコネクション及びコネクションレス・データ転送プロトコルと考えられて
いる。本発明の側面の１つは、アドレス（ＩＰアドレス）が割り当てられたアド
レス付け可能なインタフェース装置の定義を拡張して、ハードウェア、ソフトウ
ェア及びファームウェアのプラットホーム（これらは、コンピューティングに限
定されない他の用途のためのデータ転送を行う）を含めることである。コンピュ
ーティング以外の用途としては音声データやビデオデータの転送が挙げられるが
、ここでいう用途はこれらに限定されるものではない。音声データは、アナログ
／デジタル変換機（ＣＯＤＥＣやＶＯＣＯＤＥＲなど）を介してデジタル・スト
リームに変換されるアナログ信号である。

【００４０】 衛星を使用した通信システムにおいては、通信アーキテクチャとの関係で、特
有の問題が生じる。ユーザや呼び出し人をホストする“タワー”はもはや静的（
非移動的）なものではなく、時速１６，０００マイルで移動している。また、す
べての意図や目的のために、ユーザとそのネットワーク装置は非移動的なもので
ある（静止している）。この古典的な役割の逆転には（現在のワイヤレスネット
ワークとの関係で）、従来の考え方にはないネットワーク管理が要求される。

【００４１】 ネットワーク管理のための知識は、ユーザに分散させる必要がある。固有のア
ドレス付けのための機構が、役割の反転を支援するために必要である。ＧｅｏＩ
Ｐは、ＤＣＣＰ（Dynamic Client Configuration Protocol）と呼ばれるプロト
コル・スタックを介して機能するようになっており、このプロトコル・スタック
において、ＩＰアドレスが、固有のノード・アドレスとしてホストに渡されるよ
うになっている。コンフリクト（これは、近接した関係のために生じる）は、例
外的なものとして除外される。

【００４２】 上述したように、ＩＰｖ４は、４個の８ビットのメッセージを利用する。以下
において説明する図は、ＩＰｖ４への変換手順についてのソフトウェア・プラッ
トホームの実施例について説明するものである。図１には、データの入出力のた
めの複数の欄が示されている。この図における用語は、ＧｅｏＩＰを使ったＧｅ
ｏアドレス付けの説明をサポートする新しい用語を示している。図２には、未解
決のダイナミックＩＰ（ＵＤＩＰ／Unresolved Dynamic IP）、ダイナミック・
バーチャル・ゲートウェイ（ＤＶＧ／Dynamic Virtual Gateway）および次のゲ
ートウェイに加えて、ユーザの現在の緯度と経度が示されている。ＤＶＧは、バ
ーチャル・ユニキャス・トリンク（ＶＵＬ／Virtual Unicast Link）であり、固
有の名前と割り当てられたアドレスを有している。これは、バックボーンのサブ
ネット(subnet)またはサブマスク(submask)である。作動中において、ユーザと
その装置は、ＶＵＬとＤＶＧを介して、インターネットと対話する。ユーザに対
して表現するポイントは、ホストかＶＵＬである。受け渡し（handoff）の間、
図に示す次のゲートウェイは、ＶＵＬの役割を引き受ける。決定されたノードと
ユーザはＤＶＧが変更したことを知らず、ノードはまだＶＵＬを介してデータを
転送している。

【００４３】 ＵＤＩＰは、ＧＰＳの緯度と経度の役目を果たす。このＵＤＩＰは、ＶＵＬを
経て決定されるまで、絶えず変更するようになっている。図３には、ユーザのア
ドレスの動的な変更が示されている。この図に示されるように、ユーザの位置は
変わっており、そのＵＤＩＰも変わっており、さらに、ユーザは、自分のドメイ
ン及びドメイン・ネームとともにこの状態を、ネットワークに通知している。

【００４４】 従来のワイヤレス・システムでは、小型携帯移動電話機（cell phone）は、ネ
ットワークに、機器シリアルナンバー、モバイル識別番号、あるいは、固有の名
前を付けるためのその他の取り決めを、ネットワークに通知する。ＭＩＮをセル
の場所およびセクターと組み合わせることにより、ネットワークは、ユーザに到
達できる場所を認識する。本発明によれば、ダイナミックＭＩＮ又はＵＤＩＰは
、位置のデータ（これは、例えば、ＧＰＳなどによって提供される）から得られ
るようなユーザの位置である。

【００４５】 データの転送を行うために、ＶＵＬを介して要求してアドレスを解決する際に
、ＤＣＣＰは、ネットワークに固有のアドレスを返す（図４参照）。ＤＮＳネー
ム及びＤＮＳは前もって割り当てられており、ＤＣＣＰは、ＧＰＳの緯度と経度
を得て、それをＧｅｏＩＰに変換し、さらに、ユニキャストのノードとしてアド
レスを解決する。ここで、データ転送を開始することができる。ユーザの位置が
変わった場合には、ネットワーク又はＤＣＣＰが、ＧｅｏＩＰを再び解決する（
図５参照）。図５には、電話機（handset）により与えられた通りに、ＧｅｏＩ
Ｐが変更している様子が示されている。図６には、ＧｅｏＩＰの変更が、ネット
ワークに対して再び解決された様子が示されている。

【００４６】 ＧｅｏＩＰの変更を解決するための動的な能力（dynamic ability）は、多く
のネットワーク管理上の問題（例えば、米国における９１１コールのように、緊
急の呼び出しがあった場合に、その呼び出しがどの場所に出動することを必要と
しているか等の問題）を解決するものである。ただし、これには、位置ベースで
の呼び出しに応じることが可能なルーター、ずなわち、地理空間的（GeoSpatial
）なルーターの開発が必要とされる。

【００４７】 緊急事態用のアプリケーションに加えて、所定のエリア内、すなわち地理的フ
ェンス(GeoFence)内における解決されたＵＤＩＰは、ユーザにとって有意義なデ
ータ交換（広告メッセージなど）に対応できるように、プログラムすることも可
能である。ユーザが高速道路を移動していて、複数のネットワークによって設定
された地理的フェンスを横切った場合には、その地理フェンス内で新しいGeoIp
が解決され、当該位置におけるユーザにとっての有意義な情報を提示するネット
ワークからユーザにデータ・メッセージを送ることができる。商業的なアプリケ
ーションにおいては、低料金の製品やサービスの広告を行うメッセージをユーザ
に送ることができる。多くのユーザが同じポイントを通過する場合には、エニイ
キャストは、マルチキャスト・メッセージまたは地理空間的マルチキャスト（Ge
oSpatial Multicalst）を含むことができる。地理的フェンスによって規定され
るエリアが１平方マイルである場合には、当該エリア内の解決されたアドレスを
持つすべてのユーザに対して、メッセージが送られることとなる。

【００４８】 本発明の第２実施形態においては、データ・ストリームは、音声のみならず映
像も含むことが可能である。地理空間的（GeoSpatial）なエニイキャストの概念
を利用することにより、既知の位置に基づいて、所定の複数のルートを確立する
ことができる。固定されたネットワーク・ノードの場合においては、ＧＰＳ装置
により動的に割り当てられるというよりも、むしろ、静的（非動的）に割り当て
られた値が割り当てられる。エニイキャスト・モデルの場合においては、静的に
割り当てられたアドレスが、ネットワークンの中で最も近いノードまたはゲート
ウェイを決定することを手助けする。ルーティング・テーブルの更新は、規則的
なものというよりも、むしろ、交通に基づく例外的なものとなる。

【００４９】 図７は、本発明の通信方法を示すフローチャートである。初期化（ステップ７
０）は、所定の実働化(implementation)に応じたいくつかのステップを含むこと
が可能である。一般に、メモリ・レジスタ、バッファ、あるいは位置決定テクノ
ロジー装置（例えば、ＧＰＳ、ＳＰＳ）は、バッファをクリアしたり、レジスタ
を設定することなどにより、初期化される。このプロセスは、ネットワーク接続
がなされると開始し、折衝処理（negotiation process）が必要とされる。

【００５０】 次に、位置を取り込むステップ（ステップ７２）では、ＧＰＳレシーバなどの
位置決定ソース（または、位置決定装置）から、現在の緯度、経度、高度及び時
間を要求する。

【００５１】 ステップ７４は、図８との関係で後述するように、この位置データを、地理的
ＩＰアドレス（Geo-IPアドレス）へ変換するためのものである。（あらかじめ決
定されているかもしれないが）ＩＰのバージョンやプロトコルがステップ７６で
選択され、さらに、対応する変換アルゴリズム（ステップ７８又は８０）が、選
択されたプロトコルに応じて用いられる。そして、後述するように、ステップ８
２においてＩＰアドレスが組み立てられる。Geo-IPアドレスは、モバイル識別番
号（ＭＩＮ／Mobile Identification Number）及びステップ７２において得られ
た情報を利用して組み立てられ、４個の１６ビットの固有の暗号化されたフィー
ルドが生成されるようになっている。

【００５２】 ステップ７６におけるアドレス要求がＩＰｖ６である場合には、前記ＭＩＮを
含んだ８個の１６ビットのフィールド（２進）のＩＰｖ６アドレスを組み立てる
。第１フィールドの最初の３桁の２進文字は０００であり、残りの１３桁は、暗
号化された緯度、経度、時間、モバイルＩＤを含んだ７個の残りのフィールドが
従うことになる暗号鍵となる。一方、ＩＰｖ４について要求があった場合には、
ステップ８０において、４個の８ビットの２進フィールドで表されるＩＰｖ４ア
ドレスが検索される。ＩＰｖ４及びＩＰｖ６のいずれの場合においても、２進フ
ィールドの表示は、１６進数および１０進数で行われる。

【００５３】 ステップ８４においては、結果として得られたＵＤＩＰが、ＩＰアドレスの３
つの表示形式（１６進、１０進、２進）のうちのいずれかの形式で、ＲＡＭに格
納される。ステップ８６の判断はループ・タイマーを示しており、このステップ
では、５秒毎に、新しい位置が得られるとともに（ステップ７２）、新しい未解
決のダイナミック・インターネット・プロトコルが格納される（ステップ８４）
。符号８８は、タイマー・ループの経路を示している。

【００５４】 ステップ９０は、セッション・マネージャからのＵＤＩＰ（Unresolved Dynam
ic IP）に関する要求である。ステップ９２においては、ＲＡＭからの抽出が行
われる。ステップ９４においては、ＤＣＣＰ（Dynamic Client Configuration P
rocess）は、折衝（交渉）プロセス（negotiation process）の間に、バーチャ
ル・ユニキャスト・リンク（ワイヤレス装置）を介してダイナミック・バーチャ
ル・ゲートウェイ（DVG）に、ＵＤＩＰを転送する。このプロセス（すなわち、
クライアントが、自身の動的な“電話番号”（ここでいうＩＰアドレス）を通知
するプロセス）は、要求しているクライアントにサーバーがＩＰアドレスを割り
当てるという従来の手法とは全く正反対のものである。

【００５５】 折衝プロセス（ステップ９６）は、例外的なコンフリクトについての折衝を行
った上で、固有のアドレスの承認を行う。別言すれば、コンフリクトが生ずる場
合には、サーバーは新しいアドレスの交渉を行う。ステップ９６が完了すると、
セッションは確立され、さらに、ステップ９８においてデータが交換される。ス
テップ１００は、ダイナミック・バーチャル・ゲートウェイの割り当てを行う（
すなわち、プラグをソケットに接続するように、ユーザ（すなわち、ワイヤレス
装置）の通信への接続を行う）。ステップ１０２においては、サーバーは、未解
決のダイナミックＩＰが解決されたネットワーク接続（ＲＤＩＰ）であることを
宣言する。

【００５６】 ステップ１０４における判断は、未宣言値である変数Ｙを含むループ・タイマ
ーを示している（ここで、変数Ｙは、サーバが、どの程度の頻度で、対象物（ob
ject）の地理的な移動に基づいて新しいＩＰを構築し、再解決することを望んで
いるかに依存する）。変数Ｙ（すなわち、ループ・インターバル）は、移動速度
及び移動方向を示す役割を果たすものとして決定することができる。時間が、時
間と変数の合計と等しくない場合には、解決されたダイナミックＩＰはそのまま
である（“Ｃ”を参照）。一方、時間が、時間と変数の合計と等しい場合には、
ループは、経路１０６を介してステップ７２に戻り、新しいアドレスを再び構築
する。そして、ステップ１０２までのプロセスを経て、変更されたＩＰ及び位置
に基づいて新しいＩＰが再び解決される。

【００５７】 ステップ１０８は、ＤＶＧの受け渡し（handoff）である。本発明の他の重要
な側面は次の点にある。すなわち、クライアントが接続を再度折衝するのとは対
照的に、モバイル環境においては、ゲートウェイが、接続を再度折衝しなければ
ならない可能性がある。これはセッション中に絶え間なく起こる。必要でれば、
ダイナミック・バーチャル・ゲートウェイは他のサーバに渡される。ステップ１
１０は、ゲートウェイがバーチャル・ユニキャスト・リンク（virtual unicast
link）に関して新しいサーバーと交渉することを示している。

【００５８】 このようにして、ステップ１１２において、ネットワークは継ぎ目無く再確立
される。ステップ１１４は、セッションが終了するまで、ステップ９８（データ
交換のステップ）に戻ってセッションを続行し、そして、ステップ１１６でログ
オフ（logoff）し、ステップ１１８で終了する。

【００５９】 緯度と経度を変換してGeoIPアドレスを形成するための実例となるアルゴリズ
ムが、以下の仮想コードで示されている。

【００６０】 Option Explicit Dim a As Double 'lat degrees Dim b As Double 'lat min Dim c As Double 'lon degrees Dim d As Double 'lon min Dim e As Integer Dim f As Integer Dim g As Integer Dim h As Integer Dim I As Integer Dim j As Integer Dim k As Integer Dim i_1 As String Dim j_1 As String Dim k_1 As String Dim i_2 As String Dim j_2 As String Dim k_2 As String Dim l As String Dim m As String Dim n As String Dim p As String Dim q As String Dim r As String Dim s As String Dim u As String Dim v As String Dim w As String Dim x As String Private Sub Command1_Click() x ＝ Text6.Text w ＝ x Text7.Text ＝ w Text5.Text ＝ "503.819.7491@airtouch.net" End Sub Private Sub Command2_Click() a ＝ 45 b ＝ 30.345 C ＝ 122 d ＝ 30.678 I ＝ 9 j ＝ 268 k ＝ 77 e ＝(a + 45) * 1.417 f ＝(b * 4.25) g ＝(c * 1.417) h ＝(d * 4.25) l ＝ e m ＝ f n ＝ g p ＝ h Text6.Text ＝ l + "." + m + "." + n + "." + p Text9.Text ＝ k Text10.Text ＝ I Text11.Text ＝ j Text1.Text ＝ a Text2.Text ＝ b Text3.Text ＝ c Text4.Text ＝ d If I ＜＝ 255 Then i_1 ＝ I i_2 ＝ I Else: i_1 ＝ 255 i_2 ＝ I - 255 End If If j ＜＝ 255 Then j_1 ＝ j j_2 ＝ j Else: j_1 ＝ 255 j_2 ＝ j - 255 End If Text8.Text ＝ i_1 + "." + i_2 + "." + j_1 + "." + j_2 k ＝ 55 I ＝ 268 j ＝ 77 If I ＜＝ 255 Then i_1 ＝ I i_2 ＝ I Else: i_1 ＝ 255 i_2 ＝ I - 255 End If If j ＜＝ 255 Then j_1 ＝ j j_2 ＝ j Else: j_1 ＝ 255 j_2 ＝ j - 255 End If Text12.Text ＝ i_1 + "." + i_2 + "." + j_1 + "." + j_2 End Sub Private Sub Command 3_Click() a ＝ 35 b ＝ 32.345 C ＝ 111 d ＝ 50.678 e ＝(a + 45) * 1.417 f ＝(b * 4.25) g ＝(c * 1.417) h ＝(d * 4.25) I ＝ 268 I ＝ 77 k ＝ 55 l ＝ e m ＝ f n ＝ g p ＝ h Text6.Text ＝ l + "." + m + "." + n + "." + p Text9.Text ＝ k Text 10.Text ＝ I Text 11.Text ＝ j Text1.Text ＝ a Text2.Text ＝ b Text3.Text ＝ c Text4.Text ＝ d If I ＜＝ 255 Then i_1 ＝ I i_2 ＝ I Else: i_1 ＝ 255 i_2 ＝ I - 255 End If If j ＜＝ 255 Then j_1 ＝ j j_2 ＝ j Else: j_1 ＝ 255 j_2 ＝ j - 255 End If Text8.Text ＝ i_1 + "." + i_2 + "." + j_1 + "." + j_2 k ＝ 112 I ＝ 77 j ＝ 55 If I ＜＝ 255 Then i_1 ＝ I i_2 ＝ I Else: i_1 ＝ 255 i_2 ＝ I - 255 End If If j ＜＝ 255 Then j_1 ＝ j j_2 ＝ j Else: j_1 ＝ 255 j_2 ＝ j - 255 End If Text12.Text ＝ i_1 + "." + i_2 + "." + j_1 + "." + j_2 End Sub Private Sub Command4_Click() Text1.Text ＝ "" Text2.Text ＝ "" Text3.Text ＝ "" Text4.Text ＝ "" Text5.Text ＝ "" Text6.Text ＝ "" Text7.Text ＝ "" Text8.Text ＝ "" Text9.Text ＝ "" Text10.Text ＝ "" End Sub Private Sub Command5_Click() End End Sub End Sub

【００６１】 上述したプロセスは、図８のフローチャートとの関係で、より理解しやすく説
明することが可能である。図８は、未解決のダイナミック・インターネット・プ
ロトコル（ＵＤＩＰ／Unresolved Dynamic Internet Protocol）アドレスが形成
されるように位置データを変換するための方法を示すフローチャートである。こ
の図において、ＵＤＩＰアドレスは、ＩＰｖ４に準拠している。他のプロトコル
に従って形成することも可能である。このプロセスは、図７のステップ８０及び
８２における処理を詳細に示すものである。図８において、ステップ４２の「バ
ッファから文字列を取得」は、バッファ・メモリから位置データを読み出すため
に、呼び出し（コール）を行う処理である。ステップ４４においては、データの
文字列が解析されて、少なくとも４つのデータ要素が特定かつ復元される。ステ
ップ４６に示すように、このデータ要素とは、(1)緯度の度、(2)経度の分、(3)
経度の度、(4)経度の分である。これらの要素は、それぞれ、Ｘ₁、Ｘ₂、Ｙ₁、及
びＹ₂等の対応する変数名（変数値）で特定される。なお、これらの変数名は、
任意であって、しかも、単なる便宜上のものである。緯度の変数値は、新しい値
Ｆ₁とＦ₂を算出するために、ステップ４８で示される式において使用される。ま
た、経度の変数値は、ステップ５０で示される計算式に代入される。これにより
、Ｆ₁〜Ｆ₄までの４つの値が得られる。なお、このＦ₁〜Ｆ₄は、すべて、０〜２
５５の範囲内である。次に、ステップ５２において、すべての１０進の値の端数
を切り捨て最も近い整数にする。最後に、ステップ５４において、Ｆ₁からＦ₄を
結合することによって、ピリオドでフィールドを区切られたＩＰｖ４フォーマッ
トのアドレスが形成される。図８のフローチャートの下方には、変換の一例が、
符号５６によって示されている。

【００６２】 上述した変換方法は、簡単に計算を行う方法の一例であって、他の多くの変換
方法を、位置データに基づいて利用することも可能である。位置データに基づい
てＩＰプロトコルに準拠するアドレスを形成する他のすべての変換方法は、上述
した方法と等しいものであると考えるべきである。また、固有のアドレスを決定
するために用いる位置データの一部として高度を含めることは、本発明の範囲内
である。高度の値を用いることにより、例えば、同じ建物内であって異なるフロ
アーにある装置間でのコンフリクトを回避することが可能になる。

【００６３】 ＩＰｖ６への変換は、地理的なＩＰアドレス付けに関する方法の第２実施形態
と考えられる。ＩＰｖ６の場合においては、上述したように、１２８ビットのメ
ッセージが利用可能である。従来のフォーマットから緯度と経度をＧｅｏＩＰｖ
６へ変換することは、円の度数の定義を変えることにより達成することができる
。適当なアルゴリズムは、１６進の値の最小公倍数（すなわち、１６の倍数）、
および４５の倍数としての弧の長さを含んでいる。本実施形態に関しては、７２
０度が円の度数としてアルゴリズムにおいて用いられる。この概念は、ＧｅｏＩ
Ｐアドレス付け体系の１６進表現を最大化する。最大化が必要でない場合には、
大量の利用可能なアドレッシングが従来のアドレス付け体系と従来のものでない
アドレス付け体系の両方をサポートする。

【００６４】 地理的アドレス付けのために取り除かれた１００というアドレス付け体系の残
しておいたプレフィックスを利用することによって、ＧｅｏＩＰのためのFFF（
４０９５）個の固有のセクターを作り出す。４Ｆ５Ｂというアドレスは、（1001
11101011011:）という２進アドレスを生じさせる。これは、１６進表記において
、4F5B-4000 = 5B5で表され、また、１０進表記において、3931で表される。こ
れは、ＩＰ globe（地球を利用したインタネットプロトコル）の第３９３１セク
ターを表す。次の２〜１６ビットの要素は、セクター内の度や分を直接表示した
り、あるいは、ＧＰＳ装置から得られた変数で暗号化することが可能である。

【００６５】 最後に、本発明の基本原理から逸脱することなく、上述した本発明の実施形態
に多くの改変を加えることは、当業者であれば自明である。従って、本発明の範
囲は、明細書に記載された特許請求の範囲によってのみ定められるべきである。

【図面の簡単な説明】

【図１】 図１は、本発明による位置データに基づく動的ＩＰアドレスを用いた地理空間
的ルーティング方法の使用状態を示す画面の描写である。

【図２】 図２は、第1の位置データ、ＩＰｖ４に準拠したフォーマットの前記位置デー
タから生じた未解決の動的IP（UDIP）アドレスと、物理的ゲートウェイ及び動的
仮想ゲートウェイ(DVG)アドレスを示す図１と同様の画面の描写である。

【図３】 図３は、図１のような画面の描写であり、モバイル装置の新たな位置（緯度及
び経度）を示している。

【図４】 図４は、データ送信を成立させるためにアドレスを解析するためのVULを介し
たリクエストを示しており、DCCPはネットワークに固有な（ユニークな）アドレ
スを戻す(hand back)するようになっている。

【図５】 図５は、モバイル装置(handset)によって供給されたGeoIPの変化を表している
。

【図６】 図６は、ネットワークに再解決されて戻されたGeoIPの変化を表している。

【図７】 図７は、本発明による地理空間的アドレス及びデータ通信の方法を示すフロー
チャートである。

【図８】 図８は、未解決の動的インターネットプロトコル(UDIP)アドレスを生成するよ
うに位置データを変換するための方法を示すフローチャートである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ， ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，Ｋ Ｚ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ， ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，Ｓ Ｌ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 プレストン，ダン エー． アメリカ合衆国 98110 ワシントン州、 ベインブリッジ アイランド、メドウミー ア サークル 11621 (72)発明者 プレストン，ジョセフ アメリカ合衆国 98110 ワシントン州、 ベインブリッジ アイランド、サンライズ ドライブ ノースイースト 12661 Ｆターム(参考） 5K030 HB01 HB02 HC09 LB05

Claims (20)

【特許請求の範囲】
1. 【請求項１】 グローバルな位置情報を受信するステップと； 前記受信したグローバルな位置情報を処理して、現在の経度、現在の緯度及び
   現在の高度を含む現在の位置情報を求めるステップと； 前記現在の位置情報を、現在位置に位置するモバイル装置とサーバーとの間の
   送信制御及びデータのルーティングに用いられる未解決の動的インターネットプ
   ロトコル（UDIP）アドレスを形成するように変換するステップと、 を含むことを特徴とするモバイルコンピュータアプリケーション用のグローバ
   ルなユニークなアドレスを生成する方法。
2. 【請求項２】 前記UDIPアドレスは、ＩＰｖ４インターネットプロトコルに
   準拠していることを特徴とする請求項１に記載の方法
3. 【請求項３】 前記UDIPアドレスは、ＩＰｖ６インターネットプロトコルに
   準拠していることを特徴とする請求項１に記載の方法。
4. 【請求項４】 前記グローバルな位置情報は、前記モバイル装置に接続され
   たＧＰＳ受信器によって提供されることを特徴とする請求項１に記載の方法。
5. 【請求項５】 前記データは、音声又はビデオデータであることを特徴とす
   る請求項４に記載の方法。
6. 【請求項６】 前記データは、電子メールを含むことを特徴とする請求項４
   に記載の方法。
7. 【請求項７】 前記データは、テレマティクスデータを含むことを特徴とす
   る請求項４に記載の方法。
8. 【請求項８】 ホストとモバイル装置との間でデータを送信する方法であっ
   て、 前記モバイル装置の現在の物理的な位置に基づく該モバイル装置におけるUDIP
   アドレスを生成するステップと； 前記モバイル装置から前記ホスト装置に前記UDIPアドレスを送るステップと； 前記ホストと前記モバイル装置との間における次のデータ送信用に前記モバイ
   ル装置の割り当てられたアドレスとして前記ホストにおけるUDIPアドレスを登録
   かつ分析するステップと、を含むことを特徴とする前記方法。
9. 【請求項９】 さらに、前記モバイル装置の新たな現在位置に応じて、該モ
   バイル装置におけるUDIPアドレスを周期的に更新するステップと； 前記更新されたUDIPアドレスをモバイル装置からホストに送信するステップと
   ； 前記ホストにおける更新されたUDIPアドレスを前記モバイル装置の割り当てら
   れたIPアドレスとして登録かつ分析するステップと、を含むことを特徴とする請
   求項８に記載の方法。
10. 【請求項１０】 前記モバイル装置の現在の物理的位置に基づいてUDIPアド
    レスを生成するステップは、該モバイル装置の緯度及び経度に基づいて前記UDIP
    アドレスを生成することを特徴とする請求項８に記載の方法。
11. 【請求項１１】 前記モバイル装置の現在の物理的位置に基づいてUDIPアド
    レスを生成するステップは、該モバイル装置の緯度、経度及び高度に基づいて前
    記UDIPアドレスを生成することを特徴とする請求項８に記載の方法。
12. 【請求項１２】 前記モバイル装置の現在の物理的位置は、該モバイル装置
    に一体に組み込まれたGPS受信器によって求められることを特徴とする請求項８
    に記載の方法。
13. 【請求項１３】 前記モバイル装置の現在の物理的位置は、該モバイル装置
    に物理的に接続されたGPS受信器によって求められることを特徴とする請求項８
    に記載の方法。
14. 【請求項１４】 無線通信装置によるデータ通信用の動的地理空間ルーティ
    ング方法であって、 前記無線通信装置でGPS衛星送信を受信するステップと； 前記GPS衛星送信に応じて、前記無線通信装置の少なくとも緯度及び経度を含
    む現在の位置データを取得するステップと； 前記現在の位置データの関数として、未解決の動的ＩＰ（UDIP）アドレスを生
    成するステップと； 前記UDIPアドレスを前記無線通信装置を備えたルーティングデータ通信に用い
    られる遠隔サーバーに送信し、前記装置の現在位置が動的な固有な識別子を決め
    るステップと、を含むことを特徴とする前記方法論。
15. 【請求項１５】 前記UDIPアドレスは、ＩＰｖ４プロトコル規格に準拠して
    いることを特徴とする請求項１４に記載の方法。
16. 【請求項１６】 前記UDIPアドレスは、ＩＰｖ６インターネットプロトコル
    に準拠していることを特徴とする請求項１５に記載の方法。
17. 【請求項１７】 さらに、固有な名称と所定の割り当てられたＩＰアドレス
    とを有するインターネット上の第１のゲートウェイを特定するステップと； 前記特定されたゲートウェイを一時的な使用のために動的仮想ゲートウェイDV
    Gとして割り当てるステップと； ユニークな名称と所定の割り当てられたＩＰアドレスとを有するインターネッ
    ト上の第２のゲートウェイを特定するステップと； 前記第2のゲートウェイを次のゲートウェイとして割り当てるステップと； 前記UDIPを分析して、前記無線装置と前記第１及び第２のゲートウェイの選択
    された一方との間でのデータ通信用の分析された動的ＩＰアドレスを形成するス
    テップと、を含むことを特徴とするクレーム１４に記載の方法。
18. 【請求項１８】 モバイル装置によるデータ通信方法であって、 前記モバイル装置において位置データを取得するステップと、 前記モバイル装置において取得した位置データを変換して地理的ＩＰアドレス
    を生成するステップと； 前記地理的IPアドレスを所定の標準のＩＰプロトコルに従ってフォーマットし
    、それによって未解決な動的IP（UDIP）アドレス作るとともに、前記UDIPを前記
    モバイル装置内のメモリに格納するステップと； 前記ステップを周期的に繰り返し、それによって新たに取得した位置データに
    応じて前記UDIPを更新するステップと； 前記格納されたUDIPをホストへ送信するステップを含むアドレスリソリューシ
    ョンを要求するステップと； 前記UDOPに動的な仮想ゲートウェイDVGを割り当てるステップと； 前記割り当てられたDVGアドレスをUDIPに結合させ、未解決な動的IPアドレス
    （RDIP）を生成するステップと； 前記RDIPをデータ転送用の前記モバイル装置の割り当てられたＩＰアドレスと
    して使用するステップと、を含むことを特徴とする前記方法。
19. 【請求項１９】 さらに、前記位置データ最後に更新された以降の経過時間
    をモニターするステップと、前記経過時間が所定のタイムリミットを越えた場合
    に、位置データを取得するステップとを含み、前記新たに取得された位置データ
    に基づいて前記ステップを繰り返すことを特徴とする請求項１８に記載の方法。
20. 【請求項２０】 前記新たに取得された位置情報に応じて新たなDVGを割り
    当てるステップを含むことを特徴とする請求項１８に記載の方法。 技術分野 本発明は、概してデータ通信の分野に関し、具体的には、モバイル装置を用い
    る改善されたデータ通信方法に関する。特に、本発明は、動的な位置ベースでの
    （地理空間的な）インターネットのアドレス付け機構（このアドレス付け機構は
    、既存のインターネットのプロトコルやアーキテクチャと後方互換性（backward
    compatible）を持っている）を含んでいて、しかも、多数のモバイル装置との
    改善されたデータ通信を提供するようになっている。