(57)【要約】ノマディックなシステムの特性を透過的にする、シームレスなソリューションであって、既存のネットワーク・アプリケーションが、モバイル環境でも確実に動作するようにする。モバイルネットワークと組み合わされたモビリティ管理サーバ（１０２）は、数量を限定されないモバイル端末システム（１０４）それぞれの状態を維持し、ネットワークへ、及び他のピアでの処理への持続的な接続の維持に必要な、複雑なセッション管理を実行する。モバイル端末システムが圏外に出たり、サスペンドしたり、（例えば、あるネットワーク相互接続から別のものへとローミングして）ネットワークアドレスを変更したりした場合、モビリティ管理サーバは、結合しているピアのタスクとの接続を維持し、モバイル端末システムとネットワーク媒体とのコンタクトが一時的に失われても、モバイル端末システムが持続的な接続を維持できるようにする。インターフェイスベースのリスナは、ネットワーク・インターフェイスからのネットワーク接続ポイント情報を利用して、ローミング状態を判定し、ローミングに際した接続を効率的に確立する。モビリティ管理サーバは、非接続のネットワーク上で該サーバとコンタクトをとるためのリストを、モバイル端末システムに配布する。【特許請求の範囲】
【請求項１】
ＩＰベースの、接続拠点を有する複数の各ネットワーク間で実質的にシームレスにロームする少なくとも一つのモバイル装置を含むモビリティ通信システムであって、
上記モバイル装置は、少なくとも一つの別のノードを備えたローカルモバイルネットワークを介して通信し、
上記ローカルモバイルネットワークに接続される、あるいは接続されない最終的なピアと通信するために上記少なくとも一つの別ノードへ／から通信されるアプリケーションデータの機能を有効とするものであることを特徴とするモビリティ通信システム。
【請求項２】
上記モバイル装置は、モバイルプロキシ通信サービスを有することを特徴とする請求項１に記載のモビリティ通信システム。
【請求項３】
さらに、上記モバイル装置及び少なくとも一つのサーバは、上記ＩＰベースの接続拠点を有する複数の各ネットワークと通信し、
上記各ネットワークは、上記各ネットワークの間に割り当てられたモビリティ機能を備え、協動してモビリティを付与することを特徴とする請求項１に記載のモビリティ通信システム。
【請求項４】
上記ノードは、モビリティを意識しない装置を有することを特徴とする請求項１に記載のモビリティ通信システム。
【請求項５】
上記ノードは、無線通信装置を含み、
上記ローカルモバイルネットワークは、無線でモバイルな専用ネットワークを含むことを特徴とする請求項１に記載のモビリティ通信システム。
【請求項６】
上記ノードは、上記モバイル装置が通信し合う特定の接続拠点を有する各ネットワークに関係なく、上記ローカルモバイルネットワークを介して通信できる、ＩＰベースの種々な各無線通信装置の何れかを含むことを特徴とする請求項１に記載のモビリティ通信システム。
【請求項７】
上記モバイル装置は、ゲートウェイ結合エージェントを提供することを特徴とする請求項１に記載のモビリティ通信システム。
【請求項８】
上記モバイル装置は、ファイアウォールに割り当てられるＩＳＯのレイヤ３、レイヤ４及び／又はレイヤ７を提供することを特徴とする請求項１に記載のモビリティ通信システム。
【請求項９】
上記モバイル装置は、ネットワークのアドレス／ポートトランスレータを提供することを特徴とする請求項１に記載のモビリティ通信システム。
【請求項１０】
上記モバイル装置は、ＩＰのモバイルなフォーリン／ホームエージェントを提供することを特徴とする請求項１に記載のモビリティ通信システム。
【請求項１１】
上記モバイル装置は、インターフェースシグナリングエージェントを提供することを特徴とする請求項１に記載のモビリティ通信システム。
【請求項１２】
上記モバイル装置は、ＤＨＣＰサーバを提供することを特徴とする請求項１に記載のモビリティ通信システム。
【請求項１３】
上記モバイル装置は、アプリケーションレイヤプロキシを提供することを特徴とする請求項１に記載のモビリティ通信システム。
【請求項１４】
ＩＰベースの、接続拠点を有する複数の各ネットワーク間で実質的にシームレスにロームする少なくとも一つのモバイル装置によって使用されるモビリティ通信方法であって、
上記モバイル装置により、少なくとも一つの別のノードを備えたローカルモバイルネットワークを介して通信し、
ローカルモバイルネットワークに接続される、あるいは接続されない最終的なピアと通信するために、上記少なくとも一つの別のノードへ／から通信されるアプリケーションデータの機能を、上記モバイル装置によって有効とすることを特徴とするモビリティ通信方法。
【請求項１５】
上記モバイル装置は、モバイルプロキシ通信サービスを有することを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項１６】
さらに、上記モバイル装置及び少なくとも一つのサーバは、上記ＩＰベースの接続拠点を有する複数の各ネットワークと通信し、
上記各ネットワークは、上記各ネットワークの間に割り当てられたモビリティ機能を備え、協動してモビリティを付与することを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項１７】
上記ノードは、モビリティを意識していない装置を含むことを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項１８】
上記ノードは、無線通信装置を含み、
上記ローカルモバイルネットワークは、無線でモバイルな専用ネットワークを含むことを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項１９】
上記ノードは、上記モバイル装置が通信する、特定の上記接続拠点を有する各ネットワークに関係なく、上記ローカルモバイルネットワークを介して通信できる、ＩＰベースの種々な各無線通信装置の何れかを含むことを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項２０】
上記モバイル装置は、ゲートウェイ結合エージェントを提供することを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項２１】
上記モバイル装置は、ファイアウォールに割り当てられる、ＩＳＯのレイヤ３、レイヤ４及び／又はレイヤ７を提供することを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項２２】
上記モバイル装置は、ネットワークのアドレス／ポートトランスレータを提供することを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項２３】
上記モバイル装置は、モバイルなＩＰのフォーリン／ホームエージェントを提供することを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項２４】
上記モバイル装置は、インターフェースシグナリングエージェントを提供することを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項２５】
上記モバイル装置は、ＤＨＣＰサーバを提供することを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項２６】
上記モバイル装置は、アプリケーションレイヤプロキシを提供することを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項２７】
上記モバイル装置は、それらの間で負荷の均衡を保つことを行う複数のモバイル装置を含むことを特徴とする請求項１４に記載のモビリティ通信方法。
【請求項２８】
自動的な負荷の均衡方法と、接続されたシステム及び／又はユーザの接続中断無しにてオンザフライ能力を付加するために各サーバプール内に形成された、ヒエラルキー的にクラスタリングされた各モビリティ管理システムを含む共有方法とにより特徴付けられるモビリティ管理システムであって、
上記各サーバプールは、各ゾーンに分割されていることを特徴とするモビリティ管理システム。
【請求項２９】
上記各サーバプールは、集中制御及び集中管理を維持している間に、動的な選択あるいは優先権の設定を請求するために、各ゾーン内に集められていることを特徴とする請求項２８に記載のモビリティ管理システム。
【請求項３０】
上記各ゾーンは、地理的な条件に基づいて設定されていることを特徴とする請求項２９に記載のモビリティ管理システム。
【請求項３１】
上記自動的な負荷の均衡は、上記システムの全体にわたって多数の各ユーザあるいは各システムの適切な割り当てを保証するためのフェイルオーバと統合されていることを特徴とする請求項２９に記載のモビリティ管理システム。
【請求項３２】
モビリティシステムが故障したとき、サーバであるセッションを含むモバイル端末システムが、少なくとも一つのモバイルプロキシ通信サービスによって上記サーバプール内の残りの各サーバ全体にわたって自動的にフェイルオーバされて均衡化されることを特徴とする請求項２９に記載のモビリティ管理システム。
【請求項３３】
モバイルを意識しない少なくとも一つのノードと、ローカル結合されたモバイルネットワークを介して通信し、ＩＰベースの、接続拠点を有する少なくとも一つのネットワークを介してモバイル端末システムと通信する通信部、及び、
モバイルな専用ネットワークに対し、接続される、あるいは接続されない最終的なピアと通信するために、上記少なくとも一つのノードへ／から通信されるアプリケーションデータを使用可能にする処理部を含むモバイルプロキシ通信サービス。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
〔本願の関連出願の参照〕
本願は、発明の名称が、「モバイルネットワーキングのシステム及び方法」である、２００４年６月１０日に出願した米国仮出願一連番号６０／５７８，３１８の権利範囲を含むことを請求する。上記仮出願は、ここに参照として含まれる。
【０００２】
本願はさらに、以下の出願の権利範囲を含むことを請求する。即ち、発明の名称が、「コンピュータ環境における無線での接続性を提供する方法及び装置」である、１９９８年１０月９日に出願した米国仮出願一連番号６０／１０３，５９８と、発明の名称が、「コンピュータ環境におけるモバイル及び他の断続的接続性を提供する方法及び装置」である、２０００年１月１８日に出願した米国仮出願一連番号６０／１７６，３０５と、発明の名称が、「コンピュータ環境におけるモバイル及び他の断続的接続性を提供する方法及び装置」である、２００１年３月１２日に出願した米国仮出願一連番号６０／２７４，６１５と、発明の名称が、「コンピュータ環境におけるモバイル及び他の断続的接続性を提供する方法及び装置」である、１９９９年６月１１日に出願した米国仮出願一連番号０９／３３０，３１０と、発明の名称が、「コンピュータ環境におけるモバイル及び他の断続的接続性を提供する方法及び装置」である、２０００年９月１２日に出願した米国仮出願一連番号０９／６６０，５００と、発明の名称が、「コンピュータ環境におけるモバイル及び他の断続的接続性を提供する方法及び装置」である、２００１年９月１２日に出願したＰＣＴ国際出願番号ＰＣＴ／ＵＳ０１／２８３９１との権利範囲を含むことを請求する。上記出願の全ては、ここに示す参照に含まれる。
【０００３】
［発明の背景］
本発明は、ネットワークによって接続されたコンピュータ装置間の接続性に関する。より詳細には、ノマディック（移動自在な）システムの特性を透過性（トランスペアレント）を有する状態で扱うとともに、既存のネットワーク・アプリケーションを、対応するモバイル環境で確実に動作させる方法とシステムに関する。さらに詳細には、断続的に接続される、携帯型データ端末やパソコン装置などの装置間における、連続的なデータストリームのやり取りを可能にする技術及びシステムに関する。
【０００４】
［発明の背景及び要約］
近年、各企業は、重要な情報への迅速なアクセスこそが競争優位を保つための方策であると認識するようになってきた。このことから、特に安価なラップトップやハンドヘルドのコンピュータ装置の普及とも相まって、モバイルなどの断続的な接続が行われるコンピュータ装置が急速に企業ネットワークの重要な一要素となりつつある。しかしながら、こうしたノマディックな装置を既存のネットワーク・インフラへと統合することは、各企業の情報管理担当者にとって頭の痛い問題ともなっている。
【０００５】
モバイルネットワーキングに関する問題の多くは、イーサネット（登録商標）登場以前にローカルエリア・ネットワーク（ＬＡＮ）構築に伴っていた問題に近い。即ち、モバイル・プロトコルやインターフェイスには多くの種類があり、また、まだ規格が制定段階にあることから、異なるシステム間の相互運用性は無いも同然である。さらに、上記のようなネットワーク技術による通信はたいてい低速で帯域幅も限られており、各システムの特殊性から、アップデートに伴う費用も高額になっている。
【０００６】
こうした問題に加えて、モバイル技術は、以下のような固有の問題も有している。即ち、メインのネットワークと相互接続するの際には公共のネットワーク・インフラを経由する場合があるが、この際に機密情報が傍受されてしまう危険性がある。さらに、無線のインターフェースを経由して相互接続する場合であれば、機密情報がいわば「放送」されてしまうことになり、類似のインターフェイスを所有する誰もが該情報をたいした障害もなく傍受することができてしまう。
【０００７】
しかし、おそらく上記のような問題よりもさらに重要な問題としては、従来、モバイルネットワーキングが使われるのは基本的にメッセージ指向あるいはステートレスなアプリケーションに限られていて、クライアント／サーバ、ホスト／ターミナル方式をとるウェブベースあるいはファイル共有型のシステムモデルを利用した、既存あるいは新規の業務用アプリケーションには適さなかったことである。これは、一般的な業務用アプリケーションが効果的かつ確実に動作するためには、ステートレスなパケット交換だけでなく、連続的なデータストリームを用いたステートフルなセッションが必要であるという理由からであった。
【０００８】
このため、主要な市販のネットワーク・アプリケーションのほとんどは、ＴＣＰ／ＩＰセッションか、専用の仮想回路を必要としている。このようなセッションは、ネットワークが中断された場合はそれ以上機能できず、また接続時には、ネットワーク間のローミング（ネットワークアドレスの変更）が不可能である。さらに、モバイルネットワーキングは本質的に動的であり信頼性が低い。これらの問題について、以下では、モバイルネットワークにおいてよく見られる状況をいくつか考察することにする。
【０００９】
（非接続あるいは圏外のユーザ）
モバイル装置が所与のネットワークから切断されるかあるいはネットワークとのコンタクトを失う（つまり、無線相互接続の圏外に出たりネットワークがカバーしていない「穴」に入ったりする）と、モバイル装置上で動作しているセッション指向のアプリケーションはピアとのステートフルな接続を失い、動作を停止する。装置が再び取り付けられるかあるいは装置とネットワークとのコンタクトが回復すると、ユーザはネットワークとの再接続を行い、セキュリティ確保のために再ログインを実行して、アプリケーションにおいてどこで作業が中断されたかを同定し、必要ならば失われたデータの再入力を行わなければならない。このような再接続処理は時間を要し、費用もかかり、またユーザを非常に苛立たせることにもなる。
【００１０】
（他のネットワークへの、あるいはルータ境界を越える移動（ネットワークアドレス変更））
モバイルネットワークは通常、管理容易性の見地からセグメント化されているが、一方でモバイル装置はその用途上、ローミングが可能になっている。相互接続されたネットワーク間のローミングとは、ネットワークアドレスが変更されるということを意味する。ネットワークアドレスがシステムの動作中に変更される場合、対応しているピア同士の接続を保つためにルーティング情報を変更することが必要になる。さらに、新しいネットワークアドレスを取得するために、それまでに確立されたステートフルなアプリケーションのセッション全てを終了させなければならない場合もあり、上記の再接続処理に関わる問題がここでも浮上する。
【００１１】
（セキュリティ）
既に述べたように、各企業は機密情報を守る必要がある。市販のアプリケーションの多くは、物理的ネットワークへのアクセスがコントロールされ（つまり、安全な施設の内部に構築されたケーブルを使って実行され）、セキュリティは、認証や場合によっては暗号化に関する付加的な層を通じて保持されることを前提として作成されている。しかしながら、ノマディック・コンピューティングではこうした前提は自明のものではない。というのも、公共の電波や有線インフラを通過する際にデータが傍受されてしまう危険性があるからである。
【００１２】
このため、ノマディックなシステムの特性を透過性を有するものとすることによって、既存のネットワーク・アプリケーションが種々のモバイル環境で確実に動作することを可能にした、統合的なソリューションの登場が大いに望まれる。
【００１３】
本発明は、上記の問題を解決するために、企業内ネットワークを延長して、ネットワーク管理者がモバイル装置のユーザも固定装置のユーザと同じアプリケーションに容易にアクセスできるようにすることを可能にすると同時に、信頼性やネットワーク管理の一元性も失わない、一貫したソリューションを提示する。該ソリューションは、これまでの有線ネットワーク規格の長所を、発展しつつあるモバイルネットワーキングに関する規格にも組み合わせることで、既存のネットワーク・アプリケーションにも対応したものとなっている。
【００１４】
本発明の非限定的で例示的具体的な実施の形態の一側面においては、モバイル相互接続に接続されたモビリティ管理サーバ（Mobility Management Server；ＭＭＳ）は、数量を限定されないモバイル端末システム（Mobile End Systems；ＭＥＳ）それぞれの状態の維持や、ネットワークへ及びピアにおけるアプリケーション処理への持続的な接続の維持に必要な、複雑なセッションの管理を行う。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは（あるモバイル相互接続から別の相互接続へとローミングすることなどで）ネットワークアドレスを変更したりした場合でも、モビリティ管理サーバは該システムと、該システムと対応しているピアとの接続を維持する。言い換えれば、該モバイル端末システムは、実際には物理的な接続が一時中断されてしまうにも関わらず、ピアとの仮想的な接続を維持し続けることになる。
【００１５】
また、本発明の非限定的で具体的な実施の形態は、以下の（これらに限定されないが）新規かつ有用な技術、構成を提示する。
・ユーザによって設定可能なセッション優先権をモバイル・クライアントに付与するモビリティ管理サーバ。
・ネットワーク・リソースの消費を管理するための、ユーザごとのモバイル装置のポリシー管理。
・工業規格である動的ホスト構成プロトコル（Dynamic Host Configuration Protocol；ＤＨＣＰ）をモビリティ管理サーバと連携させて用いるローミング方法。
・ユーザによって設定可能なタイムアウト条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
・ユーザによって設定可能な再試行条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
【００１６】
より詳細には、本発明の好ましい具体的な実施形態の一例において、モバイル相互接続ネットワークに接続されたモビリティ管理サーバが備えられている。該モビリティ管理サーバは、数量を限定されないモバイル端末システムのそれぞれの状態を維持し、ネットワークへ及び他の処理（例えば他のネットワークベースのピア・システムにて実行される処理）への持続的な接続の維持に必要な、複合的なセッションを管理する。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは（あるモバイル相互接続から別の相互接続へとローミングすることなどで）ネットワークアドレスを変更したりした場合、モビリティ管理サーバはデータの受信と待機要求を認識して、該システムと、該システムと対応しているピアとの接続を維持する。このようにモビリティ管理サーバがプロキシとして働くことにより、モバイル端末システム上で動作するアプリケーションは、あるネットワーク媒体との物理的な接続が一時的に中断された場合でも、持続的な接続を維持することができる。
【００１７】
また、本発明の好ましい実施の形態の他の一例において、モビリティ管理サーバはモバイル端末システム用のアドレスを管理する。モバイル端末システムには、それぞれにプライマリネットワーク上のプロキシ・アドレスが割り当てられている。この非常に汎用性の高いアドレスはモバイル端末システムの「仮想アドレス」と呼ばれる。モビリティ管理サーバはこの仮想アドレスを、ノマディック・システムにおける現在の「位置」アドレスと対応付ける。モバイル端末システムの位置アドレスは、該システムがネットワーク間を移動する際に変更されるが、仮想アドレスの方は、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【００１８】
本発明の好ましい実施形態のさらに他の一例において、モビリティ管理サーバは、コンソール（制御）アプリケーションと包括的なメトリクスとによってモバイル端末システムの集中的な管理を実現する。さらに、好ましい実施形態では、ユーザによって設定可能なセッション優先権を、プロキシ・サーバ上で実行されるモバイル・クライアントに対して提供し、ネットワーク・リソースの消費を管理するための、ユーザごとのモバイル装置のポリシー管理を提供する。
【００１９】
さらに、上記一側面においては、遠隔プロシージャ・コール（ＲＰＣ）・プロトコル（Remote Procedure Call protocol）及びインターネット・モビリティ・プロトコル（Internet Mobility Protocol）が、プロキシ・サーバと各モバイル端末システムとの間の通信の確立に使用されている。
【００２０】
遠隔プロシージャ・コールによって、ローカルなシステムから、遠隔のシステムにおけるプロシージャを呼び出す処理が可能になり、ＲＰＣプロトコルを使用することで、モバイル端末システムが接続を切ったり、圏外に行ったり、動作をサスペンドしたりということを、アクティブなネットワークセッションを中断することなくできるようになる。このように、セッションの維持は専用のアプリケーションによってなされるわけではないので、市販のアプリケーションを、何ら変更することなくノマディックな環境下で使用することができるようになる。
【００２１】
ＲＰＣプロトコルは、トランザクションを、標準的なネットワークトランスポート・プロトコル及びインフラを経由して送られるメッセージ内に生成する。このＲＰＣメッセージは、モバイル端末システムにおいて実行されているアプリケーションによって開始されたネットワーク・トランザクション全体を含んでおり、これにより、モビリティ管理サーバとモバイル端末システムとの間の接続状態情報を、両者の間の物理的な接続が途切れているときをも含め、常にシンクロさせておくことが可能になる。ＲＰＣを備える本発明の実施の形態において、プロキシ・サーバとモバイル端末システムとは、全ての時間における全ての共有接続に関する統一された論理データベースを管理すべく、各トランザクションの状態について十分な情報を共有している。
【００２２】
本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルは、有線のローカルエリア・ネットワークと、それよりも信頼性の低い、無線ＬＡＮ及びＷＡＮといったネットワークとの間の相違を補償する。フレームサイズとプロトコルタイミングとが調整されることで、モバイル環境を考慮していない通信に比べるとパフォーマンスが大幅に改善され、ネットワークのトラフィックは大きく減少する。これは、帯域幅が限られているときやバッテリーの寿命を考慮に入れなければならないときに、特に重要になる。さらに、本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルによって、公共のネットワークもしくは無線を通じて、モバイル端末システム―モビリティ管理サーバ間で伝送が行われる際の、機密データの安全性が確保される。インターネット・モビリティ・プロトコルは、認証された装置からのみプライベートなネットワークにアクセスできるようにすることで、基本的なファイアウォールとしての機能も果たす。また、インターネット・モビリティ・プロトコルにより、モバイル端末システム―モビリティ管理サーバ間の全ての通信を認証、暗号化することも可能である。
【００２３】
本発明の好ましい実施形態のさらに他の一例において、モバイル相互接続は、標準的なネットワーク・アプリケーションのインターフェイスが適用できる範囲を広げるべく、標準的なトランスポート・プロトコル（例としてＴＣＰ／ＩＰ、ＵＤＰ／ＩＰ、ＤＨＣＰなど）を使用して構築される。本発明の好ましい実施形態によって、データ転送、セキュリティ、アドレス管理、装置管理、ユーザ管理が効果的に統合され、ノマディック環境を効果的に透過性を有する状態とすることができる。インターネット・モビリティ・プロトコルは、複数のデータストリーム（信頼度の高いものも低いものも）を、標準的なネットワーク・インフラ上で標準的なトランスポート・プロトコルによって与えられた、単一の仮想チャネルを通じて多重化するための効果的な方法を提供する。
【００２４】
ＲＰＣ層を用いて、インターネット・モビリティ・プロトコルは、違うソースから供給され、違う又は同じ目的地へと向かうデータを融合させて単一のデータストリームとし、これをモバイルリンクを介して送る。該モバイルリンクの反対側の端において、該データストリームは逆多重化されて複数の異なったデータストリームとなり、それぞれの最終的な目的地に伝送される。この多重化／逆多重化により、利用可能な帯域幅を（最大限のサイズのネットワークフレームを生成することで）最大限に使うことができ、複数のチャネルを確立することができる（よって、優先順位付けが可能になり、基礎をなしているネットワークがデータ通信サービスを供給している場合であれば、その品質を保証することができる可能性もある）。
【００２５】
本発明の実施の形態に関するインターネット・モビリティ・プロトコルは、さらに以下のような各特徴や各利点を提供する。なお、本発明は、以下の各特徴や各利点に限定されるものではない。
・トランスポート・プロトコルの独立性
・ネットワーク上における位置（point of presence；ＰＯＰ）あるいはネットワーク・インフラを、データの流れに影響を与えることなく変更可能（物理的境界、ポリシー、あるいは帯域幅による制約が無い場合のみ）
・付加的な経費が最小限
・伝送媒体に適した自動的なフラグメントのサイズ変更（あるフレームのプロトコル・データ・ユニットがネットワーク媒体の利用可能な上限の伝送ユニットよりも多いとき、インターネット・モビリティ・プロトコルは該フレームをフラグメント化し、再構築する。このことにより、該フレームのネットワーク伝送を保障することが可能となる。再伝送の際、該フレームは再度検査される。ネットワーク・インフラもしくは環境が変化していた場合、該フレームは再度フラグメント化されるか、あるいは伝送ユニットの上限が実際に上昇しているときには単一のフレームとして伝送される。）
・再伝送の際に、フレームに信頼性の低いデータを破棄させることで、信頼性の低いデータのセマンティクスを保持
・信頼性の高いデータグラムサービスにおける新しいセマンティクスを提供（これにより、インターネット・モビリティ・プロトコルによるピアの端末へのデータグラムの伝達が保証され、要求しているエンティティに伝達の通知がなされる）
・上りと下りの伝送パスをそれぞれ別に扱って、自動的に操作パラメータを調整し最適なスループットを実現（ヒステリシスに基づいて、フレームサイズ／フラグメント化の閾値、待機中のフレーム数（ウィンドウ）、再伝送時間、及びネットワークを通じて送られる複製データの量を減少させるための遅延承認時間などのパラメータを調整）。
・ネットワーク障害に対する耐性（モバイル環境での使用が想定されているため、一時的にネットワーク媒体間の接続が切断されても、仮想チャネルが切断されたりアプリケーションベースの接続が切断されたりしてしまうことがない）
・操作パラメータを調整するための帯域内信号方式をピアに対して提供（接続された端末のそれぞれから、そのピアに対してネットワーク・トポロジや環境の変化に関する警告を出すことが可能）
・輻輳回避アルゴリズムを採用し、必要なときにはスループットを効果的に減衰
・選択的な確認応答と高速での再伝送とによって無駄な再伝送の回数を制限し、ノマディック環境におけるハンドオフ回復のスピードアップを実現（これにより、プロトコルはロスの多いネットワーク環境においても最適なスループットを維持）
・複数のフレームを待機状態にする、スライディング・ウィンドウ技術を採用（このパラメータは各方向に調整可能で、ピアからの確認応答を要することなくフレームを所定の上限までストリーミングするために与えられる）
・シーケンス番号が非バイト指向であることにより、単一のシーケンス番号で最大のペイロード・サイズまでを表現可能
・セキュリティ対策（インターネット・モビリティ・プロトコル層に認証層と暗号化層を追加可能）
・圧縮によって、帯域幅の限られた接続における効率性を確保
・どちらのピアも新たな位置に移動することが可能な平衡型設計
・どちらの側からでもピアへの接続が確立可能
・休止している接続を迅速に破棄して消費されていたリソースを回復する、休止タイムアウトを発動可能
・接続に対して任意の最大持続時間を設定可能（例えば、所定の期間経過後あるいは所定の日時の後に、接続の終了及び／又は拒否が可能）。
【００２６】
本発明の好ましい具体的な実施形態においては、システム管理者によるネットワーク・リソースの消費の管理が可能である。例えば、システム管理者は、モバイル端末システム、モビリティ管理サーバの少なくとも一方をコントロールすることができる。この場合のコントロールとは、例えばネットワーク帯域幅や他のリソースの配分の管理や、セキュリティ関連の事項を指す。管理はクライアント側で多数のリソースを持っているクライアントについて実行するのが効果的である。
【００２７】
しかしながら、リソースを多く持たないシン・クライアントにポリシー管理のための付加的なコードや処理を負わせるのは望ましくない。よって、シン・クライアントの管理についてはモビリティ管理サーバ等によって集中的に行う、あるいはその一部を分担するのが最も現実的な解決策であると考えられる。
【００２８】
モビリティ管理サーバがモバイル端末システムの各データストリームをプロキシすることによって、ポリシー管理が集中的に行われる。さらに、モビリティ管理サーバがユーザごとにプロキシを行うので、ユーザごと、装置ごとに、ネットワーク・リソースへのアクセスを管理し制限することができる。
【００２９】
簡単な例を挙げると、モビリティ管理サーバは、特定のユーザによるあるネットワーク・リソースへのアクセスを「締め出す」ことができる。この点は、インターフェイスのネットワークが、モバイル相互接続によって組織の管理下にある施設の境界よりも外に「延長」されてしまっていることを考えると非常に重要である（例えば、以前勤めていた職場のネットワークに、元従業員が外部からアクセスを試みるといった場合を考えよ）。
【００３０】
これにとどまらず、モビリティ管理サーバによるポリシー管理はさらに多くの利点を提供しうる。例えば、モビリティ管理サーバによって、あるＵＲＬに特定のユーザのみがアクセスできるようにしたり、ネットワークサービスによる要求によって戻されるデータをフィルタリングしたり、ネットワークの帯域幅保全のためにデータを圧縮したりということが可能になるといった点である。このように、既存もしくは新規のアプリケーションレベルのサービスを、シームレスかつ透過的な形で強化することができる。
【００３１】
また、モバイル端末システムは「信頼性の低い」ネットワーク（つまり組織の管理が及ぶ範囲外のネットワーク）とも接続されるため、リモート接続中に悪質なサイバー攻撃に遭う可能性がある。モバイル端末システムとの間でポリシーやフィルタを共有することで、悪質な接続からのモバイル端末システムの保全、リモート・ノードにおける進入フィルタリング、そして企業インフラの集中管理のさらなるセキュリティ向上が可能になる。
【００３２】
本発明の実施形態の他の一例では、インターフェイスによって補助されたローミングのリスナによって、モバイル端末システムが一般的な信号伝達をサポートしたインターフェイスを利用し、インターフェイスにより補助されたローミングを行うことが可能になる。
【００３３】
本発明の上記実施形態の一例の一側面において、モバイル端末システムの、インターフェイスベースのリスナは、所定の事象（例えばコールバックや、タイマーによるタイムアウト、データの損失を示唆するネットワーク活動など）に際して、モバイル端末システムの媒体の接続状態が変化したか否かを判定する。これは例えば、リスナが、モバイル端末システムが切り離されてネットワークと通信できる状態でなくなったことを検知して、インターフェイスにこれを示唆するといったことを意味する。
【００３４】
再接続の際、リスナは予め記録された接続識別情報におけるネットワークポイントを参照して、モバイル端末システムが同じネットワークポイントに再接続されたか否かを判定する。再接続が同じネットワークポイントになされていた場合、リスナはモバイル・クライアントに、トランスポート・レベルでの通信の再確立を進めることを警告する。
【００３５】
再接続が別のネットワークポイントになされていた場合、リスナはモバイル端末システムが「ローミング」状態であることを示し、現状におけるネットワーク・セグメントで使用可能なアドレスをシステムに取得させるようにする（これは例えば、現行のアドレスを新規のサブネットにおいて有効であるように登録することを含んでもよい）。
【００３６】
リスナは（操作を介して学習した）ネットワーク・トポロジのマップを保持して、そのクライアントに対して生成される信号（「同一サブネット上のローミング」、「ローミング」等）の適否を判定する一助としてもよい。
【００３７】
本発明の非限定的な好ましい具体的実施形態の他の一例においては、モビリティ管理サーバ（ＭＭＳ）に「非接続ネットワーキング」モードでアクセスすることが可能である。この新しいアルゴリズムによって、あるネットワーク・インフラからは別のネットワーク・インフラにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、ＭＭＳとの通信を確立する／持続するのに使われる、代替のネットワークアドレスを動的／静的に見つけ出すことができるようになる。
【００３８】
この構成により、ＭＭＳが利用可能な代替アドレスのリストが予め設定され、通信中にＭＥＳ（モバイル端末システム）に送られるか、あるいはＭＥＳによって動的に学習される。実施の一形態において、ＭＭＳはＭＥＳに、一つ以上のＭＭＳネットワークアドレスもしくは他のネットワークに対応した他のＭＭＳのアイデンティティを、単一のネットワークによる通信によって送ることができる。該リストは、回路構築の際やその他接続が確立されている間のいかなる時にも、送付／更新が可能である。
【００３９】
ＭＥＳが別のネットワークへと移動するとき、ＭＥＳは該ネットワークにおける新規のネットワーク接続を通じてＭＭＳとコンタクトをとるために、ＭＭＳの「エイリアス」（ａｌｉａｓ）アドレス／アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、ルートその他の情報を共有していなくても、ＭＥＳは新規のネットワーク接続を通じてＭＭＳとのコンタクトを再確立することができる。
【００４０】
本発明の実施の形態のさらに他の例において、ポリシー管理に関する意思決定は分散型モバイルネットワークトポロジの内部にて行われ、例えば、ルールベースのポリシー管理プロシージャが、様々なメトリクスに基づいて、要求の遂行を許可、拒絶、又は制限する。このような管理形態は、例えば、マルチホーム／パス環境における最少コストルーティングといったコストメトリクスに基づいて意思決定をする際に用いられる。
【００４１】
このようなポリシー管理技術では、意思決定の際にモビリティあるいは位置取得（つまりローミング）に関する事項が考慮に入れられてもよい。例えば、管理ルールが装置の位置（ネットワークのどの接続ポイント、例えばアクセスポイント／基地局、ハブ、ルータ、ＧＰＳ座標等に近いかなど）に基づいて決定されてもよく、これにより、特定の操作が、あるビル内では許可されるが別のビルでは許可されないといったことが可能になる。
【００４２】
例えば複数の違った無線ネットワークを利用している企業の場合にこの構成が有用であると考えられる。このような企業において、例えば積込ドックとオフィスとが無線ネットワークで接続されている場合がある。システム管理者は、積込ドックにいる従業員（例えばユーザや装置）がオフィス環境の無線ネットワークにアクセスできないようにすることができる。さらに、ポリシー管理によって、許可、拒否、遅延という３つの状態のいずれかをもたらすようにすることも可能である（例えば、決定が帯域幅やコストに基づいてなされる場合、操作の実行はより適切な時期がくるまで遅延される）。
【００４３】
上記実施例におけるポリシー管理においては、決定に基づいて動作を変更することが可能となっている。ひとつのアクションの例としては、全てのアクティブなアプリケーションによる帯域幅の消費を抑えるというものがある。また、例えば、著しく帯域幅を消費する特定のアプリケーションが存在する場合に、ポリシーエンジンによって該アプリケーションによる操作／トランザクションの完了までの速度を管理することが可能となる。この動作は、誤ったアプリケーションの動作を抑制させることを動的に学習するようになっていてもよい。もうひとつのアクションの例として、データの復元（例えば、利用可能な／許可された帯域幅やコスト、ユーザによる制限に基づいたグラフィックイメージのディザリング）がある。
【００４４】
さらに、ルールエンジンは、ルール評価に基づいて他のアクションを発動させる。イベントをロギングする、警告を発する、ユーザにアクションが拒否、遅延、あるいは条件付けされたことを通知するといった外部プロシージャが実行されてもよい。これらのような通知は、既存のルールへのオーバーライドがオペレータから求められるというような、インタラクティブなものであってもよい。
【００４５】
上記実施例におけるポリシー管理エンジンにおいて、その意思決定は、装置、装置のグループ、ユーザ・グループ、ユーザ、あるいはネットワーク接続ポイントに関連した、任意の数のメトリクスもしくはその組み合わせに基づいてなされていてもよい。
【００４６】
ポリシー管理機能の一部として、他にもローカルベースの情報やサービスが、ポリシー管理、ネットワーク・モデリング、及び／又はアセット・トラッキングのために取得され／備えられていてもよい。このようなサービスには、モバイル端末システムの現在位置に関連した情報がユーザやモバイル端末システムに自動的に提供される機能が含まれる。該情報は、メッセージ、ファイルその他の電子的フォーマットにて供給されてもよい。
【００４７】
この機能の非限定的な利用例としては、ショッピングモール運営者、各種業界団体、大規模小売業者などがショッピングセンターに、ブルートゥース  ＰＡＮ、ＩＥＥＥ  ８０２．１１  ＬＡＮ、８０２．１５  ＰＡＮ、その他の無線ネットワーク規格に準拠した、無線アクセスポイントを戦略的に設けるというものがある。
【００４８】
この場合、顧客がセンター内を歩き回るのにあわせて、モバイル端末システムの現在位置周辺の店舗は顧客に情報を提示することができる。この情報としては、セールやディスカウント、特典などについてのものが含まれる。これに加え、モバイル端末システムに販促用の電子クーポン券が供給されるのもよい。店舗側は上記のようなサービスを、モール運営者、業界団体、小売業者、あるいはその他のサービス提供者による集中的な管理機構に登録することになる。
【００４９】
上記技術が利用される他の非限定的な例として、現場サービス、訪問販売、宅配などのバーティカル産業において、位置を基準にして情報を収集する、地域サービス、地図、方角、顧客、事故など公共の情報を、位置を基準にモバイル端末システムに送る、などがある。
【００５０】
さらに他の非限定的な例として、モバイル端末システムをモニタリング、トラッキングするウェブベースのサービスがある。例えば、顧客は該トラッキングサービスに登録し、信頼の置ける第三者機関が、ホスティングされているウェブサービスにログオンして顧客のモバイル端末システムの精確な位置を同定する。
【００５１】
この場合、モバイル端末システムは車両に備え付けられてもよいし、歩行者に所持されていてもよい。モバイル端末システムのさらなる小型軽量化に伴い、このようなサービスはますます現実味を帯びてきている。該サービスを利用することで、危険度の高い人々、例えば高齢者、障害者、病人などを追跡、位置確認することができる。該サービスは、自動車その他の高価な動産や荷物をトラッキングすることにも利用できる。
【００５２】
３Ｇ  ＷＡＮネットワーク、ブルートゥースネットワーク、８０２．１１ネットワークその他の無線技術を利用し、ネットワーク媒体や接続ポイントを切り替えてもシームレスな接続性を保つことができるという特性を生かして、上記のサービスを非常に低いコストで実施することが可能である。
【００５３】
その上、モバイルを意識、あるいは意識していない各装置のネットワーク又はサブネットワークの全体のモビリティを考慮するための要望もまたあり得る。例えば、今日のネットワーク装置のほとんどは、通信の目的のために、インターネットベースのプロトコル（ＩＰ）を備えているが、多くの装置は“閉じたプラットフォーム”上に築かれている。
【００５４】
この事実は、これらのシステムへの新しい機能性の割当てに取り巻く問題を複雑にし、今日のモバイル環境に参加するためのノード能力を制限する。
【００５５】
これらの装置が、様々な理由（費用、共通経費等）のために、モバイルな能力を組み入れることができない、又は組み入れないので、与えられたネットワークに接続される上記装置から、モバイルな通信に関わる上記問題を隠して、ネットワークあるいはサブネットワークの全体がモバイルになることを可能にするという動きが産業界内部にある。
【００５６】
この目的のために、いくつかの企業と規格団体とは、バックホール（backhaul）ネットワークの異なるセットを介して、ローカルに接続される各ネットワークのノードにより生成され、及び定められるＩＰトラフィックを転送する“モバイルルータ”（ネットワークモビリティ−ＮＥＭＯとしても知られている）の概念を開発している。
【００５７】
しかし、一般的にこれらのソリューションは、本発明に示す技術の進歩的な機能性を提供しない、あるいはネットワークアプリケーションに上記バックホールネットワークを利用する上記同一のシステム（すなわちＭＥＳ）上で同時に動作させ得ない。
【００５８】
それゆえ、これらの“閉じたシステム”あるいは固定されるモバイル端末システム（ＦＭＥＳ）に対し、他の装置と共に、本発明にて示された能力の利点を、修正あるいは修正無しにて、透過的及びシームレスに利用させるという要望がある。
【００５９】
上記要望を達成するために、モバイルなネットワークあるいはサブネットワークに接続される装置に対しサービスを提供するローカルプロキシシステム（例えば第２のプロキシ）として、少なくとも一つのＭＥＳのサービスを採用してもよい。
【００６０】
そのとき、上記ＭＥＳは、少なくとも一つのＭＭＳと協動して、セキュリティ、アプリケ−ションセッションの継続、圧縮、及びリンクの最適化、インナーネットワークのローミング、及び／又はポリシー管理を、透過的に及びシームレスに管理し、最終的には、負荷の均衡とフェイルオーバとを含み、非常に小型化できて中央管理可能であるシステムを提供する。
【００６１】
このように、本発明は企業ネットワークを延長して、ネットワーク管理者が、信頼性や集中的な管理形態を犠牲にすることなく、モバイル端末のユーザに、アプリケーションへの簡便なアクセスを固定端末のユーザの場合と同様に提供することを可能にする。本ソリューションは、既存の有線ネットワーク規格の長所を制定段階にあるモビリティ規格にも持たせて、既存のネットワーク・アプリケーション上で動作可能なソリューションを生み出すものである。
【００６２】
本発明の他の目的、特徴、及び優れた点は、以下に示す記載によって十分分かるであろう。また、本発明の利点は、図面を参照した以下の説明で明白になるであろう。
【００６３】
［好ましい実施の形態の詳細な説明］
図１は、本発明の、モバイル強化ネットワークコンピュータシステム１００を例示している。該ネットワークコンピュータシステム１００は、モビリティ管理サーバ１０２と、一つ以上のモバイル端末システム１０４とを含んでいる。モバイル端末システム１０４は、ローカルエリア・ネットワーク（ＬＡＮ）１０８を通じてモビリティ管理サーバ１０２と通信することができる。
【００６４】
モビリティ管理サーバ１０２は、モバイル端末システム１０４のネットワーク・レベルでのプロキシとして機能する。モビリティ管理サーバ１０２は、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム１１０とも、モビリティ管理サーバ１０２とモバイル端末システム１０４との間の相互接続が断続的で信頼性の低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって上記プロキシ機能を成し遂げている。
【００６５】
本発明の好ましい実施形態では、モビリティ管理サーバ１０２は、本発明の遠隔プロシージャ・コール・プロトコル及びインターネット・モビリティ・プロトコルを用いて、モバイル端末システム１０４と通信する。
【００６６】
この場合、モバイル端末システム１０４はモビリティ管理サーバ１０２とアクティブに接続されるが、該接続は常時アクティブに行われるものではない。例えば、
・複数のモバイル端末システム１０４ａ‐１０４ｋが、モビリティ管理サーバ１０２と、モバイル相互接続によって（この場合無線で）通信する。例として、ローカル・エリアもしくはワイドエリア・ネットワーク１０８と無線（あるいは有線）でつながった、従来型の電磁（電波）トランシーバ１０６が考えられる。
【００６７】
上記のようなモバイル相互接続により、モバイル端末システム１０４ａ‐１０４ｋが、一つのカバーエリア（cover area）１０７ａから別のカバーエリア１０７ｋへとローミングすることが可能になる。一般的に、モバイル端末システム１０４が、あるカバーエリア１０７から別のエリアにローミングしたり、最も近いトランシーバ１０６から届く範囲を外れたり、あるいは信号を一時的に遮断（例えばビルの柱の裏側を通るなどで）されたりした場合、一時的に通信が切断される。
【００６８】
・別のモバイル端末システム１０４ｌ、１０４ｍ…が、モビリティ管理サーバ１０２と、ドッキングポートやネットワークケーブルコネクタなどの着脱式の有線相互接続１０９を介して通信する。モバイル端末システム１０４は、接続１０９が外れたり、モバイル端末システム１０４の電源が切られたりした場合、一時的にＬＡＮ１０８から切断される。
【００６９】
・さらに別のモバイル端末システム（例えば１０４ｎ）が、モビリティ管理サーバ１０２と、ワイドエリア・ネットワーク、ダイアルアップ・ネットワーク、衛星ネットワーク、インターネット等のネットワーク・トポグラフィ１１１を介してノマディック接続される。一例として、ネットワーク１１１のサービスは断続的なものであってもよく、他の例として、モバイル端末システム１０４がある種類の接続形態から別の種類のものへと移行（例えば、モビリティ管理サーバ１０２と有線相互接続１０９を通じて接続される状態からネットワーク１１１を通じて接続される状態へ移行、もしくはその逆）し、移行時に一時的に接続が切断されるという構成であってもよい。
【００７０】
モバイル端末システム１０４は、標準的なモバイル装置や市販のコンピュータであってよく、例えば、モバイル端末システム１０４は、市販のトランシーバ及び／又はネットワークカードを実装したラップトップコンピュータによって構成される。モバイル端末システム１０４は、標準的なネットワーク・アプリケーションや標準的なＯＳ（オペレーティングシステム）を実行し、標準的なトランスポート・レベル・プロトコル（例えばＴＣＰ／ＩＰ）を利用して、トランスポート層で通信を行うものであってよい。
【００７１】
本発明において、さらに、モバイル端末システム１０４は、クライアントソフトウェアを実行することで、遠隔プロシージャ・コール・プロトコル及びインターネット・モビリティ・プロトコルを用いたモビリティ管理サーバ１０２との通信が可能になる。上記両プロトコルは、それらと同様のトランスポート・レベルのプロトコルを利用して伝送される。
【００７２】
モビリティ管理サーバ１０２は、ウィンドウズ（登録商標）ＮＴサーバなどの標準的なサーバによってホスティングされるソフトウェアを含んでいてよい。本発明の好ましい実施形態では、モビリティ管理サーバ１０２は、規格に準拠したクライアント／サーバ型のインテリジェントサーバであって、企業ネットワーク１０８を透過性を有した状態でノマディック環境にまで延長するものである。
【００７３】
モビリティ管理サーバ１０２は、数量を限定されないモバイル端末システム１０４それぞれのネットワーク・レベルでのプロキシとして機能するが、モビリティ管理サーバ１０２は、上記機能を、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム１１０とも、モバイル端末システム１０４とトランシーバ１０６との間のモバイル相互接続が断続的で信頼性が低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって成し遂げている。
【００７４】
例えば、サーバ１０２はどのような標準的（例えばＴＣＰ／ＩＰベースの）ネットワーク・アプリケーションであっても、変更を行うことなしに、モバイル接続を通じて実行させることができる。接続が切断されたり、圏外に出たり、あるいは動作をサスペンドしたりしたモバイル端末システム１０４のセッションは、サーバ１０２によって維持され、該システムが復帰した際にはサーバ１０２が上記セッションをレジュームする。
【００７５】
モバイル端末システム１０４が圏外に出てしまったり、シャットダウンしたり、あるいは位置アドレスを変更した場合、モビリティ管理サーバ１０２は、データの受信に関して確認応答し、モバイル端末システムが再度通信可能となるまで要求を待機させることで、モバイル端末システムとピア・システム１１０との接続を維持する。
【００７６】
サーバ１０２はまた、有線ネットワークにおける管理能力をモバイル接続にまで延長する。ネットワークソフトウェア層はそれぞれが互いに独立して動作するので、ソリューションをそれが展開されるそれぞれの環境に合わせてカスタマイズすることが可能である。
【００７７】
一例として、モビリティ管理サーバ１０２が、ローカルエリア・ネットワークやワイドエリア・ネットワークのような標準的な企業ネットワーク１０８と接続され、該ネットワーク１０８は、様々な固定端末システム（例えば一つ以上のホストコンピュータ１１０）１１０と接続される状況が考えられる。
【００７８】
モビリティ管理サーバ１０２によって、モバイル端末システム１０４と固定端末システム１１０との間の、連続セッション型データストリームを利用した通信が可能となるが、この通信は、モバイル端末システム１０４が、接続しているネットワーク相互接続とのコンタクトを失ったり、あるネットワーク相互接続１０６、１０９、１１１から別のネットワーク相互接続へと移動したりしても（例えば、無線相互接続の場合、ある無線トランシーバ１０６のカバーエリア１０７から別のカバーエリアにローミングしても）、利用可能となっている。
【００７９】
モバイル端末システム１０４は、モビリティ管理サーバ１０２との結合を、スタートアップ時か、あるいはモバイル端末システムがネットワークサービスを要求した時に確立する。結合が確立されると、モバイル端末システム１０４は、一つ以上のネットワーク・アプリケーションのセッションを、連続的あるいは共時的に始めることができる。
【００８０】
モバイル端末システム１０４−モビリティ管理サーバ１０２間の結合確立によって、モバイル端末システムが切断されたり、圏外に出たり、あるいはサスペンドしたりしても、モバイル端末システムにおけるアプリケーションのセッションを維持し、モバイル端末システムの復帰時には該セッションをレジュームすることが可能になる。本発明の好ましい実施形態では、上記の処理は完全に自動で行われ、ユーザによる介入は全く必要とされない。
【００８１】
本発明の一例において、モバイル端末システム１０４は、ＵＤＰ／ＩＰのような標準的なトランスポート・プロトコルを用いてモビリティ管理サーバ１０２と通信を行う。標準的なトランスポート・プロトコルを使用することで、モバイル端末システム１０４が、標準的なルータ１１２など企業ネットワーク１０８に既存のインフラを用いて、モビリティ管理サーバ１０２と通信することが可能になる。
【００８２】
本発明では、高レベルの遠隔プロシージャ・コール・プロトコルが、トランザクションを、モバイル強化ネットワーク１０８を介して、標準的なトランスポート・プロトコルを使用して送られるメッセージ内に生成する。
【００８３】
本発明の好ましい実施形態において、上記のようなモバイルＲＰＣメッセージは、モバイル端末システム１０４にて実行されるアプリケーションによって開始された、全てのネットワーク・トランザクションを含んでいるため、モビリティ管理サーバ１０２によって全てを完了させることができる。このことにより、モビリティ管理サーバ１０２とモバイル端末システム１０４とは、ネットワーク媒体の接続性が阻害されているときでも、接続状態情報を常に互いにシンクロさせておくことができる。
【００８４】
モバイル端末システム１０４のそれぞれは、全てのネットワーク活動を傍受し、該ネットワーク活動をモバイルＲＰＣプロトコルを通じてモビリティ管理サーバ１０２にリレーするための情報をモバイル端末システム自体に提供するモビリティ管理ソフトウェアクライアントを実行する。
【００８５】
本発明の好ましい実施形態では、該モビリティ管理クライアントは、モバイル端末システム１０４に実装されているＯＳ（ウィンドウズ（登録商標）ＮＴ、ウィンドウズ（登録商標）９８、ウィンドウズ（登録商標）９５、ウィンドウズ（登録商標）ＣＥなど）と透過性を有する状態で協働して、クライアント側でのアプリケーションのセッションを、ネットワークとのコンタクトが失われても維持し続ける。
【００８６】
モビリティ管理サーバ１０２は、それぞれのモバイル端末システム１０４の状態を管理し、例えば接続の反対側の端に接続されたホストコンピュータ１１０のような通信相手のピア１０８との連続的な接続を維持するために必要とされる複合的なセッション管理を行う。
【００８７】
モバイル端末システム１０４との通信ができなくなったり、モバイル端末システム１０４がサスペンドしたり、あるいはネットワークアドレスを変更したり（例えばあるネットワーク相互接続から別のものにローミングしたり）した場合、モビリティ管理サーバ１０２は、モバイル端末システム１０４とホストシステム１１０などの接続端との間の接続を、データ受信に関して確認応答したり、要求を待機させたりすることによって維持する。
【００８８】
このプロキシ機能によって、ピアのアプリケーションは、モバイル端末システム１０４との物理的な接続が絶たれたことを検知することがなくなる。よって、もしモバイル端末システムが一時的に接続を失ったり、あるカバーエリア１０７Ｋ内において、あるネットワーク相互接続１０６Ａから別のネットワーク相互接続１０６Ｋへとローミングしたりした場合でも、（物理的接続が再確立された際に単純に作業をレジュームすることで）モバイル端末システム１０４のアプリケーションと、その結合しているセッションを実行する端との間の連続的な接続を効果的に維持することができる。
【００８９】
モビリティ管理サーバ１０２はまた、モバイル端末システム１０４がセグメント化されたネットワークの様々な部分をローミングする際、異なったネットワークアドレスを受信するという問題を解決するべく、アドレスを管理することが可能となっている。
【００９０】
モバイル端末システム１０４はそれぞれ、プライマリネットワーク上での仮想アドレスを有している。該仮想アドレスは、標準的なプロトコルによって、あるいは静的割り当てによって決定されている。モバイル端末システム１０４のそれぞれについて、モビリティ管理サーバ１０２は該システムの現状における実際の（位置）アドレスに対応して仮想アドレスを割り当てる。
【００９１】
モバイル端末システム１０４の、あるネットワーク・セグメントから他のセグメントへの移動に伴って、該システム１０４の現在位置アドレスが変更されても、仮想アドレスは、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【００９２】
よって、モバイル端末システム１０４の位置アドレスの変更は、モビリティ管理サーバ１０２を介して、結合しているホストシステム１１０（及び他のピア）におけるセッションを実行する端からは完全に透過性を有する状態となっている。ピア１１０から見えるのは、サーバ１０２によってプロキシされた（不変の）仮想アドレスのみということになる。
【００９３】
本発明の好ましい実施形態では、モビリティ管理サーバ１０２はさらに、コンソール（制御）アプリケーションと包括的なメトリクスとによる、集中的なシステム管理が可能である。システム管理者は、上記のツールを利用して、遠隔接続を設定、管理し、遠隔接続及びシステムにおける問題を解決することができる。
【００９４】
モビリティ管理サーバ１０２によるプロキシ・サーバ機能によって、ネットワーク・アプリケーション、ユーザ、そして装置にそれぞれ異なった優先レベルを設定することができるようになる。これは、モビリティ管理サーバ１０２が有する処理用のリソースが有限であることを鑑みれば、有用なものである。
【００９５】
システム管理者が上記のようにモビリティ管理サーバ１０２の設定を変更できることで、システム及びネットワークのパフォーマンスが全体として向上する。一例として、システム管理者がモビリティ管理サーバ１０２の設定を変更できることにより、音声や映像のストリーミングのようなリアルタイムのアプリケーションに対して、モビリティ管理サーバ１０２のリソースを、あまりリソースを使用しないメールソフトのようなアプリケーションよりも多く割り当てることができる。
【００９６】
詳しく説明すると、モビリティ管理サーバ１０２は、アプリケーション、もしくはＳＮＭＰのような標準的なネットワーク管理プロトコル、ウェブベースの設定インターフェイス、ローカルなユーザインターフェイスなどのアプリケーション・インターフェイスを介して設定される。結合そのものの優先度、及び／又は、ある結合における複数のアプリケーションの優先度を設定することも可能である。
【００９７】
例えば、モビリティ管理サーバ１０２を介して動作する他の結合と関連している結合それぞれの優先度は、ユーザあるいは装置ごとに設定可能である（本実施形態では、ユーザ及びユーザがログインした装置の両方を優先するように設定された場合に、ユーザに関する設定のほうがより優先されるように設定されてもよい）。
【００９８】
あるいは結合それぞれについて、アプリケーションの優先度に関し、ネットワーク・アプリケーションごとにいくつかのレベルが設定されていてもよい。本システムでは、優先レベルはいくつでも設定することが可能である。一例として、低、中、高の３つの優先レベルが設定される例が考えられる。
【００９９】
（サーバ／クライアント型ソフトウェア・アーキテクチャの例）
図２に、モバイル端末システム１０４とモビリティ管理サーバ１０２とのソフトウェア・アーキテクチャの一例を図示する。本発明の一例において、モバイル端末システム１０４とモビリティ管理サーバ１０２は標準的なＯＳ及びアプリケーション・ソフトウェアを実行するが、このときに、ほんの少数のコンポーネントを新しく追加するだけで、断続的に接続されるモバイルネットワーク１０８を介した、信頼性が高くかつ効果的、持続的なセッションが実行可能となっている。
【０１００】
図２に示すように、モバイル端末システム１０４は、ネットワーク・インターフェイス・ドライバ２００、ＴＣＰ／ＵＤＰトランスポートサポート２０２、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４、及び一つ以上の従来型のネットワーク・アプリケーション２０８に対するインターフェイスとして使われるソケットＡＰＩ２０６を含む、従来型のＯＳソフトウェアを実行する。
【０１０１】
従来型のネットワーク・ファイル／プリント・サービス２１０が、従来型のＴＤＩ２０４との通信用にさらに設けられていてもよい。サーバ１０２は、上記と類似した、従来型のネットワーク・インターフェイス・ドライバ２００’、ＴＣＰ／ＵＤＰトランスポートサポート２０２’、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４’、及び一つ以上の従来型のネットワーク・アプリケーション２０８’に対するインターフェイスとして使われるソケットＡＰＩ２０６’を有していてもよい。
【０１０２】
モバイル端末システム１０４とモビリティ管理サーバ１０２はそれぞれ、さらにネットワーク／セキュリティ・プロバイダ２３６（モバイル端末システム）、ユーザ／セキュリティ・データベース２３８（サーバ）を備えていてもよい。
【０１０３】
本発明では、新規のモバイル・インターセプタ・コンポーネント２１２が、モバイル端末システム１０４のソフトウェア・アーキテクチャにおける、ＴＣＰ／ＵＤＰトランスポートモジュール２０２とトランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４との間に挿入されている。
【０１０４】
該モバイル・インターセプタ・コンポーネント２１２は、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４における特定のコールを傍受して、該コールを、ネットワーク１０８を介し、ＲＰＣ及びインターネット・モビリティ・プロトコル、標準的なＴＣＰ／ＩＰトランスポート・プロトコルを通じてモビリティ管理サーバ１０２へと転送する。
【０１０５】
こうして、モバイル・インターセプタ２１２は、全てのネットワーク活動を傍受して、サーバ１０２へと転送することができる。該インターセプタ２１２はＯＳと透過性を有する状態で協働するので、モバイル端末システム１０４がネットワーク１０８とのコンタクトを失っても、クライアント側のアプリケーションのセッションはアクティブであり続けることができる。
【０１０６】
モバイル・インターセプタ２１２は、トランスポート・ドライバ・インターフェイス２０４とは違うレベルで（例えばソケットＡＰＩ２０６のレベルで）動作することもできるが、ＴＤＩのレベルでモバイル・インターセプタ２１２が動作する。
【０１０７】
より詳細にはいずれかのトランスポート・プロトコル・インターフェイスにおいて動作することにより、下記のような利点が生まれる。なお、便宜的に、トランスポート・ドライバ・インターフェイスを示す全てのものをＴＤＩという略語で表わすこととする。
【０１０８】
多くの標準的なＯＳ（例えば、マイクロソフト社のウィンドウズ（登録商標）９５、ウィンドウズ（登録商標）９８、ウィンドウズ（登録商標）ＮＴ、ウィンドウズ（登録商標）ＣＥなど）はＴＤＩインターフェイス２０４を実装しているので、ＯＳのコンポーネントを変更することなく互換性が保証される。
【０１０９】
さらに、トランスポート・ドライバ・インターフェイス２０４は通常カーネル・レベルのインターフェイスであることから、ユーザモードへの切り替えが必要でなく、これにより性能を向上させることができる。
【０１１０】
さらに、ＴＤＩインターフェイス２０４のレベルで作動するモバイル・インターセプタ２１２は、様々な別のネットワーク・アプリケーション２０８（例えば複数の同時に動作しているアプリケーション）に加えて、ネットワークにおけるファイル、プリント、及び他のカーネル・モードなどのサービス２１０（インターセプタが例えばソケットＡＰＩ２０６のレベルで動作している場合はそれぞれ別に扱う必要がある）を傍受することができる。
【０１１１】
図２Ａに、どのようにインターセプタ２１２が動作するかを示す高レベルのフローチャートの一例を示す。モバイル端末システム１０４のＴＤＩインターフェイス２０４へのコール（ブロック２５０）は、モバイル・インターセプタ２１２によって傍受される（ブロック２５２）。
【０１１２】
モバイル・インターセプタ２１２によって傍受されたＲＰＣコールはインターネット・モビリティ・プロトコルに準拠してフラグメントにパッケージ化され、該フラグメントはデータグラムとして、ＵＤＰやＴＣＰといった標準的なトランスポート・プロトコルにより、ＬＡＮ、ＷＡＮ等のトランスポート１０８を介してモビリティ管理サーバ１０２へと送られる（ブロック２５２）。
【０１１３】
モビリティ管理サーバ１０２は受信したＲＰＣデータグラムをアンパックして（ブロック２５４）、要求されたサービスを実行する（例えば、データや応答を、固定端末システム１１０で動作するアプリケーションサーバ処理へと転送することで、モバイル端末システムのアプリケーション２０８のプロキシとして振舞う）。
【０１１４】
再び図２に戻って、モビリティ管理サーバ１０２は、従来型のネットワーク・インターフェイス・ドライバ２００’を介して送られる、モバイル端末システム１０４からの、あるいはモバイル端末システム１０４へ向かうメッセージを傍受する、アドレス変換部２２０を有している。
【０１１５】
例えば、アドレス変換部２２０は、セッションの相手のピア（固定端末システム１１０）からのモバイル端末システム１０４の仮想アドレス宛のメッセージを認識する。モバイル端末システムへの該メッセージはプロキシ・サーバ２２４へと送られる。プロキシ・サーバ２２４は仮想アドレスとメッセージとを待機していたトランザクションに割り当て、該応答を、上記モバイル端末システム１０４の現在位置アドレスへと転送する。
【０１１６】
さらに、図２によると、モビリティ管理サーバ１０２は、アドレス変換部（中間ドライバ）２２０とプロキシ・サーバ２２４に加えて、設定マネージャ２２８、操作／ユーザインターフェイス２３０、及びモニタ２３２を有している。
【０１１７】
設定マネージャ２２８は設定情報とパラメータとを提供して、プロキシ・サーバ２２４が接続の管理を行えるようにする。操作／ユーザインターフェイス２３０とモニタ２３２により、ユーザとプロキシ・サーバ２２４との間のやりとりが可能になる。
【０１１８】
（モバイル・インターセプタ）
図３は、本発明のＲＰＣプロトコルとインターネット・モビリティ・プロトコルとをサポートしたモバイル・インターセプタ２１２のソフトウェア・アーキテクチャの一例を示す。本例では、モバイル・インターセプタ２１２は、遠隔プロシージャ・コール・プロトコル・エンジン２４０と、インターネット・モビリティ・プロトコル・エンジン２４４の、二つの機能コンポーネントを有している。モビリティ管理サーバ１０２において動作するプロキシ・サーバ２２４により、対応するエンジン２４０’、２４４’が用意される。
【０１１９】
このように、本発明の好ましい実施形態におけるモバイル・インターセプタ２１２は、モビリティ管理サーバ１０２をそれぞれのモバイル端末システム１０４と接続するための、遠隔プロシージャ・コール・プロトコルと、インターネット・モビリティ・プロトコルとをサポートしている。
【０１２０】
遠隔プロシージャ・コールは、あるローカルシステムから、離れた別のシステムにおけるプロシージャを発動する処理を可能とするものである。一般的に、ローカルシステムは遠隔のシステムにおいてプロシージャ・コールが実行されたことを感知しない。
【０１２１】
ＲＰＣプロトコルの利用によって、モバイル端末システム１０４が、アクティブなネットワークセッションを失うことなく、圏外に出たり、操作をサスペンドしたりすることが可能になる。セッションの維持に特別なアプリケーションは必要とされないので、モバイル環境にあるネットワーク１０８において、市販のアプリケーションが何の変更も必要とせずに動作することになる。
【０１２２】
ネットワーク・アプリケーションは、一般的に、ウィンドウズソケットのようなアプリケーションレベルのインターフェイスを利用している。アプリケーションレベルのＡＰＩへの単一のコールによって、トランスポート層もしくはメディア・アクセス層における複数の送信及び受信データパケットが生成される。
【０１２３】
優先されるモバイルネットワークで、もし上記のパケットのうちの一つが失われた場合、接続全体の状態が不安定になってセッションは中止されるが、本発明の好ましい実施形態はＲＰＣを備えており、モビリティ管理サーバ１０２とモバイル端末システム１０４とは、物理的な接続が絶たれたときであっても、常に統一された論理リンクを維持するために、接続状態に関する情報を共有している。
【０１２４】
本発明のインターネット・モビリティ・プロトコルは、有線のネットワークと無線など他の信頼性の劣るネットワークとの相違点を補償する。フレームサイズとプロトコルのタイミングとが修正されることで、モバイル環境を考慮しないトランスポートと比較して性能が著しく向上し、ネットワークのトラフィックを大幅に減少することができる。このことは、帯域幅に制限がある場合やバッテリーの寿命が問題となる場合に重要となる。
【０１２５】
また、本発明のインターネット・モビリティ・プロトコルは、公共の有線ネットワークを通じて、もしくは無線によってモビリティ管理サーバ１０２とモバイル端末システム１０４との間の通信がなされる際の、機密情報のセキュリティを保証する。
【０１２６】
インターネット・モビリティ・プロトコルは、認証された装置のみが企業ネットワークにアクセスすることを許可することで、基本的なファイアウォールとしての機能を果たす。本発明のインターネット・モビリティ・プロトコルはさらに、モビリティ管理サーバ１０２とモバイル端末システム１０４との間での全ての通信を認証、暗号化することを可能にする。
【０１２７】
図３のモバイル端末システム１０４における遠隔プロシージャ・コール・プロトコル・エンジン２４０は、ＴＤＩコールパラメータをマーシャリングし、データをフォーマットし、要求を、ＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’がコールを実行するモビリティ管理サーバ１０２まで転送するべく、インターネット・モビリティ・プロトコル・エンジン２４４に送る。
【０１２８】
モバイル端末システム１０４は、遠隔プロシージャ・コール・プロトコルに基づいてＴＤＩコールパラメータをマーシャリングする。モビリティ管理サーバ１０２のＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’が上記のＲＰＣを受信すると、モビリティ管理サーバ１０２はモバイル端末システム１０４に代わってコールを実行する。
【０１２９】
モビリティ管理サーバ１０２のＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’は、接続されたモバイル端末システムそれぞれにおける完全なネットワークの状態を、ピアであるモバイル端末システム１０４のＲＰＣエンジン２４０と共有する。
【０１３０】
モバイル端末システム１０４のプロキシとしての遠隔プロシージャ・コール実行に加え、サーバのＲＰＣエンジン２４０’は、システムフローの管理、遠隔プロシージャ・コールの解析、仮想アドレスの（アドレス変換機構２２０が行うサービスに対応した）多重化、遠隔プロシージャ・コールのトランザクションの優先順位付け、スケジューリング、ポリシー実行、及び融合処理を行う。
【０１３１】
インターネット・モビリティ・プロトコル・エンジン２４４は、信頼性の高いデータグラムサービス、順位付け、フラグメント化、及びメッセージの再組立を行う。また、設定すれば、認証、データ暗号化、プライバシー保護強化、セキュリティ、そしてスループットのための圧縮も行うことができる。
【０１３２】
インターネット・モビリティ・プロトコル・エンジン２４４は、電力消費を考慮に入れる必要のある環境において、複数の異なるトランスポートを利用して機能するようになっているので、消費電力管理を意識したものであるとともに、各トランスポートに対して独立となっている。
【０１３３】
図３Ａは、モバイル・インターセプタ２１２がモビリティ管理サーバ１０２と通信してＴＤＩコールのやり取りを行う処理を例示する。一般的に、モバイル・インターセプタ２１２のＲＰＣプロトコル・エンジン２４０は、マーシャリングされたＴＤＩコールを、モビリティ管理サーバ１０２へと送るべく、インターネット・モビリティ・プロトコル・エンジン２４４へと転送する。
【０１３４】
ＲＰＣプロトコル・エンジン２４０は、この作業を、インターネット・モビリティ・プロトコル・エンジン２４４によって管理されるキューにＲＰＣコールを加えることで達成する（ブロック３０２）。帯域幅管理を円滑に行うために、インターネット・モビリティ・プロトコル・エンジン２４４は受信したＲＰＣコールの転送を所定の期間（ＲＰＣ融合タイムアウト期間）遅延させる（ブロック３０４）。
【０１３５】
一般的に、ＲＰＣ融合タイムアウトは５ミリ秒から１５ミリ秒の間に設定されるが、この数値はユーザによって変更可能である。この遅延によって、ＲＰＣエンジン２４０はＴＤＩコールをインターネット・モビリティ・プロトコル・エンジン２４４のキューに加えて、一つ以上のＲＰＣコールが同一のデータグラム（フラグメント）によって転送されるようにすることができる。
【０１３６】
融合タイムアウトが終了するか、ＲＰＣエンジン２４０がそれ以上のＲＰＣコールの受信を拒否する（判定ブロック３０６）ことを決定すると、ＲＰＣエンジン２４０は、インターネット・モビリティ・プロトコル・エンジン２４４に、キューをフラッシュ（ｆｌｕｓｈ）し、ＲＰＣコールを単一のフレームに融合し、該フレームをピアに転送するよう要求する（ブロック３０８）。この融合により伝送回数が減少し、プロトコルのパフォーマンスが高められる。
【０１３７】
しかし、インターネット・モビリティ・プロトコルは、パフォーマンス最適化のために他の外部基準に基づいてキュー２４４をフラッシュすることもしなければならず、本発明の好ましい実施形態において、単一のＲＰＣ要求でフレーム全体が占められてしまう場合、ＩＭＰ層は自動的に要求をピアに送るよう試みる。
【０１３８】
上記のように、モビリティ管理サーバ１０２のプロキシ・サーバはＲＰＣプロトコル・エンジン２４０’とインターネット・モビリティ・プロトコル・エンジン２４４’とを有している。図３Ｂは、モバイル端末システム１０４からインターネット・モビリティ・プロトコル・メッセージ・フレームを受信した際に、モビリティ管理サーバ１０２で実行される処理を例示している。
【０１３９】
該フレームをモビリティ管理サーバ１０２が受信すると、インターネット・モビリティ・プロトコル・エンジン２４４’は、フレームが（基礎となるトランスポートの最大伝送量の制約で）フラグメント化されていれば再構築し、メッセージの内容を逆多重化して、どのモバイル端末システム１０４からの受信かを決定する。この逆多重化により、インターネット・モビリティ・プロトコル・エンジン２４４’は、遠隔プロシージャ・コール・プロトコル・エンジン２４０’に、的確な結合関連文脈情報を伝えることができる。
【０１４０】
続いて、インターネット・モビリティ・プロトコル・エンジン２４４’は、受信したメッセージを、ＲＰＣ受信示唆システム作業要求３５４にして、該作業要求と結合関連文脈情報を、モビリティ管理サーバ１０２のＲＰＣプロトコル・エンジン２４０’に与える。
【０１４１】
ＲＰＣプロトコル・エンジン２４０’が作業要求３５２を受信すると、該エンジン２４０’は作業要求３５２を結合関連作業キュー３５６に加え、次に予定済みの要求をグローバルキュー３５８に送ることによって、結合処理のスケジューリングが行われる。
【０１４２】
続いて、ＲＰＣエンジン２４０’のメイン作業スレッドに、作業が実行可能となったことが伝えられる。該メインスレッドが作業を始めると、グローバルキュー３５８がポーリングされて、待機状態となっているスケジューリングされた結合処理が確認される。その後、メインスレッドは該イベントを待機状態から外し、結合関連作業キュー３５６が処理される。
【０１４３】
結合関連作業キュー３５６から、上記メインスレッドはそれまで待機していたＲＰＣ受信示唆作業要求を見つけ出す。次に、メインスレッドはＲＰＣ受信示唆作業要求３５６をキューから外し、該要求を解析する。図３Ａを参照して説明した上記融合処理により、モビリティ管理サーバ１０２は、それぞれのデータグラムに内包された複数のＲＰＣトランザクションを頻繁に受信することになる。
【０１４４】
モビリティ管理サーバ１０２は次に、該ＲＰＣトランザクションをそれぞれ逆多重化して別個の遠隔プロシージャ・コールに戻し、そして要求された機能をモバイル端末システム１０４に代わって実行する。パフォーマンス向上のため、ＲＰＣエンジン２４０’に、ＲＰＣメッセージ解析処理中の先読みメカニズムを備えさせて、ＲＰＣエンジン２４０’が、要求されたトランザクションのうちのいくつかを同時に実行できるか否か（パイプライン処理できるか否か）を確認してもよい。
【０１４５】
（ＲＰＣエンジン２４０’によるＲＰＣ結合の実行手法）
図４は、結合作業キュー３５６に加えられたＲＰＣ結合を実行する処理を例示したフローチャートである。ＲＰＣ結合の実行が予定されている時、ＲＰＣプロトコル・エンジン２４０’（状態機械として設けられていてもよい）のメインスレッドは、グローバルネットワークキュー３５８からの作業要求を待機状態から外し、作業要求の種類を決定する。
【０１４６】
本実施形態のＲＰＣ作業要求は、以下のような６つの基本的な種類に分けられる。
・スケジューリング要求（schedule request）
・接続示唆
・切断示唆
・ローカル結合中止（local terminate association）
・「リソース使用可」要求（"resource available" request）
・ｐｉｎｇ休止タイムアウト（ping inactivity timeout）
ＲＰＣプロトコル・エンジン２４０’は、上記の様々な種類の要求をそれぞれ別の方法で取り扱う。ＲＰＣプロトコル・エンジン２４０’は要求の種類（グローバルキュー３５８に記憶された、要求に関する情報によって識別される）をテストして、該要求をどう処理するかを決定する。
【０１４７】
作業要求の種類が「スケジューリング要求」である場合（判定ブロック３６０）、ＲＰＣプロトコル・エンジン２４０’はどの結合が予定されているかを判別する（ブロック３６２）。ＲＰＣプロトコル・エンジン２４０’はこの判別を、グローバルキュー３５８に記憶されている情報に基づいて実行することができる。
【０１４８】
上記判別がなされると、ＲＰＣプロトコル・エンジン２４０’が、それぞれが対応する要求を記憶している結合作業キュー３５６（１）〜３５６（ｎ）のうちの一つを特定することが可能となる。ＲＰＣエンジン２４０’によって、対応する結合制御ブロックが取得され（ブロック３６２）、結合作業処理タスク３６４が呼び出されて、上記の特定された作業キュー３５６における作業の処理が始められる。
【０１４９】
図５は、図４の「結合作業処理」タスク３６４によって実行されるステップを例示している。結合が特定されると、「結合作業処理」タスク３６４が呼び出され、対応する結合作業キュー３５６内の作業が処理される。待機状態から外された作業要求（ブロック３９０）がＲＰＣ受信要求（判定ブロック３９２）である場合、該ＲＰＣ受信要求はＲＰＣ構文解析部に送られ、処理される（ブロック３９４）。
【０１５０】
あるいは、待機状態から外された作業要求（ブロック３９０）が、保留中の受信要求である場合（判定ブロック３９６）、ＲＰＣエンジン２４０’は、ＴＤＩ２０４’に対し、アプリケーションによる接続の代わりにデータを受信し始めるよう要求する（ブロック３９８）。
【０１５１】
上記待機状態から外された作業要求が、保留中の接続要求である場合（判定ブロック４００）、ＲＰＣエンジン２４０’はＴＤＩ２０４’に、アプリケーション用途ＴＣＰ（あるいは他のトランスポート・プロトコル）接続要求を発するよう要求し（ブロック４０２）、ＴＤＩ層２０４’からの応答を待つ。
【０１５２】
ＴＤＩ２０４’による要求が完了すると、該要求の状態が決定されて、元の要求エンティティへと報告が戻される。パフォーマンス向上のため、ＲＰＣエンジン２４０’は、実際に要求を発しているピアへエラーを通知する前に、要求を結合関連作業キュー（３５６）へと戻すことで、接続要求処理を複数回行うようになっていてもよい。この処理も、ネットワーク帯域幅及びリソースの消費を減らすためのものである。
【０１５３】
上記の処理は、「スケジューリング重み付け」テスト（ブロック４０４）にパスするまで繰り返される。本例では、スケジューリング重みは、どれだけの作業要求が待機状態から外されて、上記の特定の結合がどれだけ処理されるかを決定するのに使われる。該スケジューリング重みは設定マネージャ２２８によって設定されるパラメータであり、結合接続示唆が検出されたときに取得される（図４、ブロック３７２）。この数値はユーザごとに、あるいは物理的な意味での装置ごとに設定可能である。
【０１５４】
ＲＰＣエンジンが結合作業キュー３５６の作業を（少なくとも一時的に）終了した後、ディスパッチ・キューの処理に移ってもよい（ブロック４０６）（詳細は以下）。結合の作業キュー３５６における作業の処理後、ＲＰＣエンジン２４０’は、グローバル作業キュー３５８に新たなスケジューリング要求を発信して、後で実行される結合のスケジューリングを再び行う（図４の判定ブロック３６６、ブロック３６８、図５の判定ブロック４０８、ブロック４１０）。
【０１５５】
再度図４を参照すれば、ＲＰＣ作業要求が「接続示唆」の場合（判定ブロック３７０）、ＲＰＣエンジン２４０’に、モバイル・ピア（通常はモバイル端末システム１０４だがこれに限らない）との新たな接続のインスタンスを作成せよという要求が入る。一例として、上記接続示唆により、接続を開始しようとしているピアの装置に関する以下のような情報がＲＰＣエンジン２４０’に与えられる。
・装置の物理的識別子
・該装置にログインしているユーザ名
・ピアの装置のアドレス
・ピアのＲＰＣエンジン２４０からの、付加的な接続データ
【０１５６】
接続示唆（判定ブロック３７０）を受け、ＲＰＣエンジン２４０は上記のパラメータをもって設定マネージャ２２８をコールする。設定マネージャ２２８は該パラメータを用いて、上記新規接続の設定を確定する。
【０１５７】
この設定（例えば結合スケジューリング重みや、上記に加えてデフォルトでないスケジューリング特性を要するアプリケーション全てのリストなど）は、ＲＰＣエンジン２４０’に戻されて記憶、実行される。そしてＲＰＣエンジン２４０’は新規の結合を開始し、新規の結合制御ブロックを形成する（ブロック３７２）。図５Ａが示すように、以下のような動作が実行されてもよい。
・結合制御ブロックを割り当てる（ブロック３７２Ａ）
・システム全体のリソースをデフォルトにまで初期化する（ブロック３７２Ｂ）
・現在の設定をオーバーライドする（ブロック３７２Ｃ）
・フラグを初期化する（ブロック３７２Ｄ）
・結合特有作業キューを初期化する（ブロック３７２Ｅ）
・結合のオブジェクト・ハッシュ・テーブルを初期化する（ブロック３７２Ｆ）
・融合タイマーを初期化する（ブロック３７２Ｇ）
・結合制御ブロックをセッションテーブルに挿入する（ブロック３７２Ｈ）
【０１５８】
インターネット・モビリティ・プロトコル・エンジン２４４’が結合を終了しなければならないと判断すると、「切断示唆」が該インターネット・モビリティ・プロトコル・エンジン２４４’からＲＰＣエンジン２４０’に出される。ＲＰＣエンジン２４０’はこの切断示唆をテストし（ブロック３７４）、示唆に応じて結合を停止し、結合制御ブロックを破棄する（ブロック３７６）。図５Ｂに示されるように、以下のステップが実行されてもよい。
・待機中の作業がこれ以上処理されないように、停止される結合をマークする（ブロック３７６Ａ）
・処理を含む、結合されている全ての結合オブジェクトをクローズする（ブロック３７６Ｂ）
・作業キューにある全てのエレメントを開放する（ブロック３７６Ｃ）
・融合タイマーが動作中ならば停止する（ブロック３７６Ｄ）
・結合制御ブロックの参照カウントを減少させる（ブロック３７６Ｅ）
・参照カウントが０の場合、（ブロック３７６Ｆにてテストされる）
・結合関連作業キューを破棄し、
・オブジェクト・ハッシュ・テーブルを破棄し、
・融合タイマーを破棄し、
・結合テーブルから結合制御ブロックを取り除き、
・制御ブロックを開放する（３７６Ｇ）
【０１５９】
システム１０２が結合終了の必要性を認識すると、「セッション中止」要求が出される。この要求はシステム管理者、ＯＳ、あるいはアプリケーションから発される。ＲＰＣエンジン２４０’は、セッション中止要求を上記切断示唆と同様に扱う（判定ブロック３７８、ブロック３７６）。
【０１６０】
本発明の好ましい実施形態では、ＲＰＣエンジン２４０’とインターネット・モビリティ・プロトコル・エンジン２４４’との間のインターフェイスが、クレジット（ｃｒｅｄｉｔｓ）を基にフロー制御メカニズムを特定する。ある単一のスレッドが別のスレッドに作業要求を通知するたびに、コールされたスレッドは作業キューに残っているクレジットの数に戻る。キューが満杯であればクレジットのカウントは０になるが、慣例として、コールする側のスレッドは、クレジットのカウントが０ならばそれ以上作業通知をしない。
【０１６１】
よって、ユーザによって設定可能あるいは所定の最低点をキューに付けて、待機中であった作業が処理されてリソースに余裕ができたことを、上記コールする側のスレッドに伝えるような構成が必要となる。これが、「リソース使用可」作業示唆が設けられている理由である（判定ブロック３８０にてテストされる）。図５Ｃが示すように、クレジットのカウントが０になったとき、以下のようなステップが実行されてもよい。
・ＲＰＣ＿ＬＭＰＱ＿ＳＥＮＤ＿ＦＬＡＧと設定して、結合に「ロー・マーク保留」とマークを付ける（ブロック３７９Ａ）。この状態になったら、
・受信された全てのデータグラムを破棄する（ブロック３７９Ｂ）
・データ受信を拒否して全ての受信されたストリーム・イベントを抑える（ブロック３７９Ｃ）（これにより、ＴＣＰ他のトランスポート受信ウィンドウが結果的に閉じられ、固定端末システム１１０とモビリティ管理サーバ１０２との間のフロー制御がなされる。復帰の前に、本発明の好ましい実施形態では「保留受信要求」を結合関連作業キュー３５６の前に押し込むので、保留中のストリーム受信イベントの処理が、リソースが利用可能になると直ちに継続される）。
・全ての受信された接続イベントが、受動接続のために拒否される（ブロック３７９Ｄ）
【０１６２】
「リソース使用可」示唆をＲＰＣエンジン２４０’が受け取ると（図４、判定ブロック３８０）、該ＲＰＣエンジンは、結合された結合作業キュー３５６に待機中の作業があるか否かを判定する。もしあれば、ＲＰＣエンジンは該結合についてグローバル作業キュー３５８に通知して、上記結合作業キュー３５６が動作の優先権を持つことをマークしておく（ブロック３８２）。保留中の受信要求が、結合が保留受信要求状態にある期間に通知された場合、この期間中に処理される（本発明の好ましい実施形態では、ＲＰＣエンジン２４０’は、この処理中も全ての受信された接続要求を受け入れる）。
【０１６３】
再度図４を参照すると、ＲＰＣエンジン２４０’が、モビリティ管理サーバ１０２の「ｐｉｎｇ」に使われるチャネルが所定の期間にわたって休止していると判定した場合（判定ブロック３８４）、該チャネルは閉じられ、リソースは開放されてシステムに復帰し、他の処理に使用される（ブロック３８６）。
【０１６４】
（ＲＰＣ構文解析と優先キュー）
再度図５を参照すると、ＲＰＣエンジンがＲＰＣ受信要求をその受信に際して構文解析することは前述した（ブロック３９２、３９４参照）。本発明の好ましい実施形態において、構文解析は以下の点で必要とされる。
【０１６５】
即ち、受信された単一のデータグラムが複数のＲＰＣコールを含む可能性があるからであり、また、ＲＰＣコールがインターネット・モビリティ・プロトコルのデータグラムにおける複数のフラグメントにまで広がっている可能性があるからである。ＲＰＣ受信作業要求５００のフォーマットの例が図６に示される。
【０１６６】
ＲＰＣ受信作業要求のそれぞれは、少なくともメイン・フラグメント５０２（１）を有し、加えて任意の数の付加的フラグメント５０２（２）〜５０２（Ｎ）を有していることもある。メイン・フラグメント５０２（１）は、作業要求構造ヘッダ５０３と、受信オーバーレイ５０４とを有している。
【０１６７】
受信オーバーレイ５０４は、インターネット・モビリティ・プロトコル・エンジン２４４によってメイン・フラグメント５０２（１）の先頭に設けられた受信オーバーレイである。この受信オーバーレイ５０４には、ｐユーザデータと呼ばれる、作業要求５００内で最初のＲＰＣコール５０６（１）を指し示す構造メンバがある。
【０１６８】
図６の例に、複数のＲＰＣコール５０６（１）、５０６（２）…５０６（８）を含む、作業要求５００が図示されている。図６の例が示すように、ＲＰＣ作業要求５００は、メモリの隣接するブロックや単一のフラグメント５０２に含まれていなくてもよい。同例において、第二フラグメント５０２（２）と第三フラグメント５０２（３）とは、リンクしたリスト中でメイン・フラグメント５０２（１）に連鎖されている。
【０１６９】
よって、上記例のＲＰＣパーサ３９４は以下の境界条件を取り扱う。
・ＲＰＣ受信要求５００それぞれが一つ以上のＲＰＣコールを含んでもよい
・一つ以上のＲＰＣコール５０６が、単一のフラグメント５０２中に存在してもよい
・ＲＰＣコール５０６それぞれが、フラグメント５０２中に完全に含まれていてもよい
・ＲＰＣコール５０６それぞれは、一つ以上のフラグメント５０２にまたがっていてもよい
【０１７０】
図７は、ＲＰＣ受信作業要求５００を解析するＲＰＣ構文解析部３９４を例示している。本例において、ＲＰＣ構文解析部３９４は作業要求中の第一フラグメント５０２（１）を取得し、該フラグメント中の第一ＲＰＣコール５０６（１）を取得し、そしてＲＰＣコールを解析する。構文解析部３９４はＲＰＣ受信作業要求５００中を進んで、ＲＰＣコール５０６それぞれを処理していく。
【０１７１】
ＲＰＣ受信作業要求５００のフラグメント５０２（１）の残りのフラグメント・バイト数が、ＲＰＣヘッダ５０３のサイズよりも多い場合、構文解析部３９４は、ＲＰＣコールが完全にＲＰＣフラグメント５０２に含まれていて、処理を実行してもよいかどうかを判定する（該判定は、ＲＰＣコールの長さが残りのフラグメント・バイト数より大きいかどうかをテストすることでなされてもよい）。
【０１７２】
ＲＰＣコールの種類が連鎖例外である場合、ＲＰＣコールはＲＰＣ構文解析部３９４のアップデートを行うことになる。プロキシ・サーバ２２４において、連鎖例外であるＲＰＣコールは「データグラム送信」と「ストリーム送信」だけである。この連鎖例外プロシージャによって、ＲＰＣエンジンは、ＲＰＣ送信コールのためにメモリ記述子リストを共に連鎖することによるフラグメントコピーを避けることができる。
【０１７３】
構文解析部３９４がＲＰＣコールの種類を判別すると、ＲＰＣ情報の始めへのポインタは、実行のためにＲＰＣエンジン２４０へと転送される。ＲＰＣエンジンは、実行のために全てのＴＤＩプロシージャ・コールにそれぞれ別の優先順位をつける。最も優先度の高いコールは、ＲＰＣディスパッチャ３９５へ転送され、直ちに処理される。これより下の優先順位のコールは、後に処理されるために全てディスパッチ・キュー５１０にディスパッチされる。ディスパッチ・キュー５１０はそれぞれ離散的な優先度を表わしている。
【０１７４】
本実施形態では、モバイル・アプリケーションは、「オープンアドレス」オブジェクト及び「オープン接続」オブジェクト機能を、他のＴＤＩネットワーキング機能を実行する前に呼び出す。よってシステムは、「オープンアドレス」オブジェクト及び「オープン接続」オブジェクトの呼び出し中に、アプリケーションレベルの優先順位を割り当てることになる。例示の実施形態では、アドレス又は接続オブジェクトに優先順位が付けられると、該オブジェクトに関連する全てのコールが、その割り当てられた優先順位中に実行される。
【０１７５】
例えば、ＲＰＣコールがＴＤＩオープンアドレスオブジェクト要求あるいはＴＤＩオープン接続オブジェクト要求である場合、該コールは直ちに実行されるべくＲＰＣディスパッチャ３９５に送られる。オープンアドレス及びオープン接続オブジェクトＲＰＣコールにより、上記の接続示唆中に行われる設定要求の間に設定マネージャ２２８からもたらされる情報との対応に用いられる、処理ＩＤあるいは処理名へのアクセスが可能になる。該処理ＩＤあるいは処理名は、アドレスあるいは接続オブジェクトの設定を得るために用いられる。
【０１７６】
本発明の好ましい実施形態では、全てのＲＰＣコールは、パラメータとして少なくともアドレスオブジェクト又は接続オブジェクトを有している。コールが実行されると、そのオブジェクトに割り当てられた優先度が、ＲＰＣコールの優先度とされる。アドレスあるいは接続オブジェクトに割り当てられた設定により、実行される、対応するＲＰＣコール全ての優先度が決定される。例えば、割り当てられた優先度が「高」の場合、ディスパッチ・キュー５１０にディスパッチされることなく、全てのＲＰＣコールが直ちに実行される。割り当てられた優先度が「１」の場合、全てのＲＰＣコールが、ディスパッチ・キュー５１０（１）に加えられる。
【０１７７】
再度図５を参照すると、「結合作業処理」タスク３６４の処理が、予定された結合作業量の実行を完了すると（判定ブロック４０４）、ディスパッチ・キューがサービスを要求しているか否かが確認される（ブロック４０６）。図８は、図７に示されるディスパッチ・キュー５１０の処理のための「ディスパッチ・キュー処理」（ブロック４０６、図６）によって実行されるステップを例示したフローチャートである。
【０１７８】
この例では、ディスパッチ・キュー５１０は優先度が最高のキュー（本例では５１０（１））から処理される（ブロック４０８）。ディスパッチ・キュー５１０にはそれぞれ重み係数が設定されている。
【０１７９】
この重み係数は、モバイル端末システム１０４とモビリティ管理サーバ１０２との結合が確立された際に、設定マネージャ２２８によって返される設定パラメータである。例を挙げれば、優先度の低いディスパッチ・キュー５１０の重み係数は４であり、優先度が中程度のディスパッチ・キュー５１０重み係数は８である。本例では、優先度の高いＲＰＣコールは解析後直ちに処理されるため、重み係数を有していない。
【０１８０】
ＲＰＣエンジン２４０’は、現在のキューより始めて、ＲＰＣコールをキューから外していき、キューが空になるか、ＲＰＣコールのキュー重み番号が処理されるまでループする（ブロック４１２−４１６）。キューから外されたＲＰＣコールそれぞれに対して、その実行のためにＲＰＣディスパッチャ３９５が呼び出される。ＲＰＣディスパッチャ３９５はモバイル端末システム１０４のプロキシとしてプロシージャ・コールを実行し、応答を要求している上記ＲＰＣコールに対するモバイル端末システムからの応答を生成する。
【０１８１】
上記ループを出た後、キューに残っている作業がまだある場合（判定ブロック４１８）、該キューが再実行を要することがマークされる（ブロック４２０）。ループを出ることで、上記システムはプロセッサを次に低い優先度のキューに移らせる（ブロック４２４、４１０）。これにより、ある特定のキューにどれだけの作業が割り振られていても、どの優先レベルにも実行される可能性が与えられることになる。システムは次のキューのサービスに移り、全てのキューが処理されるまで処理を繰り返す。
【０１８２】
全てのキューの処理が終了すると、システムは実行を要するマークがついたキューがあるか否かを判定して、もしあれば、スケジュール要求がグローバル作業キューに送られて、結合の再実行が予定されることになる。結合の再実行は、図４の「グローバル作業処理」ルーチンにおいて予定される。
【０１８３】
上記のアプローチにより、プロセッサが、処理すべき作業を有する他の結合にも実行の機会を与えることになる。キューそれぞれに重み係数を割り振ることで、システムは、モビリティ管理サーバ１０２のＣＰＵへのアクセスが優先レベルに応じて許可されるように調整されてもよい。これにより、優先度の高いキューは、先に実行されるだけでなく、さらに容易にＣＰＵにアクセスできるようになる。
【０１８４】
（モビリティ管理サーバのＲＰＣ応答）
上記では、どのように遠隔プロシージャ・コールがモバイル端末システム１０４からモビリティ管理サーバ１０２に送られて実行されるかを説明した。この型のＲＰＣコールに加え、モビリティ管理サーバ１０２のＲＰＣエンジン２４０’はＲＰＣイベントとＲＰＣ受信応答とをサポートしている。
【０１８５】
結合関連接続ピア（通常は固定端末システム１１０）の活動の結果として、ＲＰＣメッセージが非同期的に生成される。モビリティ管理サーバ１０２のＲＰＣエンジン２４０’は、ＲＰＣディスパッチャ３９５によって実行されるＲＰＣトランザクションを完了する。完了が成功したからといって、全てのＲＰＣコールが応答を要求するわけではないが、応答を要求する一部のＲＰＣコールにより、ＲＰＣディスパッチャ３９５は適切な応答を作成し、インターネット・モビリティ・プロトコル・エンジン２４４’に知らせ、そして該応答はピアのモバイル端末システム１０４に返される。ＲＰＣコールが失敗したときは、全てのＲＰＣコールが応答を生成する（上記においてＲＰＣ受信応答は例外）。
【０１８６】
ＲＰＣイベントは、結合関連接続（通常は固定端末システム１１０）によるネットワーク１０８の活動の結果として発信される。本発明の好ましい実施形態では、こうしたＲＰＣイベントメッセージはモビリティ管理サーバ１０２によってプロキシされ、モバイル端末システム１０４へ送られる。本発明の好ましい実施形態のモビリティ管理サーバ１０２は、以下のＲＰＣイベントコールをサポートする。
・切断イベント（結合特定接続ピア（通常は固定端末システム１１０）がトランスポート・レベルで切断要求を出した場合に生起する。該要求はモバイル端末システム１０４に代わってプロキシ・サーバ２２４に受信され、プロキシ・サーバ２２４は切断イベントをモバイル端末システムに送る）
・ストリーム受信イベント（結合特定接続ピア（通常は固定端末システム１１０）がストリームデータをモバイル端末システム１０４へ送る際に生起。プロキシ・サーバ２２４はモバイル端末システム１０４に代わって該データを受け取り、受信応答として該データをモバイル端末システムに送る）
・データグラム受信イベント（結合特定ポータルのいずれかが、ネットワーク・ピア（通常は固定端末システム１１０）から送られ、モビリティ管理サーバ１０２を経由してモバイル端末システム１０４へ送られることになっている、データグラムを受け取る際に生起する。プロキシ・サーバ２２４はモバイル端末システム１０４に代わって該データグラムを受け入れ、データグラム受信イベントという形で該データグラムをモバイル端末システム１０４へ転送する）
・接続イベント（結合特定リスニングポータルが、トランスポート層とモバイル端末システム１０４との終端間接続を確立しようとする際、該結合特定リスニングポータルがトランスポート層接続要求（通常は固定端末システム１１０から）を受信するときに生起する。プロキシ・サーバ２２４はモバイル端末システムに代わって接続要求を受け入れ、接続イベントＲＰＣコールを生成してモバイル端末システムに送る）
【０１８７】
図９は、ＲＰＣエンジン２４０’が、いかにしてプロキシ・サーバによって生成されたＲＰＣコールを扱うかということを示している。優先度の高いアドレスと接続オブジェクトに対し、ＲＰＣエンジン２４０’は、直ちに送信要求をインターネット・モビリティ・プロトコル・エンジン２４４’に向けてディスパッチする。該送信要求によって、ＲＰＣメッセージがピアのモバイル端末システム１０４に転送される。
【０１８８】
優先度の低いオブジェクトに対しては、インターネット・モビリティ・プロトコル・エンジン２４４の送信要求が適切な優先キュー５１０’に通知される。結合の実行が予定されていない場合、スケジュール要求もグローバルキュー３５８’に通知される。インターネット・モビリティ・プロトコルの送信要求は、最終的に、図５及び８を参照して既に説明したディスパッチ・キューの処理の際に実行される。
【０１８９】
（インターネット・モビリティ・プロトコルの例）
本発明のインターネット・モビリティ・プロトコルは、メッセージ指向で接続ベースのプロトコルであり、配信保証、（再）オーダ検出、ロス回復が可能である。さらに、他の従来型接続指向プロトコル（即ちＴＣＰ）とは違い、複数の別のデータストリームを単一のチャネルにまとめることが可能になっており、保証されたデータ、信頼性の低いデータ、そして新規のメッセージ指向で信頼性の高いデータを、単一の仮想チャネルによって同時にネットワークをトラバースさせることができる。この新たなメッセージ指向のサービスのレベルによって、インターネット・モビリティ・プロトコルのピアが所定のプログラムデータユニットを確認したときに、リクエスト部に通知が行われることになる。
【０１９０】
本発明のインターネット・モビリティ・プロトコルは、既存のネットワーク・トポロジや技術にオーバーレイできるように設計されている。下層のネットワークアーキテクチャに左右されないので、該インターネット・モビリティ・プロトコルは汎用性を有する。パケット化されたデータが二つのピアの間を行き来できさえすれば、インターネット・モビリティ・プロトコルの使用が可能である。ノードそれぞれにおけるネットワークの現在地点（ＰＯＰ）あるいはネットワーク・インフラは、物理的境界、特定のポリシー、又は帯域幅の制限がある場合を除き、データの流れに影響を与えることなく変更可能である。
【０１９１】
インターネット・モビリティ・プロトコルは上層の助けを借りて様々なソースからのデータを融合し、下層のデータグラム機能を利用して該データを行き来させる。独立したデータユニットがそれぞれ上層から来ると、インターネット・モビリティ・プロトコルは該データユニットを単一のストリームとして、その後伝送する。
【０１９２】
該データユニットは次に既存のネットワークを通じてピアに送られ、受信時に、上層の助力によって上記ストリームが非多重化されて、元の独立した複数のデータユニットに戻る。これにより、伝送時にはその都度最大限のネットワークフレームが生成されて、帯域幅の利用を最適化することができる。さらに、上記により、帯域幅を最大限利用できるようにチャネルを調整することができるという効果を奏するとともに、全てのセッションレベルの接続に適用可能なパラメータを持たせることが可能となる。
【０１９３】
あるチャネルが不十分であるといった稀なケースでも、インターネット・モビリティ・プロトコルはピア間に複数のチャネルを確立することができる。これにより、データの優先順位付けや、（下層のネットワークがサポートしていれば）サービス品質の保証も可能になる。
【０１９４】
さらに、インターネット・モビリティ・プロトコルは、動的に選択可能で保証されたレベルのサービス、あるいは信頼性の低いレベルのサービスに対しても考慮されている。例えば、伝送されるプロトコル・データ・ユニットをそれぞれ、有効期間か再伝送試行回数、もしくはその両方で制限して待機させることができる。インターネット・モビリティ・プロトコルは、どちらかの閾値に達するとデータユニットを有効期限切れとし、その後の伝送の試行から排除する。
【０１９５】
インターネット・モビリティ・プロトコルの、付加プロトコルとしてのオーバーヘッドは、可変長ヘッダの採用により最小限に抑えられている。該ヘッダのサイズはフレームの種類や任意フィールドによって決定される。該任意フィールドは、ある特定のオーダにおいて追加されて、受信側による解析を容易にし、その存在はヘッダ・フラグ・フィールドのビットによって示される。
【０１９６】
ピアによる通信に必要な他の制御及び設定情報は、全てバンド内制御チャネルを通過することができる。送信されるべき制御情報は全て、任意のアプリケーションレベルのプロトコル・データ・ユニットの前のフレームに加えられる。受信側では制御情報を処理して、次にペイロードの残りを上層に送る。
【０１９７】
エラー発生の確率が比較的高い、信頼性の低いネットワークにおける稼動が想定されているため、インターネット・モビリティ・プロトコルでは、データの完全性を保証し、ネットワークのパフォーマンスを最高まで引き出すべく、数々の技術が使われている。データの完全性を保証するため、フレッチャー・チェックサム・アルゴリズムが、誤ったフレームの検出用に使われている。このアルゴリズムは効率性と高い検出能力を買われて採用され、ビットエラーのみならずビットの並び替えも検出できる。ただし、上記アルゴリズムの代わりに他のチェックサム・アルゴリズムを採用してもよい。
【０１９８】
シーケンス番号は、オーダされたデータの配信を保証するために使われるが、インターネット・モビリティ・プロトコルにおけるシーケンス番号は、ＴＣＰの場合のようにデータのそれぞれのバイトを表わしているわけではない。一例としては、上記シーケンス番号は、最大６５５３５バイト（インターネット・モビリティ・プロトコル・ヘッダを含む）までの、データのフレームを表現している。該シーケンス番号は３２ビットなど適当な長さのものであって、制限された期間内での高い帯域幅のリンクにおいてラップアラウンドを生じさせないようにしている。
【０１９９】
上記の能力にデータの有効期限切れ機能を組み合わせたとき、再伝送（再試行）されたフレームが含んでいるデータ量が、送信側で生成された前バージョンよりも少ないことがある。フレームＩＤを設定して最新のバージョンのフレームが検知することも可能だが、本発明の好ましい実施形態ではデータが追加されることは絶対に無く、削除されたそれぞれの要素がプロトコル・データ・ユニット全体であるため、上記の手法はシーケンス保証には必ずしも必要でない。
【０２００】
一例として、インターネット・モビリティ・プロトコルは受信したある特定のフレームを、該フレームの異なったバージョンのものがいくら伝送されてきても、最初の一回目のみ処理する。新規のユーザ・ペイロードを運搬する、生成されたフレームそれぞれには、固有のシーケンス番号が割り振られる。
【０２０１】
スライディング・ウィンドウ技術の採用によってパフォーマンスが向上し、ピアにデータ受信の確認応答を要求する前に、複数のフレームを保留にできる（伝送できる）。適切なタイミングでのデータ配信を保証するため、肯定応答とタイマーベースの再伝送スキームとが採用されている。
【０２０２】
さらにチャネルの利用を最適化すべく、選択的な確認応答メカニズムが採用され、ネットワーク接続のロスが多い時間帯もしくは混雑した時間帯における、失われたフレームの迅速な再伝送と、素早い回復とが達成される。一例において、この選択的な確認応答メカニズムは、ヘッダに含まれる付加的なビットフィールドとして表わされる。
【０２０３】
輻輳回避アルゴリズムは、プロトコルをフレームの迅速な再伝送からバックオフさせるためにも用いられている。例えば、ラウンドトリップタイムは、再伝送無しで成功裏にピア間を伝送されたフレームそれぞれに対して計測することが可能である。この時間値は平均されて、再伝送タイムアウト値の基準となる。
【０２０４】
フレームが送られるごとに、それぞれのフレームに対してタイムアウトが設定される。あるフレームが実際に伝送されたにもかかわらず、該フレームに関する確認応答が受信されない場合、該フレームは再伝送される。このときタイムアウト値は上昇し、次の再伝送時間の基準となる。この再伝送タイムアウトには上限値及び下限値が設定されているので、その値は適切な範囲に収まるようになっている。
【０２０５】
また、インターネット・モビリティ・プロトコルでは、送信路と受信路とが別に扱われている。この手法は、本質的に非対称のチャネルにおいて特に有用である。ヒステリシスに基づいて、インターネット・モビリティ・プロトコルは自動的に、フレームサイズ（フラグメント化閾値）、保留中のフレーム数、再伝送時間、遅延承認時間などのパラメータを調整して、ネットワークを通じて送られる複製データの量を減少させる。
【０２０６】
インターネット・モビリティ・プロトコルによって、ノードが様々なネットワークの違った接続ポイントに移動することが可能になるため、下層のネットワークの特性（例えばフレームサイズ）が途中で変わってしまうことがあるが、この移動の結果、あるネットワークで伝送待ちだったフレームが、モバイル装置が現在接続している新しい媒体にはフィットしないこともありうる。
【０２０７】
このことに、フラグメント化が全てのネットワーク・インフラでサポートされているわけではないことを合わせて考慮して、フラグメント化はインターネット・モビリティ・プロトコルのレベルにおいて扱われる。それぞれのフレームが伝送される前に、インターネット・モビリティ・プロトコルにより、フレームが現時点でのフラグメント化閾値を越えているか否かが判断される。
【０２０８】
ちなみに、パフォーマンス向上の見地から、この値は現時点での最大伝送ユニットよりも少なくてよい（大きいフレームよりも小さいフレームの方が最終目的地まで到達する可能性が高いため）。プロトコルのオーバーヘッドを増加させることと、再伝送回数の増加とのトレードオフは、インターネット・モビリティ・プロトコルによって吟味され、全体的に再伝送を減少させるため、フレームサイズが減少させられることもある。
【０２０９】
あるフレームがフィットしていれば、該フレームは分割されずに伝送される。していなければ、該フレームはその接続で許容される最大のサイズにまで分割される。フレームが再伝送される場合、該フレームは再評価を受け、最大伝送ユニットが減少していれば、再度フラグメント化される（あるいは、もし最大伝送ユニットが増加していれば、該フレームはフラグメント化されない一個のフレームとして再送信されることもありうる）。
【０２１０】
プロトコルそのものは直交に設計されており、どちらの側からでもピアとの接続を確立、切断することができるようになっている。しかし、ある場合においては、実行される場所によってプロトコル・エンジンにおける些少な動作上の差異がいくつか存在し、特定の休止検出や接続寿命タイムアウトは片方の側からしか実行できないこともある。
【０２１１】
運営上必要な操作を可能にするため、モビリティ管理サーバ１０２上で動作するインターネット・モビリティ・プロトコル・エンジンは、休止期間の状況を把握している。モバイル端末システム１０４からの作業が何もないまま一定の期間が経過した場合、モビリティ管理サーバ１０２はセッションを終了させることができる。
【０２１２】
また、管理者が、ある特定の接続を確立するのに要する総所要時間を制限する、あるいは日時によってアクセスを拒否することが必要なときがあるが、この場合も、一例としてこうしたポリシータイマーはモビリティ管理サーバ１０２側からのみ操作できるようにしてもよい。
【０２１３】
一例として、インターネット・モビリティ・プロトコルを提供するソフトウェアは、ウィンドウズ（登録商標）ＮＴ、９ｘ、ＣＥ環境で、プラットフォームに合わせた修正を必要とすることなくコンパイルされ、動作できるものである。これを実現するために、インターネット・モビリティ・プロトコルでは、インターネット・モビリティ・プロトコル・フレームの送受信に、ネットワーク抽象層；ＮＡＬ）のサービスが採用されている。
【０２１４】
メモリ管理、キュー及びリスト管理、イベントロギング、警報システム、電力管理、セキュリティなどの他の標準的なユーティリティ機能も使われる。いくつかのランタイム・パラメータについては、エンジンがモバイル端末システム１０４に備えられているか、あるいはモビリティ管理サーバ１０２側に備えられているかによって変更される。これについて、数例を以下に示す。
・特定のタイムアウトは、モビリティ管理サーバ１０２からのみ呼び出し可能
・フレームの方向は、エコー検出用のフレームヘッダそれぞれにて示される
・モバイル端末システム１０４の設定により、着信接続の拒否が可能
・警報はモビリティ管理サーバ１０２にのみ通知される
・電力管理はモバイル端末システム１０４ではイネーブルにされるが、モビリティ管理サーバ１０２では必ずしも必要でない
【０２１５】
インターネット・モビリティ・プロトコルのインターフェイスは、Ｃコーラブルでプラットフォームに依存しない標準的なＡＰＩ機能をほんの少数有し、作業（上記の標準的なユーティリティ機能以外）を予定する、ＯＳ特化型の単一の機能を必要とする構成でもよい。ローカルクライアントとの通信は、定義された作業オブジェクト（作業要求）の利用によって可能になる。作業要素それぞれの完了通知は、作業オブジェクトの一部として特定されたオプションの完了コールバックルーチンを通じて、要求エンティティに通知を行うことによって、効果的に達成することができる。
【０２１６】
インターネット・モビリティ・プロトコル・エンジン自体はキューベースのものである。ローカルクライアントからの作業要素は、ＦＩＦＯオーダにしたがってグローバル作業キューに追加されるが、これは、ローカルクライアントが、「ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔｗｏｒｋ（）」などの標準的なインターネット・モビリティ・プロトコル機能を呼び出すことによってなされる。
【０２１７】
続いて、インターネット・モビリティ・プロトコル内のスケジューリング機能が該作業を除去し、適切な機能に対してディスパッチする。待機機能とスケジューリング機能を組み合わせることでＯＳのアーキテクチャ間の差を感じさせなくするので、プロトコル・エンジンが、スレッドベースのシステム（例えばウィンドウズ（登録商標）ＮＴ）や同期式のシステム（例えばマイクロソフト・ウィンドウズ（登録商標）９ｘやウィンドウズ（登録商標）ＣＥ）で動作することが可能になる。優先度に関するスキームを待機機能の上にオーバーレイすることができるので、（下の層がサポートしていれば）サービス品質を保証することができる。
【０２１８】
ネットワークの視点から見ると、インターネット・モビリティ・プロトコルは、データのコピーや移動を減らすべく、分散−集結技術を利用している。伝送はそれぞれフラグメントのリストとしてＮＡＬに送られ、ネットワーク層のトランスポートによって融合される。トランスポート・プロトコル自体が分散−集結技術をサポートしている場合、フラグメントリストは上記トランスポートを通じて転送され、媒体アクセス層ドライバあるいはハードウェアによってアセンブルされる。
【０２１９】
さらに、上記技術を拡張して、プロトコルスタックのどのレベルにおいても、いかなるプロトコルラッパーの挿入や消去を行うことも可能である。フレームの受信は、ＮＡＬ層により、ＮＡＬ登録処理時に指定された特定の入口点においてインターネット・モビリティ・プロトコルをコールバックすることで通知される。
【０２２０】
（インターネット・モビリティ・プロトコル・エンジンのエントリポイントの例）
例示の実施形態におけるインターネット・モビリティ・プロトコルは、該プロトコルのスタートアップ及びシャットダウン行動を管理する、４つの共通エントリポイントを有している。以下に示されるのがこれらのプロシージャである。
１．Internet Mobility ProtocolCreate（）
２．Internet Mobility ProtocolRun（）
３．Internet Mobility ProtocolHalt（）
４．Internet Mobility ProtocolUnload（）
【０２２１】
（Internet Mobility ProtocolCreate（）の例）
Internet Mobility ProtocolCreate（）機能は、ブートサブシステムによって呼び出され、インターネット・モビリティ・プロトコルを初期化する。この第一フェイズ中に、作業の処理を開始するのに必要なリソース全てが所得され、初期化されなければならない。該フェイズの終了時、エンジンは、システムの他の層からの作業をすぐに受け入れ可能な状態である必要がある。このとき、インターネット・モビリティ・プロトコルはグローバル設定テーブルを初期化するが、このために、インターネット・モビリティ・プロトコルは、設定マネージャ２２８のサービスを利用して該テーブルを設定する。
【０２２２】
次に、インターネット・モビリティ・プロトコルは、サスペンド及びレジューム通知機能をＡＰＭハンドラに登録する。一例ではこれらの機能はモバイル端末システム１０４の側からのみ呼び出し可能であるが、他の例として、動作中にモビリティ管理サーバ１０２がサスペンドできるようにするのが望ましいこともある。続いて、グローバル作業キュー、グローバルＮＡＬポータルリストなど他の作業用記憶域がメモリプールから割り当てられる。
【０２２３】
必要なランタイムメモリの最大量を制限し、インターネット・モビリティ・プロトコルのハンドルの固有性を保証するため、インターネット・モビリティ・プロトコルは、ハンドル生成用の２段配列構成を採用している。グローバル接続配列テーブルのサイズは、システムが設定する同時接続の最大数によって決まり、この時点で割り当てられる。全てのグローバル記憶域が割り当てられ、初期化されると、グローバル・インターネット・モビリティ・プロトコルの状態が、＿ＳＴＡＴＥ＿ＩＮＩＴＩＡＬＩＺＥ＿となる。
【０２２４】
（Internet Mobility ProtocolRun（）の例）
Internet Mobility ProtocolRun（）機能は、全てのサブシステムが初期化された後で呼び出され、インターネット・モビリティ・プロトコルのサブシステムに、待機中の作業をどれでも処理し始めてよいことを通知する。これが、一般的な動作状況におけるインターネット・モビリティ・プロトコル・エンジンの通常の状態である。該エンジンを動作状態にする前に、いくつかの第二パス初期化ステップがこの時点で実行される。
【０２２５】
インターネット・モビリティ・プロトコルは、ネットワーク通信が、任意のインターフェイスのどれを通じてでも実行されるようにする。初期化ステップの間に、インターネット・モビリティ・プロトコル−ＮＡＬ間のインターフェイス用の記憶域が割り当てられるので、インターネット・モビリティ・プロトコルはグローバルポータルリスト中を横断して、ＮＡＬの全てのリスナをスタートさせることができる。一例として、この動作は２つのステップを含んだ以下の処理のようになる。
・インターネット・モビリティ・プロトコルは、ＮＡＬ層に、初期化中に供給される設定に基づいたポータルを結びつけて（ｂｉｎｄ）オープンし、
・インターネット・モビリティ・プロトコルは、次に、Internet Mobility ProtocolＲＣＶＦＲＯＭＣＢコールバックを登録して、受信したフレームの処理を始める準備ができたことを、ＮＡＬ層に通知する。
・引き続き、ローカル持続識別子（ＰＩＤ）が初期化される。グローバル・インターネット・モビリティ・プロトコルの状態は、＿ＳＴＡＴＥ＿ＲＵＮ＿に変わる。
【０２２６】
（Internet Mobility ProtocolHalt（）の例）
Internet Mobility ProtocolHalt（）機能は、システムがシャットダウンしたことをエンジンに警告するために呼びだされる。動作中に得られたリソースは、この機能から戻る前に全て開放される。インターネット・モビリティ・プロトコルの全てのセッションは、管理用に設定された理由コードによって異常終了する。エンジンが＿ＳＴＡＴＥ＿ＨＡＬＴＥＤ＿状態になると、それ以降、他の層からの作業は受け付けられず、他の層に通知されることも無い。
【０２２７】
（Internet Mobility ProtocolUnload（）の例）
Internet Mobility ProtocolUnload（）機能は、シャットダウン処理の第二フェイズである。これが、復帰以前に、割り当てられたシステムリソースをエンジンが解放する最後の機会となる。エンジンがこの機能から戻ると、システム自体が停止するので、これ以上の作業は実行されない。
【０２２８】
（インターネット・モビリティ・プロトコル・ハンドルの例）
少なくともいくつかの例においては、メモリ（インターネット・モビリティ・プロトコル状態情報を記憶）のアドレスを、インターネット・モビリティ・プロトコルの接続を記述するトークンとして用いるだけでは不十分である。これは主に、短い期間のうちに、ある接続が終了して別の新しい接続が開始される可能性のためである。メモリアロケータが、別の接続に前のものと同じアドレスを再配分してしまう可能性が高く、この値が前の接続と新しい接続との両方を示すことになってしまう。
【０２２９】
元々のピアが、（電源が切られていたり、サスペンドしていたり、圏外にあったりなどで）セッションの終了を認識しなかった場合、前のセッションのフレームを新しいセッションの方に送ってしまうこともあり得る。ＴＣＰの場合はこれが起こり、ピアのＩＰアドレスが同じ場合、新しいセッションを生成するためにリセットが行われる。これを避けるため、インターネット・モビリティ・プロトコルは製造ハンドルを採用している。該ハンドルは２列のインデックスによって形成され、独自性を保つため一回限りのものである。テーブルは以下のようなレイアウトとなっている。
【０２３０】
テーブル１：接続オブジェクトの配列を指すポインタの配列
【０２３１】
テーブル２：インターネット・モビリティ・プロトコル制御ブロックを指す、実ポインタを含む接続オブジェクトの配列
【０２３２】
この技術により、初期化期間に割り当てられるメモリの量が最小化される。テーブル１は、スタートアップの際にサイズが決められ、割り当てがなされる。これにより、モバイル端末システム１０４の側では、少量のメモリの割り当てが可能になる（モビリティ管理サーバ１０２側でテーブル１が割り当てを要求するメモリは、サーバが多くの接続を有しているため少し大きなものになる）。
【０２３３】
テーブル１は必要時に設定される。接続要求が出されると、インターネット・モビリティ・プロトコルは、テーブル１内でテーブル２への有効なポインタを探す。エントリポイントが見つからない場合、インターネット・モビリティ・プロトコルは、新規のテーブル２に２５６個の接続オブジェクトを割り当て、テーブル２へのポインタを、テーブル１の適切なスロットに記録する。
【０２３４】
次に、プロトコル・エンジンはテーブル２を初期化し、新しく生成されたテーブルからの接続オブジェクトを割り当てて、製造ハンドルへ戻る。他のセッションが要求された場合、インターネット・モビリティ・プロトコルは再度テーブル１中をサーチして、テーブル２への有効なポインタを見つけ、該セッション用の次の接続オブジェクトを割り当てる。この作業は、以下の二つの状態のうちのどちらかになるまで続けられる。
・テーブル２から全ての接続オブジェクトが無くなった場合、新たにテーブル２が割り当てられ、初期化されて、該テーブル２を示すポインタが、テーブル１の次に利用可能なスロットに設定される。
・全ての接続オブジェクトが特定のテーブル２のインスタンスに開放され、全ての要素がある特定の期間使用されなかった場合、テーブル２の上記インスタンスにおける記憶域が開放されてメモリプールに戻され、テーブル１の関連しているポインタはゼロにされて、次の接続要求が開始された際、該入口が使用可能であることを示すようになる（テーブル２の他のインスタンスで、利用可能な接続オブジェクトがない場合に限る）。
【０２３５】
二つのグローバルカウンタは、割り当てられる接続の総数を制限できるようにするために維持されている。片方のグローバルカウンタは現時点でアクティブな接続を数え、もう片方のカウンタは、割り当てられていない接続オブジェクトの数を把握する。
【０２３６】
さらに、第二のカウンタは、任意に設定された制限まで生成可能な接続オブジェクトの総数の管理も行う。新規のテーブル２が割り当てられると、該カウンタは、該新規のテーブルが表現するオブジェクトの数を把握するため、下方に調整される。反対側では、インターネット・モビリティ・プロトコルがテーブル２のインスタンスをメモリプールに開放するときに、カウンタは、開放された接続オブジェクトの数を合わせて上方修正される。
【０２３７】
（ワークフローの例）
Internet Mobility ProtocolRequestWork（）機能によって、作業はローカルクライアントから要求される。該作業が検査され、グローバル作業キューに加えられると、Internet Mobility ProtocolQueueEligible（）機能が呼び出される。スレッド化された環境であれば、インターネット・モビリティ・プロトコルのワーカースレッドに信号が送られ（適合マークがつけられ）、制御は直ちに呼び出しエンティティへと戻る。同期的な環境であれば、グローバル作業キューが直ちに実行されて、要求された作業はいかなるものであっても処理される。どちらの場合でも、Internet Mobility ProtocolProcessWork（）機能が実行されることになる。これが作業処理のためのメインディスパッチ機能である。
【０２３８】
例示の実施形態では、グローバルキューからの作業をディスパッチできるのが一回に一つのスレッドのみの場合があり、再入を防ぐべくグローバルセマフォが用いられてもよい。プライベートなインターネット・モビリティ・プロトコルの作業では、Internet Mobility ProtocolRequestWork（）機能を使用せず、直接グローバル作業キューに作業を送ることができる。
【０２３９】
ＳＥＮＤタイプの作業オブジェクトでは、特殊な場合が想定される。信頼性の低いデータグラムのセマンティクスが保たれていることを保証するため、ＳＥＮＤタイプの作業オブジェクトをそれぞれ、有効期限あるいは再試行カウントを伴って待機させることができる。作業は該有効期限に基づいて寿命を算定される。
【０２４０】
このような所定のタイムアウトが生じた場合、作業オブジェクトは接続特定キューから除かれ、エラー状態で完了する。ＳＥＮＤオブジェクトが既にデータパスに融合されている場合、プロトコルは、再試行カウントが設定されたどのＳＥＮＤオブジェクトでも、除去を許可する。再試行カウントを超過した場合、該オブジェクトは、特定のフレームを形成する要素のリストから外され、適当なエラー状態を示しつつリクエスタへ戻される。
【０２４１】
（接続スタートアップの例）
インターネット・モビリティ・プロトコルは、ピア間の接続を確立する非常に効率的なメカニズムを有している。接続の確認は、ピア間で最低３フレームをやり取りすることでなされる。開始側は、そのピアにＩＭＰ  ＳＹＮＣフレームを送って接続確立が要求されていることを警告する。受け入れ側は、ＩＭＰ  ＥＳＴＡＢＬＩＳＨフレームを送って接続受け入れを確認するか、あるいはＩＭＰ  ＡＢＯＲＴフレームを送ることで、接続要求が拒否されたことをピアに警告する。ユーザに接続拒否の理由を理解しやすくするため、理由及び状態コードが、ＩＭＰ  ＡＢＯＲＴフレームに含まれる形で送られる。接続が許可されると、確認応答フレーム（プロトコル・データ・ユニット及び制御データがふくまれていることもある）が送られて、受け入れ側に転送され、確立フレームの受信が確認される。
【０２４２】
ネットワークのトラフィックを最小化するため、プロトコルは、ユーザ及び制御データを、接続スタートアップ時の最初のハンドシェーク機構に含まれるような構成にすることができる。この構成は、セキュリティが保障されていない環境や、同じデータパスでセキュリティ用の認証が二重に行われたり、暗号化処理が同じデータパスで行われたりすることによるパフォーマンスの低下を避けるよう、インターネット・モビリティ・プロトコルが調整されているというような、セキュリティが下層で扱われている環境において使用される。
【０２４３】
（データ転送の例）
インターネット・モビリティ・プロトコルは、フレームがネットワークに配信されたことを、ＮＡＬからの通知によって検知する。インターネット・モビリティ・プロトコルは、当該ネットワークリンクが絶えずフロー制御されているか否かを上記メトリクスによって判定するので、当初の要求が完了されるまで同じフレームを再伝送することはない。しかし、ネットワークドライバによっては、フレームの伝送について、誤って、該フレームをネットワークに送る前に配信を示唆してしまうものもある。セマフォの利用により、インターネット・モビリティ・プロトコル層はこれを検知し、当初の要求についてＮＡＬが返答するまでは、他のデータグラムを送信しない。
【０２４４】
フレームがインターネット・モビリティ・プロトコルに受信されると、該フレームは迅速に検査されて、適切な接続キューに加えられる。該フレームが、インターネット・モビリティ・プロトコルがその最終目的地を識別するのに足る情報を有していない場合、該フレームは、それを受信したインターネット・モビリティ・プロトコル・ソケット・キューに加えられ、該ソケット・キューは、続く処理のためにグローバル作業キューに加えられる。この最初の逆多重化により、受信した作業は、処理オーバーヘッドが限定された状態で、迅速に拡散させられる。
【０２４５】
（黙認の例）
再伝送時のネットワーク帯域幅及びモビリティ管理サーバ１０２の処理に要する電力の最小化のため、プロトコルは、モビリティ管理サーバ１０２が接続を「黙認」できるようにする。ユーザによる設定が可能な期間の後、モビリティ管理サーバ１０２は、対応するモバイル端末システム１０４から通知が無ければ、特定の接続へのフレームの再伝送を停止する。この時、モビリティ管理サーバ１０２は、モバイル端末システム１０４が通信できない状態（圏外、サスペンドなど）であると仮定し、接続を休止状態にする。該接続へのこの後の作業は全て、後の配信のために記憶される。該接続は、以下の状況のいずれかが満たされない限り、同じ状態にとどまり続ける。
・モビリティ管理サーバ１０２がモバイル端末システム１０４からフレームを受信し、接続を本来の状態に戻す、
・接続寿命タイムアウトの期限が切れる、
・休止タイムアウトの期限が切れる、又は
・システム管理者によって接続が中止される
【０２４６】
モビリティ管理サーバ１０２が、モバイル端末システム１０４からフレームを受信し、中断された所から接続が再開された場合、該接続で待機していた作業は全て転送され、状態が再同期化される。これ以外の場合、再接続がなされると、モバイル端末システム１０４には以前の接続の終了が通知され、モバイル端末システム１０４に送られることを待機していた作業は破棄される。
【０２４７】
（接続及び送信要求の例）
図１０Ａ〜１０Ｃは、インターネット・モビリティ・エンジン２４４によって生成される接続及び送信要求ロジックを例示する、フローチャートを形成している。ＲＰＣエンジン２４０からの命令を受信すると、インターネット・モビリティ・プロトコル・エンジン２４４は、該命令が「接続」要求かどうかを判定する（判定ブロック６０２）。該命令が「接続」要求であれば、エンジン２４４は、接続リソースの割り当てが可能かどうかを判断する（判定ブロック６０３）。十分な接続リソースが割り当てられない場合（判定ブロック６０３で「ノー」である場合）、エンジン２４４はエラーを宣言して（ブロック６０３ａ）応答する。接続リソースの割り当てが可能であれば、エンジン２４４は状態設定処理を行って、接続要求の処理に備える（ブロック６０３ｂ）。
【０２４８】
接続その他の要求に対し、エンジン２４４は該接続あるいは送信要求を待機させ、呼び出しを実行しているアプリケーションに応答する前に、グローバルイベントに通知する（ブロック６０４）。
【０２４９】
インターネット・モビリティ・プロトコルのグローバル要求キューからの接続あるいは送信要求をディスパッチするために、エンジン２４４はまず、保留されている作業の有無を判定する（判定ブロック６０５）。保留されている作業が無ければ（判定ブロック６０５で「ノー」である場合）、エンジン２４４は、図１０Ｃのブロック６２５に移って、接続用の作業を待機させるため、アプリケーションからの応答を待つ（ブロック６０５Ａ）。保留されている作業があれば（判定ブロック６０５で「イエス」の場合）、エンジン２４４は現在の状態が確立されているか否かを判定する（ブロック６０６）。
【０２５０】
状態が確立されている場合（判定ブロック６０６で「イエス」の場合）、エンジン２４４は状態確立への移行のためのステップを飛ばして、図１０Ｂの判定ブロック６１５に移る（ブロック６０６ａ）。状態が確立されていない場合、エンジン２４４は、状態確立のための一連のステップを実行する必要がある（判定ブロック６０６で「ノー」である場合）。
【０２５１】
状態確立に移行するために、エンジン２４４はまず、そのピアのアドレスが既知かどうかを判定する（判定ブロック６０７）。既知でなければ、エンジン２４４は作業をさらに待機させ、図１０Ｃのブロック６２５に移って、ピアのアドレスが来るのを待つ（ブロック６０７ａ）。
【０２５２】
ピアのアドレスが既知の場合（判定ブロック６０７で「イエス」の場合）、エンジン２４４は次に、必要なセキュリティコンテキストが取得されているかどうかを判定する（判定ブロック６０８）。取得されていない場合、エンジン２４４は作業をさらに待機させ、図１０Ｃのブロック６２５に移って、セキュリティコンテキストが来るのを待つ必要がある（ブロック６０７ａ）。
【０２５３】
セキュリティコンテキストが既に取得されている場合（判定ブロック６０８で「イエス」の場合）、エンジン２４４は「状態保留」状態を宣言して（ブロック６０８ｂ）、インターネット・モビリティ・プロトコルの同期フレームを送信し（ブロック６０９）、再伝送タイマーをスタートさせる（ブロック６１０）。
【０２５４】
エンジン２４４は、対応する確立フレームが受信されたかどうかを判定する（ブロック６１１）。受信されていない場合（判定ブロック６１１で「ノー」の場合）、エンジン２４４は、再伝送時間の期限が来たかどうかを判定する（判定ブロック６１２）。再伝送時間の期限が来ていない場合（判定ブロック６１２で「ノー」の場合）、エンジン２４４は待機し、続いてステップ６２５に移ってもよい（ブロック６１３）。
【０２５５】
最終的に、確立フレームが受信されず（ブロック６１１で判定）、再伝送時間の期限が全て切れた（判定ブロック６１４）場合、接続は中止されてもよい（ブロック６１４ａ）。結局確立フレームが受信された場合（判定ブロック６１１で「イエス」の場合）、エンジン２４４は「状態確立」状態を宣言する（ブロック６１１ａ）。
【０２５６】
状態確立がなされると、エンジン２４４は新規の接続の認証がなされているかどうかを判定する（判定ブロック６１５）。なされていない場合、エンジン２４４は待機し、ステップ６２５へと移ってよい（ブロック６１６）。接続の認証がなされている場合（判定ブロック６１５で「イエス」の場合）、エンジン２４４は認証が成功したかどうかを判定する（判定ブロック６１７）。
【０２５７】
成功していない場合（判定ブロック６１７で「ノー」の場合）接続は中止される（ブロック６１４ａ）。成功している場合、エンジン２４４は、ピア伝送ウィンドウがフルになっているかどうかを判定する（判定ブロック６１８）。フルになっていれば（判定ブロック６１８で「イエス」の場合）、エンジン２４４は確認応答を待ち、ステップ６２５に進む（判定ブロック６１９）。
【０２５８】
ウィンドウがフルになっていなければ（判定ブロック６１８で「ノー」の場合）、エンジン２４４はインターネット・モビリティ・プロトコル・データフレームを生成し（ブロック６２０）、送信する（ブロック６２１）。次に、エンジン２４４は再伝送タイマーがスタートしているかどうかを判定する（判定ブロック６２２）。
【０２５９】
していない場合、エンジン２４４は再伝送タイマーをスタートさせる（ブロック６２３）。エンジン２４４は、それ以上送信するデータが無くなるまで（判定ブロック６２４で判断される）、ブロック６１８〜６２３を繰り返す。そして、エンジン２４４はスリープモードに入ってさらに作業が来るのを待ち、グローバルディスパッチャに戻る（ブロック６２５）。
【０２６０】
（中止の例）
図１１は、接続を中止するためにインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示したフローチャートである。「接続中止」要求を受けて（ブロック６２６）、該エンジンは該要求をグローバル作業キューに加え、呼び出しを行っているアプリケーションに返答する（ブロック６２６ａ）。
【０２６１】
中止要求は最終的に、実行のため、インターネット・モビリティ・プロトコルの処理グローバル作業キューからディスパッチされる（ブロック６２７）。エンジン２４４は中止要求を調べて、該要求が緊急のものであるか、あるいは余裕のあるものであるかを判定する（判定ブロック６２８）。
【０２６２】
緊急のものの場合（判定ブロック６２８で「中止」の場合）、エンジン２４４は直ちに接続を中止する（ブロック６２９）。余裕があるものであれば（判定ブロック６２８で「余裕」の場合）、エンジン２４４は「状態クローズ」状態を宣言し（ブロック６２８ａ）、インターネット・モビリティ・プロトコルの「モーティス（Ｍｏｒｔｉｓ）」フレームを送信し（ブロック６３０）、ピアに接続がクローズされることを示唆する。
【０２６３】
次に、エンジン２４４は「モーティス」状態を宣言し（ブロック６３０ａ）、再伝送タイマーをスタートさせる（ブロック６３１）。エンジン２４４は、ピアから「ポスト・モーテム」フレームが応答されたかどうかを判定する（判定ブロック６３２）。応答されていなければ（判定ブロック６３２で「ノー」の場合）、エンジン２４４は、再伝送タイマーが時間切れになっているか否かを判定する（判定ブロック６３３）。
【０２６４】
まだ時間切れになっていない場合（判定ブロック６３３で「ノー」の場合）、エンジン２４４は待機し、ステップ６３７へ進む（ブロック６３４）。再伝送タイマーが時間切れになっている場合（判定ブロック６３３で「イエス」の場合）、エンジン２４４は総再伝送時間の期限が切れているかどうかを判定する（判定ブロック６３５）。
【０２６５】
まだ切れていない場合（判定ブロック６３５で「ノー」の場合）、ブロック６３０に戻り、モーティスフレームを再送する。すでに総再伝送時間の期限が切れている場合（判定ブロック６３５で「イエス」の場合）、エンジン２４４は直ちに接続を中止する（ブロック６３５ａ）。
【０２６６】
「ポスト・モーテム」応答フレームがピアから受信されると（判定ブロック６３２で「イエス」）、エンジン２４４は「ポスト・モーテム」状態を宣言して（ブロック６３２ａ）、接続リソースを開放し（ブロック６３６）、スリープ状態に戻ってさらに作業を待つ（ブロック６３７）。
【０２６７】
（再伝送の例）
図１２は、インターネット・モビリティ・プロトコル・エンジン２４４が実行する「再伝送」イベントロジックの例を示している。再伝送タイマーが時間切れを迎える（ブロック６５０）と、エンジン２４４は、保留中のフレームがあるかどうかを判定する（判定ブロック６５１）。保留中のフレームがなければ（判定ブロック６５１で「ノー」の場合）、エンジン２４４はタイマーを破棄して（ブロック６５２）スリープ状態に戻る（ブロック６６０）。
【０２６８】
逆に保留中のフレームがあれば（判定ブロック６５１で「イエス」の場合）、エンジン２４４は、再伝送期間全体（ｅｎｔｉｒｅ）が終了したかどうかを判定する（判定ブロック６５３）。まだ終了していなければ（判定ブロック６５３で「ノー」の場合）、処理は時間差のためにスリープ状態に戻る（ブロック６５４）。
【０２６９】
既に終了していれば（判定ブロック６５３で「イエス」の場合）、エンジン２４４は、総ての再伝送期間が終了したかどうかを判定する（判定ブロック６５５）。既に終了しており（判定ブロック６５５で「イエス」）、このイベントがモビリティ管理サーバのエンジン２４４’（モバイル端末システムのエンジン２４４に対応）で実行されている場合、休眠状態が宣言される（判定ブロック６５６、ブロック６５６ａ）。同じ状態で、モバイル端末システム１０４において実行されるインターネット・モビリティ・プロトコル・エンジン２４４は、接続を中止する（ブロック６５６ｂ）。
【０２７０】
総ての再伝送期間がまだ終了していない場合（判定ブロック６５５で「ノー」の場合）、エンジン２４４はフレームを再処理して時間切れのデータを除去し（ブロック６５７）、それを再転送し（ブロック６５８）、再転送タイマーをそのまま再始動させる（ブロック６５９）。そして処理は休眠状態に入り（ブロック６６０）、次のイベントを待つ。
【０２７１】
（インターネット・モビリティ・プロトコルのＰＤＵの期限切れの例）
図１２のブロック６５７において、要求を出している上層のインターフェイスが、結合しているピアに送られるプロトコル・データ・ユニット（つまりＳＥＮＤ作業要求）５０６の期限切れに関するタイムアウトあるいは再試行カウントを特定することが可能になる。この機能により、インターネット・モビリティ・プロトコル・エンジン２４４は、信頼性の低いデータのセマンティクス維持、再伝送されたデータからの信頼性の低いデータの除去など、他の機能も果たせるようになる。
【０２７２】
上層からのＰＤＵ（プロトコル・データ・ユニット）それぞれは、最終的にインターネット・モビリティ・プロトコル・エンジン２４４によってコーリシングされる、それぞれの要素に対する有効期限タイムアウト及び／又は再試行カウントを、特定することができる。有効期限タイムアウト及び／又は再試行カウント（アプリケーションによってはユーザによって特定可能）は、エンジン２４４による再伝送の前に、どのＰＤＵ５０６が、転送されずにフレームから除去されるべきかを決定するために使われる。
【０２７３】
ＰＤＵ５０６に関わる有効期限タイムアウトは、ＰＤＵそれぞれが伝送に際して考慮すべき、相対期間を特定する。実行依頼の間、Internet Mobility ProtocolRequestWork機能によって有効期限の値がチェックされる。該値が０で無い場合、時期タイマーは初期化される。
【０２７４】
次に、要求されたデータは、結合しているピアに送られる他のデータと同じキューに加えられる。あるＰＤＵ５０６が、有効期限パラメータが特定する期間よりも長くキューにある場合、該キューを処理する次イベントの間に、有効期限の切れた該（全ての）ＰＤＵは除去され、フレームの再伝送時に再伝送されるのではなく、ローカルに「タイムアウトによる失敗」のステータスコードをもって完了する。このアルゴリズムにより、ピアへの伝送のために待機している信頼性の低いデータが古くなること、及び／又は際限なくシステムリソースを消費することを防ぐ。
【０２７５】
図１２Ａの例において、少なくとも３つの独立したＰＤＵ５０６が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン２４４でキューに加わっている。ＰＤＵ５０６（１）は有効期限を持たず、要求に対するタイムアウトが無い。ＰＤＵ５０６（２）は、２秒の有効期間を持ち、時系列的にＰＤＵ５０６（１）の後に並んでいる。ＰＤＵ５０６（ｎ）は、２．５秒の有効期間を持ち、時系列的にＰＤＵ５０６（２）の後に並んでいる。
【０２７６】
ＰＤＵ５０６（ｎ）の待機が、キューの処理をさせ、ＰＤＵ５０６（２）の有効期間を経過させる最初のイベントであるため、ＰＤＵ５０６（２）は作業キューから外され、ローカルに完了されて、ＰＤＵ５０６（ｎ）がリストに加えられる。有効期間がＰＤＵ５０６（ｎ）に設定されている場合、ここまでの一連のイベントが繰り返される。作業キューを操作するいかなるイベント（キューに加える、キューから外す等）によっても、古くなったＰＤＵが除去され、完了される。
【０２７７】
上記のように、ＰＤＵ５０６はインターネット・モビリティ・プロトコル・エンジン２４４の伝送ロジックによって融合され、単一のデータストリームにフォーマットされる。独立した作業要素それぞれは、有効期限タイムアウトによって期限切れになっていなければ、集められてインターネット・モビリティ・プロトコル・データフレームを形成する。インターネット・モビリティ・プロトコル・エンジン２４４は、最終的にこれらのＰＤＵ５０６をピアに送り、関係するフレームをフレーム保留リストに加える。
【０２７８】
ピアが一定期間内に該フレームを認識しなかった場合（図１２の再伝送アルゴリズムを参照）、フレームは再伝送され、失われたかあるいは破損したパケットを回復する。再伝送の直前、フレームを形成するＰＤＵリストは、再試行カウントを伴った要求が待機しているかどうかを判定すべく反復される。該再試行カウントが０ではなく、０に向かって減少してゆく場合、ＰＤＵ５０６はリストから外され、フレームヘッダはデータの消去を示すように修正される。
【０２７９】
このように、古くなったデータ、低信頼のデータ、あるいは独自の再伝送ポリシーを持つアプリケーションは、エンジン２４４’の再伝送アルゴリズムによって負担をかけられることがない。
【０２８０】
図１２Ｂの例においても、少なくとも３つの独立したＰＤＵ５０６が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン２４４でキューに加わっている。ＰＤＵ５０６（１）は再試行カウント無しでキューに加わっているが、これは、継続的な再伝送の試行と、保証された配送レベルのサービスとを示している。
【０２８１】
ＰＤＵ５０２（２）は再試行カウントが１でキューに加わり、時系列的にＰＤＵ５０６（１）の後に並ぶ。ＰＤＵ５０６（ｎ）は、ある程度の時間が経過してからＰＤＵ５０２（２）より後ろに加わる。この時点で、いくつかの外部イベント（例えば上層融合・タイマー）が、エンジン２４４’に、インターネット・モビリティ・プロトコル・データフレーム５００を生成するための作業キューから十分なＰＤＵ５０６を集めて新しいフレームを生成するための論理を送信させる。
【０２８２】
フレームヘッダ５０３が求められ、これに、フレームの最初の伝送であることを示すための、再試行ＩＤとして０が付けられる。続いてフレームは、ネットワークへの後の伝送用に、ＮＡＬ層へと送られる。このときに再伝送タイマーがスタートするが、これは、当該のフレームがペイロードを含んでいるためである。
【０２８３】
説明を容易にするため、再伝送タイマーが期限を迎える前に、様々な理由でピアからの確認応答が受け取られなかったと仮定すると、エンジン２４４の再伝送ロジックにより、当該するフレーム５００が、ネットワークへ再伝送されるのに的確であるか否かが判断される。フレームをＮＡＬ層に再送する前に、エンジン２４４’の再伝送ロジックは、関連しているＰＤＵ５０６のリストを反復する。
【０２８４】
ＰＤＵ５０６（２）それぞれの再試行カウントが調べられ、０でなければ、該カウントは減少させられる。ＰＤＵ５０６（２）の再試行カウントを減少させる処理により、該カウントは０になる。ＰＤＵ５０６（２）の再試行カウントが０になったことにより、ＰＤＵ５０６（２）はリストから外され、「再試行失敗」のステータスをもってローカルに完了する。
【０２８５】
続いて、ＰＤＵ５０６（２）のデータが無いことを示すため、フレームヘッダ５０３のサイズが調整される。この処理は、残っている全てのＰＤＵについて繰り返される。フレーム５００全体が、「編集後」フレーム５００’の作成のために再処理されると、ヘッダの再試行ＩＤが増加させられて、生成されたデータグラムが、続く（再）伝送に向けてＮＡＬ層に送られる。
【０２８６】
（受信の例）
図１３Ａ〜１３Ｄは、「受信」イベント受信に伴ってインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。このような受信イベントは、インターネット・モビリティ・プロトコル・エンジン・フレームがネットワーク１０８から送られた際に生成される。この受信イベントを受けて、エンジン２４４は該イベントを事前検査し（ブロック６７０）、インターネット・モビリティ・プロトコル・エンジン・フレームである可能性があるか否かを判定する（判定ブロック６７１）。
【０２８７】
エンジンが可能性無しと判断した場合（判定ブロック６７１で「ノー」の場合）、該フレームは破棄される（ブロック６７２）。可能性ありという判断の場合（判定ブロック６７１で「イエス」の場合）、エンジン２４４は、受信したフレームと関連する接続があるかどうかを判定する（判定フレーム６７３）。
【０２８８】
受信したフレームと関連する接続がある場合（判定ブロック６７３で「イエス」の場合）、エンジン２４４は作業を接続受信キューに加え（ブロック６７４）、該接続に受信に適格であるとマークを付け（ブロック６７５）、該接続をグローバル作業キューに加える（ブロック６７６）。
【０２８９】
まだどの接続も受信したフレームと関連していない場合（判定ブロック６７３で「ノー」の場合）、エンジン２４４は、受信したフレームをソケット受信キューに加え（ブロック６７７）、該ソケット受信キューをグローバル作業キューに加える（ブロック６７８）。どちらの場合でも、エンジン２４４はグローバル作業イベントを送る（ブロック６７９）。
【０２９０】
「受信適格」イベントをグローバル作業キューからディスパッチする際（図１３Ｂ参照）、エンジン２４４はフレームをそれぞれの受信キューから外す（ブロック６８０）。インターネット・モビリティ・プロトコル・エンジン２４４がメッセージをキューから外し始められるようになる前に、複数のＩＭＰフレームを受信し、キューに加えることが可能である。
【０２９１】
エンジン２４４は、全てのフレームがキューから外れるまで作業を繰り返す（ブロック６８１、６８２）。あるフレームがキューから外れると（判定ブロック６８１で「イエス」）、エンジン２４４は受信したフレームを検査し（ブロック６８３）、該フレームが有効かどうかを判定する（判定ブロック６８４）。該受信したフレームが無効である場合、エンジン２４４は該フレームを破棄し（ブロック６８５）、受信キューから次のフレームを外す（ブロック６８０）。
【０２９２】
上記フレームが有効である場合（判定ブロック６８４で「イエス」の場合）、エンジン２４４は、該フレームが既存の接続と関連しているか否かを判定する（ブロック６８６）。していなければ（判定ブロック６８６で「ノー」の場合）、エンジン２４４は同期フレームがあるかどうかを判定する（判定ブロック６８７）。
【０２９３】
同期フレームがなければ（判定ブロック６８７で「ノー」の場合）、該フレームは破棄される（ブロック６８５）。反対に、同期フレームが受信されていれば（判定ブロック６８７で「イエス」の場合）、エンジン２４４は、図１４Ａ及び１４Ｂを参照して説明される受動接続要求により、該フレームを処理する（ブロック６８８）。
【０２９４】
上記フレームが接続と関係していれば（判定ブロック６８６で「イエス」の場合）、エンジン２４４は接続状態が依然アクティブで、まだ「ポスト・モーテム」になっていないかどうかを判定する（判定ブロック６８９）。接続が既に「ポスト・モーテム」である場合、フレームは破棄される（ブロック６８５）。
【０２９５】
そうでない場合、エンジン２４４はフレームを解析し（ブロック６９０）、該フレームが中止フレームであるかどうかを判定する（判定ブロック６９１）。該フレームが中止フレームであれば、エンジン２４４は直ちに接続を中止する（ブロック６９１ａ）。該フレームが中止フレームでなければ（判定ブロック６９１で「イエス」の場合）、エンジン２４４は確認応答情報を処理し、全ての保留中の送信フレームを開放する（ブロック６９２）。
【０２９６】
次に、エンジン２４４は、解読の必要がある場合のため、セキュリティ用のサブシステムへと送る（ブロック６９３）。フレームがセキュリティ用のサブシステムから戻ると、エンジン２４４は全ての制御データを処理する（ブロック６９４）。続いて、エンジン２４４はフレームがアプリケーションデータを含んでいるかどうかを判定する（判定ブロック６９５）。
【０２９７】
含んでいる場合、該データはアプリケーション層においてキューに加えられる（ブロック６９６）。エンジン２４４はまた、接続が休止状態であるかどうかを判定し（ブロック６９７及び６９７ａ：これは、好ましい実施形態におけるモビリティ管理サーバのエンジン２４４’にもあてはまる）、確立状態に戻す。
【０２９８】
フレームが「モーティス」フレームである可能性があれば（判定ブロック６９８で「イエス」の場合）、エンジン２４４は、アプリケーション層に「切断」を示唆し（ブロック６９９）、「モーティス」状態に入る（ブロック６９９ａ）。エンジン２４４は「ポスト・モーテム」フレームをピアに送り（ブロック７００）、「ポスト・モーテム」状態に入る（ブロック７００ａ）。
【０２９９】
続いて、エンジン２４４は接続リソースを解放し（ブロック７０１）、スリープ状態に戻って作業を待つ（ブロック７０２）。解析されたフレームが「ポスト・モーテム」フレームだった場合（判定ブロック７０３で「イエス」の場合）、ブロック７００ａ、７０１、７０２が実行される。これ以外の場合、制御はブロック６８０に戻って、次のフレームを受信キューから外す（ブロック７０４）。
【０３００】
（受動接続の例）
図１４Ａ〜１４Ｂは、「受動接続」要求に対してインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。まず、エンジン２４４は、当該装置に他の接続が存在するかどうかを判定する（ブロック７２０）。存在すれば（判定ブロック７２０で「イエス」の場合）、該エンジンは、それが最初の接続であるか否かを判定する（判定ブロック７２１）。ピアが、新規の接続が最初の接続であると認識している場合（判定ブロック７２１で「イエス」の場合）、エンジン２４４はそれ以前の接続を中止する（ブロック７２２）。
【０３０１】
最初の接続ではない場合（判定ブロック７２１で「ノー」の場合）、エンジン２４４は、シーケンスと接続ＩＤとが対応しているかどうかを判定する（判定ブロック７２３）。対応していなければ（判定ブロック７２３で「ノー」の場合）、制御は判定ブロック７２０へ戻る。シーケンスと接続ＩＤが対応していれば（判定ブロック７２３で「イエス」の場合）、エンジン２４４は複製フレームを破棄し（ブロック７２４）、図１３Ｂのステップ６８０に戻る（ブロック７２５）。
【０３０２】
他の接続が無ければ（判定ブロック７２０で「ノー」の場合）、エンジン２４４は、接続に接続リソースを割り当て可能か否かを判定する（判定ブロック７２６）。割り当て可能でない場合、エラーが宣言され（判定ブロック７２６で「ノー」の場合、ブロック７２７）、接続が中止される（ブロック７２８）。
【０３０３】
接続リソースを割り当て可能な場合（判定ブロック７２６で「イエス」の場合）、エンジン２４４は「設定」状態を宣言し（ブロック７２６ａ）、接続についてのセキュリティコンテキストを取得する（ブロック７３０）。十分なセキュリティコンテキストの取得ができなかった場合（判定ブロック７３１で「ノー」の場合）、接続は中止される（ブロック７２８）。取得できた場合、エンジン２４４は確立フレームを送り（ブロック７３２）、接続が「確立」状態になったことを宣言する（ブロック７３２ａ）。
【０３０４】
続いて、エンジン２４４は再送部を始動させ（ブロック７３３）、完了に向けて認証処理を待つ（ブロック７３４）。最後に、エンジン２４４は装置とユーザとが両方認証済みか否かを判定する（ブロック７３５）。装置とユーザのどちらかが認証されていない場合、接続は中止される（ブロック７３６）。
【０３０５】
それ以外の場合では、エンジン２４４は監視中の（ｌｉｓｔｅｎｉｎｇ）アプリケーションへの接続を示唆し（ブロック７３７）、設定を取得する（ブロック７３８）。この２ステップのどちらかが成功しなかった場合、接続は中止される（判定ブロック７３９、ブロック７４０）。成功した場合、処理はスリープ状態に戻って作業を待つ（ブロック７４１）。
【０３０６】
（異常終了の例）
図１５Ａ及び１５Ｂは、接続「中止」要求を受けて、インターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。キューを介してディスパッチされた、上記のような要求を他の処理（ブロック９９９）から受信すると（ブロック１０００）、エンジン２４４は、接続が該要求と関係しているかどうかを判断する（判定ブロック１００１）。関係していれば（判定ブロック１００１で「イエス」の場合）、エンジン２４４は元の状態をセーブして（ブロック１００２）、「中止」状態を宣言する（ブロック１００２ａ）。
【０３０７】
次に、エンジン２４４は、接続がＲＰＣエンジンに示唆されていたか否かを判定する（判定ブロック１００３）。されていれば、エンジン２４４は切断イベントを示唆し（ブロック１００４）、「ポスト・モーテム」状態を宣言して（ブロック１００３ａ）、該接続に割り当てられていたリソースを解放し（ブロック１００５）、元の状態が保留中の状態より大きいか否かを判定する（判定ブロック１００６）。
【０３０８】
元の状態が保留中の状態より大きくなければ、（判定ブロック１００６で「ノー」の場合）、処理は、呼び出しルーチンに戻るべく、ブロック１０１２に移る（ブロック１００７）。元の状態が保留中の状態より大きい場合には、エンジン２４４は、上記要求が受信フレームと関係しているかどうかを判定する（判定ブロック１００８）。
【０３０９】
中止要求が受信フレームと関係していて、受信フレームが中止フレームである場合（判定ブロック１００９）、受信フレームは呼び出しルーチンに戻る（ブロック１０１２）前に破棄される（ブロック１０１１）。
【０３１０】
（ローミング制御の例）
再度図１を参照すると、モバイルネットワーク１０８は、それぞれ別のネットワーク相互接続（１０７ａ〜１０７ｋ、無線トランシーバ１０６ａ〜１０６ｋにそれぞれ対応）を提供する、複数のセグメントを含んでいてもよい。本発明の別の側面において、モビリティ管理サーバ１０２を含むネットワーク１０８は、モバイル端末システム１０４があるネットワーク相互接続から別のネットワーク相互接続へと移る「ローミング」状況を、余裕を持って扱うことができる。一般に、ネットワーク１０８のトポロジは、管理等の理由により、いくつかのセグメント（サブネット）に分けられ、一般的には、あるセグメントにおいて、別個のネットワーク（伝送）アドレスが複数のモバイル端末システム１０４それぞれに割り当てられている。
【０３１１】
上記のようなサブネットで新規に起動したネットワーク装置は、動的ホスト構成プロトコル（ＤＨＣＰ）を使用して、自動的に設定されるのが一般的である。例えば、サブネット上のＤＨＣＰサーバは、一般的に、そのクライアントに（他のものの提供に加えて）有効なネットワークアドレスを「リース」する。ＤＨＣＰクライアントは、永続的に割り当てられた、「固定符号化された」ネットワークアドレスを有していなくてもよい。その代わり、ブート時に、ＤＨＣＰクライアントはＤＨＣＰサーバにネットワークアドレスを要求する。
【０３１２】
ＤＨＣＰサーバは、割り当てに使用可能なネットワークアドレスをプールしている。ＤＨＣＰクライアントがネットワークアドレスを要求すると、ＤＨＣＰサーバはプールしていたアドレスを、該クライアントに割り当てあるいはリースする。割り当てられたネットワークアドレスは、特定の期間（リース期間）だけ、クライアントに所有される。
【０３１３】
リース期間が終わると、ネットワークアドレスはプールに戻され、他のクライアントへの割り当てに使用できるようになる。ネットワークアドレスの自動割り当てに加え、ＤＨＣＰはネットマスク等の設定情報を、ＤＨＣＰクライアントソフトウェアを動作させているクライアントに提供する。標準的なＤＨＣＰプロトコルについての詳しい情報は、ＲＦＣ２１３１に記載されている。
【０３１４】
よって、ＤＨＣＰを使用するモバイル端末システム１０４が、サブネットからサブネットへとローミングすると、該システムは新規のネットワークアドレスを持つことになる。本発明の一側面において、モバイル端末システム１０４とモビリティ管理サーバ１０２とがＤＨＣＰの自動設定機能を利用し協調することで、モビリティ管理サーバによるモバイル端末システム１０４の「新しい」ネットワークアドレスの認識や、該アドレスと、モビリティ管理サーバがプロキシする、以前に確立されていた接続との結合が保証される。
【０３１５】
ある実施例では、モバイル端末システム１０４が別のサブネットにローミングしたり圏外に出たりしたか否かを判定するために利用される、他の標準的な方法と並んで、エコー要求−応答として、標準的なクライアント／サーバ型同報通信用のＤＨＣＰ  Ｄｉｓｃｏｖｅｒ／Ｏｆｆｅｒメッセージのシーケンスが使用される。
【０３１６】
標準的なＤＨＣＰプロトコルにしたがって、ネットワークアドレスを要求するモバイル端末システム１０４が、ＤＨＣＰ  Ｄｉｓｃｏｖｅｒメッセージの一部として、クライアント識別子とハードウェアのアドレスとを定期的に同報通信すると、これに対し、ＤＨＣＰサーバはＯｆｆｅｒ応答を同報通信する（要求しているモバイル端末システムがまだネットワークアドレスを持っていないため、該システムを特定して該応答を送るというよりも、同報通信によって該応答が伝えられるという形になる）。
【０３１７】
よって、当該サブネット上の全てのモバイル端末システム１０４は、ＤＨＣＰ  Ｏｆｆｅｒサーバからの、同サブネット上のどのモバイル端末システムに同報通信された応答であっても受信することになる。
【０３１８】
本実施例では、ＤＨＣＰ同報通信メッセージをモニターするＤＨＣＰリスナが設けられており、モバイル端末システム１０４が、あるサブネットから別のサブネットへローミングしているか、及びＤＨＣＰによって新規のネットワークアドレスが取得できるようになっているかが確認される。図１６は、ＤＨＣＰリスナのデータ構造の例を示している。例えば、モバイル端末システムのリスナのデータ構造９０２は、以下の要素を有していてもよい。
・サーバデータ構造の連結リスト、
・整数トランザクションＩＤ番号（ｘｉｄ）、
・カウンタ（「ping」）、及び
・タイムアウト値
サーバデータ構造９０４は、それぞれ別のＤＨＣＰサーバを定義するデータブロックの連結リストを有していてもよい。該データブロックそれぞれは、以下の要素を有していてもよい。
・次のサーバへのポインタ、
・サーバＩＤ（ＤＨＣＰサーバのネットワークアドレス）、
・最近該ＤＨＣＰサーバと結合したＢＯＯＴＰリレーエージェントのアドレス（ｇｉａｄｄｒ）、
・「ｐｉｎｇ」値（socket->ping）、及び
・フラグ
【０３１９】
これらのデータ構造は、ネットワーク１０８上のＤＨＣＰ同報通信トラフィックに基づいて、持続的にアップデートされる。以下に例示の諸機能は、該データ構造の維持に使用される。
・roamCreate（）  （変数を初期化）
・roamDeinitialize（）  （全てのリスナを消去）
・roamSrartIndications（）  （モバイル端末システムがローミングするかインターフェイスを変更した際に、登録主体ローミング示唆のために、供給されたコールバックルーチンを呼び出す）
・roamStopIndications（）  （適当なコールバックをリストから除去して登録ローミング示唆を停止）
・インターフェイス変更（インターフェイスがネットワークアドレスを変更したことを示す、ＯＳからのコールバック通知）
・リスナ信号（ローミング、圏外、圏内復帰のいずれかの状態を示す、リスナからのインターフェイスごとのコールバック）
【０３２０】
これに加え、リフレッシュ処理が、インターフェイス変更後にリスナをアップデートするために利用されてもよい。
【０３２１】
本発明の好ましい実施形態では、全てのモバイル端末システム１０４が、ＤＨＣＰ  Ｄｉｓｃｏｖｅｒ要求によって同じクライアント識別子とハードウェアアドレスとを伝送する。これにより、リスナのデータ構造とこれに関連する処理とが、モバイル端末システムからのＤｉｓｃｏｖｅｒ要求と、他のネットワーク装置からのＤｉｓｃｏｖｅｒ要求とを、区別することができるようになる。ＤＨＣＰサーバも同様に応答を同報通信するので、どのモバイル端末システム１０４及び／又はモビリティ管理サーバ１０２も、ＤＨＣＰサーバからどのモバイル端末システムに出されたＯｆｆｅｒ応答でも受け取ることができる。複数のＤＨＣＰサーバが単一のＤＨＣＰ  Ｄｉｓｃｏｖｅｒ要求に応答できるため、図１６のリスナのデータ構造は、サーバからの応答それぞれを、メインハンドルに連結リスト経由で結びつけられた、個別のデータブロックに記憶する。
【０３２２】
所定のクライアントハードウェアアドレス及びクライアント識別子を有するＤｉｓｃｏｖｅｒ要求の受信に際し、本発明の好ましい実施形態では、該要求がモバイル端末システム１０４から送られてきたものとして認識される。該メッセージが０に設定されたＢＯＯＴＰリレーアドレスをさらに有している場合、該メッセージはリスナと同じサブネットからのものであることが示唆されている。
【０３２３】
リスナは、最近モバイル端末システム１０４から送られたＤｉｓｃｏｖｅｒメッセージのトランザクションＩＤ（ｘｉｄ）と対応したトランザクションＩＤ（ｘｉｄ）が含まれていない限り、ＤＨＣＰ  Ｏｆｆｅｒ応答を無視してもよい。該リスナは、新規のＢＯＯＴＰリレーエージェントＩＤ及び／又は提供されたサブネットマスクでマスクされた、提供されたネットワークアドレスを持つ、既知のサーバから応答があれば、モバイル端末システム１０４がローミングしたと判定する。
【０３２４】
リスナは、旧サーバから肯定応答を受け取って初めて、新サーバを図１６のデータ構造に加える。リスナが新サーバからの応答は受け取ったが旧サーバからは受け取っていない場合、ローミング状態が示唆される（これについては設定によって変更可能である）。リスナが新旧両サーバのどちらからも応答を受け取っていない場合、リスナは圏外にあると判定される（この判定は、アプリケーションなど上層に警告を出して、停止や、バッファ・オーバーフロー回避のためのデータ送信量の減少に利用できる）。
【０３２５】
リスナがどのサーバからも応答を受信しない場合、参照点が無いため、ローミングが行われているかどうかが判定できない。この状況は、タイムアウト後にエラー警告して、呼び出し側に処理を再試行させることによって解消される。本発明の好ましい実施形態では、新規のＢＯＯＴＰリレーエージェントＩＤ（又は提供されたサブネットマスクでマスクされた、提供されたネットワークアドレス）を持つ、既知のサーバから応答があれば、モバイル端末システム１０４がローミングしたと判定する。
【０３２６】
リスナのデータ構造に、新サーバからの応答はあったが旧サーバからのものは無い場合、ローミングが行われた可能性はあるが、旧サーバからの応答がその後あるかもしれないので、待機して通知を遅らせる。新旧どちらのサーバからも応答が無い場合、モバイル端末システム１０４は圏外にある可能性があるので、モビリティ管理サーバ１０２は該システムが圏内に戻るのを待つ。
【０３２７】
図１７は、本発明の好ましい実施形態のリスナ処理のステップを例示したフローチャートである。同図によると、ＤＨＣＰリスナ処理は、適切なメモリをハンドルに割り当て、ＮＡＬソケットをＤＨＣＰクライアント及びサーバＵＤＰポートに解放し、その両者に対して受信コールバックを設定することによってなされる。次にタイマーが設定され（ブロック８０２）、上記処理は「待機」状態に入ってローミング関連のイベントを待つ（ブロック８０４）。イベントは、以下の３種の外部入力によって引き起こされる。
・ＤＨＣＰサーバパケットを受信する
・他のモバイル端末システムからのＤＨＣＰクライアントパケットを受信する
・タイマーの期限が切れる
【０３２８】
ＤＨＣＰサーバパケットを受信した場合、該パケットは、そのクライアント識別子が所定のクライアントＩＤと一致するか否かを判定するために調べられる（判定ブロック８０６）。一致しなければ、該パケットは破棄される。しかし、該パケットが所定のクライアントＩＤを含んでいる場合、該パケットがＤＨＣＰ  Ｏｆｆｅｒパケットであるか否かが判定される（判定ブロック８０８）。該Ｏｆｆｅｒパケットは、最近送られたＤＨＣＰ  Ｄｉｓｃｏｖｅｒシーケンスに対応したトランザクションＩＤを含んでいない限り、拒絶される。
【０３２９】
パケットトランザクションＩＤが対応していれば（ブロック８１０）、ＤＨＣＰ  Ｏｆｆｅｒパケットを送信したサーバが既知であるか否か（つまり、サーバＩＤが図１６のリスナのデータ構造に含まれているか否か）が判定される（ブロック８１２）。サーバＩＤがリストに無い場合（判定ブロック８１２で「ノー」の場合）、サーバＩＤがリストに加えられ、「新規」とマークされる（あるいは、リストの最初のサーバであれば、「最初」とマークされる）（ブロック８２２）。
【０３３０】
サーバが既にリストにある場合（判定ブロック８１２で「イエス」の場合）、さらに、パケットＢＯＯＴＰリレーアドレス（「ＧＩＡＤＤＲ」）がサーバアドレス（「ＧＩＡＤＤＲ」）に対応しているか否かが判定される（判定ブロック８１４）。対応していなければ、Ｏｆｆｅｒパケットは他のサブネットからのものということになるので、「ハードローミング」が実行されたと判定される（ブロック８１６）。
【０３３１】
呼び出し側のアプリケーションには、ローミングが行われたことが通知される。判定ブロック８１４でＢＯＯＴＰリレーアドレスが対応していると判定されると、ローミングは行われていないということになり、サーバ受信時間を記録し、リストの他のサーバ全てについて「新規」フラグをリセットし、現在のｐｉｎｇ番号をサーバに記憶するというリスナ処理が行われる（ブロック８１８、８２０）。続いて、処理は「待機」期間に戻る。
【０３３２】
イベントがクライアントパケットに受信されると、リスナ処理では、該パケットが所定のクライアントＩＤを有しているか、ＤＨＣＰ  Ｄｉｓｃｏｖｅｒパケットか、及び０のパケットＢＯＯＴＰリレーアドレス（ＧＩＡＤＤＲ）を有しているかどうかが判定される（ブロック８２４、８２６、８２８）。これらのステップにより、上記受信パケットが、リスナと同じサブネット上にある、他のモバイル端末システムから送信されたＤＨＣＰ  Ｄｉｓｃｏｖｅｒメッセージであるか否かが判定される。そうであれば、リスナ処理により、上記トランザクションＩＤが、後に受信されるＤＨＣＰ  Ｏｆｆｅｒパケットの比較に用いられる、ピアのトランザクションＩＤに設定され（ブロック８３０）、「ｐｉｎｇ確認」が呼び出され（ブロック８３４）、タイマーがリセットされる（ブロック８３６）。
【０３３３】
タイマーの期限切れにより、処理は「ｐｉｎｇ確認」を呼び出す（ブロック８３８）。本発明の好ましい実施形態における「ｐｉｎｇ」は、ランダムな新規のｘｉｄを有するＤＨＣＰ  Ｄｉｓｃｏｖｅｒパケットである。このｐｉｎｇ確認８３８のステップが、図１７Ａに例示されている。ｐｉｎｇ確認ルーチンの目的は、「ソフトローミング」状態（つまり、モバイル端末システムが、一時的にサブネットとのコンタクトを失ったもののその後回復したが、まだ他のサブネットにローミングはしていない状態）が発生しているか否かの判定である。処理によって、サブネット・ローミング状態、圏外状態、あるいは「サーバ無し」状態が発生しているか否かが判定される。これらを言い換えると以下のようになる。
・モバイル端末システムが、あるサブネットから別のものにローミングしたか？
・モバイル端末システムは圏外にあるか？
・ＤＨＣＰサーバは不在か？
【０３３４】
これらの状態は、モバイル端末システムの、前「ｐｉｎｇ」応答と現「ｐｉｎｇ」応答とを比較することによって判定される（判定ブロック８４６、８５０）。例えば、現ｐｉｎｇ数から旧サーバの前ｐｉｎｇ応答を引いた数が、サブネットのサーバのｐｉｎｇよりも大きく、少なくとも一つのサーバが「新規」とマークされている場合、別のサーバへのサブネット・ローミングがあったということになる。この論理により、コーリング処理に対し、サブネット・ローミング状態、圏外状態、あるいはサーバ無し状態が示唆される（あるいはいずれも示唆されない）。
【０３３５】
図１８は、モバイル端末システム１０４のローミング制御センターが実行するステップを例示したフローチャートである。モバイル端末システム１０４でのローミングを可能にするため、既知のアドレスのリストが０に初期化され（ブロック８５０）、ＯＳインターフェイス変更通知がイネーブルになり（ブロック８５２）、次に、ＯＳを呼び出して、ＤＨＣＰを利用する現在のアドレスのリストを所得する（ブロック８５４）。現在のリストから無くなった全ての既知のアドレスに対応するリスナが閉じられ（ブロック８５６）、一方、現在のリストにあるが未知のインターフェイスにあるリスナが開放される（ブロック８５８）。次に、登録主体に「ローミング」を示唆する（ブロック８６０）。
【０３３６】
図１７のリスナ処理から信号が送られると（ブロック８６２）、該信号が、「ローミング」、「圏外」、「圏内復帰」のいずれの状態を示しているかが判定される（判定ブロック８６４、８７０、８７４）。ローミング信号（判定ブロック８６４で「イエス」）により、対応するリスナ８６６が閉じられ、ＯＳがコールされて、ネットワークアドレスのＤＨＣＰリースが解放、更新される（ブロック８６８）。リスナ信号が「圏外」の場合（判定ブロック８７０）、該状態が登録主体に示唆される（ブロック８７２）。該信号が「圏内復帰」の場合（判定ブロック８７４）、該状態は全ての登録主体に示唆される（ブロック８７６）。無効のローミング命令を受信すると（ブロック８７８）、全てのリスナが閉じられ（ブロック８８０）、ＯＳインターフェイス変更通知が無効になる（ブロック８８２）。
【０３３７】
（インターフェイスによって補助されたローミングのリスナの例）
さらに、インターフェイスベースのリスナによって、同じネットワーク及び別のネットワーク媒体のネットワーク接続ポイントを横断したローミングが可能になる。該インターフェイスベースのリスナが上述のビーコン技術を要することなく動作する一方、下層の（複数の）インターフェイスが適切な信号をサポートしていない場合には、システムをビーコン状態にフォールバックさせることもできる。
【０３３８】
本実施形態において、インターフェイスベースのリスナは、ネットワーク・インターフェイス・アダプタからの（例えば低レベルのインターフェイス・ローミング・ドライバを経由した）情報を、ネットワークスタックからの情報と統合して、モバイルノードが新規のネットワーク接続ポイントに移動したか否かを判定する。
【０３３９】
図１９Ａと１９Ｂは、モバイルノードの移動パスを効率的に決定するのに利用される、リスナ・アルゴリズムを例示する。該処理では、単一のネットワーク媒体に接続された単一のネットワーク・インターフェイスが使用されているが、単独で、もしくは他のローミング・アルゴリズムと協働して、（例えば、冗長パスを使った自己回復インフラ構築のために）様々なネットワーク媒体やインターフェイスを横断するようにもできる。
【０３４０】
図１９Ａを参照すると、システム初期化時や、ネットワークアダプタドライバがロードする際に（図１９Ａ、ブロック２０００）、低レベルのインターフェイス・ローミング・ドライバは、図１８のローミング制御センターモジュールに登録を実行する（ブロック２０１０）。このような登録（例示の実施形態では、crRegisterCardHandler（）機能を通じて実現される）により、下記のエントリポイントが与えられる。
・開
・閉
・状態取得
・ドライバが登録主体に状態の変化を通知可能であれば、ブール演算を真とし、ローミング制御センターモジュールが、状態確認にタイマーベース（等）のポーリングを使わなければならない場合は、ブール演算を偽とする
【０３４１】
実施例のcrRegisterCardHandler（）機能により、インターフェイス記述ストリング、あるいはローミング制御センターモジュールを正しいローミングドライバと予備的に組み合わせるために使用できるトークンが与えられる。また、デフォルトのローミングドライバが、示唆／問合せ媒体接続性及びネットワーク接続ポイントの変更に関するＯＳ包括メカニズムを使用するインターフェイスに、インストールされてもよい。
【０３４２】
本実施例では、インターフェイスの状態がイネーブルになると（つまりネットワークへのアクセスが可能になると）（ブロック２０２０）、ローミング制御センターは、インターフェイス補助ローミング（ＩＡＲ）を、以下のステップに基づいて試みる（ただし、以下のステップは、ＯＳの設計及び／又は特定のアプリケーションに使われるホスティング装置によって、入れ替えられたり省略されたりすることがある）。
【０３４３】
１．包括ハンドラがインストールされている場合、包括crOpenInstance（）ハンドラへのコールがなされる。包括ハンドラは低レベルアダプタドライバに問合せをして、該ドライバが、媒体接続性の状態及びネットワーク接続ポイントの変更に関する信号を包括的にサポートしているか否かを判定する（ブロック２０３０）。インターフェイスドライバが該機能を包括的にサポートできない場合（判定ブロック２０３０で「ノー」の場合）、エラー状態が、コール実行側に返され、信号情報の取得に他のメカニズムを使用することが示唆される。
【０３４４】
２．包括ハンドラがエラー（判定ブロック２０３０で「ノー」）を返した場合、アクティブなインターフェイスに関する検索が、現在登録されているローミングドライバにおいて実行される（ブロック２０４０）。該インターフェイスが、crRegisterCardHandler（）フェイズ中に登録されたトークンのうちの一つと一致する場合（ブロック２０５０）、ローミング制御センターは、アダプタのインスタンスへの特定のcrOpenInstance（）をコールする。
【０３４５】
この機能は、低レベルドライバを開き、状態（媒体接続性、ネットワーク接続ポイントＩＤ）を再度ポーリングし、定期ポーリングタイマーを（可能ならば）設定することを試みるものである。低レベルドライバが、なんらかの理由で該要求をサポートしていない場合、ローミング制御センターにエラーが返されて、信号情報の取得に他のメカニズムを使用することが示唆される。
【０３４６】
３．ここまでのステップのいずれかが、要求された機能を達成できない場合、エラーがローミング制御センターに返されて、ＩＡＲ機能を使用せずに、図１７及び１７Ａのビーコンリスナ、モバイルＩＰ、あるいは場合により、ローミングを扱っている、現在接続されているネットワークなど、他のローミング・アルゴリズムにフォールバックすることが示唆される（判定ブロック２０５０で「ノー」の場合、ブロック２０６０）。これ以外の場合、インターフェイス補助ローミングがイネーブルになり（ブロック２０６０）、ローミング制御センターは下記のアルゴリズムに従う。
【０３４７】
まず、インターフェイスによって補助されたリスナは、現在の媒体接続性の状態と、ネットワーク接続ポイントの識別情報とを、ローカルデータストアに記録する（ブロック２０６０）。インターフェイスによって補助されたサブシステムがローミングフィードバックの供給に成功したと仮定して、該サブシステムは状態イベントを待つ（ブロック２１００）。該イベントは、例えば以下のものを有している。
・低レベルローミングドライバからのコールバック、
・ポーリング間隔（ブロック２０７０、２０９０）、あるいは
・ネットワーク・レベルの活動（つまり、伝送／受信にかかわる問題）からの示唆
【０３４８】
インターフェイスの状態が、媒体接続性に変化が生じたか、あるいはネットワーク接続ポイントが変更されたかを示すと（図１９Ｂの判定ブロック２１１０もしくは２１２０で「イエス」の場合）、ローミング制御センターの全てのクライアントに、以下のルールに基づいて、状態の変化が知らされる。
【０３４９】
１．状態が、下層のネットワーク媒体への接続から切断へと変化したことを示し（ブロック２１２０で「イエス」）、ピアへのパスが他に無い場合、リスナは、モバイル端末システムが接続を失ったと結論付け、ローミング制御センターはそのクライアントに、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＯＵＴ＿ＯＦ＿ＣＯＮＴＡＣＴ状態を示唆する（ブロック２１４０）。
【０３５０】
２．上記状態が、インターフェイスが媒体に再接続され、ネットワーク接続ポイントが変わっていないことを示し（ブロック２１２０で「ノー」の後、ブロック２１５０で「ノー」の場合）、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＯＵＴ＿ＯＦ＿ＣＯＮＴＡＣＴが既に示唆されている場合、モバイル端末システムが、特定のネットワーク接続ポイントとのコンタクトを失ったがその後取り戻したことが示唆される。
【０３５１】
この場合、ローミング制御センターは、適切なアクセスのために登録又は取得された全てのネットワークアドレスを再確認し（ブロック２１７０）、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＡＭ＿ＳＡＭＥ＿ＳＵＢＮＥＴを出して（ブロック２１８０）、ローミング制御センターのクライアントに、再接続が行われたので、トランスポート・レベルでの通信の再確立に必要な措置を全て実行するように警告する。例えば、サービス中断中にいくつかのデータが失われることがあれば、クライアントは該データを回復するために措置を講じるといったことである。
【０３５２】
３．上記状態が、インターフェイスが媒体に取り付けられているが、ネットワーク接続ポイントが変更されたことを示している場合（ブロック２１５０で「イエス」の場合）、ローミング制御センターはクライアントに、ローミング状態になったことを示唆する。ネットワーク接続ポイント間のハンドオフをさらに効率的にサポートするために、本例のローミング制御センターは、ローカルデータストアと並行して学習アルゴリズムを使用している。
【０３５３】
該データストアは、通常動的にポピュレートされている（学習している）が、パフォーマンス向上のため、該データストアに静的な情報（既に学習された情報）が準備されていてもよい。データストア自体は、ネットワーク接続ポイント識別子のリストを、ネットワークや媒体へのアクセスのアドレスやネットワークマスクなどの情報とともに維持している。この「ネットワーク・トポロジ・マップ」は、ローミング制御センターがクライアントに対して正しい信号の生成を決定できるように補助するものである。
【０３５４】
正しい信号の決定は、本実施例では以下のようにしてなされる。
【０３５５】
ａ）データストアのネットワーク・トポロジ・マップを検索して、インターフェイスが特定のネットワーク接続ポイントを訪れたか否かが判定される（ブロック２１９０）。対応が見つかれば（ブロック２２００で「イエス」）、該ネットワーク接続ポイントが、以前にインターフェイスが結合していたのと同じネットワーク・セグメントにあるか否かがさらにチェックされる。ネットワーク・セグメントが同じであれば、ローミング制御センターは、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＡＭ＿ＳＡＭＥ＿ＳＵＢＮＥＴを生成する。これにより、ローミング制御センターのクライアントに、ハンドオフが実行され、ハンドオフ中にデータのいくつかが失われた可能性があるため、直ちにトランスポート・レベルでの通信の再確立をするための可能な限りの措置を講じなければならないことが示唆される。
【０３５６】
ｂ）検索中に対応は発見されたが、新しいネットワーク接続ポイントは前と同じネットワーク・セグメントにない場合、リスナは、モバイル端末システムが別のサブネットワークにローミングしたと結論付ける。この場合、ローミング制御センターは、
・新規のネットワーク・セグメントで使用可能なアドレスを取得する（ブロック２２２０）。この動作は、現在のアドレスを新規のセグメントで有効なように登録すること、ローカルサーバからアドレスを（再）取得すること、あるいは以前に割り当てられたアドレスがまだ有効かどうか判定するヒューリスティックな手法を用いてもよい。最後のケースでは、ローミング制御センターにより、インターフェイスが所与のネットワーク接続ポイント間をローミングしていて、パフォーマンス維持の観点から、直ちにネットワークアドレスを破棄したり、その登録を抹消したりできないような状態にあるかどうかが判断される。この例では、（例えばＤＨＣＰを通じて）ネットワークでアドレスを取得することは、（モバイルＩＰの外部エージェントを通じて）ローカルネットワークでアドレスを登録することとは相違している。ローミングエンティティは、アドレスを（再）取得（例えばＤＨＣＰサーバからのリースを確立／アップデートして）するか、あるいは現アドレスを外部エージェント（モバイルＩＰ）に登録する。
・別のサブネットへのローミングを示唆する、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ローミング信号を、該ローミング制御センターのクライアント向けに生成する（ブロック２２３０）。
【０３５７】
ｃ）検索の結果対応が見つからなければ（ブロック２２００で「ノー」）、ネットワーク接続ポイントの識別子、媒体アクセスアドレス、ネットワークマスクや他の補助的な情報によってポピュレートされた、新規の記録を生成する（ブロック２２１０）。次に、ローミング制御センターはブロック２２２０及び２２３０を、ネットワークアドレスを取得、登録し、「ローミング」信号を生成するために実行する。
【０３５８】
上記のインターフェイスによって補助されたローミング技術により、下層のインターフェイス情報へのアクセスができるようになり、自動的かつ効率的に別の有効なネットワークパスを選択することを可能にする、（ユーザ及び／又はシステムによって定義された）付加的なポリシーパラメータが採用できるようになる。一つ以上のネットワークが同時に使用可能な場合、サブシステムは、最も負担がかからないパス（ワイドエリア・ネットワークかローカル・エリア・ネットワークかという選択）を選ぶことができる。これは、帯域幅、（１バイトあたりの）コスト、及び／又はサービス品質といった様々なメトリクスによって決定可能である。この「最低負担ルーティング」技術により、ネットワーク接続の品質、効率、フレーム損失の減少などの点で効果を得ることができる。
【０３５９】
例えば、他の利用可能なヒューリスティクス（媒体接続性、信号強度、再伝送率等）による、「メークビフォアブレーク」ハンドオフ構造が提供可能で、よってローミングノードからの／に向かう継続的なパケットフローの損失を最小化できる。下記のポリシー管理についての記述を参照のこと。
【０３６０】
図２０は、インターフェイス補助ローミングトポロジのノードのデータ構造を例示している。図２０のこのデータ構造は連結リストとして実施されているが、前後のフィールドを省略した配列として表現されることもある。無線ネットワーク・インフラにおいて、「ＮＰＯＡ」は、例えば、アクセスポイントのＭＡＣアドレスあるいはモバイルノードが結合している基地局でもよい。他のネットワークにおいては、「ＮＰＯＡ」は、介入的なネットワーク相互接続（ゲートウェイ、ＩＷＦ等）の固有の識別子であってもよい。データ構造には静的な情報が予め与えられていてもよいし、動的に情報が学習されてもよい。また、ノードそれぞれと、他の情報（例えばＭＴＵのサイズ、待ち時間、コスト、利用可能かどうかなど）とが結合していてもよい。
【０３６１】
（特定の競合状態を扱う他の実施例）
さらに行われた実験から、ネットワーク・アダプタの中には、ネットワーク・セグメントに完全登録される前に、媒体と（再）接続されていると誤って信号を出すものがあることが明らかとなった。例えば、ローミングの間、ネットワーク識別子を保持する記憶領域はまだ更新されず、したがって、システムがこれらのネットワーク・アダプタが同じサブネットにロームバックしたと誤解することが考えられる。最終的には、デバイスが登録を終了すると、記憶領域は新しいネットワーク識別子と共に更新され、さらに別のローミング信号が生成される。両方の情報が一緒にゲートされ、インターフェイスがネットワークでの登録を終了した時に１度だけ信号が送られると、このシナリオ通りに進む。しかし、ポーリングの際、「ネットワークと接続中」を示す信号が以前に生成された場合に、ネットワークＩＤがいつ有効になるかを判定するのは困難である。
【０３６２】
基本的に、ローミング中のノードはネットワークと媒体アクセスレベルで通信できるため、事実上媒体と接続状態にあるが、登録プロセスが完了していないので、事実上、リンクを通じていずれのアプリケーションデータを送ることはまだできない。したがって、この状態を補償するのが望ましい。このような補償を行う方法の一つとして、一般にはエコー要求／応答パケットとして知られているリンク確認フレームを送ることによってピア接続を判定する方法がある。これらのエコーやｐｉｎｇフレームは１つのピア（ローミング中のノードである可能性が高い）によって生成され、双方向のピア・トゥ・ピア接続が達成可能か判定する。要求を出しているピアがその要求に対する応答フレームを受け取る場合、二重通信が実現し終了する。この時点で、次に切断状態になるまでＮＰＯＡ情報が有効であると見なされる。また、該当インターフェイス上のピアからのフレーム受領等、他の情報によって、ローミング中のノードが登録プロセスが終了し、双方向通信が達成可能であることが想定可能となる。
【０３６３】
ネットワーク・インターフェイスと内在するプロトコルスタック状況間における別の競合状態は、問題を生じることがある。デバイスは、新しいネットワーク・セグメントに移動し、以下のインターフェイスから正確に信号が送られるようにすることは可能であるが、トランスポート・スタック自体はフローするアプリケーションデータのルーティング・テーブルに必要な調整を行わないことがある。この状態を補償するために、内在するトランスポートのルーティング・テーブルに変更が生じる度に、付加的信号であるＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＵＴＥ＿ＣＨＡＮＧＥが追加されて生成される。この信号が示されると、ローミング中のサブシステムクライアントはピア・システムとの接続が達成可能かどうか判定するために必要なアクションは何でも行う。これによりローミング中のクライアントは、ルーティング修正がピアへの通信経路に影響を及ぼしたかどうか判定するために、内在するトランスポートのルーティング・テーブルを介して列挙する必要がある。また、上記記載のアルゴリズム等のように、よりイントルーシブな他のアルゴリズムが、ピア間に双方向通信経路が存在することを確認するために行われてもよい。
【０３６４】
（非接続ネットワークを通じたローミング例）
本発明の非限定的な好ましい実施形態の他の一側面として、いわゆる「非接続ネットワーキング」モードでＭＭＳ（モビリティ管理サーバ）にアクセスするためのアルゴリズム及び構成がある。新しいアルゴリズムによって、あるネットワークからは別のネットワークにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、ＭＭＳとの通信を確立する／持続するのに使われる、代替のネットワークアドレスを動的／静的に見つけ出すことができるようになる。
【０３６５】
一般に、アルゴリズムによって、通信中にＭＥＳ（モバイル端末システム）に送るための、ＭＭＳが利用可能な代替アドレスのリストが可能となる。このように、ＭＭＳはＭＥＳに、一つ以上のＭＭＳネットワークアドレスもしくは他のネットワークに対応した他のＭＭＳのアイデンティティを、単一のネットワークによる通信によって送る。一例として、該リストは、回路構築の際に送付可能である。また、該リストは途中で変更可能である。この場合、該リストは接続が確立されている間のいかなる時にも更新が可能である。
【０３６６】
ＭＥＳが別のネットワークへと移動するとき、ＭＥＳは新規のネットワークの接続ポイントからＭＭＳとコンタクトをとるために、ＭＭＳの「エイリアス」アドレス／アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、又はその他の情報を共有していなくても、ＭＥＳは新規のネットワーク接続を通じてＭＭＳとのコンタクトを再確立することができる。
【０３６７】
この新しい技術を簡略化したフローチャートを図２１に示す。ＭＭＳ１０２は、２つの異なる非接続ネットワーク、すなわちネットワーク・セグメントＮ１及びＮ２と接続しているものとする。ＭＥＳ１０４は、最初にＭＭＳ１０２とネットワークＮ１を介して接続されるものとする。ネットワークＮ１を介してＭＥＳ１０４とＭＭＳ１０２との間で接続が確立されるとすぐに、ＭＭＳ１０２は、ＭＥＳ１０４に対して、ＭＭＳが一以上の他のネットワーク（例えば、ネットワークＮ２）から求められるネットワークアドレスのリストＬ又は他の識別子を送ることができる。ＭＥＳ１０４は、該リストＬを受け取り、記憶する。その後、ＭＥＳ１０４は別のネットワーク（Ｎ２）に移動する時、ＭＥＳ１０４はこの記憶されたリストＬにアクセスし、それを用いて新規のネットワーク（Ｎ２）を通じたＭＭＳ１０２との通信を効果的に再確立することが可能となる。
【０３６８】
この新しいアルゴリズムには、非接続ネットワークを通じて、ＭＭＳ１０２と通信するための代替ネットワークアドレス又は他の識別子をより効率的に取得することに加え、少なくともいくつかの用途がある。その用途の一例としてネットワークオペレーションがある。
【０３６９】
例えば、図２１に示すアルゴリズムを用いて、多くのネットワーク（いくつか、又は全てが無線ネットワーク）からの安全なファイアウォール／ゲートウェイ、及びコーポレートバックボーンとしてＭＭＳ１０２が使用される安全なネットワークをセットアップでき、モバイルノード１０４が安全に、接続を切断されることなく別々のネットワーク全てに移動することが可能となる。
【０３７０】
例えば、ＭＭＳ１０２がハブとして１つの太いパイプでコーポレートネットワーク、及び論理的に分離した多くのネットワークを接続する多数の小さなスポークと接続しているとする。ネットワークは論理的に分離しているため、ＭＭＳ１０２（この例ではルータとして動作可能）を介した場合を除いて、１つのネットワーク・セグメント上のトラフィックが別のネットワーク・セグメントに達することができない。
【０３７１】
普通、ネットワーク・セグメントからネットワーク・セグメントへ移動するノードにとって、ＭＭＳ１０２との接続に使用される「メインパブリックアドレス又は初期アドレス」への戻り方を示す、各ネットワーク・セグメントに設けられた情報／経路（つまり、デフォルトルート等）をルーティングが必要となる。
【０３７２】
接続が確立されるとすぐに、そのアドレスが接続の存続のために用いられる。ＭＥＳ１０４からフレームが送られる時、クライアント及び及び中間ノード（ルータ）におけるＩＰネットワーク（層３）のインフラストラクチャは、フレームの目的地アドレスを見て、最終目的地（ＭＭＳ１０２）にパケットを正確に送る。このことは、一般にＩＰ送信、あるいはＩＰルーティングと呼ばれるもので行われる。この機能がオンになると、あるネットワーク・セグメントのフレーム（ブロードキャスト等）が別のネットワーク・セグメントへ流れる。ＩＰ送信をしないと、あるセグメントに送られたフレームは他のセグメントへ送られることはないので、通信パイプが切断され、あるいは非接続ネットワークができてしまう。
【０３７３】
図２１に示す代替アドレスリストは、ルーティング情報のうちの幾つかをＭＥＳ１０４に送出する、又は配布する効果を有する。したがって、各セグメントは、ＭＭＳ１０２とつながっている他のセグメントの情報はない状態で離散された状態となる。ＭＥＳ１０４はＭＭＳ１０２によって認証可能であるため、ＭＭＳは認証されたＭＥＳユニット１０４にのみリストＬを送る。
【０３７４】
ＭＥＳ１０４が別のネットワーク・セグメントへ移動する時、ＭＥＳ１０４は自動的に正しいアドレスを選択し、それを用いて途中ＭＭＳとの通信を開始／継続することができる。したがって、非接続ネットワークの問題は解決され、ルーティング・インフラストラクチャの変更は必要なくなる。これにより、有効なユーザに対してのみネットワークへのアクセスを有効にすることによって、より安全なコンピュータ環境を提供することが可能となる。
【０３７５】
例えば、このようにユーザレベルのセキュリティ／暗号化と組み合わせてＭＭＳ１０２を用いることで、コーポレートバックボーンからのトラフィック、及びコーポレートバックボーンへのトラフィックを、上記のローミング技術を用いてそのセグメント上のノードを目的地としたフレームのみに限定することが可能である。フレームは選択的に暗号化でき、スポーク・ネットワーク・インフラストラクチャが有効にしたデバイスによって行われる可能性のある盗聴を阻止することができる。
【０３７６】
例を図２２に示す。図２２において、ＭＭＳ１０２は通信網やルート情報を共有しない４つの別々に分かれたネットワーク（Ｉａ、Ｉｂ、Ｉｃ、Ｉｄ）と接続されている。どの点から見ても各ネットワークＩは島となっている。コーポレートバックボーン上の有線通信を用いてネットワークの一つ（例えば、Ｉｃ）とドッキングしているＭＥＳ１０４を想定する。例えば、ＭＥＳ１０４は１９２．１６８．ｘ．ｘネットワーク上のアドレスを取得してＭＭＳ１０２と通信するものとする。
【０３７７】
ある理由によりＭＥＳが１０．１．ｘ．ｘ（Ｉａ）ネットワークに渡る、又は移動する必要があるものとする。１０．１．ｘ．ｘ（Ｉａ）ネットワークは１９２．１６８．ｘ．ｘ（Ｉｂ）ネットワークのことを知らない（つまり、（Ｉｂ）ネットワークへのルートがない）ため、ＭＥＳ１０４がその領域へ移動する時に、たとえＭＭＳが通信パイプに接続されていても通信パイプは切断される。また、モバイルノード１０４が図示される他の１０．ｘネットワークのいずれかと接続する場合においても同じことが起こる。
【０３７８】
図２１に示すアルゴリズムを用いて、接続開始時間の（あるいは他の方法で）ＭＭＳ１０２は各種非接続ネットワークＩａ、Ｉｂ、Ｉｃ、Ｉｄに関するそのインターフェイスアドレスをＭＥＳ１０４と共有し、ＭＥＳはこれらを記録する。一旦記録されると、ＭＥＳ１０４は上記ネットワークのいずれか一つに移動して新しいネットワーク・セグメントに移動したことを検出する場合、ＭＥＳは適切なネットワークアドレスを選択し、そのネットワーク・セグメントでＭＭＳと通信できる。
【０３７９】
２以上のアドレスが使用される場合、ＭＥＳ１０４は適切なアドレスを選択してスピード、コスト、有効性、ホップ等、多くのメトリクスに基づき使用する。図２１と同様のリストを受け取らなかったＭＥＳ１０４は、その「ホーム」ネットワーク以外のネットワークを通じてＭＭＳと接続することができないので、種々のネットワーク間の移動を事実上阻まれることになる。
【０３８０】
他に、図２１の技術は分散型ネットワーク・インターフェイスに用いられる。今日のネットワークにおいて、ネットワーク・アドレス・トランスレータ（ＮＡＴｓ）として知られるものが開発されている。この従来の技術を利用すれば、一つの公開ネットワークアドレスを用いるだけで多くのネットワークデバイスはインターネット上の情報へのアクセスが可能となる。この技術は、単一もしくはわずかなデバイスを介してインターネットに向けられた情報やクエリを全て送ることによって上記の機能を可能とする。
【０３８１】
該デバイスはネットワーク層で要求を記録し、その後パケットのアドレスとポート情報をデバイスのアドレス／ポートのタプルに再度対応付けし、それをその目的地に送信する。インターネット、あるいは他の当該ネットワークからフレームを受け取ると同時に、デバイスはリバースルックし、そのアドレス／ポートのタプル情報を開始デバイスのものと取り替えて、フレームを送り返す。これらの対応付けはＮＡＴにおいても静的に定義される。
【０３８２】
誰かがＬＡＮ／ＷＬＡＮの内部でＭＭＳ１０２を使用するために、それをＮＡＴに置くことを想定する。現在、ＭＭＳ１０２がＮＡＴでない限り、あるいは異なるプロキシを用いてＭＭＳと通信を全て行うことによって、誰かがイントラネットの境界範囲外に移動する時、ＭＭＳと通信するアドレスがもはやアクセス可能ではないため、ＭＭＳとはアクセス可能ではない。
【０３８３】
図２１のアルゴリズムを用いれば、ＭＭＳと直接接続されていない別のインターフェイスアドレスを静的／動的に明確にすることができる。したがって、上記のアルゴリズムを使用すれば、ＭＥＳ１０４は自動的に適切な非接続アドレスを選択し、イントラネットの領域外のネットワークと接続する時にそのアドレスを使用することができる。
【０３８４】
この概要を図２３に示す。ノードがインターフェイス“ｄ”からインターフェイス“ｇ”へ渡るとする。ＭＭＳ１０２にローカルインターフェイスを供給するだけではアクセスはできない。ＭＥＳ１０４は分散されたインターフェイスの優先順位を知る必要がある。それからＭＥＳ１０４は必要なアドレスを選択してインターフェイス“ｇ”上で使用する。その後、ＮＡＴ２０００は、各パケットに関するネットワークアドレス／ポート情報を、内部インターフェイス“ｃ”アドレスへ適切に変換する。ＭＭＳ１０２からＭＥＳ１０４に送られるフレームには逆の処理が行われる。
【０３８５】
（ポリシー管理及びロケーションベースのサービス例）
本発明の他の非限定的な実施形態として、多くのメトリクスに基づき付加的なセキュリティ、コスト削減、サービスを提供することが独自にできる手法を提供する。上記のＭＭＳはＭＥＳが確立する各アプリケーションのセッションと深く関わっているため、どちらの側（すなわち、ＭＭＳ及び／又はＭＥＳ）もポリシーベースのルールを適用してＭＥＳとその最終的なピアとの間の通信を適合して制御することができる。
【０３８６】
さらに、ＭＭＳ及び／又はＭＥＳはデバイスのロケール、又は近接性、並びにネットワークの接続に基づきアプリケーション要求を調整又は修正することができる。例えば、ＭＭＳ及び／又はＭＥＳは学習され静的に定義されて適用されたルールエンジン、あるいは確立する各アプリケーションセッション、又は試みる要求に対するポリシーに基づく他のルールを含むことができる。
【０３８７】
ＭＭＳはさらにＭＥＳにこのようなルールの幾つか、全くなし、あるいは一部、及び／又は処理を配分して、メータリング、又は傍受者によるモバイルデバイスへの侵入に対するセキュリティを提供する。分散型トポロジで利用可能な特定の他のポリシー管理技術とは違い、ＭＭＳが中心となり、ルールやポリシー決定を管理し、それらを通信中いかなる時にも遠隔地のデバイスに分散させる。
【０３８８】
ルール自体は、ユーザ、ユーザ・グループ、デバイス、デバイスグループ、プロセスアプリケーションアイデンティティ、及び／又はネットワークの接続ポイントに基づき構成可能である。一旦定義されると（学習されると）、ルールは組み合わされて、例えば、以下のものを含む種々の異なる事象、活動、及び／又はサービスを管理し、制御する。
・遠隔地のデバイスへの侵入アクセスの拒否、許可、又は調整
・アイデンティティに基づく特定のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・利用可能、又は許可された帯域幅へのアクセスの拒否、許可、又は調整
・他のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・内容又は情報の修正、調整、又は変更
このような決定は例えば、以下の要素を含む種々の異なる要素に基づいて行われる。
・モバイルデバイスについての近接性、場所、高度、及び／又は他の特性
・日時
・アプリケーション又はプロセスアイデンティティ、アドレス等
・アプリケーション動作（例えば、帯域幅条件）
・現在のネットワーク状態
・他の静的又は動的要素
【０３８９】
さらに分散型アーキテクチャを利用することで、ＭＭＳは同じ決定セットを適用又は共有することができる。ポリシー管理処理及び／又は意思決定をＭＭＳに行わせるのは、例えばモバイル装置がエンジンを実行するのに限られた処理能力を持ったり、帯域幅の限度が適用されたり、あるいはセキュリティが目的の場合に望ましい。
【０３９０】
サンプルＭＥＳの制御に使用される可能性のあるメトリクス（ルール）の幾つかを示すテーブルの例を図２４に示す。このテーブルは静的又は動的のどちらかに内容を占めてもよいし、場合によっては通信前、通信中、又は通信後に更新されてもよい。例えば、ユーザはテーブルの項目を定義するルール・エディタ（例えば、ウィザード）や他のメカニズムを使用することができる。他の構成例において、メトリクスが学習に基づくシステムによって自動的に定義され、あるいは状態の変更に基づき動的に変更される。
【０３９１】
また、ルールにはそれぞれ優先順位が割り当てられ、テーブルの場所で暗示、又は割り当てによって明確に指定される。この優先順位によってエンジンが期待動作を正確に決定することができる。付加的なユーザインターフェイスの機能によって、システム管理者やデバイスのユーザはルールエンジンに問い合わせて所定のルールセットの機能を試みることが可能となる。
【０３９２】
ポリシー管理決定の基になる、以下のメトリクスをはじめとする多数のメトリクス例を示すテーブル例を図２４に示す。
・ＭＥＳの通信機能（送信のみ、受信のみ、送受信）
・ＭＥＳの要求がプロキシされるか否か
・ＭＥＳのソースポート
・ＭＥＳのソースアドレス
・ＭＥＳの目的地ポート
・ＭＥＳの目的地アドレス
・ＭＥＳのプロトコル
・利用可能な帯域幅量
・プロセス名、アイデンティティ又は他の特性
・ネットワーク名、アイデンティティ又は他の特性
・ロケーション（例えば、ＧＰＳ座標又は他のロケーション情報）
・ネットワークの接続ポイント
・ユーザの識別子、アイデンティティ又は他の特性
・他のメトリクス
上記テーブル例は完全なリストではなく、本発明は上記テーブル例のメトリクス項目の範囲に限定されるものではない。ネットワークアクセス及び権利付与に関してモバイルノードの所望の動作を示すために、該項目はこの例のように具体的であり、あるいは包括的なメカニズム（例えば、ワイルドカード）であることが可能である。
【０３９３】
図２４のテーブル例には、メトリクスに基づくポリシー管理決定の結果を示す「否定要求」項目がさらに含まれる。一例として、図２４のテーブルに示す特定の項目例は、利用可能な帯域幅が一秒間で１００，０００バイト以下に低減される場合、目的地ポート２０、２１との接続は否定され、減速されることを示す。さらに、示した特定の例において、ルール（列）３、４によってネットワークトラフィックのみがＭＭＳへ、又はＭＭＳから流れることが可能となる（プロキシが行われない他の全てのネットワークトラフィックは暗に破棄される。）。
【０３９４】
一例において、各ＲＰＣ要求又はフレームが処理される前に、ルールエンジンはオペレーションの状況を決定するよう求められる。このプロセスの結果に基づき、その要求が許可、否定、あるいは遅延される。ポリシー管理決定をするためにＭＭＳ及び／又はＭＥＳによって行われる処理のフローチャート例を図２５に示す。
【０３９５】
先に概略を説明したローミング技術と、利用可能な他のロケーション又はナビゲーション情報とを組み合わせることによって、ＭＭＳはモバイル端末システムがいつ１箇所の接続ポイントから別の接続ポイントへ移動したか検出する。ネットワーク・トポロジの環境の変化を検出するために、モバイル端末システムの機能と関連してこの情報を組み合わせることによって、ロケールによって本発明はロケーションベースの傍受及びサービスの付加的なレベルを提供することができる。
【０３９６】
この情報の可能性を十分実現させるために、インターネット・モビリティ・プロトコルとＰＲＣエンジンの両方の改良点について概要を説明する。新しいＲＰＣのプロトコル及び構成の改良点が追加され、この機能が可能となる。これらを以下に挙げる。
【０３９７】
（ロケーション変更ＲＰＣの例）
モバイル端末システムが、インターフェイス支援型ローミング又はグローバル・ポジショニング・システムから変更を検出するといった他の方法を用いて新しい接続ポイントへ移動したことを判断した時、モバイル端末システムは、フォーマットされた「ロケーション変更ＲＰＣ要求」メッセージをそのピア、この場合モビリティ管理サーバに送る。
【０３９８】
「ロケーション変更ＲＰＣ」は、一以上の接続ポイント識別情報をタイプ、長さ、値の形式にフォーマットする。タイプは識別情報の種類を示し、対応するタイプはＡＳＣＩＩの４８ビットＩＥＥＥ  ＭＡＣ  アドレス、ＩＰＶ４  アドレス、ＩＰＶ６  アドレス、経度、緯度、高度、接続機構名を含むが、これらに限定されない。長さは識別データのバイト長を示し、該データは実際の接続ポイント識別子を含む。
【０３９９】
「ロケーション変更ＲＰＣ要求」を受け取ると、モビリティ管理サーバは、接続ポイント識別子、並びにモビリティ端末システムの識別子、ユーザ名、ＰＩＤ等の他の関連情報を含む「ロケーション変更警告」を作成する。この警告は「ロケーション変更ＲＰＣ要求」内で使用された同じタイプ、長さ、データフォーマットでフォーマットされる。その後警告サブシステムが、警告のために登録された全てのアプリケーションにロケーション変更警告と共にこの情報を送る。
【０４００】
警告のために登録されたアプリケーションは、現在の活動状況のモニタ、長期の動作ログ、ポリシー管理エンジン、第三者アプリケーション等の監視アプリケーション、並びにネットワーク管理ツールを含んでもよい。単一のそのような第三者アプリケーションは、このロケーション情報と、ウェブベースのマップとを組み合わせてモバイル端末システム又はＭＭＳの場所についての詳細情報を提供する。そのようなアプリケーションに加えて、他の動作をロケーション変更警告と関連付けることができる。これには、電子メールの送信、メッセージの印刷、プログラムの起動、及び／又はポリシー変更が含まれる。
【０４０１】
ロケーション変更ＲＰＣはそのヘッダにロケーション変更、距離変更、又は速度変更によってトリガされたかどうかを示すフィールドを含む。
【０４０２】
ある例では、ＭＥＳは自身が移動したことを知らない場合がある。ＭＥＳが接続する媒体やネットワーク・アダプタに応じて、ＭＭＳはＭＥＳが新しい接続ポイントに渡ったことを知らせる唯一のエンティティであってもよい。モバイルルータの場合を考えてみる。ルータ以降のアドレスは同じままで、ルータのアドレスだけが変わる。この場合、ＭＭＳはＭＥＳのアドレスを新しく管理することを認識する。
【０４０３】
したがって、動作の検出を完了するためには、行動検出するためのＭＥＳとＭＭＳの両方の組み合わせの動作の検出が必要となる。本実施の形態では、ソースアドレスが変更され、新しいＩＭＰメッセージが受け取られる時に、ＭＭＳはＩＭＰ層でクライアントの行動を検出する。このことが行われると、ＭＭＳは局所的にロケーション変更警告を生成する。また、ＭＭＳは接続ポイントが変更したというメッセージをＭＥＳに送る。
【０４０４】
（トポロジＲＰＣの例）
「トポロジＲＰＣ要求」はモビリティ管理サーバからモバイル端末システムへ送られる。このＲＰＣの受け取りと同時に、モバイル端末システムはそのローカルデータ記憶装置に記憶されるトポロジ情報を読み出して、トポロジＲＰＣ応答を作成する。トポロジＲＰＣ応答は、前後との接続のタイプ、長さ情報が後に続く全長フィールド、タイプ、長さ情報が後に続く接続ポイント識別子、及び、サブネット及びネットワーク情報を示す値のデータによってフォーマットされる。この情報は、サーバで提供されるモバイルネットワークの完全なトポロジカル・マップを作成するのにサーバ上で使用されてもよい。
【０４０５】
（ロケーション情報ＵＩの例）
サーバ上のユーザインターフェイスは、ロケーション情報を対応付けして表示するための方法を提供する。このロケーション情報は、各アクティブなモバイル端末システムが利用でき、長期の動作ログは全てのアクティブなモバイル端末システム及び以前アクティブだったモバイル端末システムのロケーション変更履歴を保持する。
【０４０６】
ユーザインターフェイスによって、システム管理者は接続ポイント情報を人間が読める形式に構成できる。例えば、接続ポイント情報が４８ビットのＩＥＥＥ  ＭＡＣアドレスの形式で与えられると、サーバ上のユーザインターフェイスを介して提供される情報と共にこのＭＡＣアドレスが表示される。接続ポイントが「ホールマークカード」店のアクセスポイントを示すと、次の情報「ホールマーク、住所、市、州、郵便番号」を提示するように設定される。この情報がユーザに対して表示されることによって、「ホールマーク、住所、市、州、郵便番号」情報が提供されることになる。
【０４０７】
（ロケーションＲＰＣタイマーの例）
設定可能なタイマーがモバイル端末システムに設けられており、ロケーション変更ＲＰＣがモバイル端末システムからモビリティ管理サーバに送信される速度を制限する。タイマー間隔が接続ポイントの変更が起こる速度よりも大きい場合、モバイル端末システムはタイマー間隔が終了するまで待ってから別のロケーション変更ＲＰＣを生成する。
【０４０８】
（距離変更通知の例）
距離メトリクスは、ロケーション変更ＲＰＣの生成をトリガするために設けられる。この設定によって、ユーザが前にいた元のポイントから、ｎフィート、ｎキロメータ毎、あるいは他の適当な測定単位で３次元的に移動する時に、更新を送信するようにシステムが構成される。デフォルトによってこの設定は無効になる。この設定を可能にすることによって、設定された距離間隔を上回った時に変更通知が出される。
【０４０９】
（速度閾値通知の例）
速度変更メトリクスは、ロケーション変更ＲＰＣの生成をトリガするために設けられる。このパラメータは、一時間当たりのマイル等、一秒当たりの距離で構成される。このパラメータは、上限及び下限、並びに到達した速度を持続する必要のある時間間隔（すなわち、１０分間で０ＭＰＨ、又は１分間で７０ＭＰＨ）を特定する。このスピードに達すると、ロケーション変更通知が生成される。
【０４１０】
（モバイルプロキシ通信及びクラスタリングサービスの例）
本発明の非限定の上述した機能に加えて、上記ＭＥＳはさらに、モバイルプロキシ通信サービス（ＭＰＣＳ）として機能することができる。上記追加の非限定的なモバイルプロキシ通信サービスの機能性は、モバイルな専用ネットワーク（ＭＰＮ）に対し、接続される、あるいは接続されない最終的なピアと通信するために、上記少なくとも一つのノードへ／から通信されるアプリケーションデータを使用可能にする。上記ピアと上記ＭＰＮとの接続は、ＭＥＳ／ＭＰＣＳに結合される、ＩＰベースの接続拠点を有する各ネットワークの少なくとも一つを通す可能性を有しながら、上記ＭＰＣＳを介してなされる。
【０４１１】
上記典型的なＭＰＣＳは、以下に示す非限定の例の装置及び／又はユーザに関するサービスを提供する。
・少なくとも一つのローカルのモバイルな専用ネットワーク（ＭＰＮ）に接続される固定されたモバイル端末システム（ＦＭＥＳ）（例えばカメラ、携帯機器、及び他のＩＰベースの各装置）。一度取り付けられると、ＦＭＥＳ装置は、上記ＭＰＮ上の他のＦＭＥＳ装置と通信することができ、上記ＭＰＣＳに結合された特定の接続拠点を有するネットワークと無関係にアプリケーションサービスを伝え合うことができる。
・訪問モバイルクライアント（ＶＭＣ）、訪問モバイル端末システム（ＶＭＥＳ）、及び訪問ＭＰＮｓ（ＶＭＰＮ）は、さらに、上記ＭＰＮｓの１つを介して上記ＭＰＣＳに接続でき、その結合されたＰＰＮｓを用いることができる。
・その他
【０４１２】
ＭＥＳ上で動作する上記ＭＰＣＳによる、少なくとも一つの上記ＦＭＥＳｓ、ＶＭＥＳｓ、ＶＭＣｓ及び／又はＭＰＮｓで利用可能な非限定的に説明される機能性及びサービスは、以下に示すものの何れか、あるいは全てを含んでもよい。
・認証、許可及び課金（ＡＡＡ）
ＮＴＬＭ、アクティブディレクトリ、ＲＡＤＩＵＳ、ＬＤＡＰ及び／又は他のＡＡＡサービスのようなものであるが、これらに限定されない、よく知られているあるいは標準の認証システムを介した、装置、モバイルなネットワーク、及び／又はユーザの、及び装置、モバイルなネットワーク、及び／又はユーザに関する認証、許可及び課金（ＡＡＡ）
・保証された通信路
上記ＭＰＣＳ及びＡＥＳを含むよく知られている暗号技術を用いる少なくとも一つのＭＭＳの間での保証された通信路。上記保証された通信路の自動再キー化は、完全な転送の秘密厳守のために、さらに提供されてもよい。
・アドレス管理
アドレス管理は、各々のＭＰＣＳ及び関連付けられるＦＭＥＳ（ｓ）、ＶＭＥＳ（ｓ）、ＶＭＣ（ｓ）及び又はＭＰＮｓに関する動的な、あるいは静的ないずれか一方のＩＰアドレシングを考慮したものである。
・永続的なアプリケーションセッション
ネットワークアドレス、カバー領域のすきま、大きな待時間のネットワーク、等の変化を介してアプリケーションセッションを維持する永続的なアプリケーションセッション。
・ローミング
多様なＰＰＮｓにわたるインナーネットワークのローミング及びサブネットのローミング。
・自動圧縮及びリンク最適化
遅く、大きな待ち時間の各ネットワークを介してネットワーク性能を改善する、自動圧縮及びリンクの最適化。
・ポリシー管理
アプリケーションの動作及びネットワークリソースの消費を制御するためのポリシー管理。
・他の機能性
追加の構成要素は、上記ＭＰＣＳの典型的な非限定的な実施例の機能性のコアを構成する。各々の構成要素は、各サービスのサブセットを提供するために、スタンドアロンで動作することができるが、それは、本発明の好ましい実施形態の、提供され強化された能力は、互いに協力して動作するこれらの各サービスの組合せである。説明される非限定的な追加の各構成要素の例は、以下のものを含む。
・ネットワークのアドレス／ポートのトランスレータ／モバイルなＩＰのフォーリン／ホームエージェント
・ファイアウォール／イントルージョン検出エージェント
・ＤＨＣＰサーバ
・ゲートウェイ結合／リメディエーションエージェント
・インターフェースシグナリングエージェント
・ＤＮＲ／ＤＮＳ／ディレクトリサービスのプロキシエージェント
・アプリケーションレベルのプロキシ
・強化された設定及びポリシー管理エージェント
・遠隔のクライアントユーザインターフェース
・その他
【０４１３】
上記ＭＥＳにこれらの構成要素を加えることにより、本発明に示す技術は、安全で、永続的で、管理されたアクセスを、各装置、各ユーザ、及び上記ＭＰＣＳ／ＭＥＳのＭＰＮｓに結合される各ネットワークに対し可能にする機能性を提供することができる。
【０４１４】
〔ネットワークのアドレス／ポートのトランスレータ／モバイルなＩＰのフォーリン／ホームエージェント〕
この構成要素は、少なくともＩＥＴＦ規格のＲＦＣ３０２２、あるいはＲＦＣ２００２／２００３、及びそれらの後継物にしたがって設計されて動作する。追加の機能性は、それを多様なＰＰＮｓに認識させるためにさらに加えられる。このモジュールは、上記ＭＰＮｓから上記ＰＰＮｓへの、又は逆に、上記ＰＰＮｓから上記ＭＰＮｓへの、上記ＦＭＥＳｓ、ＶＭＰＮｓ、ＶＭＥＳｓ及び／又はＶＭＣｓのための通信の配置を、非限定的な、ポリシー、設定、情報のフレーミングに好適なインターネットプロトコル（バージョン、アドレス、ポート、プロトコル）、アプリケーションの名前、あるいはセマンティクスの少なくとも一つに基づく機能を備える。
【０４１５】
〔ファイアウォール／イントルージョン検出エージェント〕
上記ＭＰＣＳが、少なくとも一つのモバイルな専用ネットワークに関するプロキシ及び／又はＮＡＰＴとして動作しているので、このエージェントは、上記ＦＭＥＳが“モバイルを意識した”装置ではないので、少なくとも上記ＦＭＥＳに対し、ファイアウォール及びイントルージョンの検出ロジックを提供する。その上、この機能性は、上記ＭＰＣＳに結合された上記ＭＰＮｓと最終的に接続するＶＭＥＳｓ及びＶＭＣｓをカバーするために拡張されてもよい。
【０４１６】
〔ＤＨＣＰサーバ〕
この構成要素は、少なくともＩＥＴＦ規格のＲＦＣ２１３１、及びそれらの後継物にしたがって設計されて動作する。上記構成要素は、接続されたＭＰＮｓ及び／又はＶＭＰＮｓの少なくとも一つのためにローカルに管理されたアドレスを提供する。それはさらに、ベンダーへの具体的な拡張をサポートし、及び／又は、動的な発見及び／又は他の高められるサービスのために用いられる可能性を有する、上記ＭＰＮｓあるいはＶＭＰＮｓに接続されたモバイル装置への情報の伝搬を可能にするＤＨＣＰ通知サービスを提供する。
【０４１７】
〔ゲートウェイ結合／リメディエーションエージェント〕
この構成要素は、ローカル／プロキシの装置／ユーザの認証を提供する。ＭＰＮｓに連結されるノードによる、あるいは上記ＶＭＰＮｓによるアドレス獲得が生じた後に、上記エージェントは、さらに、上記ＭＰＣＳの他の各サービスの何れか消費される前に、装置／ユーザ／ネットワークのレベルの認証のための手段を提供する。
【０４１８】
認証／許可／課金（ＡＡＡ）サービスを検証するための通信能力に伴う、ローカルな認証能力は、上記ＭＰＣＳが認識していない新しいあるいは未知の装置／ネットワーク／ユーザのために用いられてもよい。検証するＡＡＡサービスのバックエンドは、少なくとも一つの公知のあるいは標準の認証システムであってもよい。
【０４１９】
他のＡＡＡの機能性に伴って、上記エージェントは、訪問したあるいは固定の各装置の何れかが、特定の管理条件の範囲内で動作しているということを保証するためのリメディエーションサービスを含むことができる。上記リメディエーションの非限定的な一例は、上記ネットワークと接続する各ノードの何れかが、上記ＭＰＣＳに接続された上記ＭＰＮｓ上の他の装置の動作に悪影響を与えないことを保証する特定のレベルのアンチウイルスの保護と共に動作しているということを保証することであってもよい。上記リメディエーションエージェントは、上述のポリシー管理の機能性と協力して動作する、それ故に上記機能を中央管理可能にさせる。
【０４２０】
〔インターフェースシグナリングエージェント〕
この構成要素は、上記ＭＰＣＳに接続された上記ＰＰＮの各インターフェースの一つに変化が起こっているという事実のために、接続されたＭＥＳｓあるいはＶＭＥＳｓに対し警報を出す。上記能力は、上記ＭＥＳ、ＶＭＥＳｓ、あるいはＶＭＰＮｓ上のポリシーの発見や適用を加速化できる。上記構成要素は、さらに、上記ＭＰＣＳに接続された上記各ＰＰＮｓの各々に接続された状態の発見を可能にするクエリ（質問）能力を提供してもよい。
【０４２１】
〔ＤＮＲ／ＤＮＳ／ディレクトリの各サービスのプロキシエージェント〕
この構成要素は、ＩＥＴＦ規格により指定されるようなＤＮＲ／ＤＮＳサーバとして動作する。しかし、一つの典型的な非限定的に説明される実施形態では、上記構成要素は、プロキシサーバと共にランデブーサーバとしての強化された能力及び動作を提供する。この動作のモードでは、選択的に、及び設定情報に基づいて、上記構成要素は、問い合わされた最終的なピアのアドレスの代りに、ネームリゾリューション応答における上記ＭＰＣＳに関連付けられるアドレスを置き換えることにより対応する。この段階では、上記構成要素は、要求者のソースアドレス、上記ネーム、可能であればアプリケーションレベルのプロキシエージェントによる使用のための最終的なピアのアドレスを記録する。
【０４２２】
〔アプリケーションレベルのプロキシエージェント〕
この構成要素は、ＭＰＣＳに接続された少なくとも一つの上記ＭＰＮに接続された少なくとも上記ＦＭＥＳ、ＶＭＥＳ、ＶＭＣｓ、及び／又はＶＭＰＮｓのためのプロキシサービスを提供する。本質的には、上記構成要素は、前述した上記ＭＥＳの伝送レベルのリディレクター、上記ＮＡＰＴサービス、及び拡張された上記ＤＮＲ／ＤＮＳ／ディレクトリサービスプロキシエージェントと協力して動作する。
【０４２３】
拡張された上記ＤＮＲ／ＤＮＳ／ディレクトリサービスプロキシエージェントは、モバイルな／訪問するノードあるいはネットワーク／サブネットワークに対し、セッションの永続性、ローミング、及びポリシー管理のような上記各機能性を有するように拡張したものである。
【０４２４】
アプリケーションセッションは、上記ＭＰＣＳが通信し合っているＭＭＳを少なくとも一つの提供することによって、中央にて設定され得る互いに関連付けるマッピングを有する。一つの動作モードにおいて、及び上記ＤＮＲ／ＤＮＳ／ディレクトリサービスプロキシとの連携において、上記リゾリューション応答のフレームで指定されるアドレスに定められるＩＰデータグラムの受信時に、上記アプリケーションレベルのプロキシエージェントは、さらに、マッピングを生成して、接続された上記ＭＭＳを介した最終的なピアへの接続あるいはデータをプロキシすることができる。
【０４２５】
上記接続されたＭＭＳが上記ＰＰＮｓを介して接続不可能である場合では、上記ＭＰＣＳ、ローカルポリシー及び設定は、遮断される各動作を許可するために、キャッシュに格納され、採用されてもよい。
【０４２６】
〔強化された設定及びポリシー管理モジュール〕
上記ポリシー管理の構成要素は、上記ＭＰＣＳの動作に関する新しい設定のポリシー結果を考慮している。上記構成要素は以下のものを含むが、これに制限されない。
・ＦＭＥＳ／アプリケーションのプロキシ通信
・ＮＡＰＴマッピング／フォーリン／ホームエージェント登録
・ゲートウェイ結合／リメディエーションエージェント設定
・ＤＨＣＰサーバマッピング
・ＤＮＲ／ＤＮＳ／ディレクトリのサービスプロキシ
【０４２７】
〔遠隔のユーザインターフェース〕
この構成要素は、補助無での上記ＭＰＣＳの動作を可能にする。一つの典型的な非限定的な実施形態では、上記ＭＰＣＳの機能性と結合されるＭＥＳの能力は、埋め込まれるヘッドレス（即ち、表示装置が無い）システムに配置されることであるということが想定される。それ故に、設定、モニタリング、及び制御のための遠隔のアクセスが用いられる。上記一つの非限定的な典型的な実行では、インターフェースは、セキュリティ目的のためにＳＳＬを用いる、標準のＨＴＴＰベースの通信を用いて展開される。
【０４２８】
上記ＭＰＣＳの追加の負荷及び高容量ＭＥＳの配置をサポートするために、ＭＭＳクラスタリングサービスは、自動フェイルオーバサポートと共に、負荷の均衡及び共有を可能にする。
・各サーバプール（ＭＭＳＰ）内の各ＭＭＳシステムのヒエラルキークラスタリングは、接続された各システム及び／又は各ユーザのために、中断の無いオンザフライの能力を加えることを可能にする。ＭＭＳＰは、それらが地理的に分配されるか否かにより、さらに各ゾーンに集められてもよい。これは、中央制御及びクラスタの群れの管理を維持しながら、動的な選択あるいは優先権の設定を可能とする。
・上記ＭＭＳＰの全体にわたって多数の各ユーザあるいは各システムの適切な割当てを保証するために、フェイルオーバと統合された、自動的な負荷の均衡。あまり発生しないＭＭＳの故障と異なって、上記ＭＰＣＳｓによるサーバであるセッションを含むＭＥＳｓは、自動的にフェイルオーバされて、ゾーン内での上記ＭＭＳＰに残っている各サーバの全体にわたって、あるいはゾーン全体がアクセス不能のときに、可能であれば異なるゾーンに全体が割れ当てられて、均衡が保たれる。
【０４２９】
図２６を参照すると、この典型的に説明される非限定的な実施形態では、上記ＭＰＣＳ（システム５０００）は、ＭＭＳクラスタ（ＭＭＳＰシステム５１００）のメンバーである少なくとも一つのＭＭＳと、接続されたネットワークを介して通信できる場所を介して、接続拠点を有する少なくとも一つのネットワークあるいはサブネットワーク（ＰＰＮｓ５０１０、５０１５など）に接続される。
【０４３０】
与えられたＭＭＳＰの何れの各メンバーのセットが、付与されたゾーン内にて、１つあるいはより多くのシステムを含んでもよいということは理解されるであろう。その上、複数の各ゾーンは、優先権及び／又は有効性に基づいた選択を可能にするＭＭＳＰｓのクラスタリングを生成するために、結合されてもよい。
【０４３１】
一つの非限定的な例では、ＭＭＳＰの２つの各クラスタがあり、１つはニューヨークにあり（ゾーン１）、１つはロサンゼンルスにある（ゾーン２）。アメリカ西海岸にある装置は、近接性のためにゾーン２内のＭＭＳのサーバプールと通信することを優先してもよい。
【０４３２】
しかし、ゾーン２内のＭＭＳＰにおける各ＭＭＳシステムが、幾つかの理由のために、受容能力の理由のためにで、あるいは幾つかのポリシーの理由のためにアクセス不能となったとき、上記ＭＰＣＳ及び／又はＭＥＳは、ゾーン１（ニューヨーク）における上記ＭＭＳＰに、リディレクトされてもよく、フェイルオーバされてもよく、あるいは優先権に基づいて選択されてもよい。上記各システムの各エンドユーザは、選択／優先権のプロセスに関与してもよく、あるいは関与しなくともよい。
【０４３３】
与えられたプールの与えられたゾーンの内部のＭＭＳの間での負荷の均衡は、有効性、設定、及び負荷解析に基づき、制御され、ランダムな割当てにより成し遂げられる。上記負荷の均衡の機能性は、故障の単一な点を有しておらず、ＭＭＳＰプール５１００内の上記ＭＭＳｓへの通信を再び確立するＭＥＳ／ＭＰＣＳ５０００は、プールゾーン内の利用可能な負荷バランサの間で、リディレクトセッション要求が、ランダムに割り当てられるであろう。
【０４３４】
上記プールの内部のＭＭＳ間での周期的な通信により、アルゴリズムは、迅速に、アクセス不能な、あるいはリソースがブロックされたＭＭＳのピアを検出する。上記ＭＥＳ／ＭＰＣＳセッションのリディレクトは、安全な通信を介して生じる。
【０４３５】
初めに、上記プール（ＭＭＳＰ）内のＭＭＳの全ては、始動時に中央に設定されたオーソリティから各ピアのリストを読み出し、ＭＭＳＰ設定変更通知サービスへの加入者であることにより、このリストを最新のもの更新する。与えられたＭＭＳＰにおいて、少なくとも２つのタイプの各サーバが存在している。
・状態の各コレクターは、ＭＭＳであり、与えられたゾーンにおける与えられたプール内部の全ての他のオンラインＭＭＳからの状態メッセージを受信する。
・各リセプターは、ＭＭＳシステムであり、リディレクトされたＭＭＳ／ＭＰＣＳからリディレクトされたセッション要求を受け入れる。
【０４３６】
上記リスト内の少なくとも一つのＭＭＳが、状態コレクターとして設定されたとき、与えられたゾーンにおける与えられたプール内のＭＭＳの全ては、固定されたインターバルにて、上記プール内の全ての状態コレクターシステムに、そのサーバ状態メッセージを送信することを始める。状態をコレクトしているサーバがない場合、このメッセージを送信する活動は起こらない。ＭＭＳが設定プロセス内で、それを負荷のバランサであると検出したとき、直ちにクライアントのリディレクトする準備をして、負荷のバランサのポートを開放して、他のサーバからの状態メッセージを受け入れることを始める。
【０４３７】
上記中央に設定された情報は、上記ＭＭＳが、設定データ上でのみ負荷の均衡を行うことを可能にするが、それが固定された上記インターバル（タイムアウト有り）内にて返信が無いとき、ＭＭＳのためのクライアントをリディレクトしない。さらに、上記プール内の各々のサーバが、状態コレクター、リセプター、あるいは双方として動作することができるということは、正しく理解される。上記ＭＭＳが両方として動作する事例では、それは、それらをローカルに受け入れるのと同様に、ＭＭＳ／ＭＰＣＳセッションのリディレクトすることができる。
【０４３８】
ＭＰＣＳ５０００はさらに、モバイルな少なくとも一つの専用ネットワーク（ＭＰＮネットワーク５０２０）に接続されてもよい。ＭＰＣＳ／ＭＥＳ５０００に接続される１つ以上のＭＰＮがあってもよいということは明らかであろう。例えば、ＭＰＮは、８０２．１１ネットワーク、８０２．１５ネットワーク、あるいはＢｌｕｅｔｏｏｔｈネットワーク、ＷｉＭａｘの能力がある装置、あるいは他の有線の、あるいは無線のインフラストラクチャーに同時に接続されてもよい。
【０４３９】
新しい各ネットワークの各装置の全体は、各ネットワーク（ＶＭＰＮ）のヒエラルキー的な入れ子状の構造を提供するために、ロジカルに互いに結合されていてもよい。これらのネットワークあるいはサブネットワークの管理は、ＭＰＣＳ５０００のサービスを介して、あるいはＭＭＳＰによる中央管理により遂行されてもよい。簡潔な説明の目的のために、説明は、ＭＰＮ５０２０を介してアクセスすることに限った。ＭＰＮ５０２０への接続において、少なくとも以下に示す各タイプの各ノードを接続してもよい。
・固定されたモバイル端末システム（ＦＭＥＳ５０３０、５０３１、５０３２）
・訪問するモバイル端末システム（ＶＭＥＳ５０４０）
・訪問するモバイルクライアント（ＶＭＣ５０５０）
・追加の各ＶＭＰＮ（図示せず）
・その他の各装置
【０４４０】
本実施形態のＦＭＥＳｓ（５０３０〜５０３２）は、ＭＰＮ５０２０に接続された各ノードであり、永続的に接続されてもよいものである。これらの各装置は、これらのピアと通信するための一組の標準のインターネットモバイルプロトコルを用いる。しかし、色々の理由（費用、共通経費、等）のために、これらの装置は、“モバイルを意識した”装置ではない。
【０４４１】
これらの種類の、非限定的な装置の例は、カメラ、指紋リーダ、プリンタ、遠隔計測装置、あるいは乗物の内部に配置された単一の目的の装置であってもよい。単一の目的の装置は、修理／再配置のため、あるいは乗物それ自身が廃棄される場合に取り除かれるのみのものであってもよい。
【０４４２】
これらの装置がモバイルを意識していないので、普通は、これらの装置及び最終のピアの間で通信経路を中断することが生じたとき（即ち、ローミング、遮断、等）、データの損失、あるいは前述のモビリティに関する多くの問題に直面して、上記通信セッションは危険な状態になるという課題を生じることがある。
【０４４３】
これらの課題を解決するために、これらの装置は、通信セッションのためのプロキシとして動作するＭＰＣＳ５０００と直に通信するために設定されてもよい。ＭＰＣ５０００が、埋め込まれたＭＥＳにより提供される各機能に基づいているので、これらの通信セッションは、本発明に示す技術のメリットを得て、若干の修正、あるいは修正せずモバイルな環境で直ちに動作することができる。
【０４４４】
代りに、ＤＮＲ／ＤＮＳディレクトリプロキシの各サービスを採用することにより、それがＭＰＣＳ５０００と通信し合っているということを認識するようにＦＭＥＳを設定する必要が無い可能性がある。標準のネームリゾリューション技術を介して、上記各ＦＭＥＳのＭＰＣＳ５０００への通信をリディレクトすることは可能である。
【０４４５】
一度、上記通信セッションが、ＭＰＣＳ５０００に対し確立されると、上記通信セッションは、適切なアプリケーションの最終的なピアシステム（５０９０〜５０９１）との実際の通信セッションをプロキシする。その上、１つより多くのアプリケーションサービス（５０９０〜５０９１）のための、１つより多くの（more then one）アプリケーションセッションがあってもよいということ、及び上記アプリケーションサービス（５０９０〜５０９１）は、地理的な条件に分配されてもよく、あるいは１つより多い管理ドメインにより制御されてもよいということは明らかであろう。
【０４４６】
ＭＰＣＳ５０００により提供されるサービスを利用することができる他のタイプのシステムは、訪問するモバイル端末システム（ＶＭＥＳ５０４０）である。これらの装置は、ＭＥＳの機能性により既に提供されているタイプの装置である。
【０４４７】
これらの装置は、ＭＰＣＳ５０００と同一であるＭＭＳＰ、あるいはＭＰＣＳ５０００と完全に異なっているＭＭＳＰと通信していてもよい。ＭＰＣＳ５０００のＮＡＰＴ、ゲートウェイ結合エージェント、及びインターフェースシグナリングエージェントの使用を介して、これらの装置は、ＭＰＣＳ５０００に接続された、異なるＰＰＮｓ及びＭＰＮｓを認識して、使用する許可を与えられたものとなる。
【０４４８】
上記通信セッションが動作することの一部、あるいは上記ＶＭＥＳから立ち上げられた通信セッションが、さらに、ＭＰＣＳ５０００ベースのポリシーあるいは管理条件のプロキシサービスを用いるということは完全に可能である。
【０４４９】
一つの非限定的な典型的な実施形態では、ＶＭＥＳ５０４０は、ＰＰＮｓ５０１０及び／又は５０１５に関連付けられる変化を提示するために警報を出すためのＭＰＣＳ５０００のインターフェースシグナリングエージェントに登録することができる。各コンディション（利用可能な帯域幅（単位時間当たりの処理情報量）、ＱｏＳ、媒体接続状態、等）がＰＰＮｓ上で変わる場合、警報は、監視し／登録されたＶＭＥＳに送付されてもよい。
【０４５０】
その後、上記警報の受領は、登録されたＶＭＥＳ上の各機能において、下流での各変化の全てを考慮して、各コンディションを再評価させる。ポリシーあるいは他の各パラメータは、警報の状態に基づいて（例えば、圧縮を行う等の）調節されてもよい。さらに、上記登録の取り組み方法の代りに、これらの警報が、上記ＭＰＮｓ上の全ての各ノードにマルチキャスト／一斉通知されてもよいということは明らかであろう。これは、各々の装置が、ＭＰＣＳ５０００のインターフェースシグナリングエージェントとの通信の例を挙げて説明する必要性を低減できる。
【０４５１】
ＭＰＣＳ５０００により提供されるサービスを利用することができる他のタイプのシステムは、訪問するモバイルクライアント（ＶＭＣ５０６０）である。ＶＭＣ５０６０は、モビリティを意識、又は意識しなくてもよい装置であるが、ＭＰＮｓ５０２０に接続されたＦＭＥＳを検討する上記セットの一部ではない。
【０４５２】
一つの非限定的に説明する実施形態では、ＶＭＣ５０６０は、１つの接続点から他の接続点に移動してもよいが、通信セッションが、アクセス不能のネットワークにおいても持続するということを要求できない。この非限定的な例は、一つの試験装置のような実験室の環境で一般的に用いられる装置であってもよい。
【０４５３】
その上、これらの装置は、ＭＰＮ５０２０に対し永続的に接続されないクラスに分類されると考えられるが、適切なアプリケーションの最終的なピアシステム５０９０及び／又はピアシステム５０９１と通信するためのＭＰＣＳ５０００のサービスを使用することが好ましい。
【０４５４】
このケースでは、上記システムは、アプリケーションレベルのプロキシエージェントあるいはＰＰＮｓ５０１０／５０１５を介して通信するためのＭＰＣＳ５０００上のＮＡＰＴサービスを採用することが可能である。
【０４５５】
さらに別の非限定的に説明する実施形態では、上記ＶＭＣｓは、モバイルなＩＰのような代りのモバイル技術を用いることにより、モバイルを意識したものとしてもよい。この方法で提供される場合、上記ＶＭＣは、さらにゲートウェイ結合／リメディエーションエージェント、ＮＡＰＴ／フォーリン／ホームエージェント、及び／又はアプリケーションプロキシレベルのサービスのような上記ＭＰＣＳ上のサブセットの利用可能なサービスを利用できる。
【０４５６】
本発明の、非限定的に説明する技術のさらに別の観点は、図２６に図示されないが、明瞭に説明する目的のために、全体のＭＰＮあるいは他のＭＥＳ／ＭＰＣＳで構成されるＶＭＰＮｓのような前述されたようなものは、そのＰＰＮｓの一つとしてＭＰＮ５０２０に接続されることを最終的に決めてもよく、上記ＶＭＰＮに接続された装置が、ＭＰＣＳ５０００のサービスを用いることを可能にする。
【０４５７】
一つの非限定的な例では、上記ＶＭＰＮが、その現在のＰＰＮｓの全てがアクセス不能と決定したケースでは、ＭＰＣＳ５０００が範囲内であり、ＰＰＮｓ５０１０及び／又はＰＰＮｓ５０１５を介してネットワークリソースへのアクセスを有しているという認識可能なものであってもよい。
【０４５８】
この段階では、それは、ＭＰＮ５０２０を結合することを要求してもよく、可能であるならば、ＭＰＮ５０２０のサービスを使用することを始めてもよい。たとえ、ＰＰＮｓそれ自身が、もう一度、ポリシーのベースにアクセス可能になったとしても、上記ＶＭＰＮは、ＭＰＮ５０２０のサービスを使用することの継続を決定してもよい。
【０４５９】
このケースでは、ＭＰＣＳ５０００が、上記ＶＭＰＮに接続された上記ＰＰＮｓに対して、ネットワーク群５０７０のためのより高い質のリンクを有し得るということは、十分可能である。さらに他の実施形態では、上記ＶＭＰＮに接続された上記ＰＰＮｓがアクセス可能になるとき、上記ＶＭＰＮ及びＭＰＳＣが、実際に役割を入れ換えるということは可能である。このケースでは、ＭＰＣＳ５０００は、他のＭＰＣＳのためのＶＭＰＮになる。
【０４６０】
何れのケースでも、さらに上記ＭＥＳ／ＭＰＳＣの各サービスの各能力により、非限定的な実施形態では、上記各装置の何れかにおいて、もし、管理的なポリシーによって設定され、可能とされるとき、ネットワーク上あるいはサブネットワーク上の他のノードにより消費されるサービスへのアクセスを公表することは望ましいということは明らかであろう。
【０４６１】
ＭＰＮ５０２０に接続されてもよいシステムの変形例によれば、上記ＭＰＮｓ及びＰＰＮｓへのアクセスを管理及び制御する必要がある。ＭＰＣＳ５０００のゲートウェイ結合／リメディエーションエージェントサービスは、これを遂行して、ＭＰＮ５０２０に接続されてもよい装置を介して、ローカルの、及び集中的な管理制御を可能にする。
【０４６２】
このサービスは、認証、許可、及び課金のために必要な構成要素を提供する。一つの非限定的な実施形態では、上記サービスは、８０２．１ｘ、Ｒａｄｉｕｓ、等のような標準化された認証サービスを含み、より多くの許可を与える認証サービスのためのプロキシあるいはサプリカントとして動作してもよい。
【０４６３】
上記サービスを上記様式にて配置することは、ＭＰＣＳ５０００が内容証明データのローカルのキャッシュを要求しないので、セキュリティの欠陥を露呈する可能性を制限し得る。
【０４６４】
しかし、幾つかの状況では、ＰＰＮｓ５０１０及びＰＰＮｓ５０１５へのアクセスが利用できない場合に、動作の遮断モードを可能とするための、ローカルの認証をサポートする必要があり得る。一度、上記装置の認証及び許可がうまく決定されると、上記接続された装置が、特定の管理ガイドラインの範囲内で動作しているということを保証するために、追加の検査を発動してもよい。
【０４６５】
上記ガイドラインの一つの非限定的な例は、少なくとも特定のバージョンのアンチウイルスプログラム及びそれに関連付けられる定義を用いることを装置に要求することがあり得る。上記装置が、特定の要求を充足しない場合、上記装置は、上記要求を充足するための必要な最新のものを含む、信用が付与された領域にリディレクトされてもよい。代りに、さらに別のアクセスを無効あるいは否定するようにしてもよい。上記無効あるいは否定は、プロキシエージェント、ＮＡＰＴ／ホーム／フォーリンのエージェントあるいはリンク階層でのネットワーク制御能力の何れかと協動して遂行されてもよい。
【０４６６】
〔非限定的に説明する実施例〕
本発明は、実社会の様々な場面で応用される。例を以下に示す。
【０４６７】
（断続的に接続される携帯用コンピュータ）
多くの企業では、在宅勤務や、自宅で仕事をする社員がいることがある。そういった社員は、多くの場合、ラップトップコンピュータを使用して仕事をする。作業中に、社員は一般に自分達のラップトップコンピュータをドッキングポート又は他のコネクタを使用してイーサネット等のローカルエリア・ネットワークに接続する。ＬＡＮ接続によってネットワークサービス（例えば、プリンタ、ネットワークドライブ）やネットワーク・アプリケーション（例えば、データベースアクセス、電子データサービス）にアクセスが可能となる。
【０４６８】
あるプロジェクトに取り組む社員が、晩に帰宅する必要があり、自宅で仕事を続行したいとする。この社員は、ラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「サスペンド」して、ラップトップコンピュータを片付け、そのラップトップコンピュータを自宅に持って帰ることができる。
【０４６９】
自宅に戻るとすぐに、その社員はラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「レジューム」して、ダイアルアップ接続を介して、及び／又はインターネットを通じてオフィスＬＡＮと再接続する。（ラップトップコンピュータが一時的に中断された間、ネットワークに対するラップトップコンピュータとそのアプリケーションのプロキシを継続した）モビリティ管理サーバは、ラップトップコンピュータを再認証し、ラップトップコンピュータとの通信を再開する。
【０４７０】
自宅で仕事をしている社員の立場から見ると、ネットワーク・ドライブ・マッピング、印刷サービス、電子メールセッション、データベースクエリ、他のネットワークサービスやアプリケーションは全て会社で終わった状態そのままである。さらに、モビリティ管理サーバはラップトップコンピュータのセッションのプロキシを継続したため、社員の会社から自宅までの帰宅途中に、いずれのネットワーク・アプリケーションもラップトップコンピュータのセッションを終了しなかった。このように、本発明は、上記のような状況や他の状況において、高性能且つ有用な同一又は複数のネットワーク媒体を通じて効果的にセッションを持続可能とする。
【０４７１】
（モバイル在庫管理及び倉庫への応用）
大きな倉庫又は小売店チェーンを想定する。この構内において、在庫管理を行う従業員がパーソナルラップトップコンピュータ、並びにハンドヘルドデータ収集ユニットや端末装置などを搭載した乗物（すなわち、トラックやフォークリフト）を使って商品の在庫管理が行われる。
【０４７２】
倉庫や小売店の従業員は、ネットワークサブネットのわからない、管理監督の必要な不慣れなコンピュータユーザであることが多い。本発明によって倉庫ユーザがモバイルネットワークの複雑さを感じない、即使用可能なシステムの構築が可能となる。倉庫ユーザは、アクセスポイントの範囲内及び範囲外を動いたり、自分たちのモバイル端末システム１０４の中断及び再開をしたり、ホストセッション、ネットワークアドレス、又はトランスポート接続を気にせずに、位置を変えたりできる。さらに、モビリティ管理サーバ１０２の管理ソフトウェアは、従業員の生産能力を測るのに利用される処理数等のメトリクスを管理関係者に提供する。また、管理によりネットワークサブネット及びアクセスポイントを使用して従業員が最後にいたとされる物理的な位置を判定できる。
【０４７３】
（モバイル医療への応用）
無線ＬＡＮ技術を利用して幾つかの建物間でネットワーク通信を行う大きな病院を想定する。各建物は独自のサブネット上にある。本発明によって看護士や医師がハンドヘルドパーソナルコンピュータや端末を持って病室から病室を動き、病院のデータベースから患者情報の読出しや書込みが可能となる。ローカルデータベースやワールド・ワイド・ウェブを通じて、薬物治療や医療処置に関する最新記事へのアクセスが即座に可能となる。本発明はモバイル端末システム１０４への連続的な接続が可能なので、病院にいる間（一方向又は双方向の）ポケットベルはもはや必要なくなる。メッセージはモバイル端末システム１０４を介して医療関係者に直接送られる。倉庫の従業員の場合と同様、医療関係者は自分たちが利用しているモバイルネットワークについてわかる必要はない。さらに、モバイル端末システム１０４によって医療関係者は無線送信が望ましくないとされるエリア内（例えば、電波の放射によって医療機器に障害が出る可能性のある場所）での無線伝送ができなくなるが、中断したところから容易に再開して再接続可能となる。
【０４７４】
（トラック輸送及び貨物輸送）
運送会社は、貨物の状況を把握するのに本発明を用いる。倉庫に入っている間は、モバイル端末システム１０４はＬＡＮ技術を使用して倉庫内の貨物数を更新する。ローカルサービスから離れている間は、モバイル端末システム１０４はＣＤＰＤやＡＲＤＩＳなどのＷｉｄｅ  Ａｒｅａ  ＷＡＮサービスを使用してリアルタイムで貨物の状況や位置を維持できる。モバイル端末システム１０４はネットワーク・インフラストラクチャ間を自動的に切り替えるので、輸送関係者にネットワーク・トポロジの複雑さを感じさせない。
【０４７５】
（モバイル企業）
企業の社員は、８０２．１１．等のインフラストラクチャが設けられた企業構内にいる間、本発明によるシステムを使用して、電子メール、ウェブコンテント、メッセージサービスへのアクセスを行う。ポケットベルサービスや他のモバイル機器のサービスはもはや必要ないので、これらを維持するためのコストが削減される。既存のモバイル機器サービスの多くが提供する、コストのかかる「利用回数制」モデルに対し、モバイルインフラストラクチャは一度の資金支出で購入できる。
【０４７６】
（ＩＰマルチプリケーション）
ある組織がインターネットに接続する必要のあるＬＡＮを有する場合、ＬＡＮの管理者には二つの選択肢がある。一つ目の選択は、ＬＡＮ上の全てのコンピュータに対して割り当てるためのグローバルアドレスを取得することであり、二つ目の選択は、グローバルアドレスをいくつか取得して、アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ１０２を使用することである。多数のＩＰアドレスを取得することは、高額であるか不可能であるかである場合が多い。インターネット・サービス・プロバイダ（ＩＳＰ）を利用してインターネットにアクセスする小規模の企業は、ＩＳＰが割り当てるＩＰアドレスだけを使用することになる。ＩＰアドレスの数は同時にインターネットに接続できるコンピュータの数を制限する。また、ＩＳＰは一回の接続につき課金するため、インターネット接続が必要なコンピュータが増えれば増えるほど、この方法はそれだけ費用がかかる。
【０４７７】
アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ１０２を用いれば、これらの問題の多くを解決することができる。企業は、ＩＳＰを介してインターネットに接続するためのハードウェアとしてモビリティ管理サーバ１０２を用いることができる。これにより、モバイル端末システム１０４は容易に接続することができる。インターネットへの接続は全てモビリティ管理サーバ１０２を通じて行われるため、一つのアドレスだけをＩＳＰから取得すればよい。このように、アドレス・マルチプライヤとして本発明を用いることによって、企業はわずかな数（多くの場合一つ）のアドレスとアカウントをＩＳＰから取得すればよくなり、全体のＬＡＮでインターネットへの同時接続（十分な帯域幅が備えられていることを前提として）が可能になる。
【０４７８】
〔一時的なコマンドのポスト及びモバイルオフィス／ストア〕
ＭＥＳ／ＭＰＣＳ５０００のサービスを用いることは、一時的なコマンドのポストを設定する必要がある、企業あるいは公的な安全／最初に応答する組織のような環境下において重要な問題を解決する。上記一時的なコマンドのポストが配置される場合、本発明に述べられる技術を備えるレクリエーショナル乗物（ＲＶ）あるいは救急車／警察のパトロールカー／消防安全の乗物のような好適な乗物は、ＭＰＣＳ５０００に接続されたＰＰＮネットワークを介してホームオフィスに配置される、消費者のバックエンドサービスになるモバイルなコマンドのポストに接続されたローカルに管理された装置と通信することが可能となる。
【０４７９】
逆に、一時的なコマンドのポストに配置される各サービスは、ホームオフィスに戻って接続される各ノードからアクセスされてもよい。一例は、組織の本部で、専用のバックアップ要員からのエキスパートの技術あるいは医療の遠隔から援助を可能とするカメラである。状態情報は、さらに、一時的なコマンドのポストで動作するモバイル資産（assets）の位置を検出するために、遠隔にて集められることが可能である。一時的なコマンドのポストで受信している座標に基づいて、消防署／司令部から、消防の職員が現場にいる場所を遠隔にて追跡できることも一考に値する。
【０４８０】
他の例は、人の乗物の外で働き、ホームオフィスとの通信に必要な多数の装置（プリンタ、カメラ、等）を有する保険の査定人のような個人である。さらに他の上記例は、固定されたインフラストラクチャーへのアクセスが制限される、あるいは存在しないコンサートの開催地、フリーマーケット、等のような売り場の状況を含む。
【０４８１】
以上現在最も実用的且つ好適な実施形態とされる例と共に本発明を説明したが、本発明は開示した実施形態に限定されず、添付クレームの範囲内で種々に変形、同等に構成できるものとする。
【図面の簡単な説明】
【０４８２】
【図１】本発明のモバイル・コンピューティング・ネットワークの全体図である。
【図２】モバイル端末システムとモビリティ管理サーバとのソフトウェア・アーキテクチャを例示するものである。
【図２Ａ】モバイル端末システムとモビリティ管理サーバとの間で情報伝達を実行するステップを例示している。
【図３】モバイル・インターセプタ・アーキテクチャを例示している。
【図３Ａ】モバイル・インターセプタによって実行されるステップを例示したフローチャートである。
【図３Ｂ】ＲＰＣ作業要求を扱うＲＰＣエンジンによって実行されるステップを例示したフローチャートである。
【図４】ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５】ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ａ】ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ｂ】ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ｃ】ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図６】受信された作業要求を例示している。
【図７】受信された作業要求が、どのようにそれぞれ別の優先度のキューにディスパッチされるかを示すものである。
【図８】上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図９】上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図１０Ａ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１０Ｂ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１０Ｃ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１１】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ａ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ｂ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ｃ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ａ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ｂ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ｃ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１４Ａ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１４Ｂ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１５Ａ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１５Ｂ】インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１６】リスナのデータ構造を例示している。
【図１７】モバイル相互接続ローミングを提供するためのステップを例示している。
【図１７Ａ】モバイル相互接続ローミングを提供するためのステップを例示している。
【図１８】モバイル相互接続ローミングを提供するためのステップを例示している。
【図１９Ａ】インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図１９Ｂ】インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図２０】インターフェイスによって補助されているローミングのトポロジ・ノード・データ構造を例示する。
【図２１】モビリティ管理システムのネットワークアドレスを、非接続ネットワーク・トポロジにおいてモバイル端末システムに配布する技術を例示している。
【図２２】図２１の技術を、セキュアな通信を実現するために利用した例を示している。
【図２３】図２１の技術を、分散型ネットワーク・インターフェイス・シナリオにおけるネットワークアドレスの変換に用いた例を示している。
【図２４】ポリシー管理テーブルを例示している。
【図２５】ポリシー管理処理のステップを例示したフローチャートである。
【図２６】ＭＭＳクラスターを含むゲートウエイでの、移動自在なプロキシ通信の例を示すブロック図である。
【図２７】ゲートウエイでの、移動自在なプロキシ通信の例を示し、本発明を限定せずに説明するソフトウェアアーキテクチャのブロック図である。
【図２８】リスナおよびサービスにおいて、負荷の均衡を保つことを説明し、図示するフローチャートである。
【図１】
2008508837.tif 000002
【図２】
2008508837.tif 000003
【図２Ａ】
2008508837.tif 000004
【図３】
2008508837.tif 000005
【図３Ａ】
2008508837.tif 000006
【図３Ｂ】
2008508837.tif 000007
【図４】
2008508837.tif 000008
【図５】
2008508837.tif 000009
【図５Ａ】
2008508837.tif 000010
【図５Ｂ】
2008508837.tif 000011
【図５Ｃ】
2008508837.tif 000012
【図６】
2008508837.tif 000013
【図７】
2008508837.tif 000014
【図８】
2008508837.tif 000015
【図９】
2008508837.tif 000016
【図１０Ａ】
2008508837.tif 000017
【図１０Ｂ】
2008508837.tif 000018
【図１０Ｃ】
2008508837.tif 000019
【図１１】
2008508837.tif 000020
【図１２】
2008508837.tif 000021
【図１２Ａ】
2008508837.tif 000022
【図１２Ｂ】
2008508837.tif 000023
【図１２Ｃ】
2008508837.tif 000024
【図１３Ａ】
2008508837.tif 000025
【図１３Ｂ】
2008508837.tif 000026
【図１３Ｃ】
2008508837.tif 000027
【図１４Ａ】
2008508837.tif 000028
【図１４Ｂ】
2008508837.tif 000029
【図１５Ａ】
2008508837.tif 000030
【図１５Ｂ】
2008508837.tif 000031
【図１６】
2008508837.tif 000032
【図１７】
2008508837.tif 000033
【図１７Ａ】
2008508837.tif 000034
【図１８】
2008508837.tif 000035
【図１９Ａ】
2008508837.tif 000036
【図１９Ｂ】
2008508837.tif 000037
【図２０】
2008508837.tif 000038
【図２１】
2008508837.tif 000039
【図２２】
2008508837.tif 000040
【図２３】
2008508837.tif 000041
【図２４】
2008508837.tif 000042
【図２５】
2008508837.tif 000043
【図２７】
2008508837.tif 000044
【図２８】
2008508837.tif 000045
【図２６】
2008508837.tif 000046
【国際調査報告】
2008508837.tif 000047