JP2004509539A - コンピュータ環境におけるモバイル他の断続的接続性を提供する方法および装置 - Google Patents
コンピュータ環境におけるモバイル他の断続的接続性を提供する方法および装置 Download PDFInfo
- Publication number
- JP2004509539A JP2004509539A JP2002527943A JP2002527943A JP2004509539A JP 2004509539 A JP2004509539 A JP 2004509539A JP 2002527943 A JP2002527943 A JP 2002527943A JP 2002527943 A JP2002527943 A JP 2002527943A JP 2004509539 A JP2004509539 A JP 2004509539A
- Authority
- JP
- Japan
- Prior art keywords
- network
- mobile computing
- computing device
- mobile
- interface
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims description 201
- 238000012545 processing Methods 0.000 claims abstract description 47
- 230000002085 persistent effect Effects 0.000 claims abstract description 8
- 238000007726 management method Methods 0.000 claims description 200
- 230000008569 process Effects 0.000 claims description 72
- 230000006854 communication Effects 0.000 claims description 58
- 238000004891 communication Methods 0.000 claims description 58
- 230000032258 transport Effects 0.000 claims description 57
- 230000004044 response Effects 0.000 claims description 54
- 230000005540 biological transmission Effects 0.000 claims description 47
- 230000008859 change Effects 0.000 claims description 46
- 230000007246 mechanism Effects 0.000 claims description 16
- 230000000694 effects Effects 0.000 claims description 12
- 238000001514 detection method Methods 0.000 claims description 9
- 230000011664 signaling Effects 0.000 claims description 6
- 238000012546 transfer Methods 0.000 claims description 6
- 230000006399 behavior Effects 0.000 claims description 5
- 230000003111 delayed effect Effects 0.000 claims description 5
- 238000012986 modification Methods 0.000 claims description 5
- 230000004048 modification Effects 0.000 claims description 5
- 238000013500 data storage Methods 0.000 claims description 2
- 238000007499 fusion processing Methods 0.000 claims description 2
- 238000005259 measurement Methods 0.000 claims 1
- 230000006870 function Effects 0.000 description 46
- 239000012634 fragment Substances 0.000 description 26
- 238000005516 engineering process Methods 0.000 description 13
- 230000009471 action Effects 0.000 description 9
- 230000006855 networking Effects 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 230000004927 fusion Effects 0.000 description 7
- 230000000670 limiting effect Effects 0.000 description 7
- 239000008186 active pharmaceutical agent Substances 0.000 description 6
- 238000012790 confirmation Methods 0.000 description 6
- 238000013467 fragmentation Methods 0.000 description 6
- 238000006062 fragmentation reaction Methods 0.000 description 6
- 230000002829 reductive effect Effects 0.000 description 6
- 238000003860 storage Methods 0.000 description 6
- 239000003795 chemical substances by application Substances 0.000 description 5
- 230000003068 static effect Effects 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 4
- 238000011084 recovery Methods 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 206010000210 abortion Diseases 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 238000013519 translation Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 238000003619 Marshal aromatic alkylation reaction Methods 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 230000008878 coupling Effects 0.000 description 2
- 238000010168 coupling process Methods 0.000 description 2
- 238000005859 coupling reaction Methods 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 239000003814 drug Substances 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000003032 molecular docking Methods 0.000 description 2
- 238000007639 printing Methods 0.000 description 2
- 238000012913 prioritisation Methods 0.000 description 2
- 230000002459 sustained effect Effects 0.000 description 2
- 241001417511 Ardis Species 0.000 description 1
- 208000015976 Corneal dystrophy-perceptive deafness syndrome Diseases 0.000 description 1
- 206010019233 Headaches Diseases 0.000 description 1
- 235000008694 Humulus lupulus Nutrition 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009118 appropriate response Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000002860 competitive effect Effects 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 229940079593 drug Drugs 0.000 description 1
- 238000002592 echocardiography Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000007274 generation of a signal involved in cell-cell signaling Effects 0.000 description 1
- 231100000869 headache Toxicity 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000005855 radiation Effects 0.000 description 1
- 230000008707 rearrangement Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000010561 standard procedure Methods 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 238000012876 topography Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000011282 treatment Methods 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/188—Time-out mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1887—Scheduling and prioritising arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/133—Protocols for remote procedure calls [RPC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/563—Data redirection of data network streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/564—Enhancement of application control based on intercepted application data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
- H04W12/088—Access security using filters or firewalls
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1809—Selective-repeat protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0894—Policy-based network configuration management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/08—Reselecting an access point
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
- Small-Scale Networks (AREA)
Abstract
ノマディックなシステムの特性を透過的にする、シームレスなソリューションであって、既存のネットワーク・アプリケーションが、モバイル環境でも確実に動作するようにする。モバイルネットワークと組み合わされたモビリティ管理サーバ（１０２）は、数量を限定されないモバイル端末システム（１０４）それぞれの状態を維持し、ネットワークへ、および他のピアでの処理への持続的な接続の維持に必要な、複雑なセッション管理を実行する。モバイル端末システムが圏外に出たり、サスペンドしたり、（例えば、あるネットワーク相互接続から別のものへとローミングして）ネットワークアドレスを変更したりした場合、モビリティ管理サーバは、結合しているピアのタスクとの接続を維持し、モバイル端末システムとネットワーク媒体とのコンタクトが一時的に失われても、モバイル端末システムが持続的な接続を維持できるようにする。インターフェイスベースのリスナは、ネットワーク・インターフェイスからのネットワーク接続ポイント情報を利用して、ローミング状態を判定し、ローミングに際した接続を効率的に確立する。モビリティ管理サーバは、非接続のネットワーク上で該サーバとコンタクトをとるためのリストを、モバイル端末システムに配布する。
Description
［発明の背景］
本発明は、ネットワークによって接続されたコンピュータ装置間の接続性に関する。より詳細には、ノマディック（ｎｏｍａｄｉｃ）システムの特性を透過性（トランスペアレント）を有する状態で扱うとともに、既存のネットワーク・アプリケーションを、対応するモバイル環境で確実に動作させる方法とシステムに関する。さらに詳細には、断続的に接続される、携帯型データ端末（ｈａｎｄｈｅｌｄ ｄａｔａ ｕｎｉｔｓ）やパソコン装置などの装置間における、連続的なデータストリームのやり取りを可能にする技術およびシステムに関する。
【０００１】
［発明の背景および要約］
近年、各企業は、重要な情報への迅速なアクセスこそが競争優位を保つための方策であると認識するようになってきた。このことから、特に安価なラップトップやハンドヘルドのコンピュータ装置の普及とも相まって、モバイルなどの断続的な接続が行われるコンピュータ装置が急速に企業ネットワークの重要な一要素となりつつある。しかしながら、こうしたノマディックな装置を既存のネットワーク・インフラへと統合することは、各企業の情報管理担当者にとって頭の痛い問題ともなっている。
【０００２】
モバイルネットワーキングに関する問題の多くは、イーサネット（登録商標）登場以前にローカルエリア・ネットワーク（ＬＡＮ）構築に伴っていた問題に近い。即ち、モバイル・プロトコルやインターフェイスには多くの種類があり、また、まだ規格が制定段階にあることから、異なるシステム間の相互運用性は無いも同然である。さらに、上記のようなネットワーク技術による通信はたいてい低速で帯域幅も限られており、各システムの特殊性から、アップデートに伴う費用も高額になっている。
【０００３】
こうした問題に加えて、モバイル技術は、以下のような固有の問題も有している。即ち、メインのネットワークと相互接続するの際には公共のネットワーク・インフラを経由する場合があるが、この際に機密情報が傍受されてしまう危険性がある。さらに、無線装置を経由して相互接続する場合であれば、機密情報がいわば「放送」されてしまうことになり、類似のインターフェイスを所有する誰もが該情報をたいした障害もなく傍受することができてしまう。
【０００４】
しかし、おそらく上記のような問題よりもさらに重要な問題としては、従来、モバイルネットワーキングが使われるのは基本的にメッセージ指向あるいはステートレスなアプリケーションに限られていて、クライアント／サーバ、ホスト／ターミナル方式をとるウェブベースあるいはファイル共有型のシステムモデルを利用した、既存あるいは新規の業務用アプリケーションには適さなかったことである。これは、一般的な業務用アプリケーションが効果的かつ確実に動作するためには、ステートレスなパケット交換だけでなく、連続的なデータストリームを用いたステートフルなセッションが必要であるという理由からであった。
【０００５】
このため、主要な市販のネットワーク・アプリケーションのほとんどは、ＴＣＰ／ＩＰセッションか、専用の仮想回路を必要としている。このようなセッションは、ネットワークが中断された場合はそれ以上機能できず、また接続時には、ネットワーク間のローミング（ネットワークアドレスの変更）が不可能である。さらに、モバイルネットワーキングは本質的に動的であり信頼性が低い。これらの問題について、以下では、モバイルネットワークにおいてよく見られる状況をいくつか考察することにする。
【０００６】
（非接続あるいは圏外のユーザ）
モバイル装置が所与のネットワークから切断されるかあるいはネットワークとのコンタクトを失う（つまり、無線相互接続の圏外に出たりネットワークがカバーしていない「穴」に入ったりする）と、携帯装置上で動作しているセッション指向のアプリケーションはピアとのステートフルな接続を失い、動作を停止する。装置が再び取り付けられるかあるいは装置とネットワークとのコンタクトが回復すると、ユーザはネットワークとの再接続を行い、セキュリティ確保のために再ログインを実行して、アプリケーションにおいてどこで作業が中断されたかを同定し、必要ならば失われたデータの再入力を行わなければならない。このような再接続処理は時間を要し、費用もかかり、またユーザを非常に苛立たせることにもなる。
【０００７】
（他のネットワークへの、あるいはルータ境界を越える移動（ネットワークアドレス変更））
モバイルネットワークは通常、管理容易性の見地からセグメント化されているが、一方でモバイル装置はその用途上、ローミングが可能になっている。相互接続されたネットワーク間のローミングとは、ネットワークアドレスが変更されるということを意味する。ネットワークアドレスがシステムの動作中に変更される場合、対応しているピア同士の接続を保つためにルーティング情報を変更することが必要になる。さらに、新しいネットワークアドレスを取得するために、それまでに確立されたステートフルなアプリケーションのセッション全てを終了させなければならない場合もあり、上記の再接続処理に関わる問題がここでも浮上する。
【０００８】
（セキュリティ）
既に述べたように、各企業は機密情報を守る必要がある。市販のアプリケーションの多くは、物理的ネットワークへのアクセスがコントロールされ（つまり、安全な施設の内部に構築されたケーブルを使って実行され）、セキュリティは、認証や場合によっては暗号化に関する付加的な層を通じて保持されることを前提として作成されている。しかしながら、ノマディック・コンピューティングではこうした前提は自明のものではない。というのも、公共の電波や有線インフラを通過する際にデータが傍受されてしまう危険性があるからである。
【０００９】
このため、ノマディックなシステムの特性を透過性を有するものとすることによって、既存のネットワーク・アプリケーションが種々のモバイル環境で確実に動作することを可能にした、統合的なソリューションの登場が大いに望まれる。
【００１０】
本発明は、上記の問題を解決するために、企業内ネットワークを延長して、ネットワーク管理者がモバイル装置のユーザも固定装置のユーザと同じアプリケーションに容易にアクセスできるようにすることを可能にすると同時に、信頼性やネットワーク管理の一元性も失わない、一貫したソリューションを提示する。該ソリューションは、これまでの有線ネットワーク規格の長所を、発展しつつあるモバイルネットワーキングに関する規格にも持たせることで、既存のネットワーク・アプリケーションにも対応したものとなっている。
【００１１】
本発明の非限定的で例示的具体的な実施の形態の一側面においては、モバイル相互接続（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ）に接続されたモビリティ管理サーバ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ； ＭＭＳ）は、数量を限定されないモバイル端末システム（Ｍｏｂｉｌｅ Ｅｎｄ Ｓｙｓｔｅｍｓ； ＭＥＳ）それぞれの状態の維持や、ネットワークへおよびピアにおけるアプリケーション処理への持続的な接続の維持に必要な、複雑なセッションの管理を行う。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは（あるモバイル相互接続から別の相互接続へとローミングすることなどで）ネットワークアドレスを変更したりした場合でも、モビリティ管理サーバは該システムと、該システムと対応しているピアとの接続を維持する。言い換えれば、該モバイル端末システムは、実際には物理的な接続が一時中断されてしまうにも関わらず、ピアとの仮想的な接続を維持し続けることになる。
【００１２】
また、上記本発明の非限定的で具体的な実施の形態は、以下の（これらに限定されないが）新規かつ有用な技術、構成を提示する。
【００１３】
・ユーザによって設定可能なセッション特性をモバイル・クライアントに付与するモビリティ管理サーバ。
【００１４】
・ネットワーク・リソースの消費に関し、ユーザごとにモバイル装置のポリシーを管理。
【００１５】
・工業規格である動的ホスト構成プロトコル（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ； ＤＨＣＰ）をモビリティ管理サーバと連携させて用いるローミング方法。
【００１６】
・ユーザによって設定可能なタイムアウト条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
【００１７】
・ユーザによって設定可能な再試行条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
【００１８】
より詳細には、上記本発明の好ましい具体的な実施形態の一例において、モバイル相互接続ネットワークに接続されたモビリティ管理サーバが備えられている。該モビリティ管理サーバは、数量を限定されないモバイル端末システムそれぞれの状態を維持し、ネットワークへおよび他の処理（例えば他のネットワークベースのピア・システムにて実行される処理）への持続的な接続の維持に必要な、複合的なセッションを管理する。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは（あるモバイル相互接続から別の相互接続へとローミングすることなどで）ネットワークアドレスを変更したりした場合、モビリティ管理サーバはデータの受信と待機要求を認識して、該システムと、該システムと対応しているピアとの接続を維持する。このようにモビリティ管理サーバがプロキシとして働くことにより、モバイル端末システム上で動作するアプリケーションは、あるネットワーク媒体との物理的な接続が一時的に中断された場合でも、持続的な接続を維持することができる。
【００１９】
また、上記本発明の好ましい実施の形態の他の一例において、モビリティ管理サーバはモバイル端末システム用のアドレスを管理する。モバイル端末システムには、それぞれにプライマリネットワーク上のプロキシ・アドレスが割り当てられている。この非常に汎用性の高いアドレスはモバイル端末システムの「仮想アドレス」と呼ばれる。モビリティ管理サーバはこの仮想アドレスを、ノマディック・システムにおける現在の「位置」アドレスと対応付ける。モバイル端末システムの位置アドレスは、該システムがネットワーク間を移動する際に変更されるが、仮想アドレスの方は、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【００２０】
上記本発明の好ましい実施形態のさらに他の一例において、モビリティ管理サーバは、コンソール（制御）アプリケーションと包括的なメトリクスとによってモバイル端末システムの集中的な管理を実現する。さらに、好ましい実施形態では、ユーザによって設定可能なセッション特性を、プロキシ・サーバ上で実行されるモバイル・クライアントについて実現し、ネットワーク・リソースの消費に関し、ユーザごとにモバイル装置のポリシー設定を管理する。
【００２１】
さらに、上記一側面においては、遠隔プロシージャ・コール（ＲＰＣ）・プロトコル（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ ｐｒｏｔｏｃｏｌ）およびインターネット・モビリティ・プロトコル（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ Ｐｒｏｔｏｃｏｌ）が、プロキシ・サーバと各モバイル端末システムとの間の通信の確立に使用されている。
【００２２】
遠隔プロシージャ・コールによって、ローカルなシステムから、遠隔のシステムにおけるプロシージャを呼び出す処理が可能になり、ＲＰＣプロトコルを使用することで、モバイル端末システムが接続を切ったり、圏外に行ったり、動作をサスペンドしたりということを、アクティブなネットワークセッションを中断することなくできるようになる。このように、セッションの維持は専用のアプリケーションによってなされるわけではないので、市販のアプリケーションを、何ら変更することなくノマディックな環境下で使用することができるようになる。
【００２３】
ＲＰＣプロトコルは、トランザクションを、標準的なネットワークトランスポート・プロトコルおよびインフラを経由して送られるメッセージに生成する。このＲＰＣメッセージは、モバイル端末システムにおいて実行されているアプリケーションによって開始されたネットワーク・トランザクション全体を含んでおり、これにより、モビリティ管理サーバとモバイル端末システムとの間の接続状態情報を、両者の間の物理的な接続が途切れているときをも含め、常にシンクロさせておくことが可能になる。ＲＰＣを備える上記本発明の実施の形態において、プロキシ・サーバとモバイル端末システムとは、全ての時間における全ての共有接続に関する統一された論理データベースを管理すべく、各トランザクションの状態について十分な情報を共有している。
【００２４】
上記本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルは、有線のローカルエリア・ネットワークと、それよりも信頼性の低い、無線ＬＡＮおよびＷＡＮといったネットワークとの間の相違を補償する。フレームサイズとプロトコルタイミングとが調整されることで、モバイル環境を考慮していない通信に比べるとパフォーマンスが大幅に改善され、ネットワークのトラフィックは大きく減少する。これは、帯域幅が限られているときやバッテリーの寿命を考慮に入れなければならないときに、特に重要になる。さらに、上記本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルによって、公共のネットワークもしくは無線を通じて、モバイル端末システム―モビリティ管理サーバ間で伝送が行われる際の、機密データの安全性が確保される。インターネット・モビリティ・プロトコルは、認証された装置からのみプライベートなネットワークにアクセスできるようにすることで、基本的なファイアウォールとしての機能も果たす。また、インターネット・モビリティ・プロトコルにより、モバイル端末システム―モビリティ管理サーバ間の全ての通信を認証、暗号化することも可能である。
【００２５】
上記本発明の好ましい実施形態のさらに他の一例において、モバイル相互接続は、標準的なネットワーク・アプリケーションのインターフェイスが適用できる範囲を広げるべく、標準的なトランスポート・プロトコル（例としてＴＣＰ／ＩＰ、ＵＤＰ／ＩＰ、ＤＨＣＰなど）を使用して構築される。上記本発明の好ましい実施形態によって、データ転送、セキュリティ、アドレス管理、装置管理、ユーザ管理が効果的に統合され、ノマディック環境を効果的に透過性を有する状態とすることができる。インターネット・モビリティ・プロトコルは、複数のデータストリーム（信頼度の高いものも低いものも）を、標準的なネットワーク・インフラ上で標準的なトランスポート・プロトコルによって与えられる、単一の仮想チャネルを通じて多重化するための効果的な方法を提供する。
【００２６】
ＲＰＣ層を用いて、インターネット・モビリティ・プロトコルは、違うソースから供給され、違うまたは同じ目的地へと向かうデータを融合させて単一のデータストリームとし、これをモバイルリンクを介して送る。該モバイルリンクの反対側の端において、該データストリームは逆多重化されて複数の異なったデータストリームとなり、それぞれの最終的な目的地に伝送される。この多重化／逆多重化により、利用可能な帯域幅を（最大限のサイズのネットワークフレームを生成することで）最大限に使うことができ、複数のチャネルを確立することができる（よって、優先順位付けが可能になり、基礎をなしているネットワークがデータ通信サービスを供給している場合であれば、その品質を保証することができる可能性もある）。
【００２７】
上記本発明の実施の形態に関するインターネット・モビリティ・プロトコルは、さらに以下のような特徴や利点を実現する。なお、本発明は以下の点に限定されるものではない。
【００２８】
・トランスポート・プロトコルの独立性
・ネットワーク上における位置（ｐｏｉｎｔ ｏｆ ｐｒｅｓｅｎｃｅ； ＰＯＰ）あるいはネットワーク・インフラを、データの流れに影響を与えることなく変更可能（物理的境界、ポリシー、あるいは帯域幅による制約が無い場合のみ）
・付加的な経費が最小限
・伝送媒体に適した自動的なフラグメントのサイズ変更（あるフレームのプロトコル・データ・ユニットがネットワーク媒体の利用可能な上限の伝送ユニットよりも多いとき、インターネット・モビリティ・プロトコルは該フレームをフラグメント化し、再構築する。このことにより、該フレームのネットワーク伝送を保障することが可能となる。再伝送の際、該フレームは再度検査される。ネットワーク・インフラもしくは環境が変化していた場合、該フレームは再度フラグメント化されるか、あるいは伝送ユニットの上限が実際に上昇しているときには単一のフレームとして伝送される。）
・再伝送の際に、フレームに信頼性の低いデータを破棄させることで、信頼性の低いデータのセマンティクスを保持
・信頼性の高いデータグラムサービスにおける新しいセマンティクスを提供（これにより、インターネット・モビリティ・プロトコルによるピアの端末へのデータグラムの伝達が保証され、要求しているエンティティに伝達の通知がなされる）
・上りと下りの伝送パスをそれぞれ別に扱って、自動的に操作パラメータを調整し最適なスループットを実現（ヒステリシスに基づいて、フレームサイズ／フラグメント化の閾値、待機中のフレーム数（ウィンドウ）、再伝送時間、およびネットワークを通じて送られる複製データの量を減少させるための遅延承認時間などのパラメータを調整）。
【００２９】
・ネットワーク障害に対する耐性（モバイル環境での使用が想定されているため、一時的にネットワーク媒体間の接続が切断されても、仮想チャネルが切断されたりアプリケーションベースの接続が切断されたりしてしまうことがない）
・操作パラメータを調整するための帯域内信号方式をピアに対して提供（接続された端末のそれぞれから、そのピアに対してネットワーク・トポロジや環境の変化に関する警告を出すことが可能）
・輻輳回避アルゴリズムを採用し、必要なときにはスループットを効果的に減衰
・選択的な確認応答と高速での再伝送とによって無駄な再伝送の回数を制限し、ノマディック環境におけるハンドオフ回復のスピードアップを実現（これにより、プロトコルはロスの多いネットワーク環境においても最適なスループットを維持）
・複数のフレームを待機状態にする、スライディング・ウィンドウ技術を採用（このパラメータは各方向に調整可能で、ピアからの確認応答を要することなくフレームを所定の上限までストリーミングするために与えられる）
・シーケンス番号が非バイト指向であることにより、単一のシーケンス番号で最大のペイロード・サイズまでを表現可能
・セキュリティ対策（インターネット・モビリティ・プロトコル層に認証層と暗号化層を追加可能）
・圧縮によって、帯域幅の限られた接続における効率性を確保
・どちらのピアも新たな位置に移動することが可能な平衡型設計
・どちらの側からでもピアへの接続が確立可能
・休止している接続を迅速に破棄して消費されていたリソースを回復する、休止タイムアウトを発動可能
・接続に対して任意の最大持続時間を設定可能（例えば、所定の期間経過後あるいは所定の日時の後に、接続の終了および／または拒否が可能）。
【００３０】
本発明の好ましい具体的な実施形態においては、システム管理者によるネットワーク・リソースの消費の管理が可能である。例えば、システム管理者は、モバイル端末システム、モビリティ管理サーバの少なくとも一方をコントロールすることができる。この場合のコントロールとは、例えばネットワーク帯域幅や他のリソースの配分の管理や、セキュリティ関連の事項を指す。管理はクライアント側で多数のリソースを持っているクライアントについて実行するのが効果的である。しかしながら、リソースを多く持たないシン・クライアントにポリシー管理のための付加的なコードや処理を負わせるのは望ましくない。よって、シン・クライアントの管理についてはモビリティ管理サーバ等によって集中的に行う、あるいはその一部を分担するのが最も現実的な解決策であると考えられる。モビリティ管理サーバがモバイル端末システムの各データストリームをプロキシすることによって、ポリシー管理が集中的に行われる。さらに、モビリティ管理サーバがユーザごとにプロキシを行うので、ユーザごと、装置ごとに、ネットワーク・リソースへのアクセスを管理し制限することができる。
【００３１】
簡単な例を挙げると、モビリティ管理サーバは、特定のユーザによるあるネットワーク・リソースへのアクセスを「締め出す」（ｌｏｃｋ ｏｕｔ）ことができる。この点は、インターフェイスのネットワークが、モバイル相互接続によって組織の管理下にある施設の境界よりも外に「延長」（ｅｘｔｅｎｄ）されてしまっていることを考えると非常に重要である（例えば、以前勤めていた職場のネットワークに、元従業員が外部からアクセスを試みるといった場合を考えよ）。これにとどまらず、モビリティ管理サーバによるポリシー管理はさらに多くの利点を提供しうる。例えば、モビリティ管理サーバによって、あるＵＲＬに特定のユーザのみがアクセスできるようにしたり、ネットワークサービスによる要求によって戻されるデータをフィルタリングしたり、ネットワークの帯域幅保全のためにデータを圧縮したりということが可能になるといった点である。このように、既存もしくは新規のアプリケーションレベルのサービスを、シームレスかつ透過的な形で強化することができる。
【００３２】
また、モバイル端末システムは「信頼性の低い」（ｕｎｔｒｕｓｔｅｄ）ネットワーク（つまり組織の管理が及ぶ範囲外のネットワーク）とも接続されるため、リモート接続中に悪質なサイバー攻撃に遭う可能性がある。モバイル端末システムとの間でポリシーやフィルタを共有することで、悪質な接続からのモバイル端末システムの保全、リモート・ノードにおける進入（ｉｎｇｒｅｓｓ）フィルタリング、そして企業インフラの集中管理のさらなるセキュリティ向上が可能になる。
【００３３】
本発明の実施形態の他の一例では、インターフェイスによって補助されたローミングのリスナ（ｌｉｓｔｅｎｅｒ）によって、モバイル端末システムが一般的な信号伝達をサポートしたインターフェイスを利用し、インターフェイスによって補助されたローミングを行うことが可能になる。本発明の上記実施形態の一例の一側面において、モバイル端末システムの、インターフェイスベースのリスナは、所定の事象（例えばコールバックや、タイマーによるタイムアウト、データの損失を示唆するネットワーク活動など）に際して、モバイル端末システムの媒体の接続状態が変化したか否かを判定する。これは例えば、リスナが、モバイル端末システムが切り離されてネットワークと通信できる状態でなくなったことを検知して、インターフェイスにこれを示唆するといったことを意味する。再接続の際、リスナは予め記録された接続識別情報（ａｔｔａｃｈｍｅｎｔ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）におけるネットワークポイントを参照して、モバイル端末システムが同じネットワークポイントに再接続されたか否かを判定する。再接続が同じネットワークポイントになされていた場合、リスナはモバイル・クライアントに、トランスポート・レベルでの通信の再確立を進めることを警告する。再接続が別のネットワークポイントになされていた場合、リスナはモバイル端末システムが「ローミング」（ｒｏａｍ）状態であることを示し、現状におけるネットワーク・セグメントで使用可能なアドレスをシステムに取得させるようにする（これは例えば、現行のアドレスを新規のサブネットにおいて有効であるように登録することを含んでもよい）。リスナは（操作を介して学習した）ネットワーク・トポロジのマップを保持して、そのクライアントに対して生成される信号（「同一サブネット上のローミング」、「ローミング」等）の適否を判定する一助としてもよい。
【００３４】
上記本発明の非限定的な好ましい具体的実施形態の他の一例においては、モビリティ管理サーバ（ＭＭＳ）に「非接続ネットワーキング」（ｄｉｓｊｏｉｎｔ ｎｅｔｗｏｒｋｉｎｇ）モードでアクセスすることが可能である。この新しいアルゴリズムによって、あるネットワーク・インフラからは別のネットワーク・インフラにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、ＭＭＳとの通信を確立する／持続するのに使われる、代替のネットワークアドレスを動的／静的に見つけ出すことができるようになる。この構成により、ＭＭＳが利用可能な代替アドレスのリストが予め設定され、通信中にＭＥＳ（モバイル端末システム）に送られるかあるいはＭＥＳによって動的に学習される。実施の一形態において、ＭＭＳはＭＥＳに、一つ以上のＭＭＳネットワークアドレスもしくは他のネットワークに対応した他のＭＭＳのアイデンティティを、単一のネットワークによる通信によって送ることができる。該リストは、回路構築の際やその他接続が確立されている間のいかなる時にも、送付／更新が可能である。
【００３５】
ＭＥＳが別のネットワークへと移動するとき、ＭＥＳは該ネットワークにおける新規のネットワーク接続を通じてＭＭＳとコンタクトをとるために、ＭＭＳの「エイリアス」（ａｌｉａｓ）アドレス／アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、ルートその他の情報を共有していなくても、ＭＥＳは新規のネットワーク接続を通じてＭＭＳとのコンタクトを再確立することができる。
【００３６】
上記本発明の実施の形態のさらに他の例において、ポリシー管理に関する意思決定は分散型モバイルネットワークトポロジの内部にて行われ、例えば、ルールベースのポリシー管理プロシージャが、様々なメトリクスに基づいて要求の遂行を許可、拒絶、または制限する。このような管理形態は、例えば、マルチホーム／パス環境における最少コストルーティングといったコストメトリクスに基づいて意思決定をする際に用いられる。
【００３７】
このようなポリシー管理技術では、意思決定の際にモビリティあるいは位置取得（つまりローミング）に関する事項が考慮に入れられてもよい。例えば、管理ルールが装置の位置（ネットワークのどの接続ポイント、例えばアクセスポイント／基地局、ハブ、ルータ、ＧＰＳ座標等に近いかなど）に基づいて決定されてもよく、これにより、特定の操作が、あるビル内では許可されるが別のビルでは許可されないといったことが可能になる。例えば複数の違った無線ネットワークを利用している企業の場合にこの構成が有用であると考えられる。このような企業において、例えば積込ドックとオフィスとが無線ネットワークで接続されている場合がある。システム管理者は、積込ドックにいる従業員（例えばユーザや装置）がオフィス環境の無線ネットワークにアクセスできないようにすることができる。さらに、ポリシー管理によって、許可、拒否、遅延という３つの状態のいずれかをもたらすようにすることも可能である（例えば、決定が帯域幅やコストに基づいてなされる場合、操作の実行はより適切な時期がくるまで遅延される）。
【００３８】
上記実施例におけるポリシー管理においては、決定に基づいて動作を変更することが可能となっている。ひとつのアクションの例としては、全てのアクティブなアプリケーションによる帯域幅の消費を抑えるというものがある。また、例えば、著しく帯域幅を消費する特定のアプリケーションが存在する場合に、ポリシーエンジン（ｐｏｌｉｃｙ ｅｎｇｉｎｅ）によって該アプリケーションによる操作／トランザクションの完了までの速度を管理することが可能となる。この動作は、誤ったアプリケーションの動作を抑制させることを動的に学習するようになっていてもよい。もうひとつのアクションの例として、データの復元（例えば、利用可能な／許可された帯域幅やコスト、ユーザによる制限に基づいたグラフィックイメージのディザリング）がある。
【００３９】
さらに、ルールエンジン（ｒｕｌｅｓ ｅｎｇｉｎｅ）は、ルール評価に基づいて他のアクションを発動させる。イベントをロギングする、警告を発する、ユーザにアクションが拒否、遅延、あるいは条件付けされたことを通知するといった外部プロシージャが実行されてもよい。これらのような通知は、既存のルールへのオーバーライドがオペレータから求められるというような、インタラクティブなものであってもよい。
【００４０】
上記実施例におけるポリシー管理エンジン（ｐｏｌｉｃｙ ｍａｎａｇｅｍｅｎｔ ｅｎｇｉｎｅ）において、その意思決定は、装置、装置のグループ、ユーザ・グループ、ユーザ、あるいはネットワーク接続ポイントに関連した、任意の数のメトリクスもしくはその組み合わせに基づいてなされていてもよい。
【００４１】
ポリシー管理機能の一部として、他にもローカルベースの情報やサービスが、ポリシー管理、ネットワーク・モデリング、および／またはアセット・トラッキングのために取得され／備えられていてもよい。このようなサービスには、モバイル端末システムの現在位置に関連した情報がユーザやモバイル端末システムに自動的に提供される機能が含まれる。該情報は、メッセージ、ファイルその他の電子的フォーマットにて供給されてもよい。
【００４２】
この機能の非限定的な利用例としては、ショッピングモール運営者、各種業界団体、大規模小売業者などがショッピングセンターに、ブルートゥース ＰＡＮ、ＩＥＥＥ ８０２．１１ ＬＡＮ、８０２．１５ ＰＡＮ、その他の無線ネットワーク規格に準拠した、無線アクセスポイントを戦略的に設けるというものがある。この場合、顧客がセンター内を歩き回るのにあわせて、モバイル端末システムの現在位置周辺の店舗は顧客に情報を提示することができる。この情報としは、セールやディスカウント、特典などについてのものが含まれる。これに加え、モバイル端末システムに販促用の電子クーポン券が供給されるのもよい。店舗側は上記のようなサービスを、モール運営者、業界団体、小売業者、あるいはその他のサービス提供者による集中的な管理機構に登録することになる。
【００４３】
上記技術が利用される他の非限定的な例として、現場サービス、訪問販売、宅配などのバーティカル産業において、位置を基準にして情報を収集する、地域サービス、地図、方角、顧客、事故など公共の情報を、位置を基準にモバイル端末システムに送る、などがある。
【００４４】
さらに他の非限定的な例として、モバイル端末システムをモニタリング、トラッキングするウェブベースのサービスがある。例えば、顧客は該トラッキングサービスに登録し、信頼の置ける第三者機関が、ホスティングされているウェブサービスにログオンして顧客のモバイル端末システムの精確な位置を同定する。この場合、モバイル端末システムは車両に備え付けられてもよいし、歩行者に所持されていてもよい。モバイル端末システムのさらなる小型軽量化に伴い、このようなサービスはますます現実味を帯びてきている。該サービスを利用することで、危険度の高い人々、例えば高齢者、障害者、病人などを追跡、位置確認することができる。該サービスは、自動車その他の高価な動産や荷物をトラッキングすることにも利用できる。３Ｇ ＷＡＮネットワーク、ブルートゥースネットワーク、８０２．１１ネットワークその他の無線技術を利用し、ネットワーク媒体や接続ポイントを切り替えてもシームレスな接続性を保つことができるという特性を生かして、上記のサービスを非常に低いコストで実施することが可能である。
【００４５】
このように、本発明は企業ネットワークを延長して、ネットワーク管理者が、信頼性や集中的な管理形態を犠牲にすることなく、モバイル端末のユーザに、アプリケーションへの簡便なアクセスを固定端末のユーザの場合と同様に提供することを可能にする。本ソリューションは、既存の有線ネットワーク規格の長所を制定段階にあるモビリティ規格にも持たせて、既存のネットワーク・アプリケーション上で動作可能なソリューションを生み出すものである。
【００４６】
本発明の他の目的、特徴、および優れた点は、以下に示す記載によって十分分かるであろう。また、本発明の利点は、図面を参照した以下の説明で明白になるであろう。
【００４７】
［好ましい実施の形態の詳細な説明］
図１は、本発明の、モバイル強化ネットワークコンピュータシステム１００を例示している。該ネットワークコンピュータシステム１００は、モビリティ管理サーバ１０２と、一つ以上のモバイル端末システム１０４とを含んでいる。モバイル端末システム１０４は、ローカルエリア・ネットワーク（ＬＡＮ）１０８を通じてモビリティ管理サーバ１０２と通信することができる。モビリティ管理サーバ１０２は、モバイル端末システム１０４のネットワーク・レベルでのプロキシとして機能する。モビリティ管理サーバ１０２はこれを、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム１１０とも、モビリティ管理サーバ１０２とモバイル端末システム１０４との間の相互接続が断続的で信頼性の低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって成し遂げている。本好ましい実施形態では、モビリティ管理サーバ１０２は、本発明の遠隔プロシージャ・コール・プロトコルおよびインターネット・モビリティ・プロトコルを用いて、モバイル端末システム１０４と通信する。
【００４８】
この場合、モバイル端末システム１０４はモビリティ管理サーバ１０２とアクティブに接続されるが、該接続は常時アクティブに行われるものではない。例えば、
・複数のモバイル端末システム１０４ａ‐１０４ｋが、モビリティ管理サーバ１０２と、モバイル相互接続によって（この場合無線で）通信する。例として、ローカル・エリアもしくはワイドエリア・ネットワーク１０８と無線（あるいは有線）でつながった、従来型の電磁（電波）トランシーバ１０６が考えられる。上記のようなモバイル相互接続により、モバイル端末システム１０４ａ‐１０４ｋが、一つのカバーエリア（ｃｏｖｅｒ ａｒｅａ）１０７ａから別のカバーエリア１０７ｋへとローミングすることが可能になる。一般的に、モバイル端末システム１０４が、あるカバーエリア１０７から別のエリアにローミングしたり、最も近いトランシーバ１０６から届く範囲を外れたり、あるいは信号を一時的に遮断（例えばビルの柱の裏側を通るなどで）されたりした場合、一時的に通信が切断される。
【００４９】
・別のモバイル端末システム１０４ｌ、１０４ｍ…が、モビリティ管理サーバ１０２と、ドッキングポートやネットワークケーブルコネクタなどの着脱式（ｎｏｎ−ｐｅｒｍａｎｅｎｔ）有線相互接続１０９を介して通信する。モバイル端末システム１０４は、接続１０９が外れたり、モバイル端末システム１０４の電源が切られたりした場合、一時的にＬＡＮ１０８から切断される。
【００５０】
・さらに別のモバイル端末システム（例えば１０４ｎ）が、モビリティ管理サーバ１０２と、ワイドエリア・ネットワーク、ダイアルアップ・ネットワーク、衛星ネットワーク、インターネット等のネットワーク・トポグラフィ１１１を介してノマディック接続される。一例として、ネットワーク１１１のサービスは断続的なものであってもよく、他の例として、モバイル端末システム１０４がある種類の接続形態から別の種類のものへと移行（例えば、モビリティ管理サーバ１０２と有線相互接続１０９を通じて接続される状態からネットワーク１１１を通じて接続される状態へ移行、もしくはその逆）し、移行時に一時的に接続が切断されるという構成であってもよい。
【００５１】
モバイル端末システム１０４は、標準的なモバイル装置や市販のコンピュータであってよく、例えば、モバイル端末システム１０４は、市販のトランシーバおよび／またはネットワークカードを実装したラップトップコンピュータによって構成される。モバイル端末システム１０４は、標準的なネットワーク・アプリケーションや標準的なＯＳ（オペレーティングシステム）を実行し、標準的なトランスポート・レベル・プロトコル（例えばＴＣＰ／ＩＰ）を利用して、トランスポート層で通信を行うものであってよい。本発明において、さらに、モバイル端末システム１０４がクライアントソフトウェアを実行することで、遠隔プロシージャ・コール・プロトコルおよびインターネット・モビリティ・プロトコルを用いたモビリティ管理サーバ１０２との通信が可能になる。上記両プロトコルは、それらと同様のトランスポート・レベルのプロトコルを利用して伝送される。
【００５２】
モビリティ管理サーバ１０２は、ウィンドウズ（登録商標）ＮＴサーバなどの標準的なサーバによってホスティングされるソフトウェアを含んでいてよい。本好ましい実施形態では、モビリティ管理サーバ１０２は、規格に準拠したクライアント／サーバ型のインテリジェントサーバであって、企業ネットワーク１０８を透過性を有した状態でノマディック環境にまで延長するものである。モビリティ管理サーバ１０２は、数量を限定されないモバイル端末システム１０４それぞれのネットワーク・レベルでのプロキシとして機能するが、モビリティ管理サーバ１０２はこれを、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム１１０とも、モバイル端末システム１０４とトランシーバ１０６との間のモバイル相互接続が断続的で信頼性が低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって成し遂げている。
【００５３】
例えば、サーバ１０２はどのような標準的（例えばＴＣＰ／ＩＰベースの）ネットワーク・アプリケーションであっても、変更を行うことなしに、モバイル接続を通じて実行させることができる。接続が切断されたり、圏外に出たり、あるいは動作をサスペンドしたりしたモバイル端末システム１０４のセッションは、サーバ１０２によって維持され、該システムが復帰した際にはサーバ１０２が上記セッションをレジュームする。モバイル端末システム１０４が圏外に出てしまったり、シャットダウンしたり、あるいは位置アドレスを変更した場合、モビリティ管理サーバ１０２は、データの受信に関して確認応答し、モバイル端末システムが再度通信可能となるまで要求を待機させることで、モバイル端末システムとピア・システム１１０との接続を維持する。
【００５４】
サーバ１０２はまた、有線ネットワークにおける管理能力をモバイル接続にまで延長する。ネットワークソフトウェア層はそれぞれが互いに独立して動作するので、ソリューションをそれが展開されるそれぞれの環境に合わせてカスタマイズすることが可能である。
【００５５】
一例として、モビリティ管理サーバ１０２が、ローカルエリア・ネットワークやワイドエリア・ネットワークのような標準的な企業ネットワーク１０８と接続され、該ネットワーク１０８は、様々な固定端末システム（例えば一つ以上のホストコンピュータ１１０）１１０と接続される状況が考えられる。モビリティ管理サーバ１０２によって、モバイル端末システム１０４と固定端末システム１１０との間の、連続セッション型データストリームを利用した通信が可能となるが、この通信は、モバイル端末システム１０４が、接続しているネットワーク相互接続とのコンタクトを失ったり、あるネットワーク相互接続１０６、１０９、１１１から別のネットワーク相互接続へと移動したりしても（例えば、無線相互接続の場合、ある無線トランシーバ１０６のカバーエリア１０７から別のカバーエリアにローミングしても）、利用可能となっている。
【００５６】
モバイル端末システム１０４は、モビリティ管理サーバ１０２との結合を、スタートアップ時か、あるいはモバイル端末システムがネットワークサービスを要求した時に確立する。結合が確立されると、モバイル端末システム１０４は、一つ以上のネットワーク・アプリケーションのセッションを、連続的あるいは共時的に始めることができる。モバイル端末システム１０４−モビリティ管理サーバ１０２間の結合確立によって、モバイル端末システムが切断されたり、圏外に出たり、あるいはサスペンドしたりしても、モバイル端末システムにおけるアプリケーションのセッションを維持し、モバイル端末システムの復帰時には該セッションをレジュームすることが可能になる。本好ましい実施形態では上記の処理は完全に自動で行われ、ユーザによる介入は全く必要とされない。
【００５７】
本発明の一例において、モバイル端末システム１０４は、ＵＤＰ／ＩＰのような標準的なトランスポート・プロトコルを用いてモビリティ管理サーバ１０２と通信を行う。標準的なトランスポート・プロトコルを使用することで、モバイル端末システム１０４が、標準的なルータ１１２など企業ネットワーク１０８に既存のインフラを用いて、モビリティ管理サーバ１０２と通信することが可能になる。本発明では、高レベルの遠隔プロシージャ・コール・プロトコルが、トランザクションを、モバイル強化ネットワーク１０８を介して、標準的なトランスポート・プロトコルを使用して送られるメッセージへと生成する。本好ましい実施形態において、上記のようなモバイルＲＰＣメッセージは、モバイル端末システム１０４にて実行されるアプリケーションによって開始された、全てのネットワーク・トランザクションを含んでいるため、モビリティ管理サーバ１０２によって全てを完了させることができる。このことにより、モビリティ管理サーバ１０２とモバイル端末システム１０４とは、ネットワーク媒体の接続性が阻害されているときでも、接続状態情報を常に互いにシンクロさせておくことができる。
【００５８】
モバイル端末システム１０４のそれぞれは、全てのネットワーク活動を傍受し、該ネットワーク活動をモバイルＲＰＣプロトコルを通じてモビリティ管理サーバ１０２にリレーするための情報をモバイル端末システム自体に提供するモビリティ管理ソフトウェアクライアントを実行する。本好ましい実施形態では、該モビリティ管理クライアントは、モバイル端末システム１０４に実装されているＯＳ（ウィンドウズ（登録商標）ＮＴ、ウィンドウズ（登録商標）９８、ウィンドウズ（登録商標）９５、ウィンドウズ（登録商標）ＣＥなど）と透過性を有する状態で協働して、クライアント側でのアプリケーションのセッションを、ネットワークとのコンタクトが失われても維持し続ける。
【００５９】
モビリティ管理サーバ１０２は、それぞれのモバイル端末システム１０４の状態を管理し、例えば接続の反対側の端に接続されたホストコンピュータ１１０のような通信相手のピア１０８との連続的な接続を維持するために必要とされる複合的なセッション管理を行う。モバイル端末システム１０４との通信ができなくなったり、モバイル端末システム１０４がサスペンドしたり、あるいはネットワークアドレスを変更したり（例えばあるネットワーク相互接続から別のものにローミングしたり）した場合、モビリティ管理サーバ１０２は、モバイル端末システム１０４とホストシステム１１０などの接続端との間の接続を、データ受信に関して確認応答したり、要求を待機させたりすることによって維持する。このプロキシ機能によって、ピアのアプリケーションは、モバイル端末システム１０４との物理的な接続が絶たれたことを検知することがなくなる。よって、もしモバイル端末システムが一時的に接続を失ったり、あるカバーエリア１０７Ｋ内において、あるネットワーク相互接続１０６Ａから別のネットワーク相互接続１０６Ｋへとローミングしたりした場合でも、（物理的接続が再確立された際に単純に作業をレジュームすることで）モバイル端末システム１０４のアプリケーションと、その結合しているセッションを実行する端との間の連続的な接続を効果的に維持することができる。
【００６０】
モビリティ管理サーバ１０２はまた、モバイル端末システム１０４がセグメント化されたネットワークの様々な部分をローミングする際、異なったネットワークアドレスを受信するという問題を解決するべく、アドレスを管理することが可能となっている。モバイル端末システム１０４はそれぞれ、プライマリネットワーク上での仮想アドレスを有している。該仮想アドレスは、標準的なプロトコルによって、あるいは静的割り当てによって決定されている。モバイル端末システム１０４のそれぞれについて、モビリティ管理サーバ１０２は該システムの現状における実際の（位置）アドレスに対応して仮想アドレスを割り当てる。モバイル端末システム１０４の、あるネットワーク・セグメントから他のセグメントへの移動に伴って、該システム１０４の現在位置アドレスが変更されても、仮想アドレスは、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【００６１】
よって、モバイル端末システム１０４の位置アドレスの変更は、モビリティ管理サーバ１０２を介して、結合しているホストシステム１１０（および他のピア）におけるセッションを実行する端からは完全に透過性を有する状態となっている。ピア１１０から見えるのは、サーバ１０２によってプロキシされた（不変の）仮想アドレスのみということになる。
【００６２】
本好ましい実施形態では、モビリティ管理サーバ１０２はさらに、コンソール（制御）アプリケーションと包括的なメトリクス（ｅｘｈａｕｓｔｉｖｅ ｍｅｔｒｉｃｓ）とによる、集中的なシステム管理が可能である。システム管理者は、上記のツールを利用して、遠隔接続を設定、管理し、遠隔接続およびシステムにおける問題を解決することができる。
【００６３】
モビリティ管理サーバ１０２によるプロキシ・サーバ機能によって、ネットワーク・アプリケーション、ユーザ、そして装置にそれぞれ異なった優先レベルを設定することができるようになる。これは、モビリティ管理サーバ１０２が有する処理用のリソースが有限であることを鑑みれば、有用なものである。システム管理者が上記のようにモビリティ管理サーバ１０２の設定を変更できることで、システムおよびネットワークのパフォーマンスが全体として向上する。一例として、システム管理者がモビリティ管理サーバ１０２の設定を変更できることにより、音声や映像のストリーミングのようなリアルタイムのアプリケーションに対して、モビリティ管理サーバ１０２のリソースを、あまりリソースを使用しないメールソフトのようなアプリケーションよりも多く割り当てることができる。
【００６４】
詳しく説明すると、モビリティ管理サーバ１０２は、アプリケーション、もしくはＳＮＭＰのような標準的なネットワーク管理プロトコル、ウェブベースの設定インターフェイス、ローカルなユーザインターフェイスなどのアプリケーション・インターフェイスを介して設定される。結合（ａｓｓｏｃｉａｔｉｏｎ）そのものの優先度、および／または、ある結合における複数のアプリケーションの優先度を設定することも可能である。例えば、モビリティ管理サーバ１０２を介して動作する他の結合と関連している結合それぞれの優先度は、ユーザあるいは装置ごとに設定可能である（本実施形態では、ユーザおよびユーザがログインした装置の両方を優先するように設定された場合に、ユーザに関する設定のほうがより優先されるように設定されてもよい）。あるいは結合それぞれについて、アプリケーションの優先度に関し、ネットワーク・アプリケーションごとにいくつかのレベルが設定されていてもよい。本システムでは、優先レベルはいくつでも設定することが可能である。一例として、低、中、高の３つの優先レベルが設定される例が考えられる。
【００６５】
（サーバ／クライアント型ソフトウェア・アーキテクチャの例）
図２に、モバイル端末システム１０４とモビリティ管理サーバ１０２とのソフトウェア・アーキテクチャの一例を図示する。本発明の一例において、モバイル端末システム１０４とモビリティ管理サーバ１０２は標準的なＯＳおよびアプリケーション・ソフトウェアを実行するが、このときに、ほんの少数のコンポーネントを新しく追加するだけで、断続的に接続されるモバイルネットワーク１０８を介した、信頼性が高くかつ効果的、持続的なセッションが実行可能となっている。図２に示すように、モバイル端末システム１０４は、ネットワーク・インターフェイス・ドライバ２００、ＴＣＰ／ＵＤＰトランスポートサポート２０２、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４、および一つ以上の従来型のネットワーク・アプリケーション２０８に対するインターフェイスとして使われるソケットＡＰＩ２０６を含む、従来型のＯＳソフトウェアを実行する。従来型のネットワーク・ファイル／プリント・サービス２１０が、従来型のＴＤＩ２０４との通信用にさらに設けられていてもよい。サーバ１０２は、上記と類似した、従来型のネットワーク・インターフェイス・ドライバ２００’、ＴＣＰ／ＵＤＰトランスポートサポート２０２’、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４’、および一つ以上の従来型のネットワーク・アプリケーション２０８’に対するインターフェイスとして使われるソケットＡＰＩ２０６’を有していてもよい。モバイル端末システム１０４とモビリティ管理サーバ１０２はそれぞれ、さらにネットワーク／セキュリティ・プロバイダ２３６（モバイル端末システム）、ユーザ／セキュリティ・データベース２３８（サーバ）を備えていてもよい。
【００６６】
本発明では、新規のモバイル・インターセプタ・コンポーネント２１２が、モバイル端末システム１０４のソフトウェア・アーキテクチャにおける、ＴＣＰ／ＵＤＰトランスポートモジュール２０２とトランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４との間に挿入されている。該モバイル・インターセプタ・コンポーネント２１２は、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４における特定のコールを傍受して、該コールを、ネットワーク１０８を介し、ＲＰＣおよびインターネット・モビリティ・プロトコル、標準的なＴＣＰ／ＩＰトランスポート・プロトコルを通じてモビリティ管理サーバ１０２へと転送する。こうして、モバイル・インターセプタ２１２は、全てのネットワーク活動を傍受して、サーバ１０２へと転送することができる。該インターセプタ２１２はＯＳと透過性を有する状態で協働するので、モバイル端末システム１０４がネットワーク１０８とのコンタクトを失っても、クライアント側のアプリケーションのセッションはアクティブであり続けることができる。
【００６７】
モバイル・インターセプタ２１２は、トランスポート・ドライバ・インターフェイス２０４とは違うレベルで（例えばソケットＡＰＩ２０６のレベルで）動作することもできるが、ＴＤＩのレベルでモバイル・インターセプタ２１２が動作する、より詳細にはいずれかのトランスポート・プロトコル・インターフェイスにおいて動作することにより、下記のような利点が生まれる。なお、便宜的に、トランスポート・ドライバ・インターフェイスを示す全てのものをＴＤＩという略語で表わすこととする。多くの標準的なＯＳ（例えば、マイクロソフト社のウィンドウズ（登録商標）９５、ウィンドウズ（登録商標）９８、ウィンドウズ（登録商標）ＮＴ、ウィンドウズ（登録商標）ＣＥなど）はＴＤＩインターフェイス２０４を実装しているので、ＯＳのコンポーネントを変更することなく互換性が保証される。さらに、トランスポート・ドライバ・インターフェイス２０４は通常カーネル・レベルのインターフェイスであることから、ユーザモードへの切り替えが必要でなく、これにより性能を向上させることができる。
【００６８】
さらに、ＴＤＩインターフェイス２０４のレベルで作動するモバイル・インターセプタ２１２は、様々な別のネットワーク・アプリケーション２０８（例えば複数の同時に動作しているアプリケーション）に加えて、ネットワークにおけるファイル、プリント、および他のカーネル・モードなどのサービス２１０（インターセプタが例えばソケットＡＰＩ２０６のレベルで動作している場合はそれぞれ別に扱う必要がある）を傍受することができる。
【００６９】
図２Ａに、どのようにインターセプタ２１２が動作するかを示す高レベルのフローチャートの一例を示す。モバイル端末システム１０４のＴＤＩインターフェイス２０４へのコール（ブロック２５０）は、モバイル・インターセプタ２１２によって傍受される（ブロック２５２）。モバイル・インターセプタ２１２によって傍受されたＲＰＣコールはインターネット・モビリティ・プロトコルに準拠してフラグメントにパッケージ化され、該フラグメントはデータグラムとして、ＵＤＰやＴＣＰといった標準的なトランスポート・プロトコルにより、ＬＡＮ、ＷＡＮ等のトランスポート１０８を介してモビリティ管理サーバ１０２へと送られる（ブロック２５２）。モビリティ管理サーバ１０２は受信したＲＰＣデータグラムをアンパックして（ブロック２５４）、要求されたサービスを実行する（例えば、データや応答を、固定端末システム１１０で動作するアプリケーションサーバ処理へと転送することで、モバイル端末システムのアプリケーション２０８のプロキシとして振舞う）。
【００７０】
再び図２に戻って、モビリティ管理サーバ１０２は、従来型のネットワーク・インターフェイス・ドライバ２２２を介して送られる、モバイル端末システム１０４からの、あるいはモバイル端末システム１０４へ向かうメッセージを傍受する、アドレス変換部２２０を有している。例えば、アドレス変換部２２０は、セッションの相手のピア（固定端末システム１１０）からのモバイル端末システム１０４の仮想アドレス宛のメッセージを認識する。モバイル端末システムへの該メッセージはプロキシ・サーバ２２４へと送られる。プロキシ・サーバ２２４は仮想アドレスとメッセージとを待機していたトランザクションに割り当て、該応答を、上記モバイル端末システム１０４の現在位置アドレスへと転送する。
【００７１】
さらに、図２によると、モビリティ管理サーバ１０２は、アドレス変換部（中間ドライバ）２２０とプロキシ・サーバ２２４に加えて、設定マネージャ２２８、操作／ユーザインターフェイス２３０、およびモニタ２３２を有している。設定マネージャ２２８は設定情報とパラメータとを提供して、プロキシ・サーバ２２４が接続の管理を行えるようにする。操作／ユーザインターフェイス２３０とモニタ２３２により、ユーザとプロキシ・サーバ２２４との間のやりとりが可能になる。
【００７２】
（モバイル・インターセプタ）
図３は、本発明のＲＰＣプロトコルとインターネット・モビリティ・プロトコルとをサポートしたモバイル・インターセプタ２１２のソフトウェア・アーキテクチャの一例を示す。本例では、モバイル・インターセプタ２１２は、遠隔プロシージャ・コール・プロトコル・エンジン２４０と、インターネット・モビリティ・プロトコル・エンジン２４４の、二つの機能コンポーネントを有している。モビリティ管理サーバ１０２において動作するプロキシ・サーバ２２４によって、対応するエンジン２４０’、２４４’が用意される。
【００７３】
このように、本好ましい実施形態におけるモバイル・インターセプタ２１２は、モビリティ管理サーバ１０２をそれぞれのモバイル端末システム１０４と接続するための、遠隔プロシージャ・コール・プロトコルと、インターネット・モビリティ・プロトコルとをサポートしている。遠隔プロシージャ・コールは、あるローカルシステムから、離れた別のシステムにおけるプロシージャを発動する処理を可能とするものである。一般的に、ローカルシステムは遠隔のシステムにおいてプロシージャ・コールが実行されたことを感知しない。ＲＰＣプロトコルの利用によって、モバイル端末システム１０４が、アクティブなネットワークセッションを失うことなく、圏外に出たり、操作をサスペンドしたりすることが可能になる。セッションの維持に特別なアプリケーションは必要とされないので、モバイル環境にあるネットワーク１０８において、市販のアプリケーションが何の変更も必要とせずに動作することになる。
【００７４】
ネットワーク・アプリケーションは、一般的に、ウィンドウズソケット（Ｗｉｎｄｏｗｓ ｓｏｃｋｅｔｓ）のようなアプリケーションレベルのインターフェイスを利用している。アプリケーションレベルのＡＰＩへの単一のコールによって、トランスポート層もしくはメディア・アクセス層における複数の送信および受信データパケットが生成される。優先されるモバイルネットワークで、もし上記のパケットのうちの一つが失われた場合、接続全体の状態が不安定になってセッションは中止されるが、本発明の好ましい実施形態はＲＰＣを備えており、モビリティ管理サーバ１０２とモバイル端末システム１０４とは、物理的な接続が絶たれたときであっても、常に統一された論理リンクを維持するために、接続状態に関する情報を共有している。
【００７５】
本発明のインターネット・モビリティ・プロトコルは、有線のネットワークと無線など他の信頼性の劣るネットワークとの相違点を補償する。フレームサイズとプロトコルのタイミングとが修正されることで、モバイル環境を考慮しないトランスポートと比較して性能が著しく向上し、ネットワークのトラフィックを大幅に減少することができる。このことは、帯域幅に制限がある場合やバッテリーの寿命が問題となる場合に重要となる。
【００７６】
また、本発明のインターネット・モビリティ・プロトコルは、公共の有線ネットワークを通じて、もしくは無線によってモビリティ管理サーバ１０２とモバイル端末システム１０４との間の通信がなされる際の、機密情報のセキュリティを保証する。インターネット・モビリティ・プロトコルは、認証された装置のみが企業ネットワークにアクセスすることを許可することで、基本的なファイアウォールとしての機能を果たす。本発明のインターネット・モビリティ・プロトコルはさらに、モビリティ管理サーバ１０２とモバイル端末システム１０４との間での全ての通信を認証、暗号化することを可能にする。
【００７７】
図３のモバイル端末システム１０４における遠隔プロシージャ・コール・プロトコル・エンジン２４０は、ＴＤＩコールパラメータをマーシャリングし、データをフォーマットし、要求を、ＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’がコールを実行するモビリティ管理サーバ１０２まで転送するべく、インターネット・モビリティ・プロトコル・エンジン２４４に送る。モバイル端末システム１０４は、遠隔プロシージャ・コール・プロトコルに基づいてＴＤＩコールパラメータをマーシャリングする。モビリティ管理サーバ１０２のＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’が上記のＲＰＣを受信すると、モビリティ管理サーバ１０２はモバイル端末システム１０４に代わってコールを実行する。モビリティ管理サーバ１０２のＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’は、接続されたモバイル端末システムそれぞれにおける完全なネットワークの状態を、ピアであるモバイル端末システム１０４のＲＰＣエンジン２４０と共有する。モバイル端末システム１０４の代理としての遠隔プロシージャ・コール実行に加え、サーバのＲＰＣエンジン２４０’は、システムフローの管理、遠隔プロシージャ・コールの解析、仮想アドレスの（アドレス変換機構２２０が行うサービスに対応した）多重化、遠隔プロシージャ・コールのトランザクションの優先順位付け、スケジューリング、ポリシー実行、および融合処理（ｃｏａｌｅｓｃｉｎｇ）を行う。
【００７８】
インターネット・モビリティ・プロトコル・エンジン２４４は、信頼性の高いデータグラムサービス、順位付け、フラグメント化、およびメッセージの再組立を行う。また、設定すれば、認証、データ暗号化、プライバシー保護強化、セキュリティ、そしてスループットのための圧縮も行うことができる。インターネット・モビリティ・プロトコル・エンジン２４４は、電力消費を考慮に入れる必要のある環境において、複数の異なるトランスポートを利用して機能するようになっているので、消費電力管理を意識したものであるとともに、各トランスポートに対して独立となっている。
【００７９】
図３Ａは、モバイル・インターセプタ２１２がモビリティ管理サーバ１０２と通信してＴＤＩコールのやり取りを行う処理を例示する。一般的に、モバイル・インターセプタ２１２のＲＰＣプロトコル・エンジン２４０は、マーシャリングされたＴＤＩコールを、モビリティ管理サーバ１０２へと送るべく、インターネット・モビリティ・プロトコル・エンジン２４４へと転送する。ＲＰＣプロトコル・エンジン２４０は、この作業を、インターネット・モビリティ・プロトコル・エンジン２４４によって管理されるキューにＲＰＣコールを加えることで達成する（ブロック３０２）。帯域幅管理を円滑に行うために、インターネット・モビリティ・プロトコル・エンジン２４４は受信したＲＰＣコールの転送を所定の期間（ＲＰＣ融合タイムアウト期間）遅延させる（ブロック３０４）。一般的に、ＲＰＣ融合タイムアウトは５ミリ秒から１５ミリ秒の間に設定されるが、この数値はユーザによって変更可能である。この遅延によって、ＲＰＣエンジン２４０はＴＤＩコールをインターネット・モビリティ・プロトコル・エンジン２４４のキューに加えて、一つ以上のＲＰＣコールが同一のデータグラム（フラグメント）によって転送されるようにすることができる。
【００８０】
融合タイムアウトが終了するか、ＲＰＣエンジン２４０がそれ以上のＲＰＣコールの受信を拒否する（判定ブロック３０６）ことを決定すると、ＲＰＣエンジン２４０は、インターネット・モビリティ・プロトコル・エンジン２４４に、キューをフラッシュ（ｆｌｕｓｈ）し、ＲＰＣコールを単一のフレームに融合し、該フレームをピアに転送するよう要求する（ブロック３０８）。この融合により伝送回数が減少し、プロトコルのパフォーマンスが高められる。しかし、インターネット・モビリティ・プロトコルは、パフォーマンス最適化のために他の外部基準に基づいてキュー２４４をフラッシュすることもしなければならず、本好ましい実施形態において、単一のＲＰＣ要求でフレーム全体が占められてしまう場合、ＩＭＰ層は自動的に要求をピアに送るよう試みる。
【００８１】
上記のように、モビリティ管理サーバ１０２のプロキシ・サーバはＲＰＣプロトコル・エンジン２４０’とインターネット・モビリティ・プロトコル・エンジン２４４’とを有している。図３Ｂは、モバイル端末システム１０４からインターネット・モビリティ・プロトコル・メッセージ・フレームを受信した際に、モビリティ管理サーバ１０２で実行される処理を例示している。該フレームをモビリティ管理サーバ１０２が受信すると、インターネット・モビリティ・プロトコル・エンジン２４４’は、フレームが（基礎となるトランスポートの最大伝送量の制約で）フラグメント化されていれば再構築し、メッセージの内容を逆多重化して、どのモバイル端末システム１０４からの受信かを決定する。この逆多重化により、インターネット・モビリティ・プロトコル・エンジン２４４’は、遠隔プロシージャ・コール・プロトコル・エンジン２４０’に、的確な結合関連文脈情報（ａｓｓｏｃｉａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｃｏｎｔｅｘｔ ｉｎｆｏｒｍａｔｉｏｎ）を伝えることができる。
【００８２】
続いて、インターネット・モビリティ・プロトコル・エンジン２４４’は、受信したメッセージを、ＲＰＣ受信示唆システム作業要求（ＲＰＣ ｒｅｃｅｉｖｅ ｉｎｄｉｃａｔｉｏｎ ｓｙｓｔｅｍ ｗｏｒｋ ｒｅｑｕｅｓｔ）３５４にして、該作業要求と結合関連文脈情報を、モビリティ管理サーバ１０２のＲＰＣプロトコル・エンジン２４０’に与える。ＲＰＣプロトコル・エンジン２４０’が作業要求３５２を受信すると、該エンジン２４０’は作業要求３５２を結合関連作業キュー３５６に加え、次に予定済みの要求をグローバルキュー３５８に送ることによって、結合処理のスケジューリングが行われる。続いて、ＲＰＣエンジン２４０’のメイン作業スレッドに、作業が実行可能となったことが伝えられる。該メインスレッドが作業を始めると、グローバルキュー３５８がポーリングされて、待機状態となっているスケジューリングされた結合処理が確認される。その後、メインスレッドは該イベントを待機状態から外し、結合関連作業キュー３５６が処理される。
【００８３】
結合関連作業キュー３５６から、上記メインスレッドはそれまで待機していたＲＰＣ受信示唆作業要求を見つけ出す。次に、メインスレッドはＲＰＣ受信示唆作業要求３５６をキューから外し、該要求を解析する。図３Ａを参照して説明した上記融合処理により、モビリティ管理サーバ１０２は、それぞれのデータグラムに内包された複数のＲＰＣトランザクションを頻繁に受信することになる。モビリティ管理サーバ１０２は次に、該ＲＰＣトランザクションをそれぞれ逆多重化して別個の遠隔プロシージャ・コールに戻し、そして要求された機能をモバイル端末システム１０４に代わって実行する。パフォーマンス向上のため、ＲＰＣエンジン２４０’に、ＲＰＣメッセージ解析処理中の先読みメカニズムを備えさせて、ＲＰＣエンジン２４０’が、要求されたトランザクションのうちのいくつかを同時に実行できるか否か（パイプライン処理できるか否か）を確認してもよい。
【００８４】
（ＲＰＣエンジン２４０’によるＲＰＣ結合の実行手法）
図４は、結合作業キュー３５６に加えられたＲＰＣ結合を実行する処理を例示したフローチャートである。ＲＰＣ結合の実行が予定されている時、ＲＰＣプロトコル・エンジン２４０’（状態機械として設けられていてもよい）のメインスレッドは、グローバルネットワークキュー３５８からの作業要求を待機状態から外し、作業要求の種類を決定する。
【００８５】
本実施形態のＲＰＣ作業要求は、以下のような６つの基本的な種類に分けられる。
【００８６】
・スケジューリング要求（ｓｃｈｅｄｕｌｅ ｒｅｑｕｅｓｔ）
・接続示唆
・切断示唆
・ローカル結合中止（ｌｏｃａｌ ｔｅｒｍｉｎａｔｅ ａｓｓｏｃｉａｔｉｏｎ）
・「リソース使用可」要求（”ｒｅｓｏｕｒｃｅ ａｖａｉｌａｂｌｅ” ｒｅｑｕｅｓｔ）
・ｐｉｎｇ休止タイムアウト（ｐｉｎｇ ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｏｕｔ）
ＲＰＣプロトコル・エンジン２４０’は、上記の様々な種類の要求をそれぞれ別の方法で取り扱う。ＲＰＣプロトコル・エンジン２４０’は要求の種類（グローバルキュー３５８に記憶された、要求に関する情報によって識別される）をテストして、該要求をどう処理するかを決定する。
【００８７】
作業要求の種類が「スケジューリング要求」である場合（判定ブロック３６０）、ＲＰＣプロトコル・エンジン２４０’はどの結合が予定されているかを判別する（ブロック３６２）。ＲＰＣプロトコル・エンジン２４０’はこの判別を、グローバルキュー３５８に記憶されている情報に基づいて実行することができる。上記判別がなされると、ＲＰＣプロトコル・エンジン２４０’が、それぞれが対応する要求を記憶している結合作業キュー３５６（１）〜３５６（ｎ）のうちの一つを特定することが可能となる。ＲＰＣエンジン２４０’によって、対応する結合制御ブロックが取得され（ブロック３６２）、結合作業処理タスク（Ｐｒｏｃｅｓｓ Ａｓｓｏｃｉａｔｉｏｎ Ｗｏｒｋ ｔａｓｋ）３６４が呼び出されて、上記の特定された作業キュー３５６における作業の処理が始められる。
【００８８】
図５は、図４の「結合作業処理」タスク３６４によって実行されるステップを例示している。結合が特定されると、「結合作業処理」タスク３６４が呼び出され、対応する結合作業キュー３５６内の作業が処理される。待機状態から外された作業要求（ブロック３９０）がＲＰＣ受信要求（判定ブロック３９２）である場合、該ＲＰＣ受信要求はＲＰＣ構文解析部（ｐａｒｓｅｒ）に送られ、処理される（ブロック３９４）。あるいは、待機状態から外された作業要求（ブロック３９０）が、保留中の（ｐｅｎｄｉｎｇ）受信要求である場合（判定ブロック３９６）、ＲＰＣエンジン２４０’はＴＤＩ２０４’に、アプリケーションによる接続の代わりにデータを受信し始めるよう要求する（ブロック３９８）。上記待機状態から外された作業要求が、保留中の接続要求である場合（判定ブロック４００）、ＲＰＣエンジン２４０’はＴＤＩ２０４’に、アプリケーション用途ＴＣＰ（あるいは他のトランスポート・プロトコル）接続要求を発するよう要求し（ブロック４０２）、ＴＤＩ層２０４’からの応答を待つ。ＴＤＩ２０４’による要求が完了すると、該要求の状態が決定されて、元の要求エンティティへと報告が戻される。パフォーマンス向上のため、ＲＰＣエンジン２４０’は、実際に要求を発しているピアへエラーを通知する前に、要求を結合関連作業キュー（３５６）へと戻すことで、接続要求処理を複数回行うようになっていてもよい。この処理も、ネットワーク帯域幅およびリソースの消費を減らすためのものである。
【００８９】
上記の処理は、「スケジューリング重み付け」（ｓｃｈｅｄｕｌｉｎｇ ｗｅｉｇｈｔ ｃｏｍｐｌｅｔｅ）テスト（ブロック４０４）にパスするまで繰り返される。本例では、スケジューリング重みは、どれだけの作業要求が待機状態から外されて、上記の特定の結合がどれだけ処理されるかを決定するのに使われる。該スケジューリング重みは設定マネージャ２２８によって設定されるパラメータであり、結合接続示唆が検出されたときに取得される（図４、ブロック３７２）。この数値はユーザごとに、あるいは物理的な意味での装置ごとに設定可能である。
【００９０】
ＲＰＣエンジンが結合作業キュー３５６の作業を（少なくとも一時的に）終了した後、ディスパッチ・キューの処理に移ってもよい（ブロック４０６）（詳細は以下）。結合の作業キュー３５６における作業の処理後、ＲＰＣエンジン２４０’は、グローバル作業キュー３５８に新たなスケジューリング要求を発信して、後で実行される結合のスケジューリングを再び行う（図４の判定ブロック３６６、ブロック３６８、図５の判定ブロック４０８、ブロック４１０）。
【００９１】
再度図４を参照すれば、ＲＰＣ作業要求が「接続示唆」の場合（判定ブロック３７０）、ＲＰＣエンジン２４０’に、モバイル・ピア（通常はモバイル端末システム１０４だがこれに限らない）との新たな接続のインスタンスを作成せよという要求が入る。一例として、上記接続示唆により、接続を開始しようとしているピアの装置に関する以下のような情報がＲＰＣエンジン２４０’に与えられる。
【００９２】
・装置の物理的識別子
・該装置にログインしているユーザ名
・ピアの装置のアドレス
・ピアのＲＰＣエンジン２４０からの、付加的な接続データ
接続示唆（判定ブロック３７０）を受け、ＲＰＣエンジン２４０は上記のパラメータをもって設定マネージャ２２８をコールする。設定マネージャ２２８は該パラメータを用いて、上記新規接続の設定を確定する。この設定（例えば結合スケジューリング重みや、上記に加えてデフォルトでないスケジューリング特性を要するアプリケーション全てのリストなど）は、ＲＰＣエンジン２４０’に戻されて記憶、実行される。そしてＲＰＣエンジン２４０’は新規の結合を開始し、新規の結合制御ブロックを形成する（ブロック３７２）。図５Ａが示すように、以下のような動作が実行されてもよい。
【００９３】
・結合制御ブロックを割り当てる（ブロック３７２Ａ）
・システム全体のリソースをデフォルトにまで初期化する（ブロック３７２Ｂ）
・現在の設定をオーバーライドする（ブロック３７２Ｃ）
・フラグを初期化する（ブロック３７２Ｄ）
・結合特有作業キューを初期化する（ブロック３７２Ｅ）
・結合のオブジェクト・ハッシュ・テーブルを初期化する（ブロック３７２Ｆ）
・融合タイマーを初期化する（ブロック３７２Ｇ）
・結合制御ブロックをセッションテーブルに挿入する（ブロック３７２Ｈ）
インターネット・モビリティ・プロトコル・エンジン２４４’が結合を終了しなければならないと判断すると、「切断示唆」が該インターネット・モビリティ・プロトコル・エンジン２４４’からＲＰＣエンジン２４０’に出される。ＲＰＣエンジン２４０’はこの切断示唆をテストし（ブロック３７４）、示唆に応じて結合を停止し、結合制御ブロックを破棄する（ブロック３７６）。図５Ｂに示されるように、以下のステップが実行されてもよい。
【００９４】
・待機中の作業がこれ以上処理されないように、停止される結合をマークする（ブロック３７６Ａ）
・処理を含む、結合されている全ての結合オブジェクトをクローズする（ブロック３７６Ｂ）
・作業キューにある全てのエレメントを開放する（ブロック３７６Ｃ）
・融合タイマーが動作中ならば停止する（ブロック３７６Ｄ）
・結合制御ブロックの参照カウントを減少させる（ブロック３７６Ｅ）
・参照カウントが０の場合、（ブロック３７６Ｆにてテストされる）
・結合関連作業キューを破棄し、
・オブジェクト・ハッシュ・テーブルを破棄し、
・融合タイマーを破棄し、
・結合テーブルから結合制御ブロックを取り除き、
・制御ブロックを開放する（３７６Ｇ）
システム１０２が結合終了の必要性を認識すると、「セッション中止」要求が出される。この要求はシステム管理者、ＯＳ、あるいはアプリケーションから発される。ＲＰＣエンジン２４０’は、セッション中止要求を上記切断示唆と同様に扱う（判定ブロック３７８、ブロック３７６）。
【００９５】
本好ましい実施形態では、ＲＰＣエンジン２４０’とインターネット・モビリティ・プロトコル・エンジン２４４’との間のインターフェイスが、クレジット（ｃｒｅｄｉｔｓ）を基にフロー制御メカニズムを特定する。ある単一のスレッドが別のスレッドに作業要求を通知するたびに、コールされたスレッドは作業キューに残っているクレジットの数に戻る。キューが満杯であればクレジットのカウントは０になるが、慣例として、コールする側のスレッドは、クレジットのカウントが０ならばそれ以上作業通知をしない。よって、ユーザによって設定可能あるいは所定の最低点（ｌｏｗ−ｗａｔｅｒ ｍａｒｋ）をキューに付けて、待機中であった作業が処理されてリソースに余裕ができたことを、上記コールする側のスレッドに伝えるような構成が必要となる。これが、「リソース使用可」作業示唆が設けられている理由である（判定ブロック３８０にてテストされる）。図５Ｃが示すように、クレジットのカウントが０になったとき、以下のようなステップが実行されてもよい。
【００９６】
・ＲＰＣ＿ＬＭＰＱ＿ＳＥＮＤ＿ＦＬＡＧと設定して、結合に「ロー・マーク保留」（ｌｏｗ ｍａｒｋ ｐｅｎｄｉｎｇ）とマークを付ける（ブロック３７９Ａ）。この状態になったら、
・受信された全てのデータグラムを破棄する（ブロック３７９Ｂ）
・データ受信を拒否して全ての受信されたストリーム・イベントを抑える（ブロック３７９Ｃ）（これにより、ＴＣＰ他のトランスポート受信ウィンドウが結果的に閉じられ、固定端末システム１１０とモビリティ管理サーバ１０２との間のフロー制御がなされる。復帰の前に、本好ましい実施形態では「保留受信要求」（ｐｅｎｄｉｎｇ ｒｅｃｅｉｖｅ ｒｅｑｕｅｓｔ）を結合関連作業キュー３５６の前に押し込むので、保留中のストリーム受信イベントの処理（ｏｕｔｓｔａｎｄｉｎｇ ｓｔｒｅａｍ ｒｅｃｅｉｖｅ ｅｖｅｎｔ ｐｒｏｃｅｓｓｉｎｇ）が、リソースが利用可能になると直ちに継続される）。
【００９７】
・全ての受信された接続イベントが、受動接続のために拒否される（ブロック３７９Ｄ）
「リソース使用可」示唆をＲＰＣエンジン２４０’が受け取ると（図４、判定ブロック３８０）、該ＲＰＣエンジンは、結合された結合作業キュー３５６に待機中の作業があるか否かを判定する。もしあれば、ＲＰＣエンジンは該結合についてグローバル作業キュー３５８に通知して、上記結合作業キュー３５６が動作の優先権を持つことをマークしておく（ブロック３８２）。保留中の受信要求が、結合が保留受信要求状態にある期間に通知された場合、この期間中に処理される（本好ましい実施形態では、ＲＰＣエンジン２４０’は、この処理中も全ての受信された接続要求を受け入れる）。
【００９８】
再度図４を参照すると、ＲＰＣエンジン２４０’が、モビリティ管理サーバ１０２の「ｐｉｎｇ」に使われるチャネルが所定の期間にわたって休止していると判定した場合（判定ブロック３８４）、該チャネルは閉じられ、リソースは開放されてシステムに復帰し、他の処理に使用される（ブロック３８６）。
【００９９】
（ＲＰＣ構文解析と優先キュー）
再度図５を参照すると、ＲＰＣエンジンがＲＰＣ受信要求をその受信に際して構文解析することは前述した（ブロック３９２、３９４参照）。本好ましい実施形態において、構文解析は以下の点で必要とされる。即ち、受信された単一のデータグラムが複数のＲＰＣコールを含む可能性があるからであり、また、ＲＰＣコールがインターネット・モビリティ・プロトコルのデータグラムにおける複数のフラグメントにまで広がっている可能性があるからである。ＲＰＣ受信作業要求５００のフォーマットの例が図６に示される。ＲＰＣ受信作業要求のそれぞれは、少なくともメイン・フラグメント５０２（１）を有し、加えて任意の数の付加的フラグメント５０２（２）〜５０２（Ｎ）を有していることもある。メイン・フラグメント５０２（１）は、作業要求構造ヘッダ（ｗｏｒｋ ｒｅｑｕｅｓｔ ｓｔｒｕｃｔｕｒｅ ｈｅａｄｅｒ）５０３と、受信オーバーレイ５０４とを有している。受信オーバーレイ５０４は、インターネット・モビリティ・プロトコル・エンジン２４４によってメイン・フラグメント５０２（１）の先頭に設けられた受信オーバーレイである。この受信オーバーレイ５０４には、ｐユーザデータと呼ばれる、作業要求５００内で最初のＲＰＣコール５０６（１）を指し示す構造メンバがある。
【０１００】
図６の例に、複数のＲＰＣコール５０６（１）、５０６（２）…５０６（８）を含む、作業要求５００が図示されている。図６の例が示すように、ＲＰＣ作業要求５００は、メモリの隣接するブロックや単一のフラグメント５０２に含まれていなくてもよい。同例において、第二フラグメント５０２（２）と第三フラグメント５０２（３）とは、リンクしたリスト中でメイン・フラグメント５０２（１）に連鎖されている。
【０１０１】
よって、上記例のＲＰＣパーサ３９４は以下の境界条件を取り扱う。
【０１０２】
・ＲＰＣ受信要求５００それぞれが一つ以上のＲＰＣコールを含んでもよい
・一つ以上のＲＰＣコール５０６が、単一のフラグメント５０２中に存在してもよい
・ＲＰＣコール５０６それぞれが、フラグメント５０２中に完全に含まれていてもよい
・ＲＰＣコール５０６それぞれは、一つ以上のフラグメント５０２にまたがっていてもよい
図７は、ＲＰＣ受信作業要求５００を解析するＲＰＣ構文解析部３９４を例示している。本例において、ＲＰＣ構文解析部３９４は作業要求中の第一フラグメント５０２（１）を取得し、該フラグメント中の第一ＲＰＣコール５０６（１）を取得し、そしてＲＰＣコールを解析する。構文解析部３９４はＲＰＣ受信作業要求５００中を進んで、ＲＰＣコール５０６それぞれを処理していく。ＲＰＣ受信作業要求５００のフラグメント５０２（１）の残りのフラグメント・バイト数が、ＲＰＣヘッダ５０３のサイズよりも多い場合、構文解析部３９４は、ＲＰＣコールが完全にＲＰＣフラグメント５０２に含まれていて、処理を実行してもよいかどうかを判定する（該判定は、ＲＰＣコールの長さが残りのフラグメント・バイト数より大きいかどうかをテストすることでなされてもよい）。ＲＰＣコールの種類が連鎖例外である場合、ＲＰＣコールはＲＰＣ構文解析部３９４のアップデートを行うことになる。プロキシ・サーバ２２４において、連鎖例外であるＲＰＣコールは「データグラム送信」と「ストリーム送信」だけである。この連鎖例外プロシージャによって、ＲＰＣエンジンは、ＲＰＣ送信コールのためにメモリ記述子リストを共に連鎖することによるフラグメントコピーを避けることができる。
【０１０３】
構文解析部３９４がＲＰＣコールの種類を判別すると、ＲＰＣ情報の始めへのポインタは、実行のためにＲＰＣエンジン２４０へと転送される。ＲＰＣエンジンは、実行のために全てのＴＤＩプロシージャ・コールにそれぞれ別の優先順位をつける。最も優先度の高いコールは、ＲＰＣディスパッチャ３９５へ転送され、直ちに処理される。これより下の優先順位のコールは、後に処理されるために全てディスパッチ・キュー５１０にディスパッチされる。ディスパッチ・キュー５１０はそれぞれ離散的な優先度を表わしている。
【０１０４】
本実施形態では、モバイル・アプリケーションは、「オープンアドレス」オブジェクトおよび「オープン接続」オブジェクト機能を、他のＴＤＩネットワーキング機能を実行する前に呼び出す。よってシステムは、「オープンアドレス」オブジェクトおよび「オープン接続」オブジェクトの呼び出し中に、アプリケーションレベルの優先順位を割り当てることになる。例示の実施形態では、アドレスまたは接続オブジェクトに優先順位が付けられると、該オブジェクトに関連する全てのコールが、その割り当てられた優先順位中に実行される。
【０１０５】
例えば、ＲＰＣコールがＴＤＩオープンアドレスオブジェクト要求あるいはＴＤＩオープン接続オブジェクト要求である場合、該コールは直ちに実行されるべくＲＰＣディスパッチャ３９５に送られる。オープンアドレスおよびオープン接続オブジェクトＲＰＣコールにより、上記の接続示唆中に行われる設定要求の間に設定マネージャ２２８からもたらされる情報との対応に用いられる、処理ＩＤあるいは処理名へのアクセスが可能になる。該処理ＩＤあるいは処理名は、アドレスあるいは接続オブジェクトの設定を得るために用いられる。
【０１０６】
本好ましい実施形態では、全てのＲＰＣコールは、パラメータとして少なくともアドレスオブジェクトまたは接続オブジェクトを有している。コールが実行されると、そのオブジェクトに割り当てられた優先度が、ＲＰＣコールの優先度とされる。アドレスあるいは接続オブジェクトに割り当てられた設定により、実行される、対応するＲＰＣコール全ての優先度が決定される。例えば、割り当てられた優先度が「高」の場合、ディスパッチ・キュー５１０にディスパッチされることなく、全てのＲＰＣコールが直ちに実行される。割り当てられた優先度が「１」の場合、全てのＲＰＣコールが、ディスパッチ・キュー５１０（１）に加えられる。
【０１０７】
再度図５を参照すると、「結合作業処理」（ｐｒｏｃｅｓｓ ａｓｓｏｃｉａｔｉｏｎ ｗｏｒｋ）タスク３６４の処理が、予定された結合作業量の実行を完了すると（判定ブロック４０４）、ディスパッチ・キューがサービスを要求しているか否かが確認される（ブロック４０６）。図８は、図７に示されるディスパッチ・キュー５１０の処理のための「ディスパッチ・キュー処理」（ブロック４０６、図６）によって実行されるステップを例示したフローチャートである。
【０１０８】
この例では、ディスパッチ・キュー５１０は優先度が最高のキュー（本例では５１０（１））から処理される（ブロック４０８）。ディスパッチ・キュー５１０にはそれぞれ重み係数が設定されている。この重み係数は、モバイル端末システム１０４とモビリティ管理サーバ１０２との結合が確立された際に、設定マネージャ２２８によって返される設定パラメータである。例を挙げれば、優先度の低いディスパッチ・キュー５１０の重み係数は４であり、優先度が中程度のディスパッチ・キュー５１０重み係数は８である。本例では、優先度の高いＲＰＣコールは解析後直ちに処理されるため、重み係数を有していない。
【０１０９】
ＲＰＣエンジン２４０’は、現在のキューより始めて、ＲＰＣコールをキューから外していき、キューが空になるか、ＲＰＣコールのキュー重み番号（ｑｕｅｕｅ ｗｅｉｇｈｔ ｎｕｍｂｅｒ）が処理されるまでループする（ブロック４１２−４１６）。キューから外されたＲＰＣコールそれぞれに対して、その実行のためにＲＰＣディスパッチャ３９５が呼び出される。ＲＰＣディスパッチャ３９５はモバイル端末システム１０４の代理としてプロシージャ・コール（ｐｒｏｃｅｄｕｒａｌ ｃａｌｌ）を実行し、応答を要求している上記ＲＰＣコールに対するモバイル端末システムからの応答を生成する。
【０１１０】
上記ループを出た後、キューに残っている作業がまだある場合（判定ブロック４１８）、該キューが再実行を要することがマークされる（ブロック４２０）。ループを出ることで、上記システムはプロセッサを次に低い優先度のキューに移らせる（ブロック４２４、４１０）。これにより、ある特定のキューにどれだけの作業が割り振られていても、どの優先レベルにも実行される可能性が与えられることになる。システムは次のキューのサービスに移り、全てのキューが処理されるまで処理を繰り返す。全てのキューの処理が終了すると、システムは実行を要するマークがついたキューがあるか否かを判定して、もしあれば、スケジュール要求がグローバル作業キューに送られて、結合の再実行が予定されることになる。結合の再実行は、図４の「グローバル作業処理」ルーチンにおいて予定される。上記のアプローチにより、プロセッサが、処理すべき作業を有する他の結合にも実行の機会を与えることになる。キューそれぞれに重み係数を割り振ることで、システムは、モビリティ管理サーバ１０２のＣＰＵへのアクセスが優先レベルに応じて許可されるように調整されてもよい。これにより、優先度の高いキューは、先に実行されるだけでなく、さらに容易にＣＰＵにアクセスできるようになる。
【０１１１】
（モビリティ管理サーバのＲＰＣ応答）
上記では、どのように遠隔プロシージャ・コールがモバイル端末システム１０４からモビリティ管理サーバ１０２に送られて実行されるかを説明した。この型のＲＰＣコールに加え、モビリティ管理サーバ１０２のＲＰＣエンジン２４０’はＲＰＣイベントとＲＰＣ受信応答とをサポートしている。結合関連接続ピア（通常は固定端末システム１１０）の活動の結果として、ＲＰＣメッセージが非同期的に生成される。モビリティ管理サーバ１０２のＲＰＣエンジン２４０’は、ＲＰＣディスパッチャ３９５によって実行されるＲＰＣトランザクションを完了する。完了が成功したからといって、全てのＲＰＣコールが応答を要求するわけではないが、応答を要求する一部のＲＰＣコールにより、ＲＰＣディスパッチャ３９５は適切な応答を作成し、インターネット・モビリティ・プロトコル・エンジン２４４’に知らせ、そして該応答はピアのモバイル端末システム１０４に返される。ＲＰＣコールが失敗したときは、全てのＲＰＣコールが応答を生成する（上記においてＲＰＣ受信応答は例外）。
【０１１２】
ＲＰＣイベントは、結合関連接続（通常は固定端末システム１１０）によるネットワーク１０８の活動の結果として発信される。本好ましい実施形態では、こうしたＲＰＣイベントメッセージはモビリティ管理サーバ１０２によってプロキシされ、モバイル端末システム１０４へ送られる。本好ましい実施形態のモビリティ管理サーバ１０２は、以下のＲＰＣイベントコールをサポートする。
【０１１３】
・切断イベント（結合特定接続ピア（通常は固定端末システム１１０）がトランスポート・レベルで切断要求を出した場合に生起する。該要求はモバイル端末システム１０４に代わってプロキシ・サーバ２２４に受信され、プロキシ・サーバ２２４は切断イベントをモバイル端末システムに送る）
・ストリーム受信イベント（結合特定接続ピア（通常は固定端末システム１１０）がストリームデータをモバイル端末システム１０４へ送る際に生起。プロキシ・サーバ２２４はモバイル端末システム１０４に代わって該データを受け取り、受信応答（Ｒｅｃｅｉｖｅ Ｒｅｓｐｏｎｓｅ）として該データをモバイル端末システムに送る）
・データグラム受信イベント（結合特定ポータル（ａｓｓｏｃｉａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｐｏｒｔａｌ）のいずれかが、ネットワーク・ピア（通常は固定端末システム１１０）から送られ、モビリティ管理サーバ１０２を経由してモバイル端末システム１０４へ送られることになっている、データグラムを受け取る際に生起する。プロキシ・サーバ２２４はモバイル端末システム１０４に代わって該データグラムを受け入れ、データグラム受信イベントという形で該データグラムをモバイル端末システム１０４へ転送する）
・接続イベント（結合特定リスニングポータル（ａｓｓｏｃｉａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｌｉｓｔｅｎｉｎｇ ｐｏｒｔａｌ）が、トランスポート層とモバイル端末システム１０４との終端間接続を確立しようとする際、該結合特定リスニングポータルがトランスポート層接続要求（通常は固定端末システム１１０から）を受信するときに生起する。プロキシ・サーバ２２４はモバイル端末システムに代わって接続要求を受け入れ、接続イベントＲＰＣコールを生成してモバイル端末システムに送る）
図９は、ＲＰＣエンジン２４０’が、いかにしてプロキシ・サーバによって生成されたＲＰＣコールを扱うかということを示している。優先度の高いアドレスと接続オブジェクトに対し、ＲＰＣエンジン２４０’は、直ちに送信要求をインターネット・モビリティ・プロトコル・エンジン２４４’に向けてディスパッチする。該送信要求によって、ＲＰＣメッセージがピアのモバイル端末システム１０４に転送される。優先度の低いオブジェクトに対しては、インターネット・モビリティ・プロトコル・エンジン２４４の送信要求が適切な優先キュー５１０’に通知される。結合の実行が予定されていない場合、スケジュール要求もグローバルキュー３５８’に通知される。インターネット・モビリティ・プロトコルの送信要求は、最終的に、図５および８を参照して既に説明したディスパッチ・キューの処理の際に実行される。
【０１１４】
（インターネット・モビリティ・プロトコルの例）
本発明のインターネット・モビリティ・プロトコルは、メッセージ指向で接続ベースのプロトコルであり、配信保証、（再）オーダ検出（（ｒｅ）ｏｒｄｅｒ ｄｅｔｅｃｔｉｏｎ）、ロス回復が可能である。さらに、他の従来型接続指向プロトコル（即ちＴＣＰ）とは違い、複数の別のデータストリームを単一のチャネルにまとめることが可能になっており、保証されたデータ、信頼性の低いデータ、そして新規のメッセージ指向で信頼性の高いデータを、単一の仮想チャネルによって同時にネットワークをトラバースさせることができる。この新たなメッセージ指向のサービスのレベルによって、インターネット・モビリティ・プロトコルのピアが所定のプログラムデータユニットを確認したときに、リクエスト部に通知が行われることになる。
【０１１５】
本発明のインターネット・モビリティ・プロトコルは、既存のネットワーク・トポロジや技術にオーバーレイできるように設計されている。下層のネットワークアーキテクチャに左右されないので、該インターネット・モビリティ・プロトコルは汎用性を有する。パケット化されたデータが二つのピアの間を行き来できさえすれば、インターネット・モビリティ・プロトコルの使用が可能である。ノードそれぞれにおけるネットワークの現在地点（ＰＯＰ）あるいはネットワーク・インフラは、物理的境界、特定のポリシー、あるいは帯域幅の制限がある場合を除き、データの流れに影響を与えることなく変更可能である。
【０１１６】
インターネット・モビリティ・プロトコルは上層の助けを借りて様々なソースからのデータを融合し、下層のデータグラム機能を利用して該データを行き来させる。独立したデータユニットがそれぞれ上層から来ると、インターネット・モビリティ・プロトコルは該データユニットを単一のストリームとして、その後伝送する。該データユニットは次に既存のネットワークを通じてピアに送られ、受信時に、上層の助力によって上記ストリームが非多重化されて、元の独立した複数のデータユニットに戻る。これにより、伝送時にはその都度最大限のネットワークフレームが生成されて、帯域幅の利用を最適化することができる。さらに、上記により、帯域幅を最大限利用できるようにチャネルを調整することができるという効果を奏するとともに、全てのセッションレベルの接続に適用可能なパラメータを持たせることが可能となる。
【０１１７】
あるチャネルが不十分であるといった稀なケースでも、インターネット・モビリティ・プロトコルはピア間に複数のチャネルを確立することができる。これにより、データの優先順位付けや、（下層のネットワークがサポートしていれば）サービス品質の保証も可能になる。
【０１１８】
さらに、インターネット・モビリティ・プロトコルは、動的に選択可能で保証されたレベルのサービス、あるいは信頼性の低いレベルのサービスに対しても考慮されている。例えば、伝送されるプロトコル・データ・ユニットをそれぞれ、有効期間（ｖａｌｉｄｉｔｙ ｔｉｍｅ ｐｅｒｉｏｄ）か再伝送試行回数、もしくはその両方で制限して待機させることができる。インターネット・モビリティ・プロトコルは、どちらかの閾値に達するとデータユニットを有効期限切れとし、その後の伝送の試行から排除する。
【０１１９】
インターネット・モビリティ・プロトコルの、付加プロトコルとしてのオーバーヘッドは、可変長ヘッダの採用により最小限に抑えられている。該ヘッダのサイズはフレームの種類や任意フィールド（ｏｐｔｉｏｎａｌ ｆｉｅｌｄ）によって決定される。該任意フィールドは、ある特定のオーダにおいて追加されて、受信側による解析を容易にし、その存在はヘッダ・フラグ・フィールド（ｈｅａｄｅｒ ｆｌａｇ ｆｉｅｌｄ）のビットによって示される。ピアによる通信に必要な他の制御および設定情報は、全てバンド内制御チャネルを通過することができる。送信されるべき制御情報は全て、任意のアプリケーションレベルのプロトコル・データ・ユニットの前のフレームに加えられる。受信側では制御情報を処理して、次にペイロードの残りを上層に送る。
【０１２０】
エラー発生の確率が比較的高い、信頼性の低いネットワークにおける稼動が想定されているため、インターネット・モビリティ・プロトコルでは、データの完全性を保証し、ネットワークのパフォーマンスを最高まで引き出すべく、数々の技術が使われている。データの完全性を保証するため、フレッチャー・チェックサム・アルゴリズム（Ｆｌｅｔｃｈｅｒ ｃｈｅｃｋｓｕｍ ａｌｇｏｒｉｔｈｍ）が、誤ったフレームの検出用に使われている。このアルゴリズムは効率性と高い検出能力を買われて採用され、ビットエラーのみならずビットの並び替えも検出できる。ただし、上記アルゴリズムの代わりに他のチェックサム・アルゴリズムを採用してもよい。
【０１２１】
シーケンス番号は、オーダされたデータの配信を保証するために使われるが、インターネット・モビリティ・プロトコルにおけるシーケンス番号は、ＴＣＰの場合のようにデータのそれぞれのバイトを表わしているわけではない。一例としては、上記シーケンス番号は、最大６５５３５バイト（インターネット・モビリティ・プロトコル・ヘッダを含む）までの、データのフレームを表現している。該シーケンス番号は３２ビットなど適当な長さのものであって、制限された期間内での高い帯域幅のリンクにおいてラップアラウンドを生じさせないようにしている。
【０１２２】
上記の能力にデータの有効期限切れ機能を組み合わせたとき、再伝送（再試行）されたフレームが含んでいるデータ量が、送信側で生成された前バージョンよりも少ないことがある。フレームＩＤを設定して最新のバージョンのフレームが検知することも可能だが、本好ましい実施形態ではデータが追加されることは絶対に無く、削除されたそれぞれの要素がプロトコル・データ・ユニット全体であるため、上記の手法はシーケンス保証には必ずしも必要でない。一例として、インターネット・モビリティ・プロトコルは受信したある特定のフレームを、該フレームの異なったバージョンのものがいくら伝送されてきても、最初の一回目のみ処理する。新規のユーザ・ペイロードを運搬する、生成されたフレームそれぞれには、固有のシーケンス番号が割り振られる。
【０１２３】
スライディング・ウィンドウ技術の採用によってパフォーマンスが向上し、ピアにデータ受信の確認応答を要求する前に、複数のフレームを保留にできる（伝送できる）。適切なタイミングでのデータ配信を保証するため、肯定応答とタイマーベースの再伝送スキームとが採用されている。さらにチャネルの利用を最適化すべく、選択的な確認応答メカニズムが採用され、ネットワーク接続のロスが多い時間帯もしくは混雑した時間帯における、失われたフレームの迅速な再伝送と、素早い回復とが達成される。一例において、この選択的な確認応答メカニズムは、ヘッダに含まれる付加的なビットフィールドとして表わされる。
【０１２４】
輻輳回避アルゴリズムは、プロトコルをフレームの迅速な再伝送からバックオフさせるためにも用いられている。例えば、ラウンドトリップタイムは、再伝送無しで成功裏にピア間を伝送されたフレームそれぞれに対して計測することが可能である。この時間値は平均されて、再伝送タイムアウト値（ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｏｕｔ ｖａｌｕｅ）の基準となる。フレームが送られるごとに、それぞれのフレームに対してタイムアウトが設定される。あるフレームが実際に伝送されたにもかかわらず、該フレームに関する確認応答が受信されない場合、該フレームは再伝送される。このときタイムアウト値は上昇し、次の再伝送時間の基準となる。この再伝送タイムアウトには上限値および下限値が設定されているので、その値は適切な範囲に収まるようになっている。
【０１２５】
また、インターネット・モビリティ・プロトコルでは、送信路と受信路とが別に扱われている。この手法は、本質的に非対称のチャネルにおいて特に有用である。ヒステリシスに基づいて、インターネット・モビリティ・プロトコルは自動的に、フレームサイズ（フラグメント化閾値）、保留中のフレーム数、再伝送時間、遅延承認時間などのパラメータを調整して、ネットワークを通じて送られる複製データの量を減少させる。
【０１２６】
インターネット・モビリティ・プロトコルによって、ノードが様々なネットワークの違った接続ポイントに移動することが可能になるため、下層のネットワークの特性（例えばフレームサイズ）が途中で変わってしまうことがあるが、この移動の結果、あるネットワークで伝送待ちだったフレームが、モバイル装置が現在接続している新しい媒体にはフィットしないこともありうる。このことに、フラグメント化が全てのネットワーク・インフラでサポートされているわけではないことを合わせて考慮して、フラグメント化はインターネット・モビリティ・プロトコルのレベルにおいて扱われる。それぞれのフレームが伝送される前に、インターネット・モビリティ・プロトコルにより、フレームが現時点でのフラグメント化閾値を越えているか否かが判断される。ちなみに、パフォーマンス向上の見地から、この値は現時点での最大伝送ユニットよりも少なくてよい（大きいフレームよりも小さいフレームの方が最終目的地まで到達する可能性が高いため）。プロトコルのオーバーヘッドを増加させることと、再伝送回数の増加とのトレードオフは、インターネット・モビリティ・プロトコルによって吟味され、全体的に再伝送を減少させるため、フレームサイズが減少させられることもある。あるフレームがフィットしていれば、該フレームは分割されずに伝送される。していなければ、該フレームはその接続で許容される最大のサイズにまで分割される。フレームが再伝送される場合、該フレームは再評価を受け、最大伝送ユニットが減少していれば、再度フラグメント化される（あるいは、もし最大伝送ユニットが増加していれば、該フレームはフラグメント化されない一個のフレームとして再送信されることもありうる）。
【０１２７】
プロトコルそのものは直交に設計されており、どちらの側からでもピアとの接続を確立、切断することができるようになっている。しかし、ある場合においては、実行される場所によってプロトコル・エンジンにおける些少な動作上の差異がいくつか存在し、特定の休止検出や接続寿命タイムアウトは片方の側からしか実行できないこともある。運営上必要な操作を可能にするため、モビリティ管理サーバ１０２上で動作するインターネット・モビリティ・プロトコル・エンジンは、休止期間の状況を把握している。モバイル端末システム１０４からの作業が何もないまま一定の期間が経過した場合、モビリティ管理サーバ１０２はセッションを終了させることができる。また、管理者が、ある特定の接続を確立するのに要する総所要時間を制限する、あるいは日時によってアクセスを拒否することが必要なときがあるが、この場合も、一例としてこうしたポリシータイマーはモビリティ管理サーバ１０２側からのみ操作できるようにしてもよい。
【０１２８】
一例として、インターネット・モビリティ・プロトコルを提供するソフトウェアは、ウィンドウズ（登録商標）ＮＴ、９ｘ、ＣＥ環境で、プラットフォームに合わせた修正を必要とすることなくコンパイルされ、動作できるものである。これを実現するために、インターネット・モビリティ・プロトコルでは、インターネット・モビリティ・プロトコル・フレームの送受信に、ネットワーク抽象層（ｎｅｔｗｏｒｋ ａｂｓｔｒａｃｔｉｏｎ ｌａｙｅｒ； ＮＡＬ）のサービスが採用されている。メモリ管理、キューおよびリスト管理、イベントロギング、警報システム、電力管理、セキュリティなどの他の標準的なユーティリティ機能も使われる。いくつかのランタイム・パラメータについては、エンジンがモバイル端末システム１０４に備えられているか、あるいはモビリティ管理サーバ１０２側に備えられているかによって変更される。これについて、数例を以下に示す。
【０１２９】
・特定のタイムアウトは、モビリティ管理サーバ１０２からのみ呼び出し可能
・フレームの方向は、エコー検出用のフレームヘッダそれぞれにて示される
・モバイル端末システム１０４の設定により、着信接続（ｉｎｂｏｕｎｄ ｃｏｎｎｅｃｔｉｏｎ）の拒否が可能
・警報はモビリティ管理サーバ１０２にのみ通知される
・電力管理はモバイル端末システム１０４ではイネーブルにされるが、モビリティ管理サーバ１０２では必ずしも必要でない
インターネット・モビリティ・プロトコルのインターフェイスは、Ｃコーラブルでプラットフォームに依存しない標準的なＡＰＩ機能をほんの少数有し、作業（上記の標準的なユーティリティ機能以外）を予定する、ＯＳ特化型の単一の機能を必要とする構成でもよい。ローカルクライアントとの通信は、定義された作業オブジェクト（作業要求）の利用によって可能になる。作業要素それぞれの完了通知は、作業オブジェクトの一部として特定されたオプションの完了コールバックルーチンを通じて、要求エンティティに通知を行うことによって、効果的に達成することができる。
【０１３０】
インターネット・モビリティ・プロトコル・エンジン自体はキューベースのものである。ローカルクライアントからの作業要素は、ＦＩＦＯオーダに従ってグローバル作業キューに追加されるが、これは、ローカルクライアントが、「ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔｗｏｒｋ（）」などの標準的なインターネット・モビリティ・プロトコル機能を呼び出すことによってなされる。続いて、インターネット・モビリティ・プロトコル内のスケジューリング機能が該作業を除去し、適切な機能に対してディスパッチする。待機機能とスケジューリング機能を組み合わせることでＯＳのアーキテクチャ間の差を感じさせなくするので、プロトコル・エンジンが、スレッドベースのシステム（例えばウィンドウズ（登録商標）ＮＴ）や同期式のシステム（例えばマイクロソフト・ウィンドウズ（登録商標）９ｘやウィンドウズ（登録商標）ＣＥ）で動作することが可能になる。優先度に関するスキームを待機機能の上にオーバーレイすることができるので、（下の層がサポートしていれば）サービス品質を保証することができる。
【０１３１】
ネットワークの視点から見ると、インターネット・モビリティ・プロトコルは、データのコピーや移動を減らすべく、分散−集結技術（ｓｃａｔｔｅｒ−ｇａｔｈｅｒ ｔｅｃｈｎｉｑｕｅｓ）を利用している。伝送はそれぞれフラグメントのリストとしてＮＡＬに送られ、ネットワーク層のトランスポートによって融合される。トランスポート・プロトコル自体が分散−集結技術をサポートしている場合、フラグメントリストは上記トランスポートを通じて転送され、媒体アクセス層ドライバあるいはハードウェアによってアセンブルされる。さらに、上記技術を拡張して、プロトコルスタックのどのレベルにおいても、いかなるプロトコルラッパーの挿入や消去を行うことも可能である。フレームの受信は、ＮＡＬ層により、ＮＡＬ登録処理（ＮＡＬ ｒｅｇｉｓｔｒａｔｉｏｎ ｐｒｏｃｅｓｓ）時に指定された特定の入口点においてインターネット・モビリティ・プロトコルをコールバックすることで通知される。
【０１３２】
（インターネット・モビリティ・プロトコル・エンジンのエントリポイントの例）
例示の実施形態におけるインターネット・モビリティ・プロトコルは、該プロトコルのスタートアップおよびシャットダウン行動を管理する、４つの共通エントリポイントを有している。以下に示されるのがこれらのプロシージャである。
【０１３３】
１．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＣｒｅａｔｅ（）
２．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｕｎ（）
３．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＨａｌｔ（）
４．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＵｎｌｏａｄ（）
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＣｒｅａｔｅ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＣｒｅａｔｅ（）機能は、ブートサブシステムによって呼び出され、インターネット・モビリティ・プロトコルを初期化する。この第一フェイズ中に、作業の処理を開始するのに必要なリソース全てが所得され、初期化されなければならない。該フェイズの終了時、エンジンは、システムの他の層からの作業をすぐに受け入れ可能な状態である必要がある。このとき、インターネット・モビリティ・プロトコルはグローバル設定テーブルを初期化するが、このために、インターネット・モビリティ・プロトコルは、設定マネージャ２２８のサービスを利用して該テーブルを設定（ｐｏｐｕｌａｔｅ）する。
【０１３４】
次に、インターネット・モビリティ・プロトコルは、サスペンドおよびレジューム通知機能をＡＰＭハンドラに登録する。一例ではこれらの機能はモバイル端末システム１０４の側からのみ呼び出し可能であるが、他の例として、動作中にモビリティ管理サーバ１０２がサスペンドできるようにするのが望ましいこともある。続いて、グローバル作業キュー、グローバルＮＡＬポータルリストなど他の作業用記憶域がメモリプールから割り当てられる。
【０１３５】
必要なランタイムメモリの最大量を制限し、インターネット・モビリティ・プロトコルのハンドルの固有性を保証するため、インターネット・モビリティ・プロトコルは、ハンドル生成用の２段配列構成（２−ｔｉｅｒ ａｒｒａｙ ｓｃｈｅｍｅ）を採用している。グローバル接続配列テーブルのサイズは、システムが設定する同時接続の最大数によって決まり、この時点で割り当てられる。全てのグローバル記憶域が割り当てられ、初期化されると、グローバル・インターネット・モビリティ・プロトコルの状態が、＿ＳＴＡＴＥ＿ＩＮＩＴＩＡＬＩＺＥ＿となる。
【０１３６】
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｕｎ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｕｎ（）機能は、全てのサブシステムが初期化された後で呼び出され、インターネット・モビリティ・プロトコルのサブシステムに、待機中の作業をどれでも処理し始めてよいことを通知する。これが、一般的な動作状況におけるインターネット・モビリティ・プロトコル・エンジンの通常の状態である。該エンジンを動作状態にする前に、いくつかの第二パス初期化ステップがこの時点で実行される。
【０１３７】
インターネット・モビリティ・プロトコルは、ネットワーク通信が、任意のインターフェイスのどれを通じてでも実行されるようにする。初期化ステップの間に、インターネット・モビリティ・プロトコル−ＮＡＬ間のインターフェイス用の記憶域が割り当てられるので、インターネット・モビリティ・プロトコルはグローバルポータルリスト中を横断して、ＮＡＬの全てのリスナをスタートさせることができる。一例として、この動作は２つのステップを含んだ以下の処理のようになる。
【０１３８】
・インターネット・モビリティ・プロトコルは、ＮＡＬ層に、初期化中に供給される設定に基づいたポータルを結びつけて（ｂｉｎｄ）オープンし、
・インターネット・モビリティ・プロトコルは、次に、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲＣＶＦＲＯＭＣＢコールバックを登録して、受信したフレームの処理を始める準備ができたことを、ＮＡＬ層に通知する。
【０１３９】
・引き続き、ローカル持続識別子（ｌｏｃａｌ ｐｅｒｓｉｓｔｅｎｔ ｉｄｅｎｔｉｆｉｅｒ； ＰＩＤ）が初期化される。グローバル・インターネット・モビリティ・プロトコルの状態は、＿ＳＴＡＴＥ＿ＲＵＮ＿に変わる。
【０１４０】
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＨａｌｔ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＨａｌｔ（）機能は、システムがシャットダウンしたことをエンジンに警告するために呼びだされる。動作中に得られたリソースは、この機能から戻る前に全て開放される。インターネット・モビリティ・プロトコルの全てのセッションは、管理用に設定された理由コードによって異常終了する。エンジンが＿ＳＴＡＴＥ＿ＨＡＬＴＥＤ＿状態になると、それ以降、他の層からの作業は受け付けられず、他の層に通知されることも無い。
【０１４１】
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＵｎｌｏａｄ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＵｎｌｏａｄ（）機能は、シャットダウン処理の第二フェイズである。これが、復帰以前に、割り当てられたシステムリソースをエンジンが解放する最後の機会となる。エンジンがこの機能から戻ると、システム自体が停止するので、これ以上の作業は実行されない。
【０１４２】
（インターネット・モビリティ・プロトコル・ハンドルの例）
少なくともいくつかの例においては、メモリ（インターネット・モビリティ・プロトコル状態情報を記憶）のアドレスを、インターネット・モビリティ・プロトコルの接続を記述するトークンとして用いるだけでは不十分である。これは主に、短い期間のうちに、ある接続が終了して別の新しい接続が開始される可能性のためである。メモリアロケータが、別の接続に前のものと同じアドレスを再配分してしまう可能性が高く、この値が前の接続と新しい接続との両方を示すことになってしまう。元々のピアが、（電源が切られていたり、サスペンドしていたり、圏外にあったりなどで）セッションの終了を認識しなかった場合、前のセッションのフレームを新しいセッションの方に送ってしまうこともあり得る。ＴＣＰの場合はこれが起こり、ピアのＩＰアドレスが同じ場合、新しいセッションを生成するためにリセットが行われる。これを避けるため、インターネット・モビリティ・プロトコルは製造ハンドル（ｍａｎｕｆａｃｔｕｒｅｄ ｈａｎｄｌｅ）を採用している。該ハンドルは２列のインデックスによって形成され、独自性を保つため一回限りのものである。テーブルは以下のようなレイアウトとなっている。
【０１４３】
テーブル１：接続オブジェクトの配列を指すポインタの配列
テーブル２：インターネット・モビリティ・プロトコル制御ブロックを指す、実ポインタを含む接続オブジェクトの配列
この技術により、初期化期間に割り当てられるメモリの量が最小化される。テーブル１は、スタートアップの際にサイズが決められ、割り当てがなされる。これにより、モバイル端末システム１０４の側では、少量のメモリの割り当てが可能になる（モビリティ管理サーバ１０２側でテーブル１が割り当てを要求するメモリは、サーバが多くの接続を有しているため少し大きなものになる）。
【０１４４】
テーブル１は必要時に設定（ｐｏｐｕｌａｔｅ）される。接続要求が出されると、インターネット・モビリティ・プロトコルは、テーブル１内でテーブル２への有効なポインタを探す。エントリポイントが見つからない場合、インターネット・モビリティ・プロトコルは、新規のテーブル２に２５６個の接続オブジェクトを割り当て、テーブル２へのポインタを、テーブル１の適切なスロットに記録する。次に、プロトコル・エンジンはテーブル２を初期化し、新しく生成されたテーブルからの接続オブジェクトを割り当てて、製造ハンドルへ戻る。他のセッションが要求された場合、インターネット・モビリティ・プロトコルは再度テーブル１中をサーチして、テーブル２への有効なポインタを見つけ、該セッション用の次の接続オブジェクトを割り当てる。この作業は、以下の二つの状態のうちのどちらかになるまで続けられる。
【０１４５】
・テーブル２から全ての接続オブジェクトが無くなった場合、新たにテーブル２が割り当てられ、初期化されて、該テーブル２を示すポインタが、テーブル１の次に利用可能なスロットに設定される。
【０１４６】
・全ての接続オブジェクトが特定のテーブル２のインスタンスに開放され、全ての要素がある特定の期間使用されなかった場合、テーブル２の上記インスタンスにおける記憶域が開放されてメモリプールに戻され、テーブル１の関連しているポインタはゼロにされて、次の接続要求が開始された際、該入口が使用可能であることを示すようになる（テーブル２の他のインスタンスで、利用可能な接続オブジェクトがない場合に限る）。
【０１４７】
二つのグローバルカウンタは、割り当てられる接続の総数を制限できるようにするために維持されている。片方のグローバルカウンタは現時点でアクティブな接続を数え、もう片方のカウンタは、割り当てられていない接続オブジェクトの数を把握する。さらに、第二のカウンタは、任意に設定された制限まで生成可能な接続オブジェクトの総数の管理も行う。新規のテーブル２が割り当てられると、該カウンタは、該新規のテーブルが表現するオブジェクトの数を把握するため、下方に調整される。反対側では、インターネット・モビリティ・プロトコルがテーブル２のインスタンスをメモリプールに開放するときに、カウンタは、開放された接続オブジェクトの数を合わせて上方修正される。
【０１４８】
（ワークフローの例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔＷｏｒｋ（）機能によって、作業はローカルクライアントから要求される。該作業が検査（ｖａｌｉｄａｔｅ）され、グローバル作業キューに加えられると、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＱｕｅｕｅＥｌｉｇｉｂｌｅ（）機能が呼び出される。スレッド化された環境であれば、インターネット・モビリティ・プロトコルのワーカースレッドに信号が送られ（適合マークがつけられ）、制御は直ちに呼び出しエンティティへと戻る。同期的な環境であれば、グローバル作業キューが直ちに実行されて、要求された作業はいかなるものであっても処理される。どちらの場合でも、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＰｒｏｃｅｓｓＷｏｒｋ（）機能が実行されることになる。これが作業処理のためのメインディスパッチ機能である。
【０１４９】
例示の実施形態では、グローバルキューからの作業をディスパッチできるのが一回に一つのスレッドのみの場合があり、再入を防ぐべくグローバルセマフォが用いられてもよい。プライベートなインターネット・モビリティ・プロトコルの作業では、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔＷｏｒｋ（）機能を使用せず、直接グローバル作業キューに作業を送ることができる。
【０１５０】
ＳＥＮＤタイプの作業オブジェクトでは、特殊な場合が想定される。信頼性の低いデータグラムのセマンティクスが保たれていることを保証するため、ＳＥＮＤタイプの作業オブジェクトをそれぞれ、有効期限あるいは再試行カウントを伴って待機させることができる。作業は該有効期限に基づいて寿命を算定される。このような所定のタイムアウトが生じた場合、作業オブジェクトは接続特定キューから除かれ、エラー状態で完了する。ＳＥＮＤオブジェクトが既にデータパスに融合されている場合、プロトコルは、再試行カウントが設定されたどのＳＥＮＤオブジェクトでも、除去を許可する。再試行カウントを超過した場合、該オブジェクトは、特定のフレームを形成する要素のリストから外され、適当なエラー状態を示しつつリクエスタへ戻される。
【０１５１】
（接続スタートアップの例）
インターネット・モビリティ・プロトコルは、ピア間の接続を確立する非常に効率的なメカニズムを有している。接続の確認は、ピア間で最低３フレームをやり取りすることでなされる。開始側は、そのピアにＩＭＰ ＳＹＮＣフレームを送って接続確立が要求されていることを警告する。受け入れ側は、ＩＭＰ ＥＳＴＡＢＬＩＳＨフレームを送って接続受け入れを確認するか、あるいはＩＭＰ ＡＢＯＲＴフレームを送ることで、接続要求が拒否されたことをピアに警告する。ユーザに接続拒否の理由を理解しやすくするため、理由および状態コードが、ＩＭＰ ＡＢＯＲＴフレームに含まれる形で送られる。接続が許可されると、確認応答フレーム（プロトコル・データ・ユニットおよび制御データがふくまれていることもある）が送られて、受け入れ側に転送され、確立フレームの受信が確認される。
【０１５２】
ネットワークのトラフィックを最小化するため、プロトコルは、ユーザおよび制御データを、接続スタートアップ時の最初のハンドシェーク機構に含まれるようにすることができる。この構成は、セキュリティが保障されていない環境や、同じデータパスでセキュリティ用の認証が二重に行われたり、暗号化処理が同じデータパスで行われたりすることによるパフォーマンスの低下を避けるよう、インターネット・モビリティ・プロトコルが調整されているというような、セキュリティが下層で扱われている環境において使用される。
【０１５３】
（データ転送の例）
インターネット・モビリティ・プロトコルは、フレームがネットワークに配信されたことを、ＮＡＬからの通知によって検知する。インターネット・モビリティ・プロトコルは、当該ネットワークリンクが絶えずフロー制御されているか否かを上記メトリクスによって判定するので、当初の要求が完了されるまで同じフレームを再伝送することはない。しかし、ネットワークドライバによっては、フレームの伝送について、誤って、該フレームをネットワークに送る前に配信を示唆してしまうものもある。セマフォの利用により、インターネット・モビリティ・プロトコル層はこれを検知し、当初の要求についてＮＡＬが返答するまでは、他のデータグラムを送信しない。
【０１５４】
フレームがインターネット・モビリティ・プロトコルに受信されると、該フレームは迅速に検査されて、適切な接続キューに加えられる。該フレームが、インターネット・モビリティ・プロトコルがその最終目的地を識別するのに足る情報を有していない場合、該フレームは、それを受信したインターネット・モビリティ・プロトコル・ソケット・キューに加えられ、該ソケット・キューは、続く処理のためにグローバル作業キューに加えられる。この最初の逆多重化により、受信した作業は、処理オーバーヘッドが限定された状態で、迅速に拡散させられる。
【０１５５】
（黙認（ａｃｑｕｉｅｓｃｉｎｇ）の例）
再伝送時のネットワーク帯域幅およびモビリティ管理サーバ１０２の処理に要する電力の最小化のため、プロトコルは、モビリティ管理サーバ１０２が接続を「黙認」できるようにする。ユーザによる設定が可能な期間の後、モビリティ管理サーバ１０２は、対応するモバイル端末システム１０４から通知が無ければ、特定の接続へのフレームの再伝送を停止する。この時、モビリティ管理サーバ１０２は、モバイル端末システム１０４が通信できない状態（圏外、サスペンドなど）であると仮定し、接続を休止状態にする。該接続へのこの後の作業は全て、後の配信のために記憶される。該接続は、以下の状況のいずれかが満たされない限り、同じ状態にとどまり続ける。
【０１５６】
・モビリティ管理サーバ１０２がモバイル端末システム１０４からフレームを受信し、接続を本来の状態に戻す、
・接続寿命タイムアウトの期限が切れる、
・休止タイムアウトの期限が切れる、または
・システム管理者によって接続が中止される
モビリティ管理サーバ１０２が、モバイル端末システム１０４からフレームを受信し、中断された所から接続が再開された場合、該接続で待機していた作業は全て転送され、状態が再同期化される。これ以外の場合、再接続がなされると、モバイル端末システム１０４には以前の接続の終了が通知され、モバイル端末システム１０４に送られることを待機していた作業は破棄される。
【０１５７】
（接続および送信要求の例）
図１０Ａ〜１０Ｃは、インターネット・モビリティ・エンジン２４４によって生成される接続および送信要求ロジックを例示する、フローチャートを形成している。ＲＰＣエンジン２４０からの命令を受信すると、インターネット・モビリティ・プロトコル・エンジン２４４は、該命令が「接続」要求かどうかを判定する（判定ブロック６０２）。該命令が「接続」要求であれば、エンジン２４４は、接続リソースの割り当てが可能かどうかを判断する（判定ブロック６０３）。十分な接続リソースが割り当てられない場合（判定ブロック６０３で「ノー」である場合）、エンジン２４４はエラーを宣言して（ブロック６０３ａ）応答する。接続リソースの割り当てが可能であれば、エンジン２４４は状態設定処理を行って、接続要求の処理に備える（ブロック６０３ｂ）。
【０１５８】
接続その他の要求に対し、エンジン２４４は該接続あるいは送信要求を待機させ、呼び出しを実行しているアプリケーションに応答する前に、グローバルイベントに通知する（ブロック６０４）。
【０１５９】
インターネット・モビリティ・プロトコルのグローバル要求キューからの接続あるいは送信要求をディスパッチするために、エンジン２４４はまず、保留されている作業の有無を判定する（判定ブロック６０５）。保留されている作業が無ければ（判定ブロック６０５で「ノー」である場合）、エンジン２４４は、図１０Ｃのブロック６２５に移って、接続用の作業を待機させるため、アプリケーションからの応答を待つ（ブロック６０５Ａ）。保留されている作業があれば（判定ブロック６０５で「イエス」の場合）、エンジン２４４は現在の状態が確立されているか否かを判定する（ブロック６０６）。状態が確立されている場合（判定ブロック６０６で「イエス」の場合）、エンジン２４４は状態確立への移行のためのステップを飛ばして、図１０Ｂの判定ブロック６１５に移る（ブロック６０６ａ）。状態が確立されていない場合、エンジン２４４は状態確立のための一連のステップを実行する必要がある（判定ブロック６０６で「ノー」である場合）。
【０１６０】
状態確立に移行するために、エンジン２４４はまず、そのピアのアドレスが既知かどうかを判定する（判定ブロック６０７）。既知でなければ、エンジン２４４は作業をさらに待機させ、図１０Ｃのブロック６２５に移って、ピアのアドレスが来るのを待つ（ブロック６０７ａ）。ピアのアドレスが既知の場合（判定ブロック６０７で「イエス」の場合）、エンジン２４４は次に、必要なセキュリティコンテキストが取得されているかどうかを判定する（判定ブロック６０８）。取得されていない場合、エンジン２４４は作業をさらに待機させ、図１０Ｃのブロック６２５に移って、セキュリティコンテキストが来るのを待つ必要がある（ブロック６０７ａ）。セキュリティコンテキストが既に取得されている場合（判定ブロック６０８で「イエス」の場合）、エンジン２４４は「状態保留」状態を宣言して（ブロック６０８ｂ）、インターネット・モビリティ・プロトコルの同期フレームを送信し（ブロック６０９）、再伝送タイマーをスタートさせる（ブロック６１０）。エンジン２４４は、対応する確立フレームが受信されたかどうかを判定する（ブロック６１１）。受信されていない場合（判定ブロック６１１で「ノー」の場合）、エンジン２４４は、再伝送時間の期限が来たかどうかを判定する（判定ブロック６１２）。再伝送時間の期限が来ていない場合（判定ブロック６１２で「ノー」の場合）、エンジン２４４は待機し、続いてステップ６２５に移ってもよい（ブロック６１３）。最終的に、確立フレームが受信されず（ブロック６１１で判定）、再伝送時間の期限が全て切れた（判定ブロック６１４）場合、接続は中止されてもよい（ブロック６１４ａ）。結局確立フレームが受信された場合（判定ブロック６１１で「イエス」の場合）、エンジン２４４は「状態確立」状態を宣言する（ブロック６１１ａ）。
【０１６１】
状態確立がなされると、エンジン２４４は新規の接続の認証がなされているかどうかを判定する（判定ブロック６１５）。なされていない場合、エンジン２４４は待機し、ステップ６２５へと移ってよい（ブロック６１６）。接続の認証がなされている場合（判定ブロック６１５で「イエス」の場合）、エンジン２４４は認証が成功したかどうかを判定する（判定ブロック６１７）。成功していない場合（判定ブロック６１７で「ノー」の場合）接続は中止される（ブロック６１４ａ）。成功している場合、エンジン２４４は、ピア伝送ウィンドウがフルになっているかどうかを判定する（判定ブロック６１８）。フルになっていれば（判定ブロック６１８で「イエス」の場合）、エンジン２４４は確認応答を待ち、ステップ６２５に進む（判定ブロック６１９）。ウィンドウがフルになっていなければ（判定ブロック６１８で「ノー」の場合）、エンジン２４４はインターネット・モビリティ・プロトコル・データフレームを生成し（ブロック６２０）、送信する（ブロック６２１）。次に、エンジン２４４は再伝送タイマーがスタートしているかどうかを判定する（判定ブロック６２２）。していない場合、エンジン２４４は再伝送タイマーをスタートさせる（ブロック６２３）。エンジン２４４は、それ以上送信するデータが無くなるまで（判定ブロック６２４で判断される）、ブロック６１８〜６２３を繰り返す。そして、エンジン２４４はスリープモードに入ってさらに作業が来るのを待ち、グローバルディスパッチャに戻る（ブロック６２５）。
【０１６２】
（中止の例）
図１１は、接続を中止するためにインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示したフローチャートである。「接続中止」要求を受けて（ブロック６２６）、該エンジンは該要求をグローバル作業キューに加え、呼び出しを行っているアプリケーションに返答する（ブロック６２６ａ）。中止要求は最終的に、実行のため、インターネット・モビリティ・プロトコルの処理グローバル作業キューからディスパッチされる（ブロック６２７）。エンジン２４４は中止要求を調べて、該要求が緊急のものであるか、あるいは余裕のあるものであるかを判定する（判定ブロック６２８）。緊急のものの場合（判定ブロック６２８で「中止」の場合）、エンジン２４４は直ちに接続を中止する（ブロック６２９）。余裕があるものであれば（判定ブロック６２８で「余裕」の場合）、エンジン２４４は「状態クローズ（ｓｔａｔｅ ｃｌｏｓｅ）」状態を宣言し（ブロック６２８ａ）、インターネット・モビリティ・プロトコルの「モーティス（Ｍｏｒｔｉｓ）」フレームを送信し（ブロック６３０）、ピアに接続がクローズされることを示唆する。次に、エンジン２４４は「モーティス」状態を宣言し（ブロック６３０ａ）、再伝送タイマーをスタートさせる（ブロック６３１）。エンジン２４４は、ピアから「ポスト・モーテム（ｐｏｓｔ ｍｏｒｔｅｍ）」フレームが応答されたかどうかを判定する（判定ブロック６３２）。応答されていなければ（判定ブロック６３２で「ノー」の場合）、エンジン２４４は、再伝送タイマーが時間切れになっているか否かを判定する（判定ブロック６３３）。まだ時間切れになっていない場合（判定ブロック６３３で「ノー」の場合）、エンジン２４４は待機し、ステップ６３７へ進む（ブロック６３４）。再伝送タイマーが時間切れになっている場合（判定ブロック６３３で「イエス」の場合）、エンジン２４４は総再伝送時間の期限が切れているかどうかを判定する（判定ブロック６３５）。まだ切れていない場合（判定ブロック６３５で「ノー」の場合）、ブロック６３０に戻り、モーティスフレームを再送する。すでに総再伝送時間の期限が切れている場合（判定ブロック６３５で「イエス」の場合）、エンジン２４４は直ちに接続を中止する（ブロック６３５ａ）。
【０１６３】
「ポスト・モーテム」応答フレームがピアから受信されると（判定ブロック６３２で「イエス」）、エンジン２４４は「ポスト・モーテム」状態を宣言して（ブロック６３２ａ）、接続リソースを開放し（ブロック６３６）、スリープ状態に戻ってさらに作業を待つ（ブロック６３７）。
【０１６４】
（再伝送の例）
図１２は、インターネット・モビリティ・プロトコル・エンジン２４４が実行する「再伝送」イベントロジックの例を示している。再伝送タイマーが時間切れを迎える（ブロック６５０）と、エンジン２４４は、保留中のフレームがあるかどうかを判定する（判定ブロック６５１）。保留中のフレームがなければ（判定ブロック６５１で「ノー」の場合）、エンジン２４４はタイマーを破棄して（ブロック６５２）スリープ状態に戻る（ブロック６６０）。逆に保留中のフレームがあれば（判定ブロック６５１で「イエス」の場合）、エンジン２４４は、再伝送期間全体（ｅｎｔｉｒｅ）が終了したかどうかを判定する（判定ブロック６５３）。まだ終了していなければ（判定ブロック６５３で「ノー」の場合）、処理は時間差のためにスリープ状態に戻る（ブロック６５４）。既に終了していれば（判定ブロック６５３で「イエス」の場合）、エンジン２４４は、総ての（ｔｏｔａｌ）再伝送期間が終了したかどうかを判定する（判定ブロック６５５）。既に終了しており（判定ブロック６５５で「イエス」）、このイベントがモビリティ管理サーバのエンジン２４４’（モバイル端末システムのエンジン２４４に対応）で実行されている場合、休眠状態が宣言される（判定ブロック６５６、ブロック６５６ａ）。同じ状態で、モバイル端末システム１０４において実行されるインターネット・モビリティ・プロトコル・エンジン２４４は、接続を中止する（ブロック６５６ｂ）。
【０１６５】
総ての再伝送期間がまだ終了していない場合（判定ブロック６５５で「ノー」の場合）、エンジン２４４はフレームを再処理して時間切れのデータを除去し（ブロック６５７）、それを再転送し（ブロック６５８）、再転送タイマーをそのまま再始動させる（ブロック６５９）。そして処理は休眠状態に入り（ブロック６６０）、次のイベントを待つ。
【０１６６】
（インターネット・モビリティ・プロトコルのＰＤＵの期限切れの例）
図１２のブロック６５７において、要求を出している上層のインターフェイスが、結合しているピアに送られるプロトコル・データ・ユニット（つまりＳＥＮＤ作業要求）５０６の期限切れに関するタイムアウトあるいは再試行カウントを特定することが可能になる。この機能により、インターネット・モビリティ・プロトコル・エンジン２４４は、信頼性の低いデータのセマンティクス維持、再伝送されたデータからの信頼性の低いデータの除去など、他の機能も果たせるようになる。上層からのＰＤＵ（プロトコル・データ・ユニット）それぞれは、最終的にインターネット・モビリティ・プロトコル・エンジン２４４によってコーリシングされる、それぞれの要素に対する有効期限タイムアウト（ｖａｌｉｄｉｔｙ ｔｉｍｅｏｕｔ）および／または再試行カウントを、特定することができる。有効期限タイムアウトおよび／または再試行カウント（アプリケーションによってはユーザによって特定可能）は、エンジン２４４による再伝送の前に、どのＰＤＵ５０６が、転送されずにフレームから除去されるべきかを決定するために使われる。
【０１６７】
ＰＤＵ５０６に関わる有効期限タイムアウトは、ＰＤＵそれぞれが伝送に際して考慮すべき、相対期間（ｒｅｌａｔｉｖｅ ｔｉｍｅ ｐｅｒｉｏｄ）を特定する。実行依頼の間、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔＷｏｒｋ機能によって有効期限の値（ｅｘｐｉｒｙ ｔｉｍｅｏｕｔ ｖａｌｕｅ）がチェックされる。該値が０で無い場合、時期タイマー（ａｇｅ ｔｉｍｅｒ）は初期化される。次に、要求されたデータは、結合しているピアに送られる他のデータと同じキューに加えられる。あるＰＤＵ５０６が、有効期限パラメータ（ｖａｌｉｄｉｔｙ ｐｅｒｉｏｄ ｐａｒａｍｅｔｅｒ）が特定する期間よりも長くキューにある場合、該キューを処理する次イベントの間に、有効期限の切れた該（全ての）ＰＤＵは除去され、フレームの再伝送時に再伝送されるのではなく、ローカルに「タイムアウトによる失敗（ｔｉｍｅｏｕｔ ｆａｉｌｕｒｅ）」のステータスコードをもって完了する。このアルゴリズムにより、ピアへの伝送のために待機している信頼性の低いデータが古くなる（ｇｒｏｗ ｓｔａｌｅ）こと、および／または際限なくシステムリソースを消費することを防ぐ。
【０１６８】
図１２Ａの例において、少なくとも３つの独立したＰＤＵ５０６が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン２４４でキューに加わっている。ＰＤＵ５０６（１）は有効期限を持たず、要求に対するタイムアウトが無い。ＰＤＵ５０６（２）は、２秒の有効期間を持ち、時系列的にＰＤＵ５０６（１）の後に並んでいる。ＰＤＵ５０６（ｎ）は、２．５秒の有効期間を持ち、時系列的にＰＤＵ５０６（２）の後に並んでいる。ＰＤＵ５０６（ｎ）の待機が、キューの処理をさせ、ＰＤＵ５０６（２）の有効期間を経過させる最初のイベントであるため、ＰＤＵ５０６（２）は作業キューから外され、ローカルに完了されて、ＰＤＵ５０６（ｎ）がリストに加えられる。有効期間がＰＤＵ５０６（ｎ）に設定されている場合、ここまでの一連のイベントが繰り返される。作業キューを操作するいかなるイベント（キューに加える、キューから外す等）によっても、古くなったＰＤＵが除去され、完了される。
【０１６９】
上記のように、ＰＤＵ５０６はインターネット・モビリティ・プロトコル・エンジン２４４の伝送ロジックによって融合され、単一のデータストリームにフォーマットされる。独立した作業要素それぞれは、有効期限タイムアウトによって期限切れになっていなければ、集められてインターネット・モビリティ・プロトコル・データフレームを形成する。インターネット・モビリティ・プロトコル・エンジン２４４は、最終的にこれらのＰＤＵ５０６をピアに送り、関係するフレームをフレーム保留リスト（Ｆｒａｍｅｓ−Ｏｕｔｓｔａｎｄｉｎｇ ｌｉｓｔ）に加える。ピアが一定期間内に該フレームを認識しなかった場合（図１２の再伝送アルゴリズムを参照）、フレームは再伝送され、失われたかあるいは破損したパケットを回復する。再伝送の直前、フレームを形成するＰＤＵリストは、再試行カウントを伴った要求が待機しているかどうかを判定すべく反復される。該再試行カウントが０ではなく、０に向かって減少してゆく場合、ＰＤＵ５０６はリストから外され、フレームヘッダはデータの消去を示すように修正される。このように、古くなったデータ、低信頼のデータ、あるいは独自の再伝送ポリシーを持つアプリケーションは、エンジン２４４’の再伝送アルゴリズムによって負担をかけられることがない。
【０１７０】
図１２Ｂの例においても、少なくとも３つの独立したＰＤＵ５０６が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン２４４でキューに加わっている。ＰＤＵ５０６（１）は再試行カウント無しでキューに加わっているが、これは、継続的な再伝送の試行と、保証された配送レベルのサービスとを示している。ＰＤＵ５０２（２）は再試行カウントが１でキューに加わり、時系列的にＰＤＵ５０６（１）の後に並ぶ。ＰＤＵ５０６（ｎ）は、ある程度の時間が経過してからＰＤＵ５０２（２）より後ろに加わる。この時点で、いくつかの外部イベント（例えば上層融合・タイマー）が、エンジン２４４’に、インターネット・モビリティ・プロトコル・データフレーム５００を生成するための作業キューから十分なＰＤＵ５０６を集めて新しいフレームを生成するための論理を送信させる。フレームヘッダ５０３が求められ、これに、フレームの最初の伝送であることを示すための、再試行ＩＤとして０が付けられる。続いてフレームは、ネットワークへの後の伝送用に、ＮＡＬ層へと送られる。このときに再伝送タイマーがスタートするが、これは、当該のフレームがペイロードを含んでいるためである。説明を容易にするため、再伝送タイマーが期限を迎える前に、様々な理由でピアからの確認応答が受け取られなかったと仮定すると、エンジン２４４の再伝送ロジックにより、当該するフレーム５００が、ネットワークへ再伝送されるのに的確であるか否かが判断される。フレームをＮＡＬ層に再送する前に、エンジン２４４’の再伝送ロジックは、関連しているＰＤＵ５０６のリストを反復する。ＰＤＵ５０６（２）それぞれの再試行カウントが調べられ、０でなければ、該カウントは減少させられる。ＰＤＵ５０６（２）の再試行カウントを減少させる処理により、該カウントは０になる。ＰＤＵ５０６（２）の再試行カウントが０になったことにより、ＰＤＵ５０６（２）はリストから外され、「再試行失敗（ｒｅｔｒｙ ｆａｉｌｕｒｅ）」のステータスをもってローカルに完了する。続いて、ＰＤＵ５０６（２）のデータが無いことを示すため、フレームヘッダ５０３のサイズが調整される。この処理は、残っている全てのＰＤＵについて繰り返される。フレーム５００全体が、「編集後」フレーム５００’の作成のために再処理されると、ヘッダの再試行ＩＤが増加させられて、生成されたデータグラムが、続く（再）伝送に向けてＮＡＬ層に送られる。
【０１７１】
（受信の例）
図１３Ａ〜１３Ｄは、「受信」イベント受信に伴ってインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。このような受信イベントは、インターネット・モビリティ・プロトコル・エンジン・フレームがネットワーク１０８から送られた際に生成される。この受信イベントを受けて、エンジン２４４は該イベントを事前検査（ｐｒｅ−ｖａｌｉｄａｔｅ）し（ブロック６７０）、インターネット・モビリティ・プロトコル・エンジン・フレームである可能性があるか否かを判定する（判定ブロック６７１）。エンジンが可能性無しと判断した場合（判定ブロック６７１で「ノー」の場合）、該フレームは破棄される（ブロック６７２）。可能性ありという判断の場合（判定ブロック６７１で「イエス」の場合）、エンジン２４４は、受信したフレームと関連する接続があるかどうかを判定する（判定フレーム６７３）。受信したフレームと関連する接続がある場合（判定ブロック６７３で「イエス」の場合）、エンジン２４４は作業を接続受信キューに加え（ブロック６７４）、該接続に受信に適格であるとマークを付け（ブロック６７５）、該接続をグローバル作業キューに加える（ブロック６７６）。まだどの接続も受信したフレームと関連していない場合（判定ブロック６７３で「ノー」の場合）、エンジン２４４は、受信したフレームをソケット受信キューに加え（ブロック６７７）、該ソケット受信キューをグローバル作業キューに加える（ブロック６７８）。どちらの場合でも、エンジン２４４はグローバル作業イベントを送る（ブロック６７９）。「受信適格」イベントをグローバル作業キューからディスパッチする際（図１３Ｂ参照）、エンジン２４４はフレームをそれぞれの受信キューから外す（ブロック６８０）。インターネット・モビリティ・プロトコル・エンジン２４４がメッセージをキューから外し始められるようになる前に、複数のＩＭＰフレームを受信し、キューに加えることが可能である。エンジン２４４は、全てのフレームがキューから外れるまで作業を繰り返す（ブロック６８１、６８２）。あるフレームがキューから外れると（判定ブロック６８１で「イエス」）、エンジン２４４は受信したフレームを検査し（ブロック６８３）、該フレームが有効かどうかを判定する（判定ブロック６８４）。該受信したフレームが無効である場合、エンジン２４４は該フレームを破棄し（ブロック６８５）、受信キューから次のフレームを外す（ブロック６８０）。上記フレームが有効である場合（判定ブロック６８４で「イエス」の場合）、エンジン２４４は、該フレームが既存の接続と関連しているか否かを判定する（ブロック６８６）。していなければ（判定ブロック６８６で「ノー」の場合）、エンジン２４４は同期フレームがあるかどうかを判定する（判定ブロック６８７）。同期フレームがなければ（判定ブロック６８７で「ノー」の場合）、該フレームは破棄される（ブロック６８５）。反対に、同期フレームが受信されていれば（判定ブロック６８７で「イエス」の場合）、エンジン２４４は、図１４Ａおよび１４Ｂを参照して説明される受動接続要求により、該フレームを処理する（ブロック６８８）。
【０１７２】
上記フレームが接続と関係していれば（判定ブロック６８６で「イエス」の場合）、エンジン２４４は接続状態が依然アクティブで、まだ「ポスト・モーテム」になっていないかどうかを判定する（判定ブロック６８９）。接続が既に「ポスト・モーテム」である場合、フレームは破棄される（ブロック６８５）。そうでない場合、エンジン２４４はフレームを解析し（ブロック６９０）、該フレームが中止フレームであるかどうかを判定する（判定ブロック６９１）。該フレームが中止フレームであれば、エンジン２４４は直ちに接続を中止する（ブロック６９１ａ）。該フレームが中止フレームでなければ（判定ブロック６９１で「イエス」の場合）、エンジン２４４は確認応答情報を処理し、全ての保留中の送信フレームを開放する（ブロック６９２）。次に、エンジン２４４は、解読の必要がある場合のため、セキュリティ用のサブシステムへと送る（ブロック６９３）。フレームがセキュリティ用のサブシステムから戻ると、エンジン２４４は全ての制御データを処理する（ブロック６９４）。続いて、エンジン２４４はフレームがアプリケーションデータを含んでいるかどうかを判定する（判定ブロック６９５）。含んでいる場合、該データはアプリケーション層においてキューに加えられる（ブロック６９６）。エンジン２４４はまた、接続が休止状態であるかどうかを判定し（ブロック６９７および６９７ａ：これは、好ましい実施形態におけるモビリティ管理サーバのエンジン２４４’にもあてはまる）、確立状態に戻す。
【０１７３】
フレームが「モーティス」フレームである可能性があれば（判定ブロック６９８で「イエス」の場合）、エンジン２４４は、アプリケーション層に「切断」を示唆し（ブロック６９９）、「モーティス」状態に入る（ブロック６９９ａ）。エンジン２４４は「ポスト・モーテム」フレームをピアに送り（ブロック７００）、「ポスト・モーテム」状態に入る（ブロック７００ａ）。続いて、エンジン２４４は接続リソースを解放し（ブロック７０１）、スリープ状態に戻って作業を待つ（ブロック７０２）。解析されたフレームが「ポスト・モーテム」フレームだった場合（判定ブロック７０３で「イエス」の場合）、ブロック７００ａ、７０１、７０２が実行される。これ以外の場合、制御はブロック６８０に戻って、次のフレームを受信キューから外す（ブロック７０４）。
【０１７４】
（受動接続の例）
図１４Ａ〜１４Ｂは、「受動接続」要求に対してインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。まず、エンジン２４４は、当該装置に他の接続が存在するかどうかを判定する（ブロック７２０）。存在すれば（判定ブロック７２０で「イエス」の場合）、該エンジンは、それが最初の接続であるか否かを判定する（判定ブロック７２１）。ピアが、新規の接続が最初の接続であると認識している場合（判定ブロック７２１で「イエス」の場合）、エンジン２４４はそれ以前の接続を中止する（ブロック７２２）。最初の接続ではない場合（判定ブロック７２１で「ノー」の場合）、エンジン２４４は、シーケンスと接続ＩＤとが対応しているかどうかを判定する（判定ブロック７２３）。対応していなければ（判定ブロック７２３で「ノー」の場合）、制御は判定ブロック７２０へ戻る。シーケンスと接続ＩＤが対応していれば（判定ブロック７２３で「イエス」の場合）、エンジン２４４は複製フレームを破棄し（ブロック７２４）、図１３Ｂのステップ６８０に戻る（ブロック７２５）。
【０１７５】
他の接続が無ければ（判定ブロック７２０で「ノー」の場合）、エンジン２４４は、接続に接続リソースを割り当て可能か否かを判定する（判定ブロック７２６）。割り当て可能でない場合、エラーが宣言され（判定ブロック７２６で「ノー」の場合、ブロック７２７）、接続が中止される（ブロック７２８）。接続リソースを割り当て可能な場合（判定ブロック７２６で「イエス」の場合）、エンジン２４４は「設定」状態を宣言し（ブロック７２６ａ）、接続についてのセキュリティコンテキストを取得する（ブロック７３０）。十分なセキュリティコンテキストの取得ができなかった場合（判定ブロック７３１で「ノー」の場合）、接続は中止される（ブロック７２８）。取得できた場合、エンジン２４４は確立フレームを送り（ブロック７３２）、接続が「確立」状態になったことを宣言する（ブロック７３２ａ）。続いて、エンジン２４４は再送部（ｒｅｔｒａｎｓｍｉｔｔｅｒ）を始動させ（ブロック７３３）、完了に向けて認証処理を待つ（ブロック７３４）。最後に、エンジン２４４は装置とユーザとが両方認証済みか否かを判定する（ブロック７３５）。装置とユーザのどちらかが認証されていない場合、接続は中止される（ブロック７３６）。それ以外の場合、エンジン２４４は監視中の（ｌｉｓｔｅｎｉｎｇ）アプリケーションへの接続を示唆し（ブロック７３７）、設定を取得する（ブロック７３８）。この２ステップのどちらかが成功しなかった場合、接続は中止される（判定ブロック７３９、ブロック７４０）。成功した場合、処理はスリープ状態に戻って作業を待つ（ブロック７４１）。
【０１７６】
（異常終了の例）
図１５Ａおよび１５Ｂは、接続「中止」要求を受けて、インターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。キューを介してディスパッチされた、上記のような要求を他の処理（ブロック９９９）から受信すると（ブロック１０００）、エンジン２４４は、接続が該要求と関係しているかどうかを判断する（判定ブロック１００１）。関係していれば（判定ブロック１００１で「イエス」の場合）、エンジン２４４は元の状態をセーブして（ブロック１００２）、「中止」状態を宣言する（ブロック１００２ａ）。次に、エンジン２４４は、接続がＲＰＣエンジンに示唆されていたか否かを判定する（判定ブロック１００３）。されていれば、エンジン２４４は切断イベントを示唆し（ブロック１００４）、「ポスト・モーテム」状態を宣言して（ブロック１００３ａ）、該接続に割り当てられていたリソースを解放し（ブロック１００５）、元の状態が保留中の状態より大きいか否かを判定する（判定ブロック１００６）。元の状態が保留中の状態より大きくなければ、（判定ブロック１００６で「ノー」の場合）、処理は、呼び出しルーチンに戻るべく、ブロック１０１２に移る（ブロック１００７）。元の状態が保留中の状態より大きい場合には、エンジン２４４は、上記要求が受信フレームと関係しているかどうかを判定する（判定ブロック１００８）。中止要求が受信フレームと関係していて、受信フレームが中止フレームである場合（判定ブロック１００９）、受信フレームは呼び出しルーチンに戻る（ブロック１０１２）前に破棄される（ブロック１０１１）。
【０１７７】
（ローミング制御の例）
再度図１を参照すると、モバイルネットワーク１０８は、それぞれ別のネットワーク相互接続（１０７ａ〜１０７ｋ、無線トランシーバ１０６ａ〜１０６ｋにそれぞれ対応）を提供する、複数のセグメントを含んでいてもよい。本発明の別の側面において、モビリティ管理サーバ１０２を含むネットワーク１０８は、モバイル端末システム１０４があるネットワーク相互接続から別のネットワーク相互接続へと移る「ローミング」状況を、余裕を持って（ｇｒａｃｅｆｕｌｌｙ）扱うことができる。一般に、ネットワーク１０８のトポロジは、管理等の理由により、いくつかのセグメント（サブネット）に分けられ、一般的には、あるセグメントにおいて、別個のネットワーク（伝送）アドレスが複数のモバイル端末システム１０４それぞれに割り当てられている。
【０１７８】
上記のようなサブネットで新規に起動したネットワーク装置は、動的ホスト構成プロトコル（ＤＨＣＰ）を使用して、自動的に設定されるのが一般的である。例えば、サブネット上のＤＨＣＰサーバは、一般的に、そのクライアントに（他のものの提供に加えて）有効なネットワークアドレスを「リース」する。ＤＨＣＰクライアントは、永続的に割り当てられた、「固定符号化された（ｈａｒｄ−ｃｏｄｅｄ）」ネットワークアドレスを有していなくてもよい。その代わり、ブート時に、ＤＨＣＰクライアントはＤＨＣＰサーバにネットワークアドレスを要求する。ＤＨＣＰサーバは、割り当てに使用可能なネットワークアドレスをプールしている。ＤＨＣＰクライアントがネットワークアドレスを要求すると、ＤＨＣＰサーバはプールしていたアドレスを、該クライアントに割り当てあるいはリースする。割り当てられたネットワークアドレスは、特定の期間（リース期間）だけ、クライアントに所有される。リース期間が終わると、ネットワークアドレスはプールに戻され、他のクライアントへの割り当てに使用できるようになる。ネットワークアドレスの自動割り当てに加え、ＤＨＣＰはネットマスク等の設定情報を、ＤＨＣＰクライアントソフトウェアを動作させているクライアントに提供する。標準的なＤＨＣＰプロトコルについての詳しい情報は、ＲＦＣ２１３１に記載されている。
【０１７９】
よって、ＤＨＣＰを使用するモバイル端末システム１０４が、サブネットからサブネットへとローミングすると、該システムは新規のネットワークアドレスを持つことになる。本発明の一側面において、モバイル端末システム１０４とモビリティ管理サーバ１０２とがＤＨＣＰの自動設定機能を利用し協調することで、モビリティ管理サーバによるモバイル端末システム１０４の「新しい」ネットワークアドレスの認識や、該アドレスと、モビリティ管理サーバがプロキシする、以前に確立されていた接続との結合が保証される。
【０１８０】
ある実施例では、モバイル端末システム１０４が別のサブネットにローミングしたり圏外に出たりしたか否かを判定するために利用される、他の標準的な方法と並んで、エコー要求−応答（ｅｃｈｏ ｒｅｑｕｅｓｔ−ｒｅｓｐｏｎｓｅ）として、標準的なクライアント／サーバ型同報通信用のＤＨＣＰ Ｄｉｓｃｏｖｅｒ／Ｏｆｆｅｒメッセージのシーケンスが使用される。標準的なＤＨＣＰプロトコルに従って、ネットワークアドレスを要求するモバイル端末システム１０４が、ＤＨＣＰ Ｄｉｓｃｏｖｅｒメッセージの一部として、クライアント識別子とハードウェアのアドレスとを定期的に同報通信すると、これに対し、ＤＨＣＰサーバはＯｆｆｅｒ応答を同報通信する（要求しているモバイル端末システムがまだネットワークアドレスを持っていないため、該システムを特定して該応答を送るというよりも、同報通信によって該応答が伝えられるという形になる）。よって、当該サブネット上の全てのモバイル端末システム１０４は、ＤＨＣＰ Ｏｆｆｅｒサーバからの、同サブネット上のどのモバイル端末システムに同報通信された応答であっても受信することになる。
【０１８１】
本実施例では、ＤＨＣＰ同報通信メッセージをモニターするＤＨＣＰリスナが設けられており、モバイル端末システム１０４が、あるサブネットから別のサブネットへローミングしているか、およびＤＨＣＰによって新規のネットワークアドレスが取得できるようになっているかが確認される。図１６は、ＤＨＣＰリスナのデータ構造の例を示している。例えば、モバイル端末システムのリスナのデータ構造９０２は、以下の要素を有していてもよい。
【０１８２】
・サーバデータ構造の連結リスト、
・整数トランザクションＩＤ番号（ｘｉｄ）、
・カウンタ（「ｐｉｎｇ」）、および
・タイムアウト値
サーバデータ構造９０４は、それぞれ別のＤＨＣＰサーバを定義するデータブロックの連結リストを有していてもよい。該データブロックそれぞれは、以下の要素を有していてもよい。
【０１８３】
・次のサーバへのポインタ、
・サーバＩＤ（ＤＨＣＰサーバのネットワークアドレス）、
・最近該ＤＨＣＰサーバと結合したＢＯＯＴＰリレーエージェントのアドレス（ｇｉａｄｄｒ）、
・「ｐｉｎｇ」値（ｓｏｃｋｅｔ−＞ｐｉｎｇ）、および
・フラグ
これらのデータ構造は、ネットワーク１０８上のＤＨＣＰ同報通信トラフィックに基づいて、持続的にアップデートされる。以下に例示の諸機能は、該データ構造の維持に使用される。
【０１８４】
・ｒｏａｍＣｒｅａｔｅ（） （変数を初期化）
・ｒｏａｍＤｅｉｎｉｔｉａｌｉｚｅ（） （全てのリスナを消去）
・ｒｏａｍＳｒａｒｔＩｎｄｉｃａｔｉｏｎｓ（） （モバイル端末システムがローミングするかインターフェイスを変更した際に、登録主体ローミング示唆（ｒｅｇｉｓｔｒａｎｔ ｒｏａｍｉｎｇ ｉｎｄｉｃａｔｉｏｎｓ）のために、供給されたコールバックルーチンを呼び出す）
・ｒｏａｍＳｔｏｐＩｎｄｉｃａｔｉｏｎｓ（） （適当なコールバックをリストから除去して登録ローミング示唆を停止）
・インターフェイス変更（インターフェイスがネットワークアドレスを変更したことを示す、ＯＳからのコールバック通知）
・リスナ信号（ローミング、圏外、圏内復帰のいずれかの状態を示す、リスナからのインターフェイスごとのコールバック）
これに加え、リフレッシュ処理が、インターフェイス変更後にリスナをアップデートするために利用されてもよい。
【０１８５】
本好ましい実施形態では、全てのモバイル端末システム１０４が、ＤＨＣＰ Ｄｉｓｃｏｖｅｒ要求によって同じクライアント識別子とハードウェアアドレスとを伝送する。これにより、リスナのデータ構造とこれに関連する処理とが、モバイル端末システムからのＤｉｓｃｏｖｅｒ要求と、他のネットワーク装置からのＤｉｓｃｏｖｅｒ要求とを、区別することができるようになる。ＤＨＣＰサーバも同様に応答を同報通信するので、どのモバイル端末システム１０４および／またはモビリティ管理サーバ１０２も、ＤＨＣＰサーバからどのモバイル端末システムに出されたＯｆｆｅｒ応答でも受け取ることができる。複数のＤＨＣＰサーバが単一のＤＨＣＰ Ｄｉｓｃｏｖｅｒ要求に応答できるため、図１６のリスナのデータ構造は、サーバからの応答それぞれを、メインハンドルに連結リスト経由で結びつけられた、個別のデータブロックに記憶する。
【０１８６】
所定のクライアントハードウェアアドレスおよびクライアント識別子を有するＤｉｓｃｏｖｅｒ要求の受信に際し、本好ましい実施形態では、該要求がモバイル端末システム１０４から送られてきたものとして認識される。該メッセージが０に設定されたＢＯＯＴＰリレーアドレスをさらに有している場合、該メッセージはリスナと同じサブネットからのものであることが示唆されている。リスナは、最近モバイル端末システム１０４から送られたＤｉｓｃｏｖｅｒメッセージのトランザクションＩＤ（ｘｉｄ）と対応したトランザクションＩＤ（ｘｉｄ）が含まれていない限り、ＤＨＣＰ Ｏｆｆｅｒ応答を無視してもよい。該リスナは、新規のＢＯＯＴＰリレーエージェントＩＤおよび／または提供されたサブネットマスクでマスクされた、提供されたネットワークアドレスを持つ、既知のサーバから応答があれば、モバイル端末システム１０４がローミングしたと判定する。リスナは、旧サーバから肯定応答を受け取って初めて、新サーバを図１６のデータ構造に加える。リスナが新サーバからの応答は受け取ったが旧サーバからは受け取っていない場合、ローミング状態が示唆される（これについては設定によって変更可能である）。リスナが新旧両サーバのどちらからも応答を受け取っていない場合、リスナは圏外にあると判定される（この判定は、アプリケーションなど上層に警告を出して、停止や、バッファ・オーバーフロー回避のためのデータ送信量の減少に利用できる）。
【０１８７】
リスナがどのサーバからも応答を受信しない場合、参照点が無いため、ローミングが行われているかどうかが判定できない。この状況は、タイムアウト後にエラー警告して、呼び出し側に処理を再試行させることによって解消される。本好ましい実施形態では、新規のＢＯＯＴＰリレーエージェントＩＤ（または提供されたサブネットマスクでマスクされた、提供されたネットワークアドレス）を持つ、既知のサーバから応答があれば、モバイル端末システム１０４がローミングしたと判定する。リスナのデータ構造に、新サーバからの応答はあったが旧サーバからのものは無い場合、ローミングが行われた可能性はあるが、旧サーバからの応答がその後あるかもしれないので、待機して通知を遅らせる。新旧どちらのサーバからも応答が無い場合、モバイル端末システム１０４は圏外にある可能性があるので、モビリティ管理サーバ１０２は該システムが圏内に戻るのを待つ。
【０１８８】
図１７は、本好ましい実施形態のリスナ処理のステップを例示したフローチャートである。同図によると、ＤＨＣＰリスナ処理は、適切なメモリをハンドルに割り当て、ＮＡＬソケットをＤＨＣＰクライアントおよびサーバＵＤＰポートに解放し、その両者に対して受信コールバックを設定することによってなされる。次にタイマーが設定され（ブロック８０２）、上記処理は「待機」状態に入ってローミング関連のイベントを待つ（ブロック８０４）。イベントは、以下の３種の外部入力によって引き起こされる。
【０１８９】
・ＤＨＣＰサーバパケットを受信する
・他のモバイル端末システムからのＤＨＣＰクライアントパケットを受信する ・タイマーの期限が切れる
ＤＨＣＰサーバパケットを受信した場合、該パケットは、そのクライアント識別子が所定のクライアントＩＤと一致するか否かを判定するために調べられる（判定ブロック８０６）。一致しなければ、該パケットは破棄される。しかし、該パケットが所定のクライアントＩＤを含んでいる場合、該パケットがＤＨＣＰ Ｏｆｆｅｒパケットであるか否かが判定される（判定ブロック８０８）。該Ｏｆｆｅｒパケットは、最近送られたＤＨＣＰ Ｄｉｓｃｏｖｅｒシーケンスに対応したトランザクションＩＤを含んでいない限り、拒絶される。
【０１９０】
パケットトランザクションＩＤが対応していれば（ブロック８１０）、ＤＨＣＰ Ｏｆｆｅｒパケットを送信したサーバが既知であるか否か（つまり、サーバＩＤが図１６のリスナのデータ構造に含まれているか否か）が判定される（ブロック８１２）。サーバＩＤがリストに無い場合（判定ブロック８１２で「ノー」の場合）、サーバＩＤがリストに加えられ、「新規」とマークされる（あるいは、リストの最初のサーバであれば、「最初」とマークされる）（ブロック８２２）。サーバが既にリストにある場合（判定ブロック８１２で「イエス」の場合）、さらに、パケットＢＯＯＴＰリレーアドレス（「ＧＩＡＤＤＲ」）がサーバアドレス（「ＧＩＡＤＤＲ」）に対応しているか否かが判定される（判定ブロック８１４）。対応していなければ、Ｏｆｆｅｒパケットは他のサブネットからのものということになるので、「ハードローミング（ｈａｒｄ ｒｏａｍ）」が実行されたと判定される（ブロック８１６）。呼び出し側のアプリケーションには、ローミングが行われたことが通知される。判定ブロック８１４でＢＯＯＴＰリレーアドレスが対応していると判定されると、ローミングは行われていないということになり、サーバ受信時間を記録し、リストの他のサーバ全てについて「新規」フラグをリセットし、現在のｐｉｎｇ番号をサーバに記憶するというリスナ処理が行われる（ブロック８１８、８２０）。続いて、処理は「待機」期間に戻る。
【０１９１】
イベントがクライアントパケットに受信されると、リスナ処理では、該パケットが所定のクライアントＩＤを有しているか、ＤＨＣＰ Ｄｉｓｃｏｖｅｒパケットか、および０のパケットＢＯＯＴＰリレーアドレス（ＧＩＡＤＤＲ）を有しているかどうかが判定される（ブロック８２４、８２６、８２８）。これらのステップにより、上記受信パケットが、リスナと同じサブネット上にある、他のモバイル端末システムから送信されたＤＨＣＰ Ｄｉｓｃｏｖｅｒメッセージであるか否かが判定される。そうであれば、リスナ処理により、上記トランザクションＩＤが、後に受信されるＤＨＣＰ Ｏｆｆｅｒパケットの比較に用いられる、ピアのトランザクションＩＤに設定され（ブロック８３０）、「ｐｉｎｇ確認」が呼び出され（ブロック８３４）、タイマーがリセットされる（ブロック８３６）。
【０１９２】
タイマーの期限切れにより、処理は「ｐｉｎｇ確認」を呼び出す（ブロック８３８）。本好ましい実施形態における「ｐｉｎｇ」は、ランダムな新規のｘｉｄを有するＤＨＣＰ Ｄｉｓｃｏｖｅｒパケットである。このｐｉｎｇ確認８３８のステップが、図１７Ａに例示されている。ｐｉｎｇ確認ルーチンの目的は、「ソフトローミング（ｓｏｆｔ ｒｏａｍ）」状態（つまり、モバイル端末システムが、一時的にサブネットとのコンタクトを失ったもののその後回復したが、まだ他のサブネットにローミングはしていない状態）が発生しているか否かの判定である。処理によって、サブネット・ローミング状態、圏外状態、あるいは「サーバ無し」状態が発生しているか否かが判定される。これらを言い換えると以下のようになる。
【０１９３】
・モバイル端末システムが、あるサブネットから別のものにローミングしたか？
・モバイル端末システムは圏外にあるか？
・ＤＨＣＰサーバは不在か？
これらの状態は、モバイル端末システムの、前「ｐｉｎｇ」応答と現「ｐｉｎｇ」応答とを比較することによって判定される（判定ブロック８４６、８５０）。例えば、現ｐｉｎｇ数から旧サーバの前ｐｉｎｇ応答を引いた数が、サブネットのサーバのｐｉｎｇよりも大きく、少なくとも一つのサーバが「新規」とマークされている場合、別のサーバへのサブネット・ローミングがあったということになる。この論理により、コーリング処理に対し、サブネット・ローミング状態、圏外状態、あるいはサーバ無し状態が示唆される（あるいはいずれも示唆されない）。
【０１９４】
図１８は、モバイル端末システム１０４のローミング制御センター（ｒｏａｍｉｎｇ ｃｏｎｔｒｏｌ ｃｅｎｔｅｒ）が実行するステップを例示したフローチャートである。モバイル端末システム１０４でのローミングを可能にするため、既知のアドレスのリストが０に初期化され（ブロック８５０）、ＯＳインターフェイス変更通知がイネーブルになり（ブロック８５２）、次に、ＯＳを呼び出して、ＤＨＣＰを利用する現在のアドレスのリストを所得する（ブロック８５４）。現在のリストから無くなった全ての既知のアドレスに対応するリスナが閉じられ（ブロック８５６）、一方、現在のリストにあるが未知のインターフェイスにあるリスナが開放される（ブロック８５８）。次に、登録主体に「ローミング」を示唆する（ブロック８６０）。
【０１９５】
図１７のリスナ処理から信号が送られると（ブロック８６２）、該信号が、「ローミング」、「圏外」、「圏内復帰」のいずれの状態を示しているかが判定される（判定ブロック８６４、８７０、８７４）。ローミング信号（判定ブロック８６４で「イエス」）により、対応するリスナ８６６が閉じられ、ＯＳがコールされて、ネットワークアドレスのＤＨＣＰリースが解放、更新される（ブロック８６８）。リスナ信号が「圏外」の場合（判定ブロック８７０）、該状態が登録主体に示唆される（ブロック８７２）。該信号が「圏内復帰」の場合（判定ブロック８７４）、該状態は全ての登録主体に示唆される（ブロック８７６）。無効のローミング命令を受信すると（ブロック８７８）、全てのリスナが閉じられ（ブロック８８０）、ＯＳインターフェイス変更通知が無効になる（ブロック８８２）。
【０１９６】
（インターフェイスによって補助されたローミングのリスナの例）
さらに、インターフェイスベースのリスナによって、同じネットワークおよび別のネットワーク媒体のネットワーク接続ポイントを横断したローミングが可能になる。該インターフェイスベースのリスナが上述のビーコン技術を要することなく動作する一方、下層の（複数の）インターフェイスが適切な信号をサポートしていない場合には、システムをビーコン状態にフォールバックさせることもできる。
【０１９７】
本実施形態において、インターフェイスベースのリスナは、ネットワーク・インターフェイス・アダプタからの（例えば低レベルのインターフェイス・ローミング・ドライバを経由した）情報を、ネットワークスタックからの情報と統合して、モバイルノードが新規のネットワーク接続ポイントに移動したか否かを判定する。図１９Ａと１９Ｂは、モバイルノードの移動パス（ｍｉｇｒａｔｉｏｎ ｐａｔｈ）を効率的に決定するのに利用される、リスナ・アルゴリズムを例示する。該処理では、単一のネットワーク媒体に接続された単一のネットワーク・インターフェイスが使用されているが、単独で、もしくは他のローミング・アルゴリズムと協働して、（例えば、冗長パスを使った自己回復インフラ構築のために）様々なネットワーク媒体やインターフェイスを横断するようにもできる。
【０１９８】
図１９Ａを参照すると、システム初期化時や、ネットワークアダプタドライバがロードする際に（図１９Ａ、ブロック２０００）、低レベルのインターフェイス・ローミング・ドライバは、図１８のローミング制御センターモジュールに登録を実行する（ブロック２０１０）。このような登録（例示の実施形態では、ｃｒＲｅｇｉｓｔｅｒＣａｒｄＨａｎｄｌｅｒ（）機能を通じて実現される）により、下記のエントリポイントが与えられる。
【０１９９】
・開
・閉
・状態（ｓｔａｔｕｓ）取得
・ドライバが登録主体に状態の変化を通知可能であれば、ブール演算を真とし、ローミング制御センターモジュールが、状態確認にタイマーベース（等）のポーリングを使わなければならない場合は、ブール演算を偽とする
実施例のｃｒＲｅｇｉｓｔｅｒＣａｒｄＨａｎｄｌｅｒ（）機能により、インターフェイス記述ストリング、あるいはローミング制御センターモジュールを正しいローミングドライバと予備的に組み合わせるために使用できるトークンが与えられる。また、デフォルトのローミングドライバが、示唆／問合せ（ｓｉｇｎａｌｉｎｇ／ｑｕｅｒｙｉｎｇ）媒体接続性およびネットワーク接続ポイントの変更に関するＯＳ包括メカニズム（Ｏ／Ｓ ｇｅｎｅｒｉｃ ｍｅｃｈａｎｉｓｍ）を使用するインターフェイスに、インストールされてもよい。
【０２００】
本実施例では、インターフェイスの状態がイネーブルになると（つまりネットワークへのアクセスが可能になると）（ブロック２０２０）、ローミング制御センターは、インターフェイス補助ローミング（ｉｎｔｅｒｆａｃｅ ａｓｓｉｓｔｅｄ ｒｏａｍｉｎｇ； ＩＡＲ）を、以下のステップに基づいて試みる（ただし、以下のステップは、ＯＳの設計および／または特定のアプリケーションに使われるホスティング装置によって、入れ替えられたり省略されたりすることがある）。
【０２０１】
１．包括ハンドラ（ｇｅｎｅｒｉｃ ｈａｎｄｌｅｒ）がインストールされている場合、包括ｃｒＯｐｅｎＩｎｓｔａｎｃｅ（）ハンドラへのコールがなされる。包括ハンドラは低レベルアダプタドライバに問合せをして、該ドライバが、媒体接続性の状態およびネットワーク接続ポイントの変更に関する信号を包括的にサポートしているか否かを判定する（ブロック２０３０）。インターフェイスドライバが該機能を包括的にサポートできない場合（判定ブロック２０３０で「ノー」の場合）、エラー状態が、コール実行側に返され、信号情報の取得に他のメカニズムを使用することが示唆される。
【０２０２】
２．包括ハンドラがエラー（判定ブロック２０３０で「ノー」）を返した場合、アクティブなインターフェイスに関する検索が、現在登録されているローミングドライバにおいて実行される（ブロック２０４０）。該インターフェイスが、ｃｒＲｅｇｉｓｔｅｒＣａｒｄＨａｎｄｌｅｒ（）フェイズ中に登録されたトークンのうちの一つと一致する場合（ブロック２０５０）、ローミング制御センターは、アダプタのインスタンスへの特定のｃｒＯｐｅｎＩｎｓｔａｎｃｅ（）をコールする。この機能は、低レベルドライバを開き、状態（媒体接続性、ネットワーク接続ポイントＩＤ）を再度ポーリングし、定期ポーリングタイマーを（可能ならば）設定することを試みるものである。低レベルドライバが、なんらかの理由で該要求をサポートしていない場合、ローミング制御センターにエラーが返されて、信号情報の取得に他のメカニズムを使用することが示唆される。
【０２０３】
３．ここまでのステップのいずれかが、要求された機能を達成できない場合、エラーがローミング制御センターに返されて、ＩＡＲ機能を使用せずに、図１７および１７Ａのビーコンリスナ（ｂｅａｃｏｎｉｎｇ ｌｉｓｔｅｎｅｒ）、モバイルＩＰ、あるいは場合により、ローミングを扱っている、現在接続されているネットワークなど、他のローミング・アルゴリズムにフォールバックすることが示唆される（判定ブロック２０５０で「ノー」の場合、ブロック２０６０）。これ以外の場合、インターフェイス補助ローミングがイネーブルになり（ブロック２０６０）、ローミング制御センターは下記のアルゴリズムに従う。
【０２０４】
まず、インターフェイスによって補助されたリスナは、現在の媒体接続性の状態と、ネットワーク接続ポイントの識別情報とを、ローカルデータストアに記録する（ブロック２０６０）。インターフェイスによって補助されたサブシステムがローミングフィードバックの供給に成功したと仮定して、該サブシステムは状態イベントを待つ（ブロック２１００）。該イベントは、例えば以下のものを有している。
【０２０５】
・低レベルローミングドライバからのコールバック、
・ポーリング間隔（ｔｉｍｅｄ ｐｏｌｌ ｉｎｔｅｒｖａｌ）（ブロック２０７０、２０９０）、あるいは
・ネットワーク・レベルの活動（つまり、伝送／受信にかかわる問題）からの示唆
インターフェイスの状態が、媒体接続性に変化が生じたか、あるいはネットワーク接続ポイントが変更されたかを示すと（図１９Ｂの判定ブロック２１１０もしくは２１２０で「イエス」の場合）、ローミング制御センターの全てのクライアントに、以下のルールに基づいて、状態の変化が知らされる。
【０２０６】
１．状態が、下層のネットワーク媒体への接続から切断へと変化したことを示し（ブロック２１２０で「イエス」）、ピアへのパスが他に無い場合、リスナは、モバイル端末システムが接続を失ったと結論付け、ローミング制御センターはそのクライアントに、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＯＵＴ＿ＯＦ＿ＣＯＮＴＡＣＴ状態を示唆する（ブロック２１４０）。
【０２０７】
２．上記状態が、インターフェイスが媒体に再接続され、ネットワーク接続ポイントが変わっていないことを示し（ブロック２１２０で「ノー」の後、ブロック２１５０で「ノー」の場合）、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＯＵＴ＿ＯＦ＿ＣＯＮＴＡＣＴが既に示唆されている場合、モバイル端末システムが、特定のネットワーク接続ポイントとのコンタクトを失ったがその後取り戻したことが示唆される。この場合、ローミング制御センターは、適切なアクセスのために登録または取得された全てのネットワークアドレスを再確認し（ブロック２１７０）、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＡＭ＿ＳＡＭＥ＿ＳＵＢＮＥＴを出して（ブロック２１８０）、ローミング制御センターのクライアントに、再接続が行われたので、トランスポート・レベルでの通信の再確立に必要な措置を全て実行するように警告する。例えば、サービス中断中にいくつかのデータが失われることがあれば、クライアントは該データを回復するために措置を講じるといったことである。
【０２０８】
３．上記状態が、インターフェイスが媒体に取り付けられているが、ネットワーク接続ポイントが変更されたことを示している場合（ブロック２１５０で「イエス」の場合）、ローミング制御センターはクライアントに、ローミング状態になったことを示唆する。ネットワーク接続ポイント間のハンドオフをさらに効率的にサポートするために、本例のローミング制御センターは、ローカルデータストアと並行して学習アルゴリズムを使用している。該データストアは、通常動的にポピュレートされている（学習している）が、パフォーマンス向上のため、該データストアに静的な情報（既に学習された情報）が準備されていてもよい。データストア自体は、ネットワーク接続ポイント識別子のリストを、ネットワークや媒体へのアクセスのアドレスやネットワークマスクなどの情報とともに維持している。この「ネットワーク・トポロジ・マップ」は、ローミング制御センターがクライアントに対して正しい信号の生成を決定できるように補助するものである。
【０２０９】
正しい信号の決定は、本実施例では以下のようにしてなされる。
【０２１０】
ａ）データストアのネットワーク・トポロジ・マップを検索して、インターフェイスが特定のネットワーク接続ポイントを訪れたか否かが判定される（ブロック２１９０）。対応が見つかれば（ブロック２２００で「イエス」）、該ネットワーク接続ポイントが、以前にインターフェイスが結合していたのと同じネットワーク・セグメントにあるか否かがさらにチェックされる。ネットワーク・セグメントが同じであれば、ローミング制御センターは、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＡＭ＿ＳＡＭＥ＿ＳＵＢＮＥＴを生成する。これにより、ローミング制御センターのクライアントに、ハンドオフが実行され、ハンドオフ中にデータのいくつかが失われた可能性があるため、直ちにトランスポート・レベルでの通信の再確立をするための可能な限りの措置を講じなければならないことが示唆される。
【０２１１】
ｂ）検索中に対応は発見されたが、新しいネットワーク接続ポイントは前と同じネットワーク・セグメントにない場合、リスナは、モバイル端末システムが別のサブネットワークにローミングしたと結論付ける。この場合、ローミング制御センターは、
・新規のネットワーク・セグメントで使用可能なアドレスを取得する（ブロック２２２０）。この動作は、現在のアドレスを新規のセグメントで有効なように登録すること、ローカルサーバからアドレスを（再）取得すること、あるいは以前に割り当てられたアドレスがまだ有効かどうか判定するヒューリスティックな手法を用いてもよい。最後のケースでは、ローミング制御センターにより、インターフェイスが所与のネットワーク接続ポイント間をローミングしていて、パフォーマンス維持の観点から、直ちにネットワークアドレスを破棄したり、その登録を抹消したりできないような状態にあるかどうかが判断される。この例では、（例えばＤＨＣＰを通じて）ネットワークでアドレスを取得することは、（モバイルＩＰの外部エージェントを通じて）ローカルネットワークでアドレスを登録することとは相違している。ローミングエンティティは、アドレスを（再）取得（例えばＤＨＣＰサーバからのリースを確立／アップデートして）するか、あるいは現アドレスを外部エージェント（モバイルＩＰ）に登録する。
【０２１２】
・別のサブネットへのローミングを示唆する、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ローミング信号を、該ローミング制御センターのクライアント向けに生成する（ブロック２２３０）。
【０２１３】
ｃ）検索の結果対応が見つからなければ（ブロック２２００で「ノー」）、ネットワーク接続ポイントの識別子、媒体アクセスアドレス、ネットワークマスクや他の補助的な情報によってポピュレートされた、新規の記録を生成する（ブロック２２１０）。次に、ローミング制御センターはブロック２２２０および２２３０を、ネットワークアドレスを取得、登録し、「ローミング」信号を生成するために実行する。
【０２１４】
上記のインターフェイスによって補助されたローミング技術により、下層のインターフェイス情報へのアクセスができるようになり、自動的かつ効率的に別の有効なネットワークパスを選択することを可能にする、（ユーザおよび／またはシステムによって定義された）付加的なポリシーパラメータが採用できるようになる。一つ以上のネットワークが同時に使用可能な場合、サブシステムは、最も負担がかからないパス（ワイドエリア・ネットワークかローカル・エリア・ネットワークかという選択）を選ぶことができる。これは、帯域幅、（１バイトあたりの）コスト、および／またはサービス品質といった様々なメトリクスによって決定可能である。この「最低負担ルーティング」技術により、ネットワーク接続の品質、効率、フレーム損失の減少などの点で効果を得ることができる。例えば、他の利用可能なヒューリスティクス（媒体接続性、信号強度、再伝送率等）による、「メークビフォアブレーク（ｍａｋｅ ｂｅｆｏｒｅ ｂｒａｋｅ）」ハンドオフ構造が提供可能で、よってローミングノードからの／に向かう継続的なパケットフローの損失を最小化できる。下記のポリシー管理についての記述を参照のこと。
【０２１５】
図２０は、インターフェイス補助ローミングトポロジのノードのデータ構造を例示している。図２０のこのデータ構造は連結リストとして実施されているが、前後のフィールドを省略した配列として表現されることもある。無線ネットワーク・インフラにおいて、「ＮＰＯＡ」は、例えば、アクセスポイントのＭＡＣアドレスあるいはモバイルノードが結合している基地局でもよい。他のネットワークにおいては、「ＮＰＯＡ」は、介入的なネットワーク相互接続（ゲートウェイ、ＩＷＦ等）の固有の識別子であってもよい。データ構造には静的な情報が予め与えられていてもよいし、動的に情報が学習されてもよい。また、ノードそれぞれと、他の情報（例えばＭＴＵのサイズ、待ち時間、コスト、利用可能かどうかなど）とが結合していてもよい。
【０２１６】
（特定の競合状態を扱う他の実施例）
さらに行われた実験から、ネットワーク・アダプタの中には、ネットワーク・セグメントに完全登録される前に、媒体と（再）接続されていると誤って信号を出すものがあることが明らかとなった。例えば、ローミングの間、ネットワーク識別子を保持する記憶領域はまだ更新されず、従って、システムがこれらのネットワーク・アダプタが同じサブネットにロームバックしたと誤解することが考えられる。最終的には、デバイスが登録を終了すると、記憶領域は新しいネットワーク識別子と共に更新され、さらに別のローミング信号が生成される。両方の情報が一緒にゲートされ、インターフェイスがネットワークでの登録を終了した時に１度だけ信号が送られると、このシナリオ通りに進む。しかし、ポーリングの際、「ネットワークと接続中」を示す信号が以前に生成された場合に、ネットワークＩＤがいつ有効になるかを判定するのは困難である。
【０２１７】
基本的に、ローミング中のノードはネットワークと媒体アクセスレベルで通信できるため、事実上媒体と接続状態にあるが、登録プロセスが完了していないので、事実上、リンクを通じていずれのアプリケーションデータを送ることはまだできない。従って、この状態を補償するのが望ましい。このような補償を行う方法の一つとして、一般にはエコー要求／応答パケットとして知られているリンク確認フレームを送ることによってピア接続を判定する方法がある。これらのエコーやｐｉｎｇフレームは１つのピア（ローミング中のノードである可能性が高い）によって生成され、双方向のピア・トゥ・ピア接続が達成可能か判定する。要求を出しているピアがその要求に対する応答フレームを受け取る場合、二重通信が実現し終了する。この時点で、次に切断状態になるまでＮＰＯＡ情報が有効であると見なされる。また、該当インターフェイス上のピアからのフレーム受領等、他の情報によって、ローミング中のノードが登録プロセスが終了し、双方向通信が達成可能であることが想定可能となる。
【０２１８】
ネットワーク・インターフェイスと内在するプロトコルスタック状況間における別の競合状態は、問題を生じることがある。デバイスは、新しいネットワーク・セグメントに移動し、以下のインターフェイスから正確に信号が送られるようにすることは可能であるが、トランスポート・スタック自体はフローするアプリケーションデータのルーティング・テーブルに必要な調整を行わないことがある。この状態を補償するために、内在するトランスポートのルーティング・テーブルに変更が生じる度に、付加的信号であるＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＵＴＥ＿ＣＨＡＮＧＥが追加されて生成される。この信号が示されると、ローミング中のサブシステムクライアントはピア・システムとの接続が達成可能かどうか判定するために必要なアクションは何でも行う。これによりローミング中のクライアントは、ルーティング修正がピアへの通信経路に影響を及ぼしたかどうか判定するために、内在するトランスポートのルーティング・テーブルを介して列挙する必要がある。また、上記記載のアルゴリズム等のように、よりイントルーシブな他のアルゴリズムが、ピア間に双方向通信経路が存在することを確認するために行われてもよい。
【０２１９】
（非接続ネットワークを通じたローミング例）
本発明の非限定的な好ましい実施形態の他の一側面として、いわゆる「非接続ネットワーキング」（ｄｉｓｊｏｉｎｔ ｎｅｔｗｏｒｋｉｎｇ）モードでＭＭＳ（モビリティ管理サーバ）にアクセスするためのアルゴリズム及び構成がある。新しいアルゴリズムによって、あるネットワークからは別のネットワークにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、ＭＭＳとの通信を確立する／持続するのに使われる、代替のネットワークアドレスを動的／静的に見つけ出すことができるようになる。
【０２２０】
一般に、アルゴリズムによって、通信中にＭＥＳ（モバイル端末システム）に送るための、ＭＭＳが利用可能な代替アドレスのリストが可能となる。このように、ＭＭＳはＭＥＳに、一つ以上のＭＭＳネットワークアドレスもしくは他のネットワークに対応した他のＭＭＳのアイデンティティを、単一のネットワークによる通信によって送る。一例として、該リストは、回路構築の際に送付可能である。また、該リストは途中で変更可能である。この場合、該リストは接続が確立されている間のいかなる時にも更新が可能である。
【０２２１】
ＭＥＳが別のネットワークへと移動するとき、ＭＥＳは新規のネットワークの接続ポイントからＭＭＳとコンタクトをとるために、ＭＭＳの「エイリアス」（ａｌｉａｓ）アドレス／アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、又はその他の情報を共有していなくても、ＭＥＳは新規のネットワーク接続を通じてＭＭＳとのコンタクトを再確立することができる。
【０２２２】
この新しい技術を簡略化したフローチャートを図２１に示す。ＭＭＳ１０２は、２つの異なる非接続ネットワーク、すなわちネットワーク・セグメントＮ１及びＮ２と接続しているものとする。ＭＥＳ１０４は、最初にＭＭＳ１０２とネットワークＮ１を介して接続されるものとする。ネットワークＮ１を介してＭＥＳ１０４とＭＭＳ１０２との間で接続が確立されるとすぐに、ＭＭＳ１０２は、ＭＥＳ１０４に対して、ＭＭＳが一以上の他のネットワーク（例えば、ネットワークＮ２）から求められるネットワークアドレスのリストＬ又は他の識別子を送ることができる。ＭＥＳ１０４は、該リストＬを受け取り、記憶する。その後、ＭＥＳ１０４は別のネットワーク（Ｎ２）に移動する時、ＭＥＳ１０４はこの記憶されたリストＬにアクセスし、それを用いて新規のネットワーク（Ｎ２）を通じたＭＭＳ１０２との通信を効果的に再確立することが可能となる。
【０２２３】
この新しいアルゴリズムには、非接続ネットワークを通じて、ＭＭＳ１０２と通信するための代替ネットワークアドレス又は他の識別子をより効率的に取得することに加え、少なくともいくつかの用途がある。その用途の一例としてネットワークオペレーションがある。例えば、図２１に示すアルゴリズムを用いて、多くのネットワーク（いくつか、又は全てが無線ネットワーク）からの安全なファイアウォール／ゲートウェイ、及びコーポレートバックボーンとしてＭＭＳ１０２が使用される安全なネットワークをセットアップでき、モバイルノード１０４が安全に、接続を切断されることなく別々のネットワーク全てに移動することが可能となる。例えば、ＭＭＳ１０２がハブとして１つの太いパイプでコーポレートネットワーク、及び論理的に分離した多くのネットワークを接続する多数の小さなスポークと接続しているとする。ネットワークは論理的に分離しているため、ＭＭＳ１０２（この例ではルータとして動作可能）を介した場合を除いて、１つのネットワーク・セグメント上のトラフィックが別のネットワーク・セグメントに達することができない。
【０２２４】
普通、ネットワーク・セグメントからネットワーク・セグメントへ移動するノードにとって、ＭＭＳ１０２との接続に使用される「メインパブリックアドレス又は初期アドレス」への戻り方を示す、各ネットワーク・セグメントに設けられた情報／経路（つまり、デフォルトルート等）をルーティングが必要となる。
接続が確立されるとすぐに、そのアドレスが接続の存続のために用いられる。ＭＥＳ１０４からフレームが送られる時、クライアント及び及び中間ノード（ルータ）におけるＩＰネットワーク（層３）のインフラストラクチャは、フレームの目的地アドレスを見て、最終目的地（ＭＭＳ１０２）にパケットを正確に送る。このことは、一般にＩＰ送信（ＩＰ ｆｏｒｗａｒｄｉｎｇ）、あるいはＩＰルーティングと呼ばれるもので行われる。この機能がオンになると、あるネットワーク・セグメントのフレーム（ブロードキャスト等）が別のネットワーク・セグメントへ流れる。ＩＰ送信をしないと、あるセグメントに送られたフレームは他のセグメントへ送られることはないので、通信パイプが切断され、あるいは非接続ネットワークができてしまう。
【０２２５】
図２１に示す代替アドレスリストは、ルーティング情報のうちの幾つかをＭＥＳ１０４に送出する、又は配布する効果を有する。従って、各セグメントは、ＭＭＳ１０２とつながっている他のセグメントの情報はない状態で離散された状態となる。ＭＥＳ１０４はＭＭＳ１０２によって認証可能であるため、ＭＭＳは認証されたＭＥＳユニット１０４にのみリストＬを送る。ＭＥＳ１０４が別のネットワーク・セグメントへ移動する時、ＭＥＳ１０４は自動的に正しいアドレスを選択し、それを用いて途中ＭＭＳとの通信を開始／継続することができる。従って、非接続ネットワークの問題は解決され、ルーティング・インフラストラクチャの変更は必要なくなる。これにより、有効なユーザに対してのみネットワークへのアクセスを有効にすることによって、より安全なコンピュータ環境を提供することが可能となる。
【０２２６】
例えば、このようにユーザレベルのセキュリティ／暗号化と組み合わせてＭＭＳ１０２を用いることで、コーポレートバックボーンからのトラフィック、及びコーポレートバックボーンへのトラフィックを、上記のローミング技術を用いてそのセグメント上のノードを目的地としたフレームのみに限定することが可能である。フレームは選択的に暗号化でき、スポーク・ネットワーク・インフラストラクチャが有効にしたデバイスによって行われる可能性のある盗聴を阻止することができる。
【０２２７】
例を図２２に示す。図２２において、ＭＭＳ１０２は通信網やルート情報を共有しない４つの別々に分かれたネットワーク（Ｉａ、Ｉｂ、Ｉｃ、Ｉｄ）と接続されている。どの点から見ても各ネットワークＩは島となっている。コーポレートバックボーン上の有線通信を用いてネットワークの一つ（例えば、Ｉｃ）とドッキングしているＭＥＳ１０４を想定する。例えば、ＭＥＳ１０４は１９２．１６８．ｘ．ｘネットワーク上のアドレスを取得してＭＭＳ１０２と通信するものとする。
【０２２８】
ある理由によりＭＥＳが１０．１．ｘ．ｘ（Ｉａ）ネットワークに渡る、又は移動する必要があるものとする。１０．１．ｘ．ｘ（Ｉａ）ネットワークは１９２．１６８．ｘ．ｘ（Ｉｂ）ネットワークのことを知らない（つまり、（Ｉｂ）ネットワークへのルートがない）ため、ＭＥＳ１０４がその領域へ移動する時に、たとえＭＭＳが通信パイプに接続されていても通信パイプは切断される。また、モバイルノード１０４が図示される他の１０．ｘネットワークのいずれかと接続する場合においても同じことが起こる。
【０２２９】
図２１に示すアルゴリズムを用いて、接続開始時間の（あるいは他の方法で）ＭＭＳ１０２は各種非接続ネットワークＩａ、Ｉｂ、Ｉｃ、Ｉｄに関するそのインターフェイスアドレスをＭＥＳ１０４と共有し、ＭＥＳはこれらを記録する。一旦記録されると、ＭＥＳ１０４は上記ネットワークのいずれか一つに移動して新しいネットワーク・セグメントに移動したことを検出する場合、ＭＥＳは適切なネットワークアドレスを選択し、そのネットワーク・セグメントでＭＭＳと通信できる。２以上のアドレスが使用される場合、ＭＥＳ１０４は適切なアドレスを選択してスピード、コスト、有効性、ホップ等、多くのメトリクスに基づき使用する。図２１と同様のリストを受け取らなかったＭＥＳ１０４は、その「ホーム」ネットワーク以外のネットワークを通じてＭＭＳと接続することができないので、種々のネットワーク間の移動を事実上阻まれることになる。
【０２３０】
他に、図２１の技術は分散型ネットワーク・インターフェイスに用いられる。今日のネットワークにおいて、ネットワーク・アドレス・トランスレータ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒｓ；ＮＡＴｓ）として知られるものが開発されている。この従来の技術を利用すれば、一つの公開ネットワークアドレスを用いるだけで多くのネットワークデバイスはインターネット上の情報へのアクセスが可能となる。この技術は、単一もしくはわずかなデバイスを介してインターネットに向けられた情報やクエリを全て送ることによって上記の機能を可能とする。該デバイスはネットワーク層で要求を記録し、その後パケットのアドレスとポート情報をデバイスのアドレス／ポートのタプルに再度対応付けし、それをその目的地に送信する。インターネット、あるいは他の当該ネットワークからフレームを受け取ると同時に、デバイスはリバースルックし、そのアドレス／ポートのタプル情報を開始デバイスのものと取り替えて、フレームを送り返す。これらの対応付けはＮＡＴにおいても静的に定義される。
【０２３１】
誰かがＬＡＮ／ＷＬＡＮの内部でＭＭＳ１０２を使用するために、それをＮＡＴに置くことを想定する。現在、ＭＭＳ１０２がＮＡＴでない限り、あるいは異なるプロキシを用いてＭＭＳと通信を全て行うことによって、誰かがイントラネットの境界範囲外に移動する時、ＭＭＳと通信するアドレスがもはやアクセス可能ではないため、ＭＭＳとはアクセス可能ではない。図２１のアルゴリズムを用いれば、ＭＭＳと直接接続されていない別のインターフェイスアドレスを静的／動的に明確にすることができる。従って、上記のアルゴリズムを使用すれば、ＭＥＳ１０４は自動的に適切な非接続アドレスを選択し、イントラネットの領域外のネットワークと接続する時にそのアドレスを使用することができる。
【０２３２】
この概要を図２３に示す。ノードがインターフェイス“ｄ”からインターフェイス“ｇ”へ渡るとする。ＭＭＳ１０２にローカルインターフェイスを供給するだけではアクセスはできない。ＭＥＳ１０４は分散されたインターフェイスの優先順位を知る必要がある。それからＭＥＳ１０４は必要なアドレスを選択してインターフェイス“ｇ”上で使用する。その後、ＮＡＴ２０００は、各パケットに関するネットワークアドレス／ポート情報を、内部インターフェイス“ｃ”アドレスへ適切に変換する。ＭＭＳ１０２からＭＥＳ１０４に送られるフレームには逆の処理が行われる。
【０２３３】
（ポリシー管理及びロケーションベースのサービス例）
本発明の他の非限定的な実施形態として、多くのメトリクスに基づき付加的なセキュリティ、コスト削減、サービスを提供することが独自にできる手法を提供する。上記のＭＭＳはＭＥＳが確立する各アプリケーションのセッションと深く関わっているため、どちらの側（すなわち、ＭＭＳおよび／またはＭＥＳ）もポリシーベースのルールを適用してＭＥＳとその最終的なピアとの間の通信を適合して制御することができる。さらに、ＭＭＳおよび／またはＭＥＳはデバイスのロケール、又は近接性（ｐｒｏｘｉｍｉｔｙ）、並びにネットワークの接続に基づきアプリケーション要求を調整又は修正することができる。例えば、ＭＭＳおよび／またはＭＥＳは学習され静的に定義されて適用されたルールエンジン、あるいは確立する各アプリケーションセッション、又は試みる要求に対するポリシーに基づく他のルールを含むことができる。ＭＭＳはさらにＭＥＳにこのようなルールの幾つか、全くなし、あるいは一部、および／または処理を配分して、メータリング（ｍｅｔｅｒｉｎｇ）、又は傍受者によるモバイルデバイスへの侵入（ｒｏｇｕｅ ａｔｔａｃｋｓ）に対するセキュリティを提供する。分散型トポロジで利用可能な特定の他のポリシー管理技術とは違い、ＭＭＳが中心となり、ルールやポリシー決定を管理し、それらを通信中いかなる時にも遠隔地のデバイスに分散させる。
【０２３４】
ルール自体は、ユーザ、ユーザ・グループ、デバイス、デバイスグループ、プロセスアプリケーションアイデンティティ、および／またはネットワークの接続ポイントに基づき構成可能である。一旦定義されると（学習されると）、ルールは組み合わされて、例えば、以下のものを含む種々の異なる事象、活動、および／またはサービスを管理し、制御する。
【０２３５】
・遠隔地のデバイスへの侵入アクセスの拒否、許可、又は調整
・アイデンティティに基づく特定のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・利用可能、又は許可された帯域幅へのアクセスの拒否、許可、又は調整
・他のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・内容又は情報の修正、調整、又は変更
このような決定は例えば、以下の要素を含む種々の異なる要素に基づいて行われる。
【０２３６】
・モバイルデバイスについての近接性、場所、高度、および／または他の特性
・日時
・アプリケーション又はプロセスアイデンティティ、アドレス等
・アプリケーション動作（例えば、帯域幅条件）
・現在のネットワーク状態
・他の静的又は動的要素
さらに分散型アーキテクチャを利用することで、ＭＭＳは同じ決定セットを適用又は共有することができる。ポリシー管理処理および／または意思決定をＭＭＳに行わせるのは、例えばモバイル装置がエンジンを実行するのに限られた処理能力を持ったり、帯域幅の限度が適用されたり、あるいはセキュリティが目的の場合に望ましい。
【０２３７】
サンプルＭＥＳの制御に使用される可能性のあるメトリクス（ルール）の幾つかを示すテーブルの例を図２４に示す。このテーブルは静的又は動的のどちらかに内容を占めてもよいし、場合によっては通信前、通信中、又は通信後に更新されてもよい。例えば、ユーザはテーブルの項目を定義するルール・エディタ（例えば、ウィザード）や他のメカニズムを使用することができる。他の構成例において、メトリクスが学習に基づくシステムによって自動的に定義され、あるいは状態の変更に基づき動的に変更される。また、ルールにはそれぞれ優先順位が割り当てられ、テーブルの場所で暗示、または割り当てによって明確に指定される。この優先順位によってエンジンが期待動作を正確に決定することができる。付加的なユーザインターフェイスの機能によって、システム管理者やデバイスのユーザはルールエンジンに問い合わせて所定のルールセットの機能を試みることが可能となる。
【０２３８】
ポリシー管理決定の基になる、以下のメトリクスをはじめとする多数のメトリクス例を示すテーブル例を図２４に示す。
【０２３９】
・ＭＥＳの通信機能（送信のみ、受信のみ、送受信）
・ＭＥＳの要求がプロキシされるか否か
・ＭＥＳのソースポート
・ＭＥＳのソースアドレス
・ＭＥＳの目的地ポート
・ＭＥＳの目的地アドレス
・ＭＥＳのプロトコル
・利用可能な帯域幅量
・プロセス名、アイデンティティ又は他の特性
・ネットワーク名、アイデンティティ又は他の特性
・ロケーション（例えば、ＧＰＳ座標又は他のロケーション情報）
・ネットワークの接続ポイント
・ユーザの識別子、アイデンティティ又は他の特性
・他のメトリクス
上記テーブル例は完全なリストではなく、本発明は上記テーブル例のメトリクス項目の範囲に限定されるものではない。ネットワークアクセス及び権利付与に関してモバイルノードの所望の動作を示すために、該項目はこの例のように具体的であり、あるいは包括的なメカニズム（例えば、ワイルドカード）であることが可能である。
【０２４０】
図２４のテーブル例には、メトリクスに基づくポリシー管理決定の結果を示す「否定要求」項目がさらに含まれる。一例として、図２４のテーブルに示す特定の項目例は、利用可能な帯域幅が一秒間で１００，０００バイト以下に低減される場合、目的地ポート２０、２１との接続は否定され、減速されることを示す。さらに、示した特定の例において、ルール（列）３、４によってネットワークトラフィックのみがＭＭＳへ、又はＭＭＳから流れることが可能となる（プロキシが行われない他の全てのネットワークトラフィックは暗に破棄される。）。
【０２４１】
一例において、各ＲＰＣ要求又はフレームが処理される前に、ルールエンジンはオペレーションの状況を決定するよう求められる。このプロセスの結果に基づき、その要求が許可、否定、あるいは遅延される。ポリシー管理決定をするためにＭＭＳおよび／またはＭＥＳによって行われる処理のフローチャート例を図２５に示す。
【０２４２】
先に概略を説明したローミング技術と、利用可能な他のロケーション又はナビゲーション情報とを組み合わせることによって、ＭＭＳはモバイル端末システムがいつ１箇所の接続ポイントから別の接続ポイントへ移動したか検出する。ネットワーク・トポロジの環境の変化を検出するために、モバイル端末システムの機能と関連してこの情報を組み合わせることによって、ロケールによって本発明はロケーションベースの傍受及びサービスの付加的なレベルを提供することができる。
【０２４３】
この情報の可能性を十分実現させるために、インターネット・モビリティ・プロトコルとＰＲＣエンジンの両方の改良点について概要を説明する。新しいＲＰＣのプロトコル及び構成の改良点が追加され、この機能が可能となる。これらを以下に挙げる。
【０２４４】
（ロケーション変更ＲＰＣ（Ｌｏｃａｔｉｏｎ Ｃｈａｎｇｅ ＲＰＣ）の例）
モバイル端末システムが、インターフェイス支援型ローミング又はグローバル・ポジショニング・システムから変更を検出するといった他の方法を用いて新しい接続ポイントへ移動したことを判断した時、モバイル端末システムは、フォーマットされた「ロケーション変更ＲＰＣ要求（Ｌｏｃａｔｉｏｎ Ｃｈａｎｇｅ ＲＰＣ Ｒｅｑｕｅｓｔ）」メッセージをそのピア、この場合モビリティ管理サーバに送る。「ロケーション変更ＲＰＣ」は、一以上の接続ポイント識別情報をタイプ、長さ、値の形式にフォーマットする。タイプは識別情報の種類を示し、対応するタイプはＡＳＣＩＩの４８ビットＩＥＥＥ ＭＡＣ アドレス、ＩＰＶ４ アドレス、ＩＰＶ６ アドレス、経度、緯度、高度、接続機構名を含むが、これらに限定されない。長さは識別データのバイト長を示し、該データは実際の接続ポイント識別子を含む。「ロケーション変更ＲＰＣ要求」を受け取ると、モビリティ管理サーバは、接続ポイント識別子、並びにモビリティ端末システムの識別子、ユーザ名、ＰＩＤ等の他の関連情報を含む「ロケーション変更警告（Ｌｏｃａｔｉｏｎ Ｃｈａｎｇｅ Ａｌｅｒｔ）」を作成する。この警告は「ロケーション変更ＲＰＣ要求」内で使用された同じタイプ、長さ、データフォーマットでフォーマットされる。その後警告サブシステムが、警告のために登録された全てのアプリケーションにロケーション変更警告と共にこの情報を送る。警告のために登録されたアプリケーションは、現在の活動状況のモニタ、長期の動作ログ、ポリシー管理エンジン、第三者アプリケーション等の監視アプリケーション、並びにネットワーク管理ツールを含んでもよい。単一のそのような第三者アプリケーションは、このロケーション情報と、ウェブベースのマップとを組み合わせてモバイル端末システム又はＭＭＳの場所についての詳細情報を提供する。そのようなアプリケーションに加えて、他の動作をロケーション変更警告と関連付けることができる。これには、電子メールの送信、メッセージの印刷、プログラムの起動、および／またはポリシー変更が含まれる。
【０２４５】
ロケーション変更ＲＰＣはそのヘッダにロケーション変更、距離変更、又は速度変更によってトリガされたかどうかを示すフィールドを含む。
【０２４６】
ある例では、ＭＥＳは自身が移動したことを知らない場合がある。ＭＥＳが接続する媒体やネットワーク・アダプタに応じて、ＭＭＳはＭＥＳが新しい接続ポイントに渡ったことを知らせる唯一のエンティティであってもよい。モバイルルータの場合を考えてみる。ルータ以降のアドレスは同じままで、ルータのアドレスだけが変わる。この場合、ＭＭＳはＭＥＳのアドレスを新しく管理することを認識する。したがって、動作の検出を完了するためには、行動検出するためのＭＥＳとＭＭＳの両方の組み合わせの動作の検出が必要となる。本実施の形態では、ソースアドレスが変更され、新しいＩＭＰメッセージが受け取られる時に、ＭＭＳはＩＭＰ層でクライアントの行動を検出する。このことが行われると、ＭＭＳは局所的にロケーション変更警告を生成する。また、ＭＭＳは接続ポイントが変更したというメッセージをＭＥＳに送る。
【０２４７】
（トポロジＲＰＣの例）
「トポロジＲＰＣ要求（Ｔｏｐｏｌｏｇｙ ＲＰＣ Ｒｅｑｕｅｓｔ）」はモビリティ管理サーバからモバイル端末システムへ送られる。このＲＰＣの受け取りと同時に、モバイル端末システムはそのローカルデータ記憶装置に記憶されるトポロジ情報を読み出して、トポロジＲＰＣ応答（Ｔｏｐｏｌｏｇｙ ＲＰＣ Ｒｅｓｐｏｎｓｅ）を作成する。トポロジＲＰＣ応答は、前後との接続のタイプ、長さ情報が後に続く全長フィールド（Ｔｏｔａｌ Ｌｅｎｇｔｈ Ｆｉｅｌｄ）、タイプ、長さ情報が後に続く接続ポイント識別子、および、サブネットおよびネットワーク情報を示す値のデータによってフォーマットされる。この情報は、サーバで提供されるモバイルネットワークの完全なトポロジカル・マップを作成するのにサーバ上で使用されてもよい。
【０２４８】
（ロケーション情報ＵＩの例）
サーバ上のユーザインターフェイスは、ロケーション情報を対応付けして表示するための方法を提供する。このロケーション情報は、各アクティブなモバイル端末システムが利用でき、長期の動作ログは全てのアクティブなモバイル端末システム及び以前アクティブだったモバイル端末システムのロケーション変更履歴を保持する。ユーザインターフェイスによって、システム管理者は接続ポイント情報を人間が読める形式に構成できる。例えば、接続ポイント情報が４８ビットのＩＥＥＥ ＭＡＣアドレスの形式で与えられると、サーバ上のユーザインターフェイスを介して提供される情報と共にこのＭＡＣアドレスが表示される。接続ポイントが「ホールマークカード（ＨａｌｌＭａｒｋ Ｃａｒｄｓ）」店のアクセスポイントを示すと、次の情報「ホールマーク、住所、市、州、郵便番号」を提示するように設定される。この情報がユーザに対して表示されることによって、「ホールマーク、住所、市、州、郵便番号」情報が提供されることになる。
【０２４９】
（ロケーションＲＰＣタイマーの例）
設定可能なタイマーがモバイル端末システムに設けられており、ロケーション変更ＲＰＣがモバイル端末システムからモビリティ管理サーバに送信される速度を制限する。タイマー間隔が接続ポイントの変更が起こる速度よりも大きい場合、モバイル端末システムはタイマー間隔が終了するまで待ってから別のロケーション変更ＲＰＣを生成する。
【０２５０】
（距離変更通知の例）
距離メトリクスは、ロケーション変更ＲＰＣの生成をトリガするために設けられる。この設定によって、ユーザが前にいた元のポイントから、ｎフィート、ｎキロメータ毎、あるいは他の適当な測定単位で３次元的に移動する時に、更新を送信するようにシステムが構成される。デフォルトによってこの設定は無効になる。この設定を可能にすることによって、設定された距離間隔を上回った時に変更通知が出される。
【０２５１】
（速度閾値通知の例）
速度変更メトリクスは、ロケーション変更ＲＰＣの生成をトリガするために設けられる。このパラメータは、一時間当たりのマイル等、一秒当たりの距離で構成される。このパラメータは、上限及び下限、並びに到達した速度を持続する必要のある時間間隔（すなわち、１０分間で０ＭＰＨ、又は１分間で７０ＭＰＨ）を特定する。このスピードに達すると、ロケーション変更通知が生成される。
【０２５２】
［応用例］
本発明は、実社会の様々な場面で応用される。例を以下に示す。
【０２５３】
（断続的に接続される携帯用コンピュータ）
多くの企業では、在宅勤務や、自宅で仕事をする社員がいることがある。そういった社員は、多くの場合、ラップトップコンピュータを使用して仕事をする。作業中に、社員は一般に自分達のラップトップコンピュータをドッキングポート又は他のコネクタを使用してイーサネット（Ｅｔｈｅｒｎｅｔ）等のローカルエリア・ネットワーク（Ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）に接続する。ＬＡＮ接続によってネットワークサービス（例えば、プリンタ、ネットワークドライブ）やネットワーク・アプリケーション（例えば、データベースアクセス、電子データサービス）にアクセスが可能となる。
【０２５４】
あるプロジェクトに取り組む社員が、晩に帰宅する必要があり、自宅で仕事を続行したいとする。この社員は、ラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「サスペンド」して、ラップトップコンピュータを片付け、そのラップトップコンピュータを自宅に持って帰ることができる。
【０２５５】
自宅に戻るとすぐに、その社員はラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「レジューム」して、ダイアルアップ接続を介して、および／またはインターネットを通じてオフィスＬＡＮと再接続する。（ラップトップコンピュータが一時的に中断された間、ネットワークに対するラップトップコンピュータとそのアプリケーションのプロキシを継続した）モビリティ管理サーバは、ラップトップコンピュータを再認証し、ラップトップコンピュータとの通信を再開する。
【０２５６】
自宅で仕事をしている社員の立場から見ると、ネットワーク・ドライブ・マッピング、印刷サービス、電子メールセッション、データベースクエリ、他のネットワークサービスやアプリケーションは全て会社で終わった状態そのままである。さらに、モビリティ管理サーバはラップトップコンピュータのセッションのプロキシを継続したため、社員の会社から自宅までの帰宅途中に、いずれのネットワーク・アプリケーションもラップトップコンピュータのセッションを終了しなかった。このように、本発明は、上記のような状況や他の状況において、高性能且つ有用な同一又は複数のネットワーク媒体を通じて効果的にセッションを持続可能とする。
【０２５７】
（モバイル在庫管理及び倉庫への応用）
大きな倉庫又は小売店チェーンを想定する。この構内において、在庫管理を行う従業員がパーソナルラップトップコンピュータ、並びにハンドヘルドデータ収集ユニットや端末装置などを搭載した乗物（すなわち、トラックやフォークリフト）を使って商品の在庫管理が行われる。
【０２５８】
倉庫や小売店の従業員は、ネットワークサブネットのわからない、管理監督の必要な不慣れなコンピュータユーザであることが多い。本発明によって倉庫ユーザがモバイルネットワークの複雑さを感じない、即使用可能なシステムの構築が可能となる。倉庫ユーザは、アクセスポイントの範囲内及び範囲外を動いたり、自分たちのモバイル端末システム１０４の中断及び再開をしたり、ホストセッション、ネットワークアドレス、又はトランスポート接続を気にせずに、位置を変えたりできる。さらに、モビリティ管理サーバ１０２の管理ソフトウェアは、従業員の生産能力を測るのに利用される処理数等のメトリクスを管理関係者に提供する。また、管理によりネットワークサブネット及びアクセスポイントを使用して従業員が最後にいたとされる物理的な位置を判定できる。
【０２５９】
（モバイル医療への応用）
無線ＬＡＮ技術を利用して幾つかの建物間でネットワーク通信を行う大きな病院を想定する。各建物は独自のサブネット上にある。本発明によって看護士や医師がハンドヘルドパーソナルコンピュータや端末を持って病室から病室を動き、病院のデータベースから患者情報の読出しや書込みが可能となる。ローカルデータベースやワールド・ワイド・ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）を通じて、薬物治療や医療処置に関する最新記事へのアクセスが即座に可能となる。本発明はモバイル端末システム１０４への連続的な接続が可能なので、病院にいる間（一方向又は双方向の）ポケットベルはもはや必要なくなる。メッセージはモバイル端末システム１０４を介して医療関係者に直接送られる。倉庫の従業員の場合と同様、医療関係者は自分たちが利用しているモバイルネットワークについてわかる必要はない。さらに、モバイル端末システム１０４によって医療関係者は無線送信が望ましくないとされるエリア内（例えば、電波の放射によって医療機器に障害が出る可能性のある場所）での無線伝送ができなくなるが、中断したところから容易に再開して再接続可能となる。
【０２６０】
（トラック輸送及び貨物輸送）
運送会社は、貨物の状況を把握するのに本発明を用いる。倉庫に入っている間は、モバイル端末システム１０４はＬＡＮ技術を使用して倉庫内の貨物数を更新する。ローカルサービスから離れている間は、モバイル端末システム１０４はＣＤＰＤやＡＲＤＩＳ等のＷｉｄｅ Ａｒｅａ ＷＡＮサービスを使用してリアルタイムで貨物の状況や位置を維持できる。モバイル端末システム１０４はネットワーク・インフラストラクチャ間を自動的に切り替えるので、輸送関係者にネットワーク・トポロジの複雑さを感じさせない。
モバイル企業
企業の社員は、８０２．１１．等のインフラストラクチャが設けられた企業構内にいる間、本発明によるシステムを使用して、電子メール、ウェブコンテント、メッセージサービスへのアクセスを行う。ポケットベルサービスや他のモバイル機器のサービスはもはや必要ないので、これらを維持するためのコストが削減される。既存のモバイル機器サービスの多くが提供する、コストのかかる「利用回数制（ｐａｙ−ｐｅｒ−ｕｓｅ）」モデルに対し、モバイルインフラストラクチャは一度の資金支出で購入できる。
【０２６１】
（ＩＰマルチプリケーション）
ある組織がインターネットに接続する必要のあるＬＡＮを有する場合、ＬＡＮの管理者には二つの選択肢がある。一つ目の選択は、ＬＡＮ上の全てのコンピュータに対して割り当てるためのグローバルアドレスを取得することであり、二つ目の選択は、グローバルアドレスをいくつか取得して、アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ１０２を使用することである。多数のＩＰアドレスを取得することは、高額であるか不可能であるかである場合が多い。インターネット・サービス・プロバイダ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｉｖｉｄｅｒ； ＩＳＰ）を利用してインターネットにアクセスする小規模の企業は、ＩＳＰが割り当てるＩＰアドレスだけを使用することになる。ＩＰアドレスの数は同時にインターネットに接続できるコンピュータの数を制限する。また、ＩＳＰは一回の接続につき課金するため、インターネット接続が必要なコンピュータが増えれば増えるほど、この方法はそれだけ費用がかかる。
【０２６２】
アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ１０２を用いれば、これらの問題の多くを解決することができる。企業は、ＩＳＰを介してインターネットに接続するためのハードウェアとしてモビリティ管理サーバ１０２を用いることができる。これにより、モバイル端末システム１０４は容易に接続することができる。インターネットへの接続は全てモビリティ管理サーバ１０２を通じて行われるため、一つのアドレスだけをＩＳＰから取得すればよい。このように、アドレス・マルチプライヤとして本発明を用いることによって、企業はわずかな数（多くの場合一つ）のアドレスとアカウントをＩＳＰから取得すればよくなり、全体のＬＡＮでインターネットへの同時接続（十分な帯域幅が備えられていることを前提として）が可能になる。
【０２６３】
以上現在最も実用的且つ好適な実施形態とされる例と共に本発明を説明したが、本発明は開示した実施形態に限定されず、添付クレームの範囲内で種々に変形、同等に構成できるものとする。
【図面の簡単な説明】
【図１】
本発明のモバイル・コンピューティング・ネットワークの全体図である。
【図２】
モバイル端末システムとモビリティ管理サーバとのソフトウェア・アーキテクチャを例示するものである。
【図２Ａ】
モバイル端末システムとモビリティ管理サーバとの間で情報伝達を実行するステップを例示している。
【図３】
モバイル・インターセプタ・アーキテクチャを例示している。
【図３Ａ】
モバイル・インターセプタによって実行されるステップを例示したフローチャートである。
【図３Ｂ】
ＲＰＣ作業要求を扱うＲＰＣエンジン（ＲＰＣ ｅｎｇｉｎｅ）によって実行されるステップを例示したフローチャートである。
【図４】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ａ】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ｂ】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ｃ】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図６】
受信された作業要求を例示している。
【図７】
受信された作業要求が、どのようにそれぞれ別の優先度のキューにディスパッチされるかを示すものである。
【図８】
上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図９】
上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図１０Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１０Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１０Ｃ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１１】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ｃ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ｃ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１４Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１４Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１５Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１５Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１６】
リスナのデータ構造を例示している。
【図１７】
モバイル相互接続ローミング（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ ｒｏａｍｉｎｇ）を提供するためのステップを例示している。
【図１７Ａ】
モバイル相互接続ローミング（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ ｒｏａｍｉｎｇ）を提供するためのステップを例示している。
【図１８】
モバイル相互接続ローミング（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ ｒｏａｍｉｎｇ）を提供するためのステップを例示している。
【図１９Ａ】
インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図１９Ｂ】
インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図２０】
インターフェイスによって補助されているローミングのトポロジ・ノード・データ構造を例示する。
【図２１】
モビリティ管理システムのネットワークアドレスを、非接続ネットワーク・トポロジにおいてモバイル端末システムに配布する技術を例示している。
【図２２】
図２１の技術を、セキュアな通信を実現するために利用した例を示している。
【図２３】
図２１の技術を、分散型ネットワーク・インターフェイス・シナリオにおけるネットワークアドレスの変換に用いた例を示している。
【図２４】
ポリシー管理テーブルを例示している。
【図２５】
ポリシー管理処理のステップを例示したフローチャートである。
本発明は、ネットワークによって接続されたコンピュータ装置間の接続性に関する。より詳細には、ノマディック（ｎｏｍａｄｉｃ）システムの特性を透過性（トランスペアレント）を有する状態で扱うとともに、既存のネットワーク・アプリケーションを、対応するモバイル環境で確実に動作させる方法とシステムに関する。さらに詳細には、断続的に接続される、携帯型データ端末（ｈａｎｄｈｅｌｄ ｄａｔａ ｕｎｉｔｓ）やパソコン装置などの装置間における、連続的なデータストリームのやり取りを可能にする技術およびシステムに関する。
【０００１】
［発明の背景および要約］
近年、各企業は、重要な情報への迅速なアクセスこそが競争優位を保つための方策であると認識するようになってきた。このことから、特に安価なラップトップやハンドヘルドのコンピュータ装置の普及とも相まって、モバイルなどの断続的な接続が行われるコンピュータ装置が急速に企業ネットワークの重要な一要素となりつつある。しかしながら、こうしたノマディックな装置を既存のネットワーク・インフラへと統合することは、各企業の情報管理担当者にとって頭の痛い問題ともなっている。
【０００２】
モバイルネットワーキングに関する問題の多くは、イーサネット（登録商標）登場以前にローカルエリア・ネットワーク（ＬＡＮ）構築に伴っていた問題に近い。即ち、モバイル・プロトコルやインターフェイスには多くの種類があり、また、まだ規格が制定段階にあることから、異なるシステム間の相互運用性は無いも同然である。さらに、上記のようなネットワーク技術による通信はたいてい低速で帯域幅も限られており、各システムの特殊性から、アップデートに伴う費用も高額になっている。
【０００３】
こうした問題に加えて、モバイル技術は、以下のような固有の問題も有している。即ち、メインのネットワークと相互接続するの際には公共のネットワーク・インフラを経由する場合があるが、この際に機密情報が傍受されてしまう危険性がある。さらに、無線装置を経由して相互接続する場合であれば、機密情報がいわば「放送」されてしまうことになり、類似のインターフェイスを所有する誰もが該情報をたいした障害もなく傍受することができてしまう。
【０００４】
しかし、おそらく上記のような問題よりもさらに重要な問題としては、従来、モバイルネットワーキングが使われるのは基本的にメッセージ指向あるいはステートレスなアプリケーションに限られていて、クライアント／サーバ、ホスト／ターミナル方式をとるウェブベースあるいはファイル共有型のシステムモデルを利用した、既存あるいは新規の業務用アプリケーションには適さなかったことである。これは、一般的な業務用アプリケーションが効果的かつ確実に動作するためには、ステートレスなパケット交換だけでなく、連続的なデータストリームを用いたステートフルなセッションが必要であるという理由からであった。
【０００５】
このため、主要な市販のネットワーク・アプリケーションのほとんどは、ＴＣＰ／ＩＰセッションか、専用の仮想回路を必要としている。このようなセッションは、ネットワークが中断された場合はそれ以上機能できず、また接続時には、ネットワーク間のローミング（ネットワークアドレスの変更）が不可能である。さらに、モバイルネットワーキングは本質的に動的であり信頼性が低い。これらの問題について、以下では、モバイルネットワークにおいてよく見られる状況をいくつか考察することにする。
【０００６】
（非接続あるいは圏外のユーザ）
モバイル装置が所与のネットワークから切断されるかあるいはネットワークとのコンタクトを失う（つまり、無線相互接続の圏外に出たりネットワークがカバーしていない「穴」に入ったりする）と、携帯装置上で動作しているセッション指向のアプリケーションはピアとのステートフルな接続を失い、動作を停止する。装置が再び取り付けられるかあるいは装置とネットワークとのコンタクトが回復すると、ユーザはネットワークとの再接続を行い、セキュリティ確保のために再ログインを実行して、アプリケーションにおいてどこで作業が中断されたかを同定し、必要ならば失われたデータの再入力を行わなければならない。このような再接続処理は時間を要し、費用もかかり、またユーザを非常に苛立たせることにもなる。
【０００７】
（他のネットワークへの、あるいはルータ境界を越える移動（ネットワークアドレス変更））
モバイルネットワークは通常、管理容易性の見地からセグメント化されているが、一方でモバイル装置はその用途上、ローミングが可能になっている。相互接続されたネットワーク間のローミングとは、ネットワークアドレスが変更されるということを意味する。ネットワークアドレスがシステムの動作中に変更される場合、対応しているピア同士の接続を保つためにルーティング情報を変更することが必要になる。さらに、新しいネットワークアドレスを取得するために、それまでに確立されたステートフルなアプリケーションのセッション全てを終了させなければならない場合もあり、上記の再接続処理に関わる問題がここでも浮上する。
【０００８】
（セキュリティ）
既に述べたように、各企業は機密情報を守る必要がある。市販のアプリケーションの多くは、物理的ネットワークへのアクセスがコントロールされ（つまり、安全な施設の内部に構築されたケーブルを使って実行され）、セキュリティは、認証や場合によっては暗号化に関する付加的な層を通じて保持されることを前提として作成されている。しかしながら、ノマディック・コンピューティングではこうした前提は自明のものではない。というのも、公共の電波や有線インフラを通過する際にデータが傍受されてしまう危険性があるからである。
【０００９】
このため、ノマディックなシステムの特性を透過性を有するものとすることによって、既存のネットワーク・アプリケーションが種々のモバイル環境で確実に動作することを可能にした、統合的なソリューションの登場が大いに望まれる。
【００１０】
本発明は、上記の問題を解決するために、企業内ネットワークを延長して、ネットワーク管理者がモバイル装置のユーザも固定装置のユーザと同じアプリケーションに容易にアクセスできるようにすることを可能にすると同時に、信頼性やネットワーク管理の一元性も失わない、一貫したソリューションを提示する。該ソリューションは、これまでの有線ネットワーク規格の長所を、発展しつつあるモバイルネットワーキングに関する規格にも持たせることで、既存のネットワーク・アプリケーションにも対応したものとなっている。
【００１１】
本発明の非限定的で例示的具体的な実施の形態の一側面においては、モバイル相互接続（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ）に接続されたモビリティ管理サーバ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ； ＭＭＳ）は、数量を限定されないモバイル端末システム（Ｍｏｂｉｌｅ Ｅｎｄ Ｓｙｓｔｅｍｓ； ＭＥＳ）それぞれの状態の維持や、ネットワークへおよびピアにおけるアプリケーション処理への持続的な接続の維持に必要な、複雑なセッションの管理を行う。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは（あるモバイル相互接続から別の相互接続へとローミングすることなどで）ネットワークアドレスを変更したりした場合でも、モビリティ管理サーバは該システムと、該システムと対応しているピアとの接続を維持する。言い換えれば、該モバイル端末システムは、実際には物理的な接続が一時中断されてしまうにも関わらず、ピアとの仮想的な接続を維持し続けることになる。
【００１２】
また、上記本発明の非限定的で具体的な実施の形態は、以下の（これらに限定されないが）新規かつ有用な技術、構成を提示する。
【００１３】
・ユーザによって設定可能なセッション特性をモバイル・クライアントに付与するモビリティ管理サーバ。
【００１４】
・ネットワーク・リソースの消費に関し、ユーザごとにモバイル装置のポリシーを管理。
【００１５】
・工業規格である動的ホスト構成プロトコル（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ； ＤＨＣＰ）をモビリティ管理サーバと連携させて用いるローミング方法。
【００１６】
・ユーザによって設定可能なタイムアウト条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
【００１７】
・ユーザによって設定可能な再試行条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
【００１８】
より詳細には、上記本発明の好ましい具体的な実施形態の一例において、モバイル相互接続ネットワークに接続されたモビリティ管理サーバが備えられている。該モビリティ管理サーバは、数量を限定されないモバイル端末システムそれぞれの状態を維持し、ネットワークへおよび他の処理（例えば他のネットワークベースのピア・システムにて実行される処理）への持続的な接続の維持に必要な、複合的なセッションを管理する。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは（あるモバイル相互接続から別の相互接続へとローミングすることなどで）ネットワークアドレスを変更したりした場合、モビリティ管理サーバはデータの受信と待機要求を認識して、該システムと、該システムと対応しているピアとの接続を維持する。このようにモビリティ管理サーバがプロキシとして働くことにより、モバイル端末システム上で動作するアプリケーションは、あるネットワーク媒体との物理的な接続が一時的に中断された場合でも、持続的な接続を維持することができる。
【００１９】
また、上記本発明の好ましい実施の形態の他の一例において、モビリティ管理サーバはモバイル端末システム用のアドレスを管理する。モバイル端末システムには、それぞれにプライマリネットワーク上のプロキシ・アドレスが割り当てられている。この非常に汎用性の高いアドレスはモバイル端末システムの「仮想アドレス」と呼ばれる。モビリティ管理サーバはこの仮想アドレスを、ノマディック・システムにおける現在の「位置」アドレスと対応付ける。モバイル端末システムの位置アドレスは、該システムがネットワーク間を移動する際に変更されるが、仮想アドレスの方は、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【００２０】
上記本発明の好ましい実施形態のさらに他の一例において、モビリティ管理サーバは、コンソール（制御）アプリケーションと包括的なメトリクスとによってモバイル端末システムの集中的な管理を実現する。さらに、好ましい実施形態では、ユーザによって設定可能なセッション特性を、プロキシ・サーバ上で実行されるモバイル・クライアントについて実現し、ネットワーク・リソースの消費に関し、ユーザごとにモバイル装置のポリシー設定を管理する。
【００２１】
さらに、上記一側面においては、遠隔プロシージャ・コール（ＲＰＣ）・プロトコル（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ ｐｒｏｔｏｃｏｌ）およびインターネット・モビリティ・プロトコル（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ Ｐｒｏｔｏｃｏｌ）が、プロキシ・サーバと各モバイル端末システムとの間の通信の確立に使用されている。
【００２２】
遠隔プロシージャ・コールによって、ローカルなシステムから、遠隔のシステムにおけるプロシージャを呼び出す処理が可能になり、ＲＰＣプロトコルを使用することで、モバイル端末システムが接続を切ったり、圏外に行ったり、動作をサスペンドしたりということを、アクティブなネットワークセッションを中断することなくできるようになる。このように、セッションの維持は専用のアプリケーションによってなされるわけではないので、市販のアプリケーションを、何ら変更することなくノマディックな環境下で使用することができるようになる。
【００２３】
ＲＰＣプロトコルは、トランザクションを、標準的なネットワークトランスポート・プロトコルおよびインフラを経由して送られるメッセージに生成する。このＲＰＣメッセージは、モバイル端末システムにおいて実行されているアプリケーションによって開始されたネットワーク・トランザクション全体を含んでおり、これにより、モビリティ管理サーバとモバイル端末システムとの間の接続状態情報を、両者の間の物理的な接続が途切れているときをも含め、常にシンクロさせておくことが可能になる。ＲＰＣを備える上記本発明の実施の形態において、プロキシ・サーバとモバイル端末システムとは、全ての時間における全ての共有接続に関する統一された論理データベースを管理すべく、各トランザクションの状態について十分な情報を共有している。
【００２４】
上記本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルは、有線のローカルエリア・ネットワークと、それよりも信頼性の低い、無線ＬＡＮおよびＷＡＮといったネットワークとの間の相違を補償する。フレームサイズとプロトコルタイミングとが調整されることで、モバイル環境を考慮していない通信に比べるとパフォーマンスが大幅に改善され、ネットワークのトラフィックは大きく減少する。これは、帯域幅が限られているときやバッテリーの寿命を考慮に入れなければならないときに、特に重要になる。さらに、上記本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルによって、公共のネットワークもしくは無線を通じて、モバイル端末システム―モビリティ管理サーバ間で伝送が行われる際の、機密データの安全性が確保される。インターネット・モビリティ・プロトコルは、認証された装置からのみプライベートなネットワークにアクセスできるようにすることで、基本的なファイアウォールとしての機能も果たす。また、インターネット・モビリティ・プロトコルにより、モバイル端末システム―モビリティ管理サーバ間の全ての通信を認証、暗号化することも可能である。
【００２５】
上記本発明の好ましい実施形態のさらに他の一例において、モバイル相互接続は、標準的なネットワーク・アプリケーションのインターフェイスが適用できる範囲を広げるべく、標準的なトランスポート・プロトコル（例としてＴＣＰ／ＩＰ、ＵＤＰ／ＩＰ、ＤＨＣＰなど）を使用して構築される。上記本発明の好ましい実施形態によって、データ転送、セキュリティ、アドレス管理、装置管理、ユーザ管理が効果的に統合され、ノマディック環境を効果的に透過性を有する状態とすることができる。インターネット・モビリティ・プロトコルは、複数のデータストリーム（信頼度の高いものも低いものも）を、標準的なネットワーク・インフラ上で標準的なトランスポート・プロトコルによって与えられる、単一の仮想チャネルを通じて多重化するための効果的な方法を提供する。
【００２６】
ＲＰＣ層を用いて、インターネット・モビリティ・プロトコルは、違うソースから供給され、違うまたは同じ目的地へと向かうデータを融合させて単一のデータストリームとし、これをモバイルリンクを介して送る。該モバイルリンクの反対側の端において、該データストリームは逆多重化されて複数の異なったデータストリームとなり、それぞれの最終的な目的地に伝送される。この多重化／逆多重化により、利用可能な帯域幅を（最大限のサイズのネットワークフレームを生成することで）最大限に使うことができ、複数のチャネルを確立することができる（よって、優先順位付けが可能になり、基礎をなしているネットワークがデータ通信サービスを供給している場合であれば、その品質を保証することができる可能性もある）。
【００２７】
上記本発明の実施の形態に関するインターネット・モビリティ・プロトコルは、さらに以下のような特徴や利点を実現する。なお、本発明は以下の点に限定されるものではない。
【００２８】
・トランスポート・プロトコルの独立性
・ネットワーク上における位置（ｐｏｉｎｔ ｏｆ ｐｒｅｓｅｎｃｅ； ＰＯＰ）あるいはネットワーク・インフラを、データの流れに影響を与えることなく変更可能（物理的境界、ポリシー、あるいは帯域幅による制約が無い場合のみ）
・付加的な経費が最小限
・伝送媒体に適した自動的なフラグメントのサイズ変更（あるフレームのプロトコル・データ・ユニットがネットワーク媒体の利用可能な上限の伝送ユニットよりも多いとき、インターネット・モビリティ・プロトコルは該フレームをフラグメント化し、再構築する。このことにより、該フレームのネットワーク伝送を保障することが可能となる。再伝送の際、該フレームは再度検査される。ネットワーク・インフラもしくは環境が変化していた場合、該フレームは再度フラグメント化されるか、あるいは伝送ユニットの上限が実際に上昇しているときには単一のフレームとして伝送される。）
・再伝送の際に、フレームに信頼性の低いデータを破棄させることで、信頼性の低いデータのセマンティクスを保持
・信頼性の高いデータグラムサービスにおける新しいセマンティクスを提供（これにより、インターネット・モビリティ・プロトコルによるピアの端末へのデータグラムの伝達が保証され、要求しているエンティティに伝達の通知がなされる）
・上りと下りの伝送パスをそれぞれ別に扱って、自動的に操作パラメータを調整し最適なスループットを実現（ヒステリシスに基づいて、フレームサイズ／フラグメント化の閾値、待機中のフレーム数（ウィンドウ）、再伝送時間、およびネットワークを通じて送られる複製データの量を減少させるための遅延承認時間などのパラメータを調整）。
【００２９】
・ネットワーク障害に対する耐性（モバイル環境での使用が想定されているため、一時的にネットワーク媒体間の接続が切断されても、仮想チャネルが切断されたりアプリケーションベースの接続が切断されたりしてしまうことがない）
・操作パラメータを調整するための帯域内信号方式をピアに対して提供（接続された端末のそれぞれから、そのピアに対してネットワーク・トポロジや環境の変化に関する警告を出すことが可能）
・輻輳回避アルゴリズムを採用し、必要なときにはスループットを効果的に減衰
・選択的な確認応答と高速での再伝送とによって無駄な再伝送の回数を制限し、ノマディック環境におけるハンドオフ回復のスピードアップを実現（これにより、プロトコルはロスの多いネットワーク環境においても最適なスループットを維持）
・複数のフレームを待機状態にする、スライディング・ウィンドウ技術を採用（このパラメータは各方向に調整可能で、ピアからの確認応答を要することなくフレームを所定の上限までストリーミングするために与えられる）
・シーケンス番号が非バイト指向であることにより、単一のシーケンス番号で最大のペイロード・サイズまでを表現可能
・セキュリティ対策（インターネット・モビリティ・プロトコル層に認証層と暗号化層を追加可能）
・圧縮によって、帯域幅の限られた接続における効率性を確保
・どちらのピアも新たな位置に移動することが可能な平衡型設計
・どちらの側からでもピアへの接続が確立可能
・休止している接続を迅速に破棄して消費されていたリソースを回復する、休止タイムアウトを発動可能
・接続に対して任意の最大持続時間を設定可能（例えば、所定の期間経過後あるいは所定の日時の後に、接続の終了および／または拒否が可能）。
【００３０】
本発明の好ましい具体的な実施形態においては、システム管理者によるネットワーク・リソースの消費の管理が可能である。例えば、システム管理者は、モバイル端末システム、モビリティ管理サーバの少なくとも一方をコントロールすることができる。この場合のコントロールとは、例えばネットワーク帯域幅や他のリソースの配分の管理や、セキュリティ関連の事項を指す。管理はクライアント側で多数のリソースを持っているクライアントについて実行するのが効果的である。しかしながら、リソースを多く持たないシン・クライアントにポリシー管理のための付加的なコードや処理を負わせるのは望ましくない。よって、シン・クライアントの管理についてはモビリティ管理サーバ等によって集中的に行う、あるいはその一部を分担するのが最も現実的な解決策であると考えられる。モビリティ管理サーバがモバイル端末システムの各データストリームをプロキシすることによって、ポリシー管理が集中的に行われる。さらに、モビリティ管理サーバがユーザごとにプロキシを行うので、ユーザごと、装置ごとに、ネットワーク・リソースへのアクセスを管理し制限することができる。
【００３１】
簡単な例を挙げると、モビリティ管理サーバは、特定のユーザによるあるネットワーク・リソースへのアクセスを「締め出す」（ｌｏｃｋ ｏｕｔ）ことができる。この点は、インターフェイスのネットワークが、モバイル相互接続によって組織の管理下にある施設の境界よりも外に「延長」（ｅｘｔｅｎｄ）されてしまっていることを考えると非常に重要である（例えば、以前勤めていた職場のネットワークに、元従業員が外部からアクセスを試みるといった場合を考えよ）。これにとどまらず、モビリティ管理サーバによるポリシー管理はさらに多くの利点を提供しうる。例えば、モビリティ管理サーバによって、あるＵＲＬに特定のユーザのみがアクセスできるようにしたり、ネットワークサービスによる要求によって戻されるデータをフィルタリングしたり、ネットワークの帯域幅保全のためにデータを圧縮したりということが可能になるといった点である。このように、既存もしくは新規のアプリケーションレベルのサービスを、シームレスかつ透過的な形で強化することができる。
【００３２】
また、モバイル端末システムは「信頼性の低い」（ｕｎｔｒｕｓｔｅｄ）ネットワーク（つまり組織の管理が及ぶ範囲外のネットワーク）とも接続されるため、リモート接続中に悪質なサイバー攻撃に遭う可能性がある。モバイル端末システムとの間でポリシーやフィルタを共有することで、悪質な接続からのモバイル端末システムの保全、リモート・ノードにおける進入（ｉｎｇｒｅｓｓ）フィルタリング、そして企業インフラの集中管理のさらなるセキュリティ向上が可能になる。
【００３３】
本発明の実施形態の他の一例では、インターフェイスによって補助されたローミングのリスナ（ｌｉｓｔｅｎｅｒ）によって、モバイル端末システムが一般的な信号伝達をサポートしたインターフェイスを利用し、インターフェイスによって補助されたローミングを行うことが可能になる。本発明の上記実施形態の一例の一側面において、モバイル端末システムの、インターフェイスベースのリスナは、所定の事象（例えばコールバックや、タイマーによるタイムアウト、データの損失を示唆するネットワーク活動など）に際して、モバイル端末システムの媒体の接続状態が変化したか否かを判定する。これは例えば、リスナが、モバイル端末システムが切り離されてネットワークと通信できる状態でなくなったことを検知して、インターフェイスにこれを示唆するといったことを意味する。再接続の際、リスナは予め記録された接続識別情報（ａｔｔａｃｈｍｅｎｔ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）におけるネットワークポイントを参照して、モバイル端末システムが同じネットワークポイントに再接続されたか否かを判定する。再接続が同じネットワークポイントになされていた場合、リスナはモバイル・クライアントに、トランスポート・レベルでの通信の再確立を進めることを警告する。再接続が別のネットワークポイントになされていた場合、リスナはモバイル端末システムが「ローミング」（ｒｏａｍ）状態であることを示し、現状におけるネットワーク・セグメントで使用可能なアドレスをシステムに取得させるようにする（これは例えば、現行のアドレスを新規のサブネットにおいて有効であるように登録することを含んでもよい）。リスナは（操作を介して学習した）ネットワーク・トポロジのマップを保持して、そのクライアントに対して生成される信号（「同一サブネット上のローミング」、「ローミング」等）の適否を判定する一助としてもよい。
【００３４】
上記本発明の非限定的な好ましい具体的実施形態の他の一例においては、モビリティ管理サーバ（ＭＭＳ）に「非接続ネットワーキング」（ｄｉｓｊｏｉｎｔ ｎｅｔｗｏｒｋｉｎｇ）モードでアクセスすることが可能である。この新しいアルゴリズムによって、あるネットワーク・インフラからは別のネットワーク・インフラにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、ＭＭＳとの通信を確立する／持続するのに使われる、代替のネットワークアドレスを動的／静的に見つけ出すことができるようになる。この構成により、ＭＭＳが利用可能な代替アドレスのリストが予め設定され、通信中にＭＥＳ（モバイル端末システム）に送られるかあるいはＭＥＳによって動的に学習される。実施の一形態において、ＭＭＳはＭＥＳに、一つ以上のＭＭＳネットワークアドレスもしくは他のネットワークに対応した他のＭＭＳのアイデンティティを、単一のネットワークによる通信によって送ることができる。該リストは、回路構築の際やその他接続が確立されている間のいかなる時にも、送付／更新が可能である。
【００３５】
ＭＥＳが別のネットワークへと移動するとき、ＭＥＳは該ネットワークにおける新規のネットワーク接続を通じてＭＭＳとコンタクトをとるために、ＭＭＳの「エイリアス」（ａｌｉａｓ）アドレス／アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、ルートその他の情報を共有していなくても、ＭＥＳは新規のネットワーク接続を通じてＭＭＳとのコンタクトを再確立することができる。
【００３６】
上記本発明の実施の形態のさらに他の例において、ポリシー管理に関する意思決定は分散型モバイルネットワークトポロジの内部にて行われ、例えば、ルールベースのポリシー管理プロシージャが、様々なメトリクスに基づいて要求の遂行を許可、拒絶、または制限する。このような管理形態は、例えば、マルチホーム／パス環境における最少コストルーティングといったコストメトリクスに基づいて意思決定をする際に用いられる。
【００３７】
このようなポリシー管理技術では、意思決定の際にモビリティあるいは位置取得（つまりローミング）に関する事項が考慮に入れられてもよい。例えば、管理ルールが装置の位置（ネットワークのどの接続ポイント、例えばアクセスポイント／基地局、ハブ、ルータ、ＧＰＳ座標等に近いかなど）に基づいて決定されてもよく、これにより、特定の操作が、あるビル内では許可されるが別のビルでは許可されないといったことが可能になる。例えば複数の違った無線ネットワークを利用している企業の場合にこの構成が有用であると考えられる。このような企業において、例えば積込ドックとオフィスとが無線ネットワークで接続されている場合がある。システム管理者は、積込ドックにいる従業員（例えばユーザや装置）がオフィス環境の無線ネットワークにアクセスできないようにすることができる。さらに、ポリシー管理によって、許可、拒否、遅延という３つの状態のいずれかをもたらすようにすることも可能である（例えば、決定が帯域幅やコストに基づいてなされる場合、操作の実行はより適切な時期がくるまで遅延される）。
【００３８】
上記実施例におけるポリシー管理においては、決定に基づいて動作を変更することが可能となっている。ひとつのアクションの例としては、全てのアクティブなアプリケーションによる帯域幅の消費を抑えるというものがある。また、例えば、著しく帯域幅を消費する特定のアプリケーションが存在する場合に、ポリシーエンジン（ｐｏｌｉｃｙ ｅｎｇｉｎｅ）によって該アプリケーションによる操作／トランザクションの完了までの速度を管理することが可能となる。この動作は、誤ったアプリケーションの動作を抑制させることを動的に学習するようになっていてもよい。もうひとつのアクションの例として、データの復元（例えば、利用可能な／許可された帯域幅やコスト、ユーザによる制限に基づいたグラフィックイメージのディザリング）がある。
【００３９】
さらに、ルールエンジン（ｒｕｌｅｓ ｅｎｇｉｎｅ）は、ルール評価に基づいて他のアクションを発動させる。イベントをロギングする、警告を発する、ユーザにアクションが拒否、遅延、あるいは条件付けされたことを通知するといった外部プロシージャが実行されてもよい。これらのような通知は、既存のルールへのオーバーライドがオペレータから求められるというような、インタラクティブなものであってもよい。
【００４０】
上記実施例におけるポリシー管理エンジン（ｐｏｌｉｃｙ ｍａｎａｇｅｍｅｎｔ ｅｎｇｉｎｅ）において、その意思決定は、装置、装置のグループ、ユーザ・グループ、ユーザ、あるいはネットワーク接続ポイントに関連した、任意の数のメトリクスもしくはその組み合わせに基づいてなされていてもよい。
【００４１】
ポリシー管理機能の一部として、他にもローカルベースの情報やサービスが、ポリシー管理、ネットワーク・モデリング、および／またはアセット・トラッキングのために取得され／備えられていてもよい。このようなサービスには、モバイル端末システムの現在位置に関連した情報がユーザやモバイル端末システムに自動的に提供される機能が含まれる。該情報は、メッセージ、ファイルその他の電子的フォーマットにて供給されてもよい。
【００４２】
この機能の非限定的な利用例としては、ショッピングモール運営者、各種業界団体、大規模小売業者などがショッピングセンターに、ブルートゥース ＰＡＮ、ＩＥＥＥ ８０２．１１ ＬＡＮ、８０２．１５ ＰＡＮ、その他の無線ネットワーク規格に準拠した、無線アクセスポイントを戦略的に設けるというものがある。この場合、顧客がセンター内を歩き回るのにあわせて、モバイル端末システムの現在位置周辺の店舗は顧客に情報を提示することができる。この情報としは、セールやディスカウント、特典などについてのものが含まれる。これに加え、モバイル端末システムに販促用の電子クーポン券が供給されるのもよい。店舗側は上記のようなサービスを、モール運営者、業界団体、小売業者、あるいはその他のサービス提供者による集中的な管理機構に登録することになる。
【００４３】
上記技術が利用される他の非限定的な例として、現場サービス、訪問販売、宅配などのバーティカル産業において、位置を基準にして情報を収集する、地域サービス、地図、方角、顧客、事故など公共の情報を、位置を基準にモバイル端末システムに送る、などがある。
【００４４】
さらに他の非限定的な例として、モバイル端末システムをモニタリング、トラッキングするウェブベースのサービスがある。例えば、顧客は該トラッキングサービスに登録し、信頼の置ける第三者機関が、ホスティングされているウェブサービスにログオンして顧客のモバイル端末システムの精確な位置を同定する。この場合、モバイル端末システムは車両に備え付けられてもよいし、歩行者に所持されていてもよい。モバイル端末システムのさらなる小型軽量化に伴い、このようなサービスはますます現実味を帯びてきている。該サービスを利用することで、危険度の高い人々、例えば高齢者、障害者、病人などを追跡、位置確認することができる。該サービスは、自動車その他の高価な動産や荷物をトラッキングすることにも利用できる。３Ｇ ＷＡＮネットワーク、ブルートゥースネットワーク、８０２．１１ネットワークその他の無線技術を利用し、ネットワーク媒体や接続ポイントを切り替えてもシームレスな接続性を保つことができるという特性を生かして、上記のサービスを非常に低いコストで実施することが可能である。
【００４５】
このように、本発明は企業ネットワークを延長して、ネットワーク管理者が、信頼性や集中的な管理形態を犠牲にすることなく、モバイル端末のユーザに、アプリケーションへの簡便なアクセスを固定端末のユーザの場合と同様に提供することを可能にする。本ソリューションは、既存の有線ネットワーク規格の長所を制定段階にあるモビリティ規格にも持たせて、既存のネットワーク・アプリケーション上で動作可能なソリューションを生み出すものである。
【００４６】
本発明の他の目的、特徴、および優れた点は、以下に示す記載によって十分分かるであろう。また、本発明の利点は、図面を参照した以下の説明で明白になるであろう。
【００４７】
［好ましい実施の形態の詳細な説明］
図１は、本発明の、モバイル強化ネットワークコンピュータシステム１００を例示している。該ネットワークコンピュータシステム１００は、モビリティ管理サーバ１０２と、一つ以上のモバイル端末システム１０４とを含んでいる。モバイル端末システム１０４は、ローカルエリア・ネットワーク（ＬＡＮ）１０８を通じてモビリティ管理サーバ１０２と通信することができる。モビリティ管理サーバ１０２は、モバイル端末システム１０４のネットワーク・レベルでのプロキシとして機能する。モビリティ管理サーバ１０２はこれを、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム１１０とも、モビリティ管理サーバ１０２とモバイル端末システム１０４との間の相互接続が断続的で信頼性の低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって成し遂げている。本好ましい実施形態では、モビリティ管理サーバ１０２は、本発明の遠隔プロシージャ・コール・プロトコルおよびインターネット・モビリティ・プロトコルを用いて、モバイル端末システム１０４と通信する。
【００４８】
この場合、モバイル端末システム１０４はモビリティ管理サーバ１０２とアクティブに接続されるが、該接続は常時アクティブに行われるものではない。例えば、
・複数のモバイル端末システム１０４ａ‐１０４ｋが、モビリティ管理サーバ１０２と、モバイル相互接続によって（この場合無線で）通信する。例として、ローカル・エリアもしくはワイドエリア・ネットワーク１０８と無線（あるいは有線）でつながった、従来型の電磁（電波）トランシーバ１０６が考えられる。上記のようなモバイル相互接続により、モバイル端末システム１０４ａ‐１０４ｋが、一つのカバーエリア（ｃｏｖｅｒ ａｒｅａ）１０７ａから別のカバーエリア１０７ｋへとローミングすることが可能になる。一般的に、モバイル端末システム１０４が、あるカバーエリア１０７から別のエリアにローミングしたり、最も近いトランシーバ１０６から届く範囲を外れたり、あるいは信号を一時的に遮断（例えばビルの柱の裏側を通るなどで）されたりした場合、一時的に通信が切断される。
【００４９】
・別のモバイル端末システム１０４ｌ、１０４ｍ…が、モビリティ管理サーバ１０２と、ドッキングポートやネットワークケーブルコネクタなどの着脱式（ｎｏｎ−ｐｅｒｍａｎｅｎｔ）有線相互接続１０９を介して通信する。モバイル端末システム１０４は、接続１０９が外れたり、モバイル端末システム１０４の電源が切られたりした場合、一時的にＬＡＮ１０８から切断される。
【００５０】
・さらに別のモバイル端末システム（例えば１０４ｎ）が、モビリティ管理サーバ１０２と、ワイドエリア・ネットワーク、ダイアルアップ・ネットワーク、衛星ネットワーク、インターネット等のネットワーク・トポグラフィ１１１を介してノマディック接続される。一例として、ネットワーク１１１のサービスは断続的なものであってもよく、他の例として、モバイル端末システム１０４がある種類の接続形態から別の種類のものへと移行（例えば、モビリティ管理サーバ１０２と有線相互接続１０９を通じて接続される状態からネットワーク１１１を通じて接続される状態へ移行、もしくはその逆）し、移行時に一時的に接続が切断されるという構成であってもよい。
【００５１】
モバイル端末システム１０４は、標準的なモバイル装置や市販のコンピュータであってよく、例えば、モバイル端末システム１０４は、市販のトランシーバおよび／またはネットワークカードを実装したラップトップコンピュータによって構成される。モバイル端末システム１０４は、標準的なネットワーク・アプリケーションや標準的なＯＳ（オペレーティングシステム）を実行し、標準的なトランスポート・レベル・プロトコル（例えばＴＣＰ／ＩＰ）を利用して、トランスポート層で通信を行うものであってよい。本発明において、さらに、モバイル端末システム１０４がクライアントソフトウェアを実行することで、遠隔プロシージャ・コール・プロトコルおよびインターネット・モビリティ・プロトコルを用いたモビリティ管理サーバ１０２との通信が可能になる。上記両プロトコルは、それらと同様のトランスポート・レベルのプロトコルを利用して伝送される。
【００５２】
モビリティ管理サーバ１０２は、ウィンドウズ（登録商標）ＮＴサーバなどの標準的なサーバによってホスティングされるソフトウェアを含んでいてよい。本好ましい実施形態では、モビリティ管理サーバ１０２は、規格に準拠したクライアント／サーバ型のインテリジェントサーバであって、企業ネットワーク１０８を透過性を有した状態でノマディック環境にまで延長するものである。モビリティ管理サーバ１０２は、数量を限定されないモバイル端末システム１０４それぞれのネットワーク・レベルでのプロキシとして機能するが、モビリティ管理サーバ１０２はこれを、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム１１０とも、モバイル端末システム１０４とトランシーバ１０６との間のモバイル相互接続が断続的で信頼性が低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって成し遂げている。
【００５３】
例えば、サーバ１０２はどのような標準的（例えばＴＣＰ／ＩＰベースの）ネットワーク・アプリケーションであっても、変更を行うことなしに、モバイル接続を通じて実行させることができる。接続が切断されたり、圏外に出たり、あるいは動作をサスペンドしたりしたモバイル端末システム１０４のセッションは、サーバ１０２によって維持され、該システムが復帰した際にはサーバ１０２が上記セッションをレジュームする。モバイル端末システム１０４が圏外に出てしまったり、シャットダウンしたり、あるいは位置アドレスを変更した場合、モビリティ管理サーバ１０２は、データの受信に関して確認応答し、モバイル端末システムが再度通信可能となるまで要求を待機させることで、モバイル端末システムとピア・システム１１０との接続を維持する。
【００５４】
サーバ１０２はまた、有線ネットワークにおける管理能力をモバイル接続にまで延長する。ネットワークソフトウェア層はそれぞれが互いに独立して動作するので、ソリューションをそれが展開されるそれぞれの環境に合わせてカスタマイズすることが可能である。
【００５５】
一例として、モビリティ管理サーバ１０２が、ローカルエリア・ネットワークやワイドエリア・ネットワークのような標準的な企業ネットワーク１０８と接続され、該ネットワーク１０８は、様々な固定端末システム（例えば一つ以上のホストコンピュータ１１０）１１０と接続される状況が考えられる。モビリティ管理サーバ１０２によって、モバイル端末システム１０４と固定端末システム１１０との間の、連続セッション型データストリームを利用した通信が可能となるが、この通信は、モバイル端末システム１０４が、接続しているネットワーク相互接続とのコンタクトを失ったり、あるネットワーク相互接続１０６、１０９、１１１から別のネットワーク相互接続へと移動したりしても（例えば、無線相互接続の場合、ある無線トランシーバ１０６のカバーエリア１０７から別のカバーエリアにローミングしても）、利用可能となっている。
【００５６】
モバイル端末システム１０４は、モビリティ管理サーバ１０２との結合を、スタートアップ時か、あるいはモバイル端末システムがネットワークサービスを要求した時に確立する。結合が確立されると、モバイル端末システム１０４は、一つ以上のネットワーク・アプリケーションのセッションを、連続的あるいは共時的に始めることができる。モバイル端末システム１０４−モビリティ管理サーバ１０２間の結合確立によって、モバイル端末システムが切断されたり、圏外に出たり、あるいはサスペンドしたりしても、モバイル端末システムにおけるアプリケーションのセッションを維持し、モバイル端末システムの復帰時には該セッションをレジュームすることが可能になる。本好ましい実施形態では上記の処理は完全に自動で行われ、ユーザによる介入は全く必要とされない。
【００５７】
本発明の一例において、モバイル端末システム１０４は、ＵＤＰ／ＩＰのような標準的なトランスポート・プロトコルを用いてモビリティ管理サーバ１０２と通信を行う。標準的なトランスポート・プロトコルを使用することで、モバイル端末システム１０４が、標準的なルータ１１２など企業ネットワーク１０８に既存のインフラを用いて、モビリティ管理サーバ１０２と通信することが可能になる。本発明では、高レベルの遠隔プロシージャ・コール・プロトコルが、トランザクションを、モバイル強化ネットワーク１０８を介して、標準的なトランスポート・プロトコルを使用して送られるメッセージへと生成する。本好ましい実施形態において、上記のようなモバイルＲＰＣメッセージは、モバイル端末システム１０４にて実行されるアプリケーションによって開始された、全てのネットワーク・トランザクションを含んでいるため、モビリティ管理サーバ１０２によって全てを完了させることができる。このことにより、モビリティ管理サーバ１０２とモバイル端末システム１０４とは、ネットワーク媒体の接続性が阻害されているときでも、接続状態情報を常に互いにシンクロさせておくことができる。
【００５８】
モバイル端末システム１０４のそれぞれは、全てのネットワーク活動を傍受し、該ネットワーク活動をモバイルＲＰＣプロトコルを通じてモビリティ管理サーバ１０２にリレーするための情報をモバイル端末システム自体に提供するモビリティ管理ソフトウェアクライアントを実行する。本好ましい実施形態では、該モビリティ管理クライアントは、モバイル端末システム１０４に実装されているＯＳ（ウィンドウズ（登録商標）ＮＴ、ウィンドウズ（登録商標）９８、ウィンドウズ（登録商標）９５、ウィンドウズ（登録商標）ＣＥなど）と透過性を有する状態で協働して、クライアント側でのアプリケーションのセッションを、ネットワークとのコンタクトが失われても維持し続ける。
【００５９】
モビリティ管理サーバ１０２は、それぞれのモバイル端末システム１０４の状態を管理し、例えば接続の反対側の端に接続されたホストコンピュータ１１０のような通信相手のピア１０８との連続的な接続を維持するために必要とされる複合的なセッション管理を行う。モバイル端末システム１０４との通信ができなくなったり、モバイル端末システム１０４がサスペンドしたり、あるいはネットワークアドレスを変更したり（例えばあるネットワーク相互接続から別のものにローミングしたり）した場合、モビリティ管理サーバ１０２は、モバイル端末システム１０４とホストシステム１１０などの接続端との間の接続を、データ受信に関して確認応答したり、要求を待機させたりすることによって維持する。このプロキシ機能によって、ピアのアプリケーションは、モバイル端末システム１０４との物理的な接続が絶たれたことを検知することがなくなる。よって、もしモバイル端末システムが一時的に接続を失ったり、あるカバーエリア１０７Ｋ内において、あるネットワーク相互接続１０６Ａから別のネットワーク相互接続１０６Ｋへとローミングしたりした場合でも、（物理的接続が再確立された際に単純に作業をレジュームすることで）モバイル端末システム１０４のアプリケーションと、その結合しているセッションを実行する端との間の連続的な接続を効果的に維持することができる。
【００６０】
モビリティ管理サーバ１０２はまた、モバイル端末システム１０４がセグメント化されたネットワークの様々な部分をローミングする際、異なったネットワークアドレスを受信するという問題を解決するべく、アドレスを管理することが可能となっている。モバイル端末システム１０４はそれぞれ、プライマリネットワーク上での仮想アドレスを有している。該仮想アドレスは、標準的なプロトコルによって、あるいは静的割り当てによって決定されている。モバイル端末システム１０４のそれぞれについて、モビリティ管理サーバ１０２は該システムの現状における実際の（位置）アドレスに対応して仮想アドレスを割り当てる。モバイル端末システム１０４の、あるネットワーク・セグメントから他のセグメントへの移動に伴って、該システム１０４の現在位置アドレスが変更されても、仮想アドレスは、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【００６１】
よって、モバイル端末システム１０４の位置アドレスの変更は、モビリティ管理サーバ１０２を介して、結合しているホストシステム１１０（および他のピア）におけるセッションを実行する端からは完全に透過性を有する状態となっている。ピア１１０から見えるのは、サーバ１０２によってプロキシされた（不変の）仮想アドレスのみということになる。
【００６２】
本好ましい実施形態では、モビリティ管理サーバ１０２はさらに、コンソール（制御）アプリケーションと包括的なメトリクス（ｅｘｈａｕｓｔｉｖｅ ｍｅｔｒｉｃｓ）とによる、集中的なシステム管理が可能である。システム管理者は、上記のツールを利用して、遠隔接続を設定、管理し、遠隔接続およびシステムにおける問題を解決することができる。
【００６３】
モビリティ管理サーバ１０２によるプロキシ・サーバ機能によって、ネットワーク・アプリケーション、ユーザ、そして装置にそれぞれ異なった優先レベルを設定することができるようになる。これは、モビリティ管理サーバ１０２が有する処理用のリソースが有限であることを鑑みれば、有用なものである。システム管理者が上記のようにモビリティ管理サーバ１０２の設定を変更できることで、システムおよびネットワークのパフォーマンスが全体として向上する。一例として、システム管理者がモビリティ管理サーバ１０２の設定を変更できることにより、音声や映像のストリーミングのようなリアルタイムのアプリケーションに対して、モビリティ管理サーバ１０２のリソースを、あまりリソースを使用しないメールソフトのようなアプリケーションよりも多く割り当てることができる。
【００６４】
詳しく説明すると、モビリティ管理サーバ１０２は、アプリケーション、もしくはＳＮＭＰのような標準的なネットワーク管理プロトコル、ウェブベースの設定インターフェイス、ローカルなユーザインターフェイスなどのアプリケーション・インターフェイスを介して設定される。結合（ａｓｓｏｃｉａｔｉｏｎ）そのものの優先度、および／または、ある結合における複数のアプリケーションの優先度を設定することも可能である。例えば、モビリティ管理サーバ１０２を介して動作する他の結合と関連している結合それぞれの優先度は、ユーザあるいは装置ごとに設定可能である（本実施形態では、ユーザおよびユーザがログインした装置の両方を優先するように設定された場合に、ユーザに関する設定のほうがより優先されるように設定されてもよい）。あるいは結合それぞれについて、アプリケーションの優先度に関し、ネットワーク・アプリケーションごとにいくつかのレベルが設定されていてもよい。本システムでは、優先レベルはいくつでも設定することが可能である。一例として、低、中、高の３つの優先レベルが設定される例が考えられる。
【００６５】
（サーバ／クライアント型ソフトウェア・アーキテクチャの例）
図２に、モバイル端末システム１０４とモビリティ管理サーバ１０２とのソフトウェア・アーキテクチャの一例を図示する。本発明の一例において、モバイル端末システム１０４とモビリティ管理サーバ１０２は標準的なＯＳおよびアプリケーション・ソフトウェアを実行するが、このときに、ほんの少数のコンポーネントを新しく追加するだけで、断続的に接続されるモバイルネットワーク１０８を介した、信頼性が高くかつ効果的、持続的なセッションが実行可能となっている。図２に示すように、モバイル端末システム１０４は、ネットワーク・インターフェイス・ドライバ２００、ＴＣＰ／ＵＤＰトランスポートサポート２０２、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４、および一つ以上の従来型のネットワーク・アプリケーション２０８に対するインターフェイスとして使われるソケットＡＰＩ２０６を含む、従来型のＯＳソフトウェアを実行する。従来型のネットワーク・ファイル／プリント・サービス２１０が、従来型のＴＤＩ２０４との通信用にさらに設けられていてもよい。サーバ１０２は、上記と類似した、従来型のネットワーク・インターフェイス・ドライバ２００’、ＴＣＰ／ＵＤＰトランスポートサポート２０２’、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４’、および一つ以上の従来型のネットワーク・アプリケーション２０８’に対するインターフェイスとして使われるソケットＡＰＩ２０６’を有していてもよい。モバイル端末システム１０４とモビリティ管理サーバ１０２はそれぞれ、さらにネットワーク／セキュリティ・プロバイダ２３６（モバイル端末システム）、ユーザ／セキュリティ・データベース２３８（サーバ）を備えていてもよい。
【００６６】
本発明では、新規のモバイル・インターセプタ・コンポーネント２１２が、モバイル端末システム１０４のソフトウェア・アーキテクチャにおける、ＴＣＰ／ＵＤＰトランスポートモジュール２０２とトランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４との間に挿入されている。該モバイル・インターセプタ・コンポーネント２１２は、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４における特定のコールを傍受して、該コールを、ネットワーク１０８を介し、ＲＰＣおよびインターネット・モビリティ・プロトコル、標準的なＴＣＰ／ＩＰトランスポート・プロトコルを通じてモビリティ管理サーバ１０２へと転送する。こうして、モバイル・インターセプタ２１２は、全てのネットワーク活動を傍受して、サーバ１０２へと転送することができる。該インターセプタ２１２はＯＳと透過性を有する状態で協働するので、モバイル端末システム１０４がネットワーク１０８とのコンタクトを失っても、クライアント側のアプリケーションのセッションはアクティブであり続けることができる。
【００６７】
モバイル・インターセプタ２１２は、トランスポート・ドライバ・インターフェイス２０４とは違うレベルで（例えばソケットＡＰＩ２０６のレベルで）動作することもできるが、ＴＤＩのレベルでモバイル・インターセプタ２１２が動作する、より詳細にはいずれかのトランスポート・プロトコル・インターフェイスにおいて動作することにより、下記のような利点が生まれる。なお、便宜的に、トランスポート・ドライバ・インターフェイスを示す全てのものをＴＤＩという略語で表わすこととする。多くの標準的なＯＳ（例えば、マイクロソフト社のウィンドウズ（登録商標）９５、ウィンドウズ（登録商標）９８、ウィンドウズ（登録商標）ＮＴ、ウィンドウズ（登録商標）ＣＥなど）はＴＤＩインターフェイス２０４を実装しているので、ＯＳのコンポーネントを変更することなく互換性が保証される。さらに、トランスポート・ドライバ・インターフェイス２０４は通常カーネル・レベルのインターフェイスであることから、ユーザモードへの切り替えが必要でなく、これにより性能を向上させることができる。
【００６８】
さらに、ＴＤＩインターフェイス２０４のレベルで作動するモバイル・インターセプタ２１２は、様々な別のネットワーク・アプリケーション２０８（例えば複数の同時に動作しているアプリケーション）に加えて、ネットワークにおけるファイル、プリント、および他のカーネル・モードなどのサービス２１０（インターセプタが例えばソケットＡＰＩ２０６のレベルで動作している場合はそれぞれ別に扱う必要がある）を傍受することができる。
【００６９】
図２Ａに、どのようにインターセプタ２１２が動作するかを示す高レベルのフローチャートの一例を示す。モバイル端末システム１０４のＴＤＩインターフェイス２０４へのコール（ブロック２５０）は、モバイル・インターセプタ２１２によって傍受される（ブロック２５２）。モバイル・インターセプタ２１２によって傍受されたＲＰＣコールはインターネット・モビリティ・プロトコルに準拠してフラグメントにパッケージ化され、該フラグメントはデータグラムとして、ＵＤＰやＴＣＰといった標準的なトランスポート・プロトコルにより、ＬＡＮ、ＷＡＮ等のトランスポート１０８を介してモビリティ管理サーバ１０２へと送られる（ブロック２５２）。モビリティ管理サーバ１０２は受信したＲＰＣデータグラムをアンパックして（ブロック２５４）、要求されたサービスを実行する（例えば、データや応答を、固定端末システム１１０で動作するアプリケーションサーバ処理へと転送することで、モバイル端末システムのアプリケーション２０８のプロキシとして振舞う）。
【００７０】
再び図２に戻って、モビリティ管理サーバ１０２は、従来型のネットワーク・インターフェイス・ドライバ２２２を介して送られる、モバイル端末システム１０４からの、あるいはモバイル端末システム１０４へ向かうメッセージを傍受する、アドレス変換部２２０を有している。例えば、アドレス変換部２２０は、セッションの相手のピア（固定端末システム１１０）からのモバイル端末システム１０４の仮想アドレス宛のメッセージを認識する。モバイル端末システムへの該メッセージはプロキシ・サーバ２２４へと送られる。プロキシ・サーバ２２４は仮想アドレスとメッセージとを待機していたトランザクションに割り当て、該応答を、上記モバイル端末システム１０４の現在位置アドレスへと転送する。
【００７１】
さらに、図２によると、モビリティ管理サーバ１０２は、アドレス変換部（中間ドライバ）２２０とプロキシ・サーバ２２４に加えて、設定マネージャ２２８、操作／ユーザインターフェイス２３０、およびモニタ２３２を有している。設定マネージャ２２８は設定情報とパラメータとを提供して、プロキシ・サーバ２２４が接続の管理を行えるようにする。操作／ユーザインターフェイス２３０とモニタ２３２により、ユーザとプロキシ・サーバ２２４との間のやりとりが可能になる。
【００７２】
（モバイル・インターセプタ）
図３は、本発明のＲＰＣプロトコルとインターネット・モビリティ・プロトコルとをサポートしたモバイル・インターセプタ２１２のソフトウェア・アーキテクチャの一例を示す。本例では、モバイル・インターセプタ２１２は、遠隔プロシージャ・コール・プロトコル・エンジン２４０と、インターネット・モビリティ・プロトコル・エンジン２４４の、二つの機能コンポーネントを有している。モビリティ管理サーバ１０２において動作するプロキシ・サーバ２２４によって、対応するエンジン２４０’、２４４’が用意される。
【００７３】
このように、本好ましい実施形態におけるモバイル・インターセプタ２１２は、モビリティ管理サーバ１０２をそれぞれのモバイル端末システム１０４と接続するための、遠隔プロシージャ・コール・プロトコルと、インターネット・モビリティ・プロトコルとをサポートしている。遠隔プロシージャ・コールは、あるローカルシステムから、離れた別のシステムにおけるプロシージャを発動する処理を可能とするものである。一般的に、ローカルシステムは遠隔のシステムにおいてプロシージャ・コールが実行されたことを感知しない。ＲＰＣプロトコルの利用によって、モバイル端末システム１０４が、アクティブなネットワークセッションを失うことなく、圏外に出たり、操作をサスペンドしたりすることが可能になる。セッションの維持に特別なアプリケーションは必要とされないので、モバイル環境にあるネットワーク１０８において、市販のアプリケーションが何の変更も必要とせずに動作することになる。
【００７４】
ネットワーク・アプリケーションは、一般的に、ウィンドウズソケット（Ｗｉｎｄｏｗｓ ｓｏｃｋｅｔｓ）のようなアプリケーションレベルのインターフェイスを利用している。アプリケーションレベルのＡＰＩへの単一のコールによって、トランスポート層もしくはメディア・アクセス層における複数の送信および受信データパケットが生成される。優先されるモバイルネットワークで、もし上記のパケットのうちの一つが失われた場合、接続全体の状態が不安定になってセッションは中止されるが、本発明の好ましい実施形態はＲＰＣを備えており、モビリティ管理サーバ１０２とモバイル端末システム１０４とは、物理的な接続が絶たれたときであっても、常に統一された論理リンクを維持するために、接続状態に関する情報を共有している。
【００７５】
本発明のインターネット・モビリティ・プロトコルは、有線のネットワークと無線など他の信頼性の劣るネットワークとの相違点を補償する。フレームサイズとプロトコルのタイミングとが修正されることで、モバイル環境を考慮しないトランスポートと比較して性能が著しく向上し、ネットワークのトラフィックを大幅に減少することができる。このことは、帯域幅に制限がある場合やバッテリーの寿命が問題となる場合に重要となる。
【００７６】
また、本発明のインターネット・モビリティ・プロトコルは、公共の有線ネットワークを通じて、もしくは無線によってモビリティ管理サーバ１０２とモバイル端末システム１０４との間の通信がなされる際の、機密情報のセキュリティを保証する。インターネット・モビリティ・プロトコルは、認証された装置のみが企業ネットワークにアクセスすることを許可することで、基本的なファイアウォールとしての機能を果たす。本発明のインターネット・モビリティ・プロトコルはさらに、モビリティ管理サーバ１０２とモバイル端末システム１０４との間での全ての通信を認証、暗号化することを可能にする。
【００７７】
図３のモバイル端末システム１０４における遠隔プロシージャ・コール・プロトコル・エンジン２４０は、ＴＤＩコールパラメータをマーシャリングし、データをフォーマットし、要求を、ＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’がコールを実行するモビリティ管理サーバ１０２まで転送するべく、インターネット・モビリティ・プロトコル・エンジン２４４に送る。モバイル端末システム１０４は、遠隔プロシージャ・コール・プロトコルに基づいてＴＤＩコールパラメータをマーシャリングする。モビリティ管理サーバ１０２のＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’が上記のＲＰＣを受信すると、モビリティ管理サーバ１０２はモバイル端末システム１０４に代わってコールを実行する。モビリティ管理サーバ１０２のＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’は、接続されたモバイル端末システムそれぞれにおける完全なネットワークの状態を、ピアであるモバイル端末システム１０４のＲＰＣエンジン２４０と共有する。モバイル端末システム１０４の代理としての遠隔プロシージャ・コール実行に加え、サーバのＲＰＣエンジン２４０’は、システムフローの管理、遠隔プロシージャ・コールの解析、仮想アドレスの（アドレス変換機構２２０が行うサービスに対応した）多重化、遠隔プロシージャ・コールのトランザクションの優先順位付け、スケジューリング、ポリシー実行、および融合処理（ｃｏａｌｅｓｃｉｎｇ）を行う。
【００７８】
インターネット・モビリティ・プロトコル・エンジン２４４は、信頼性の高いデータグラムサービス、順位付け、フラグメント化、およびメッセージの再組立を行う。また、設定すれば、認証、データ暗号化、プライバシー保護強化、セキュリティ、そしてスループットのための圧縮も行うことができる。インターネット・モビリティ・プロトコル・エンジン２４４は、電力消費を考慮に入れる必要のある環境において、複数の異なるトランスポートを利用して機能するようになっているので、消費電力管理を意識したものであるとともに、各トランスポートに対して独立となっている。
【００７９】
図３Ａは、モバイル・インターセプタ２１２がモビリティ管理サーバ１０２と通信してＴＤＩコールのやり取りを行う処理を例示する。一般的に、モバイル・インターセプタ２１２のＲＰＣプロトコル・エンジン２４０は、マーシャリングされたＴＤＩコールを、モビリティ管理サーバ１０２へと送るべく、インターネット・モビリティ・プロトコル・エンジン２４４へと転送する。ＲＰＣプロトコル・エンジン２４０は、この作業を、インターネット・モビリティ・プロトコル・エンジン２４４によって管理されるキューにＲＰＣコールを加えることで達成する（ブロック３０２）。帯域幅管理を円滑に行うために、インターネット・モビリティ・プロトコル・エンジン２４４は受信したＲＰＣコールの転送を所定の期間（ＲＰＣ融合タイムアウト期間）遅延させる（ブロック３０４）。一般的に、ＲＰＣ融合タイムアウトは５ミリ秒から１５ミリ秒の間に設定されるが、この数値はユーザによって変更可能である。この遅延によって、ＲＰＣエンジン２４０はＴＤＩコールをインターネット・モビリティ・プロトコル・エンジン２４４のキューに加えて、一つ以上のＲＰＣコールが同一のデータグラム（フラグメント）によって転送されるようにすることができる。
【００８０】
融合タイムアウトが終了するか、ＲＰＣエンジン２４０がそれ以上のＲＰＣコールの受信を拒否する（判定ブロック３０６）ことを決定すると、ＲＰＣエンジン２４０は、インターネット・モビリティ・プロトコル・エンジン２４４に、キューをフラッシュ（ｆｌｕｓｈ）し、ＲＰＣコールを単一のフレームに融合し、該フレームをピアに転送するよう要求する（ブロック３０８）。この融合により伝送回数が減少し、プロトコルのパフォーマンスが高められる。しかし、インターネット・モビリティ・プロトコルは、パフォーマンス最適化のために他の外部基準に基づいてキュー２４４をフラッシュすることもしなければならず、本好ましい実施形態において、単一のＲＰＣ要求でフレーム全体が占められてしまう場合、ＩＭＰ層は自動的に要求をピアに送るよう試みる。
【００８１】
上記のように、モビリティ管理サーバ１０２のプロキシ・サーバはＲＰＣプロトコル・エンジン２４０’とインターネット・モビリティ・プロトコル・エンジン２４４’とを有している。図３Ｂは、モバイル端末システム１０４からインターネット・モビリティ・プロトコル・メッセージ・フレームを受信した際に、モビリティ管理サーバ１０２で実行される処理を例示している。該フレームをモビリティ管理サーバ１０２が受信すると、インターネット・モビリティ・プロトコル・エンジン２４４’は、フレームが（基礎となるトランスポートの最大伝送量の制約で）フラグメント化されていれば再構築し、メッセージの内容を逆多重化して、どのモバイル端末システム１０４からの受信かを決定する。この逆多重化により、インターネット・モビリティ・プロトコル・エンジン２４４’は、遠隔プロシージャ・コール・プロトコル・エンジン２４０’に、的確な結合関連文脈情報（ａｓｓｏｃｉａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｃｏｎｔｅｘｔ ｉｎｆｏｒｍａｔｉｏｎ）を伝えることができる。
【００８２】
続いて、インターネット・モビリティ・プロトコル・エンジン２４４’は、受信したメッセージを、ＲＰＣ受信示唆システム作業要求（ＲＰＣ ｒｅｃｅｉｖｅ ｉｎｄｉｃａｔｉｏｎ ｓｙｓｔｅｍ ｗｏｒｋ ｒｅｑｕｅｓｔ）３５４にして、該作業要求と結合関連文脈情報を、モビリティ管理サーバ１０２のＲＰＣプロトコル・エンジン２４０’に与える。ＲＰＣプロトコル・エンジン２４０’が作業要求３５２を受信すると、該エンジン２４０’は作業要求３５２を結合関連作業キュー３５６に加え、次に予定済みの要求をグローバルキュー３５８に送ることによって、結合処理のスケジューリングが行われる。続いて、ＲＰＣエンジン２４０’のメイン作業スレッドに、作業が実行可能となったことが伝えられる。該メインスレッドが作業を始めると、グローバルキュー３５８がポーリングされて、待機状態となっているスケジューリングされた結合処理が確認される。その後、メインスレッドは該イベントを待機状態から外し、結合関連作業キュー３５６が処理される。
【００８３】
結合関連作業キュー３５６から、上記メインスレッドはそれまで待機していたＲＰＣ受信示唆作業要求を見つけ出す。次に、メインスレッドはＲＰＣ受信示唆作業要求３５６をキューから外し、該要求を解析する。図３Ａを参照して説明した上記融合処理により、モビリティ管理サーバ１０２は、それぞれのデータグラムに内包された複数のＲＰＣトランザクションを頻繁に受信することになる。モビリティ管理サーバ１０２は次に、該ＲＰＣトランザクションをそれぞれ逆多重化して別個の遠隔プロシージャ・コールに戻し、そして要求された機能をモバイル端末システム１０４に代わって実行する。パフォーマンス向上のため、ＲＰＣエンジン２４０’に、ＲＰＣメッセージ解析処理中の先読みメカニズムを備えさせて、ＲＰＣエンジン２４０’が、要求されたトランザクションのうちのいくつかを同時に実行できるか否か（パイプライン処理できるか否か）を確認してもよい。
【００８４】
（ＲＰＣエンジン２４０’によるＲＰＣ結合の実行手法）
図４は、結合作業キュー３５６に加えられたＲＰＣ結合を実行する処理を例示したフローチャートである。ＲＰＣ結合の実行が予定されている時、ＲＰＣプロトコル・エンジン２４０’（状態機械として設けられていてもよい）のメインスレッドは、グローバルネットワークキュー３５８からの作業要求を待機状態から外し、作業要求の種類を決定する。
【００８５】
本実施形態のＲＰＣ作業要求は、以下のような６つの基本的な種類に分けられる。
【００８６】
・スケジューリング要求（ｓｃｈｅｄｕｌｅ ｒｅｑｕｅｓｔ）
・接続示唆
・切断示唆
・ローカル結合中止（ｌｏｃａｌ ｔｅｒｍｉｎａｔｅ ａｓｓｏｃｉａｔｉｏｎ）
・「リソース使用可」要求（”ｒｅｓｏｕｒｃｅ ａｖａｉｌａｂｌｅ” ｒｅｑｕｅｓｔ）
・ｐｉｎｇ休止タイムアウト（ｐｉｎｇ ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｏｕｔ）
ＲＰＣプロトコル・エンジン２４０’は、上記の様々な種類の要求をそれぞれ別の方法で取り扱う。ＲＰＣプロトコル・エンジン２４０’は要求の種類（グローバルキュー３５８に記憶された、要求に関する情報によって識別される）をテストして、該要求をどう処理するかを決定する。
【００８７】
作業要求の種類が「スケジューリング要求」である場合（判定ブロック３６０）、ＲＰＣプロトコル・エンジン２４０’はどの結合が予定されているかを判別する（ブロック３６２）。ＲＰＣプロトコル・エンジン２４０’はこの判別を、グローバルキュー３５８に記憶されている情報に基づいて実行することができる。上記判別がなされると、ＲＰＣプロトコル・エンジン２４０’が、それぞれが対応する要求を記憶している結合作業キュー３５６（１）〜３５６（ｎ）のうちの一つを特定することが可能となる。ＲＰＣエンジン２４０’によって、対応する結合制御ブロックが取得され（ブロック３６２）、結合作業処理タスク（Ｐｒｏｃｅｓｓ Ａｓｓｏｃｉａｔｉｏｎ Ｗｏｒｋ ｔａｓｋ）３６４が呼び出されて、上記の特定された作業キュー３５６における作業の処理が始められる。
【００８８】
図５は、図４の「結合作業処理」タスク３６４によって実行されるステップを例示している。結合が特定されると、「結合作業処理」タスク３６４が呼び出され、対応する結合作業キュー３５６内の作業が処理される。待機状態から外された作業要求（ブロック３９０）がＲＰＣ受信要求（判定ブロック３９２）である場合、該ＲＰＣ受信要求はＲＰＣ構文解析部（ｐａｒｓｅｒ）に送られ、処理される（ブロック３９４）。あるいは、待機状態から外された作業要求（ブロック３９０）が、保留中の（ｐｅｎｄｉｎｇ）受信要求である場合（判定ブロック３９６）、ＲＰＣエンジン２４０’はＴＤＩ２０４’に、アプリケーションによる接続の代わりにデータを受信し始めるよう要求する（ブロック３９８）。上記待機状態から外された作業要求が、保留中の接続要求である場合（判定ブロック４００）、ＲＰＣエンジン２４０’はＴＤＩ２０４’に、アプリケーション用途ＴＣＰ（あるいは他のトランスポート・プロトコル）接続要求を発するよう要求し（ブロック４０２）、ＴＤＩ層２０４’からの応答を待つ。ＴＤＩ２０４’による要求が完了すると、該要求の状態が決定されて、元の要求エンティティへと報告が戻される。パフォーマンス向上のため、ＲＰＣエンジン２４０’は、実際に要求を発しているピアへエラーを通知する前に、要求を結合関連作業キュー（３５６）へと戻すことで、接続要求処理を複数回行うようになっていてもよい。この処理も、ネットワーク帯域幅およびリソースの消費を減らすためのものである。
【００８９】
上記の処理は、「スケジューリング重み付け」（ｓｃｈｅｄｕｌｉｎｇ ｗｅｉｇｈｔ ｃｏｍｐｌｅｔｅ）テスト（ブロック４０４）にパスするまで繰り返される。本例では、スケジューリング重みは、どれだけの作業要求が待機状態から外されて、上記の特定の結合がどれだけ処理されるかを決定するのに使われる。該スケジューリング重みは設定マネージャ２２８によって設定されるパラメータであり、結合接続示唆が検出されたときに取得される（図４、ブロック３７２）。この数値はユーザごとに、あるいは物理的な意味での装置ごとに設定可能である。
【００９０】
ＲＰＣエンジンが結合作業キュー３５６の作業を（少なくとも一時的に）終了した後、ディスパッチ・キューの処理に移ってもよい（ブロック４０６）（詳細は以下）。結合の作業キュー３５６における作業の処理後、ＲＰＣエンジン２４０’は、グローバル作業キュー３５８に新たなスケジューリング要求を発信して、後で実行される結合のスケジューリングを再び行う（図４の判定ブロック３６６、ブロック３６８、図５の判定ブロック４０８、ブロック４１０）。
【００９１】
再度図４を参照すれば、ＲＰＣ作業要求が「接続示唆」の場合（判定ブロック３７０）、ＲＰＣエンジン２４０’に、モバイル・ピア（通常はモバイル端末システム１０４だがこれに限らない）との新たな接続のインスタンスを作成せよという要求が入る。一例として、上記接続示唆により、接続を開始しようとしているピアの装置に関する以下のような情報がＲＰＣエンジン２４０’に与えられる。
【００９２】
・装置の物理的識別子
・該装置にログインしているユーザ名
・ピアの装置のアドレス
・ピアのＲＰＣエンジン２４０からの、付加的な接続データ
接続示唆（判定ブロック３７０）を受け、ＲＰＣエンジン２４０は上記のパラメータをもって設定マネージャ２２８をコールする。設定マネージャ２２８は該パラメータを用いて、上記新規接続の設定を確定する。この設定（例えば結合スケジューリング重みや、上記に加えてデフォルトでないスケジューリング特性を要するアプリケーション全てのリストなど）は、ＲＰＣエンジン２４０’に戻されて記憶、実行される。そしてＲＰＣエンジン２４０’は新規の結合を開始し、新規の結合制御ブロックを形成する（ブロック３７２）。図５Ａが示すように、以下のような動作が実行されてもよい。
【００９３】
・結合制御ブロックを割り当てる（ブロック３７２Ａ）
・システム全体のリソースをデフォルトにまで初期化する（ブロック３７２Ｂ）
・現在の設定をオーバーライドする（ブロック３７２Ｃ）
・フラグを初期化する（ブロック３７２Ｄ）
・結合特有作業キューを初期化する（ブロック３７２Ｅ）
・結合のオブジェクト・ハッシュ・テーブルを初期化する（ブロック３７２Ｆ）
・融合タイマーを初期化する（ブロック３７２Ｇ）
・結合制御ブロックをセッションテーブルに挿入する（ブロック３７２Ｈ）
インターネット・モビリティ・プロトコル・エンジン２４４’が結合を終了しなければならないと判断すると、「切断示唆」が該インターネット・モビリティ・プロトコル・エンジン２４４’からＲＰＣエンジン２４０’に出される。ＲＰＣエンジン２４０’はこの切断示唆をテストし（ブロック３７４）、示唆に応じて結合を停止し、結合制御ブロックを破棄する（ブロック３７６）。図５Ｂに示されるように、以下のステップが実行されてもよい。
【００９４】
・待機中の作業がこれ以上処理されないように、停止される結合をマークする（ブロック３７６Ａ）
・処理を含む、結合されている全ての結合オブジェクトをクローズする（ブロック３７６Ｂ）
・作業キューにある全てのエレメントを開放する（ブロック３７６Ｃ）
・融合タイマーが動作中ならば停止する（ブロック３７６Ｄ）
・結合制御ブロックの参照カウントを減少させる（ブロック３７６Ｅ）
・参照カウントが０の場合、（ブロック３７６Ｆにてテストされる）
・結合関連作業キューを破棄し、
・オブジェクト・ハッシュ・テーブルを破棄し、
・融合タイマーを破棄し、
・結合テーブルから結合制御ブロックを取り除き、
・制御ブロックを開放する（３７６Ｇ）
システム１０２が結合終了の必要性を認識すると、「セッション中止」要求が出される。この要求はシステム管理者、ＯＳ、あるいはアプリケーションから発される。ＲＰＣエンジン２４０’は、セッション中止要求を上記切断示唆と同様に扱う（判定ブロック３７８、ブロック３７６）。
【００９５】
本好ましい実施形態では、ＲＰＣエンジン２４０’とインターネット・モビリティ・プロトコル・エンジン２４４’との間のインターフェイスが、クレジット（ｃｒｅｄｉｔｓ）を基にフロー制御メカニズムを特定する。ある単一のスレッドが別のスレッドに作業要求を通知するたびに、コールされたスレッドは作業キューに残っているクレジットの数に戻る。キューが満杯であればクレジットのカウントは０になるが、慣例として、コールする側のスレッドは、クレジットのカウントが０ならばそれ以上作業通知をしない。よって、ユーザによって設定可能あるいは所定の最低点（ｌｏｗ−ｗａｔｅｒ ｍａｒｋ）をキューに付けて、待機中であった作業が処理されてリソースに余裕ができたことを、上記コールする側のスレッドに伝えるような構成が必要となる。これが、「リソース使用可」作業示唆が設けられている理由である（判定ブロック３８０にてテストされる）。図５Ｃが示すように、クレジットのカウントが０になったとき、以下のようなステップが実行されてもよい。
【００９６】
・ＲＰＣ＿ＬＭＰＱ＿ＳＥＮＤ＿ＦＬＡＧと設定して、結合に「ロー・マーク保留」（ｌｏｗ ｍａｒｋ ｐｅｎｄｉｎｇ）とマークを付ける（ブロック３７９Ａ）。この状態になったら、
・受信された全てのデータグラムを破棄する（ブロック３７９Ｂ）
・データ受信を拒否して全ての受信されたストリーム・イベントを抑える（ブロック３７９Ｃ）（これにより、ＴＣＰ他のトランスポート受信ウィンドウが結果的に閉じられ、固定端末システム１１０とモビリティ管理サーバ１０２との間のフロー制御がなされる。復帰の前に、本好ましい実施形態では「保留受信要求」（ｐｅｎｄｉｎｇ ｒｅｃｅｉｖｅ ｒｅｑｕｅｓｔ）を結合関連作業キュー３５６の前に押し込むので、保留中のストリーム受信イベントの処理（ｏｕｔｓｔａｎｄｉｎｇ ｓｔｒｅａｍ ｒｅｃｅｉｖｅ ｅｖｅｎｔ ｐｒｏｃｅｓｓｉｎｇ）が、リソースが利用可能になると直ちに継続される）。
【００９７】
・全ての受信された接続イベントが、受動接続のために拒否される（ブロック３７９Ｄ）
「リソース使用可」示唆をＲＰＣエンジン２４０’が受け取ると（図４、判定ブロック３８０）、該ＲＰＣエンジンは、結合された結合作業キュー３５６に待機中の作業があるか否かを判定する。もしあれば、ＲＰＣエンジンは該結合についてグローバル作業キュー３５８に通知して、上記結合作業キュー３５６が動作の優先権を持つことをマークしておく（ブロック３８２）。保留中の受信要求が、結合が保留受信要求状態にある期間に通知された場合、この期間中に処理される（本好ましい実施形態では、ＲＰＣエンジン２４０’は、この処理中も全ての受信された接続要求を受け入れる）。
【００９８】
再度図４を参照すると、ＲＰＣエンジン２４０’が、モビリティ管理サーバ１０２の「ｐｉｎｇ」に使われるチャネルが所定の期間にわたって休止していると判定した場合（判定ブロック３８４）、該チャネルは閉じられ、リソースは開放されてシステムに復帰し、他の処理に使用される（ブロック３８６）。
【００９９】
（ＲＰＣ構文解析と優先キュー）
再度図５を参照すると、ＲＰＣエンジンがＲＰＣ受信要求をその受信に際して構文解析することは前述した（ブロック３９２、３９４参照）。本好ましい実施形態において、構文解析は以下の点で必要とされる。即ち、受信された単一のデータグラムが複数のＲＰＣコールを含む可能性があるからであり、また、ＲＰＣコールがインターネット・モビリティ・プロトコルのデータグラムにおける複数のフラグメントにまで広がっている可能性があるからである。ＲＰＣ受信作業要求５００のフォーマットの例が図６に示される。ＲＰＣ受信作業要求のそれぞれは、少なくともメイン・フラグメント５０２（１）を有し、加えて任意の数の付加的フラグメント５０２（２）〜５０２（Ｎ）を有していることもある。メイン・フラグメント５０２（１）は、作業要求構造ヘッダ（ｗｏｒｋ ｒｅｑｕｅｓｔ ｓｔｒｕｃｔｕｒｅ ｈｅａｄｅｒ）５０３と、受信オーバーレイ５０４とを有している。受信オーバーレイ５０４は、インターネット・モビリティ・プロトコル・エンジン２４４によってメイン・フラグメント５０２（１）の先頭に設けられた受信オーバーレイである。この受信オーバーレイ５０４には、ｐユーザデータと呼ばれる、作業要求５００内で最初のＲＰＣコール５０６（１）を指し示す構造メンバがある。
【０１００】
図６の例に、複数のＲＰＣコール５０６（１）、５０６（２）…５０６（８）を含む、作業要求５００が図示されている。図６の例が示すように、ＲＰＣ作業要求５００は、メモリの隣接するブロックや単一のフラグメント５０２に含まれていなくてもよい。同例において、第二フラグメント５０２（２）と第三フラグメント５０２（３）とは、リンクしたリスト中でメイン・フラグメント５０２（１）に連鎖されている。
【０１０１】
よって、上記例のＲＰＣパーサ３９４は以下の境界条件を取り扱う。
【０１０２】
・ＲＰＣ受信要求５００それぞれが一つ以上のＲＰＣコールを含んでもよい
・一つ以上のＲＰＣコール５０６が、単一のフラグメント５０２中に存在してもよい
・ＲＰＣコール５０６それぞれが、フラグメント５０２中に完全に含まれていてもよい
・ＲＰＣコール５０６それぞれは、一つ以上のフラグメント５０２にまたがっていてもよい
図７は、ＲＰＣ受信作業要求５００を解析するＲＰＣ構文解析部３９４を例示している。本例において、ＲＰＣ構文解析部３９４は作業要求中の第一フラグメント５０２（１）を取得し、該フラグメント中の第一ＲＰＣコール５０６（１）を取得し、そしてＲＰＣコールを解析する。構文解析部３９４はＲＰＣ受信作業要求５００中を進んで、ＲＰＣコール５０６それぞれを処理していく。ＲＰＣ受信作業要求５００のフラグメント５０２（１）の残りのフラグメント・バイト数が、ＲＰＣヘッダ５０３のサイズよりも多い場合、構文解析部３９４は、ＲＰＣコールが完全にＲＰＣフラグメント５０２に含まれていて、処理を実行してもよいかどうかを判定する（該判定は、ＲＰＣコールの長さが残りのフラグメント・バイト数より大きいかどうかをテストすることでなされてもよい）。ＲＰＣコールの種類が連鎖例外である場合、ＲＰＣコールはＲＰＣ構文解析部３９４のアップデートを行うことになる。プロキシ・サーバ２２４において、連鎖例外であるＲＰＣコールは「データグラム送信」と「ストリーム送信」だけである。この連鎖例外プロシージャによって、ＲＰＣエンジンは、ＲＰＣ送信コールのためにメモリ記述子リストを共に連鎖することによるフラグメントコピーを避けることができる。
【０１０３】
構文解析部３９４がＲＰＣコールの種類を判別すると、ＲＰＣ情報の始めへのポインタは、実行のためにＲＰＣエンジン２４０へと転送される。ＲＰＣエンジンは、実行のために全てのＴＤＩプロシージャ・コールにそれぞれ別の優先順位をつける。最も優先度の高いコールは、ＲＰＣディスパッチャ３９５へ転送され、直ちに処理される。これより下の優先順位のコールは、後に処理されるために全てディスパッチ・キュー５１０にディスパッチされる。ディスパッチ・キュー５１０はそれぞれ離散的な優先度を表わしている。
【０１０４】
本実施形態では、モバイル・アプリケーションは、「オープンアドレス」オブジェクトおよび「オープン接続」オブジェクト機能を、他のＴＤＩネットワーキング機能を実行する前に呼び出す。よってシステムは、「オープンアドレス」オブジェクトおよび「オープン接続」オブジェクトの呼び出し中に、アプリケーションレベルの優先順位を割り当てることになる。例示の実施形態では、アドレスまたは接続オブジェクトに優先順位が付けられると、該オブジェクトに関連する全てのコールが、その割り当てられた優先順位中に実行される。
【０１０５】
例えば、ＲＰＣコールがＴＤＩオープンアドレスオブジェクト要求あるいはＴＤＩオープン接続オブジェクト要求である場合、該コールは直ちに実行されるべくＲＰＣディスパッチャ３９５に送られる。オープンアドレスおよびオープン接続オブジェクトＲＰＣコールにより、上記の接続示唆中に行われる設定要求の間に設定マネージャ２２８からもたらされる情報との対応に用いられる、処理ＩＤあるいは処理名へのアクセスが可能になる。該処理ＩＤあるいは処理名は、アドレスあるいは接続オブジェクトの設定を得るために用いられる。
【０１０６】
本好ましい実施形態では、全てのＲＰＣコールは、パラメータとして少なくともアドレスオブジェクトまたは接続オブジェクトを有している。コールが実行されると、そのオブジェクトに割り当てられた優先度が、ＲＰＣコールの優先度とされる。アドレスあるいは接続オブジェクトに割り当てられた設定により、実行される、対応するＲＰＣコール全ての優先度が決定される。例えば、割り当てられた優先度が「高」の場合、ディスパッチ・キュー５１０にディスパッチされることなく、全てのＲＰＣコールが直ちに実行される。割り当てられた優先度が「１」の場合、全てのＲＰＣコールが、ディスパッチ・キュー５１０（１）に加えられる。
【０１０７】
再度図５を参照すると、「結合作業処理」（ｐｒｏｃｅｓｓ ａｓｓｏｃｉａｔｉｏｎ ｗｏｒｋ）タスク３６４の処理が、予定された結合作業量の実行を完了すると（判定ブロック４０４）、ディスパッチ・キューがサービスを要求しているか否かが確認される（ブロック４０６）。図８は、図７に示されるディスパッチ・キュー５１０の処理のための「ディスパッチ・キュー処理」（ブロック４０６、図６）によって実行されるステップを例示したフローチャートである。
【０１０８】
この例では、ディスパッチ・キュー５１０は優先度が最高のキュー（本例では５１０（１））から処理される（ブロック４０８）。ディスパッチ・キュー５１０にはそれぞれ重み係数が設定されている。この重み係数は、モバイル端末システム１０４とモビリティ管理サーバ１０２との結合が確立された際に、設定マネージャ２２８によって返される設定パラメータである。例を挙げれば、優先度の低いディスパッチ・キュー５１０の重み係数は４であり、優先度が中程度のディスパッチ・キュー５１０重み係数は８である。本例では、優先度の高いＲＰＣコールは解析後直ちに処理されるため、重み係数を有していない。
【０１０９】
ＲＰＣエンジン２４０’は、現在のキューより始めて、ＲＰＣコールをキューから外していき、キューが空になるか、ＲＰＣコールのキュー重み番号（ｑｕｅｕｅ ｗｅｉｇｈｔ ｎｕｍｂｅｒ）が処理されるまでループする（ブロック４１２−４１６）。キューから外されたＲＰＣコールそれぞれに対して、その実行のためにＲＰＣディスパッチャ３９５が呼び出される。ＲＰＣディスパッチャ３９５はモバイル端末システム１０４の代理としてプロシージャ・コール（ｐｒｏｃｅｄｕｒａｌ ｃａｌｌ）を実行し、応答を要求している上記ＲＰＣコールに対するモバイル端末システムからの応答を生成する。
【０１１０】
上記ループを出た後、キューに残っている作業がまだある場合（判定ブロック４１８）、該キューが再実行を要することがマークされる（ブロック４２０）。ループを出ることで、上記システムはプロセッサを次に低い優先度のキューに移らせる（ブロック４２４、４１０）。これにより、ある特定のキューにどれだけの作業が割り振られていても、どの優先レベルにも実行される可能性が与えられることになる。システムは次のキューのサービスに移り、全てのキューが処理されるまで処理を繰り返す。全てのキューの処理が終了すると、システムは実行を要するマークがついたキューがあるか否かを判定して、もしあれば、スケジュール要求がグローバル作業キューに送られて、結合の再実行が予定されることになる。結合の再実行は、図４の「グローバル作業処理」ルーチンにおいて予定される。上記のアプローチにより、プロセッサが、処理すべき作業を有する他の結合にも実行の機会を与えることになる。キューそれぞれに重み係数を割り振ることで、システムは、モビリティ管理サーバ１０２のＣＰＵへのアクセスが優先レベルに応じて許可されるように調整されてもよい。これにより、優先度の高いキューは、先に実行されるだけでなく、さらに容易にＣＰＵにアクセスできるようになる。
【０１１１】
（モビリティ管理サーバのＲＰＣ応答）
上記では、どのように遠隔プロシージャ・コールがモバイル端末システム１０４からモビリティ管理サーバ１０２に送られて実行されるかを説明した。この型のＲＰＣコールに加え、モビリティ管理サーバ１０２のＲＰＣエンジン２４０’はＲＰＣイベントとＲＰＣ受信応答とをサポートしている。結合関連接続ピア（通常は固定端末システム１１０）の活動の結果として、ＲＰＣメッセージが非同期的に生成される。モビリティ管理サーバ１０２のＲＰＣエンジン２４０’は、ＲＰＣディスパッチャ３９５によって実行されるＲＰＣトランザクションを完了する。完了が成功したからといって、全てのＲＰＣコールが応答を要求するわけではないが、応答を要求する一部のＲＰＣコールにより、ＲＰＣディスパッチャ３９５は適切な応答を作成し、インターネット・モビリティ・プロトコル・エンジン２４４’に知らせ、そして該応答はピアのモバイル端末システム１０４に返される。ＲＰＣコールが失敗したときは、全てのＲＰＣコールが応答を生成する（上記においてＲＰＣ受信応答は例外）。
【０１１２】
ＲＰＣイベントは、結合関連接続（通常は固定端末システム１１０）によるネットワーク１０８の活動の結果として発信される。本好ましい実施形態では、こうしたＲＰＣイベントメッセージはモビリティ管理サーバ１０２によってプロキシされ、モバイル端末システム１０４へ送られる。本好ましい実施形態のモビリティ管理サーバ１０２は、以下のＲＰＣイベントコールをサポートする。
【０１１３】
・切断イベント（結合特定接続ピア（通常は固定端末システム１１０）がトランスポート・レベルで切断要求を出した場合に生起する。該要求はモバイル端末システム１０４に代わってプロキシ・サーバ２２４に受信され、プロキシ・サーバ２２４は切断イベントをモバイル端末システムに送る）
・ストリーム受信イベント（結合特定接続ピア（通常は固定端末システム１１０）がストリームデータをモバイル端末システム１０４へ送る際に生起。プロキシ・サーバ２２４はモバイル端末システム１０４に代わって該データを受け取り、受信応答（Ｒｅｃｅｉｖｅ Ｒｅｓｐｏｎｓｅ）として該データをモバイル端末システムに送る）
・データグラム受信イベント（結合特定ポータル（ａｓｓｏｃｉａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｐｏｒｔａｌ）のいずれかが、ネットワーク・ピア（通常は固定端末システム１１０）から送られ、モビリティ管理サーバ１０２を経由してモバイル端末システム１０４へ送られることになっている、データグラムを受け取る際に生起する。プロキシ・サーバ２２４はモバイル端末システム１０４に代わって該データグラムを受け入れ、データグラム受信イベントという形で該データグラムをモバイル端末システム１０４へ転送する）
・接続イベント（結合特定リスニングポータル（ａｓｓｏｃｉａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｌｉｓｔｅｎｉｎｇ ｐｏｒｔａｌ）が、トランスポート層とモバイル端末システム１０４との終端間接続を確立しようとする際、該結合特定リスニングポータルがトランスポート層接続要求（通常は固定端末システム１１０から）を受信するときに生起する。プロキシ・サーバ２２４はモバイル端末システムに代わって接続要求を受け入れ、接続イベントＲＰＣコールを生成してモバイル端末システムに送る）
図９は、ＲＰＣエンジン２４０’が、いかにしてプロキシ・サーバによって生成されたＲＰＣコールを扱うかということを示している。優先度の高いアドレスと接続オブジェクトに対し、ＲＰＣエンジン２４０’は、直ちに送信要求をインターネット・モビリティ・プロトコル・エンジン２４４’に向けてディスパッチする。該送信要求によって、ＲＰＣメッセージがピアのモバイル端末システム１０４に転送される。優先度の低いオブジェクトに対しては、インターネット・モビリティ・プロトコル・エンジン２４４の送信要求が適切な優先キュー５１０’に通知される。結合の実行が予定されていない場合、スケジュール要求もグローバルキュー３５８’に通知される。インターネット・モビリティ・プロトコルの送信要求は、最終的に、図５および８を参照して既に説明したディスパッチ・キューの処理の際に実行される。
【０１１４】
（インターネット・モビリティ・プロトコルの例）
本発明のインターネット・モビリティ・プロトコルは、メッセージ指向で接続ベースのプロトコルであり、配信保証、（再）オーダ検出（（ｒｅ）ｏｒｄｅｒ ｄｅｔｅｃｔｉｏｎ）、ロス回復が可能である。さらに、他の従来型接続指向プロトコル（即ちＴＣＰ）とは違い、複数の別のデータストリームを単一のチャネルにまとめることが可能になっており、保証されたデータ、信頼性の低いデータ、そして新規のメッセージ指向で信頼性の高いデータを、単一の仮想チャネルによって同時にネットワークをトラバースさせることができる。この新たなメッセージ指向のサービスのレベルによって、インターネット・モビリティ・プロトコルのピアが所定のプログラムデータユニットを確認したときに、リクエスト部に通知が行われることになる。
【０１１５】
本発明のインターネット・モビリティ・プロトコルは、既存のネットワーク・トポロジや技術にオーバーレイできるように設計されている。下層のネットワークアーキテクチャに左右されないので、該インターネット・モビリティ・プロトコルは汎用性を有する。パケット化されたデータが二つのピアの間を行き来できさえすれば、インターネット・モビリティ・プロトコルの使用が可能である。ノードそれぞれにおけるネットワークの現在地点（ＰＯＰ）あるいはネットワーク・インフラは、物理的境界、特定のポリシー、あるいは帯域幅の制限がある場合を除き、データの流れに影響を与えることなく変更可能である。
【０１１６】
インターネット・モビリティ・プロトコルは上層の助けを借りて様々なソースからのデータを融合し、下層のデータグラム機能を利用して該データを行き来させる。独立したデータユニットがそれぞれ上層から来ると、インターネット・モビリティ・プロトコルは該データユニットを単一のストリームとして、その後伝送する。該データユニットは次に既存のネットワークを通じてピアに送られ、受信時に、上層の助力によって上記ストリームが非多重化されて、元の独立した複数のデータユニットに戻る。これにより、伝送時にはその都度最大限のネットワークフレームが生成されて、帯域幅の利用を最適化することができる。さらに、上記により、帯域幅を最大限利用できるようにチャネルを調整することができるという効果を奏するとともに、全てのセッションレベルの接続に適用可能なパラメータを持たせることが可能となる。
【０１１７】
あるチャネルが不十分であるといった稀なケースでも、インターネット・モビリティ・プロトコルはピア間に複数のチャネルを確立することができる。これにより、データの優先順位付けや、（下層のネットワークがサポートしていれば）サービス品質の保証も可能になる。
【０１１８】
さらに、インターネット・モビリティ・プロトコルは、動的に選択可能で保証されたレベルのサービス、あるいは信頼性の低いレベルのサービスに対しても考慮されている。例えば、伝送されるプロトコル・データ・ユニットをそれぞれ、有効期間（ｖａｌｉｄｉｔｙ ｔｉｍｅ ｐｅｒｉｏｄ）か再伝送試行回数、もしくはその両方で制限して待機させることができる。インターネット・モビリティ・プロトコルは、どちらかの閾値に達するとデータユニットを有効期限切れとし、その後の伝送の試行から排除する。
【０１１９】
インターネット・モビリティ・プロトコルの、付加プロトコルとしてのオーバーヘッドは、可変長ヘッダの採用により最小限に抑えられている。該ヘッダのサイズはフレームの種類や任意フィールド（ｏｐｔｉｏｎａｌ ｆｉｅｌｄ）によって決定される。該任意フィールドは、ある特定のオーダにおいて追加されて、受信側による解析を容易にし、その存在はヘッダ・フラグ・フィールド（ｈｅａｄｅｒ ｆｌａｇ ｆｉｅｌｄ）のビットによって示される。ピアによる通信に必要な他の制御および設定情報は、全てバンド内制御チャネルを通過することができる。送信されるべき制御情報は全て、任意のアプリケーションレベルのプロトコル・データ・ユニットの前のフレームに加えられる。受信側では制御情報を処理して、次にペイロードの残りを上層に送る。
【０１２０】
エラー発生の確率が比較的高い、信頼性の低いネットワークにおける稼動が想定されているため、インターネット・モビリティ・プロトコルでは、データの完全性を保証し、ネットワークのパフォーマンスを最高まで引き出すべく、数々の技術が使われている。データの完全性を保証するため、フレッチャー・チェックサム・アルゴリズム（Ｆｌｅｔｃｈｅｒ ｃｈｅｃｋｓｕｍ ａｌｇｏｒｉｔｈｍ）が、誤ったフレームの検出用に使われている。このアルゴリズムは効率性と高い検出能力を買われて採用され、ビットエラーのみならずビットの並び替えも検出できる。ただし、上記アルゴリズムの代わりに他のチェックサム・アルゴリズムを採用してもよい。
【０１２１】
シーケンス番号は、オーダされたデータの配信を保証するために使われるが、インターネット・モビリティ・プロトコルにおけるシーケンス番号は、ＴＣＰの場合のようにデータのそれぞれのバイトを表わしているわけではない。一例としては、上記シーケンス番号は、最大６５５３５バイト（インターネット・モビリティ・プロトコル・ヘッダを含む）までの、データのフレームを表現している。該シーケンス番号は３２ビットなど適当な長さのものであって、制限された期間内での高い帯域幅のリンクにおいてラップアラウンドを生じさせないようにしている。
【０１２２】
上記の能力にデータの有効期限切れ機能を組み合わせたとき、再伝送（再試行）されたフレームが含んでいるデータ量が、送信側で生成された前バージョンよりも少ないことがある。フレームＩＤを設定して最新のバージョンのフレームが検知することも可能だが、本好ましい実施形態ではデータが追加されることは絶対に無く、削除されたそれぞれの要素がプロトコル・データ・ユニット全体であるため、上記の手法はシーケンス保証には必ずしも必要でない。一例として、インターネット・モビリティ・プロトコルは受信したある特定のフレームを、該フレームの異なったバージョンのものがいくら伝送されてきても、最初の一回目のみ処理する。新規のユーザ・ペイロードを運搬する、生成されたフレームそれぞれには、固有のシーケンス番号が割り振られる。
【０１２３】
スライディング・ウィンドウ技術の採用によってパフォーマンスが向上し、ピアにデータ受信の確認応答を要求する前に、複数のフレームを保留にできる（伝送できる）。適切なタイミングでのデータ配信を保証するため、肯定応答とタイマーベースの再伝送スキームとが採用されている。さらにチャネルの利用を最適化すべく、選択的な確認応答メカニズムが採用され、ネットワーク接続のロスが多い時間帯もしくは混雑した時間帯における、失われたフレームの迅速な再伝送と、素早い回復とが達成される。一例において、この選択的な確認応答メカニズムは、ヘッダに含まれる付加的なビットフィールドとして表わされる。
【０１２４】
輻輳回避アルゴリズムは、プロトコルをフレームの迅速な再伝送からバックオフさせるためにも用いられている。例えば、ラウンドトリップタイムは、再伝送無しで成功裏にピア間を伝送されたフレームそれぞれに対して計測することが可能である。この時間値は平均されて、再伝送タイムアウト値（ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｏｕｔ ｖａｌｕｅ）の基準となる。フレームが送られるごとに、それぞれのフレームに対してタイムアウトが設定される。あるフレームが実際に伝送されたにもかかわらず、該フレームに関する確認応答が受信されない場合、該フレームは再伝送される。このときタイムアウト値は上昇し、次の再伝送時間の基準となる。この再伝送タイムアウトには上限値および下限値が設定されているので、その値は適切な範囲に収まるようになっている。
【０１２５】
また、インターネット・モビリティ・プロトコルでは、送信路と受信路とが別に扱われている。この手法は、本質的に非対称のチャネルにおいて特に有用である。ヒステリシスに基づいて、インターネット・モビリティ・プロトコルは自動的に、フレームサイズ（フラグメント化閾値）、保留中のフレーム数、再伝送時間、遅延承認時間などのパラメータを調整して、ネットワークを通じて送られる複製データの量を減少させる。
【０１２６】
インターネット・モビリティ・プロトコルによって、ノードが様々なネットワークの違った接続ポイントに移動することが可能になるため、下層のネットワークの特性（例えばフレームサイズ）が途中で変わってしまうことがあるが、この移動の結果、あるネットワークで伝送待ちだったフレームが、モバイル装置が現在接続している新しい媒体にはフィットしないこともありうる。このことに、フラグメント化が全てのネットワーク・インフラでサポートされているわけではないことを合わせて考慮して、フラグメント化はインターネット・モビリティ・プロトコルのレベルにおいて扱われる。それぞれのフレームが伝送される前に、インターネット・モビリティ・プロトコルにより、フレームが現時点でのフラグメント化閾値を越えているか否かが判断される。ちなみに、パフォーマンス向上の見地から、この値は現時点での最大伝送ユニットよりも少なくてよい（大きいフレームよりも小さいフレームの方が最終目的地まで到達する可能性が高いため）。プロトコルのオーバーヘッドを増加させることと、再伝送回数の増加とのトレードオフは、インターネット・モビリティ・プロトコルによって吟味され、全体的に再伝送を減少させるため、フレームサイズが減少させられることもある。あるフレームがフィットしていれば、該フレームは分割されずに伝送される。していなければ、該フレームはその接続で許容される最大のサイズにまで分割される。フレームが再伝送される場合、該フレームは再評価を受け、最大伝送ユニットが減少していれば、再度フラグメント化される（あるいは、もし最大伝送ユニットが増加していれば、該フレームはフラグメント化されない一個のフレームとして再送信されることもありうる）。
【０１２７】
プロトコルそのものは直交に設計されており、どちらの側からでもピアとの接続を確立、切断することができるようになっている。しかし、ある場合においては、実行される場所によってプロトコル・エンジンにおける些少な動作上の差異がいくつか存在し、特定の休止検出や接続寿命タイムアウトは片方の側からしか実行できないこともある。運営上必要な操作を可能にするため、モビリティ管理サーバ１０２上で動作するインターネット・モビリティ・プロトコル・エンジンは、休止期間の状況を把握している。モバイル端末システム１０４からの作業が何もないまま一定の期間が経過した場合、モビリティ管理サーバ１０２はセッションを終了させることができる。また、管理者が、ある特定の接続を確立するのに要する総所要時間を制限する、あるいは日時によってアクセスを拒否することが必要なときがあるが、この場合も、一例としてこうしたポリシータイマーはモビリティ管理サーバ１０２側からのみ操作できるようにしてもよい。
【０１２８】
一例として、インターネット・モビリティ・プロトコルを提供するソフトウェアは、ウィンドウズ（登録商標）ＮＴ、９ｘ、ＣＥ環境で、プラットフォームに合わせた修正を必要とすることなくコンパイルされ、動作できるものである。これを実現するために、インターネット・モビリティ・プロトコルでは、インターネット・モビリティ・プロトコル・フレームの送受信に、ネットワーク抽象層（ｎｅｔｗｏｒｋ ａｂｓｔｒａｃｔｉｏｎ ｌａｙｅｒ； ＮＡＬ）のサービスが採用されている。メモリ管理、キューおよびリスト管理、イベントロギング、警報システム、電力管理、セキュリティなどの他の標準的なユーティリティ機能も使われる。いくつかのランタイム・パラメータについては、エンジンがモバイル端末システム１０４に備えられているか、あるいはモビリティ管理サーバ１０２側に備えられているかによって変更される。これについて、数例を以下に示す。
【０１２９】
・特定のタイムアウトは、モビリティ管理サーバ１０２からのみ呼び出し可能
・フレームの方向は、エコー検出用のフレームヘッダそれぞれにて示される
・モバイル端末システム１０４の設定により、着信接続（ｉｎｂｏｕｎｄ ｃｏｎｎｅｃｔｉｏｎ）の拒否が可能
・警報はモビリティ管理サーバ１０２にのみ通知される
・電力管理はモバイル端末システム１０４ではイネーブルにされるが、モビリティ管理サーバ１０２では必ずしも必要でない
インターネット・モビリティ・プロトコルのインターフェイスは、Ｃコーラブルでプラットフォームに依存しない標準的なＡＰＩ機能をほんの少数有し、作業（上記の標準的なユーティリティ機能以外）を予定する、ＯＳ特化型の単一の機能を必要とする構成でもよい。ローカルクライアントとの通信は、定義された作業オブジェクト（作業要求）の利用によって可能になる。作業要素それぞれの完了通知は、作業オブジェクトの一部として特定されたオプションの完了コールバックルーチンを通じて、要求エンティティに通知を行うことによって、効果的に達成することができる。
【０１３０】
インターネット・モビリティ・プロトコル・エンジン自体はキューベースのものである。ローカルクライアントからの作業要素は、ＦＩＦＯオーダに従ってグローバル作業キューに追加されるが、これは、ローカルクライアントが、「ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔｗｏｒｋ（）」などの標準的なインターネット・モビリティ・プロトコル機能を呼び出すことによってなされる。続いて、インターネット・モビリティ・プロトコル内のスケジューリング機能が該作業を除去し、適切な機能に対してディスパッチする。待機機能とスケジューリング機能を組み合わせることでＯＳのアーキテクチャ間の差を感じさせなくするので、プロトコル・エンジンが、スレッドベースのシステム（例えばウィンドウズ（登録商標）ＮＴ）や同期式のシステム（例えばマイクロソフト・ウィンドウズ（登録商標）９ｘやウィンドウズ（登録商標）ＣＥ）で動作することが可能になる。優先度に関するスキームを待機機能の上にオーバーレイすることができるので、（下の層がサポートしていれば）サービス品質を保証することができる。
【０１３１】
ネットワークの視点から見ると、インターネット・モビリティ・プロトコルは、データのコピーや移動を減らすべく、分散−集結技術（ｓｃａｔｔｅｒ−ｇａｔｈｅｒ ｔｅｃｈｎｉｑｕｅｓ）を利用している。伝送はそれぞれフラグメントのリストとしてＮＡＬに送られ、ネットワーク層のトランスポートによって融合される。トランスポート・プロトコル自体が分散−集結技術をサポートしている場合、フラグメントリストは上記トランスポートを通じて転送され、媒体アクセス層ドライバあるいはハードウェアによってアセンブルされる。さらに、上記技術を拡張して、プロトコルスタックのどのレベルにおいても、いかなるプロトコルラッパーの挿入や消去を行うことも可能である。フレームの受信は、ＮＡＬ層により、ＮＡＬ登録処理（ＮＡＬ ｒｅｇｉｓｔｒａｔｉｏｎ ｐｒｏｃｅｓｓ）時に指定された特定の入口点においてインターネット・モビリティ・プロトコルをコールバックすることで通知される。
【０１３２】
（インターネット・モビリティ・プロトコル・エンジンのエントリポイントの例）
例示の実施形態におけるインターネット・モビリティ・プロトコルは、該プロトコルのスタートアップおよびシャットダウン行動を管理する、４つの共通エントリポイントを有している。以下に示されるのがこれらのプロシージャである。
【０１３３】
１．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＣｒｅａｔｅ（）
２．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｕｎ（）
３．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＨａｌｔ（）
４．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＵｎｌｏａｄ（）
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＣｒｅａｔｅ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＣｒｅａｔｅ（）機能は、ブートサブシステムによって呼び出され、インターネット・モビリティ・プロトコルを初期化する。この第一フェイズ中に、作業の処理を開始するのに必要なリソース全てが所得され、初期化されなければならない。該フェイズの終了時、エンジンは、システムの他の層からの作業をすぐに受け入れ可能な状態である必要がある。このとき、インターネット・モビリティ・プロトコルはグローバル設定テーブルを初期化するが、このために、インターネット・モビリティ・プロトコルは、設定マネージャ２２８のサービスを利用して該テーブルを設定（ｐｏｐｕｌａｔｅ）する。
【０１３４】
次に、インターネット・モビリティ・プロトコルは、サスペンドおよびレジューム通知機能をＡＰＭハンドラに登録する。一例ではこれらの機能はモバイル端末システム１０４の側からのみ呼び出し可能であるが、他の例として、動作中にモビリティ管理サーバ１０２がサスペンドできるようにするのが望ましいこともある。続いて、グローバル作業キュー、グローバルＮＡＬポータルリストなど他の作業用記憶域がメモリプールから割り当てられる。
【０１３５】
必要なランタイムメモリの最大量を制限し、インターネット・モビリティ・プロトコルのハンドルの固有性を保証するため、インターネット・モビリティ・プロトコルは、ハンドル生成用の２段配列構成（２−ｔｉｅｒ ａｒｒａｙ ｓｃｈｅｍｅ）を採用している。グローバル接続配列テーブルのサイズは、システムが設定する同時接続の最大数によって決まり、この時点で割り当てられる。全てのグローバル記憶域が割り当てられ、初期化されると、グローバル・インターネット・モビリティ・プロトコルの状態が、＿ＳＴＡＴＥ＿ＩＮＩＴＩＡＬＩＺＥ＿となる。
【０１３６】
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｕｎ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｕｎ（）機能は、全てのサブシステムが初期化された後で呼び出され、インターネット・モビリティ・プロトコルのサブシステムに、待機中の作業をどれでも処理し始めてよいことを通知する。これが、一般的な動作状況におけるインターネット・モビリティ・プロトコル・エンジンの通常の状態である。該エンジンを動作状態にする前に、いくつかの第二パス初期化ステップがこの時点で実行される。
【０１３７】
インターネット・モビリティ・プロトコルは、ネットワーク通信が、任意のインターフェイスのどれを通じてでも実行されるようにする。初期化ステップの間に、インターネット・モビリティ・プロトコル−ＮＡＬ間のインターフェイス用の記憶域が割り当てられるので、インターネット・モビリティ・プロトコルはグローバルポータルリスト中を横断して、ＮＡＬの全てのリスナをスタートさせることができる。一例として、この動作は２つのステップを含んだ以下の処理のようになる。
【０１３８】
・インターネット・モビリティ・プロトコルは、ＮＡＬ層に、初期化中に供給される設定に基づいたポータルを結びつけて（ｂｉｎｄ）オープンし、
・インターネット・モビリティ・プロトコルは、次に、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲＣＶＦＲＯＭＣＢコールバックを登録して、受信したフレームの処理を始める準備ができたことを、ＮＡＬ層に通知する。
【０１３９】
・引き続き、ローカル持続識別子（ｌｏｃａｌ ｐｅｒｓｉｓｔｅｎｔ ｉｄｅｎｔｉｆｉｅｒ； ＰＩＤ）が初期化される。グローバル・インターネット・モビリティ・プロトコルの状態は、＿ＳＴＡＴＥ＿ＲＵＮ＿に変わる。
【０１４０】
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＨａｌｔ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＨａｌｔ（）機能は、システムがシャットダウンしたことをエンジンに警告するために呼びだされる。動作中に得られたリソースは、この機能から戻る前に全て開放される。インターネット・モビリティ・プロトコルの全てのセッションは、管理用に設定された理由コードによって異常終了する。エンジンが＿ＳＴＡＴＥ＿ＨＡＬＴＥＤ＿状態になると、それ以降、他の層からの作業は受け付けられず、他の層に通知されることも無い。
【０１４１】
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＵｎｌｏａｄ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＵｎｌｏａｄ（）機能は、シャットダウン処理の第二フェイズである。これが、復帰以前に、割り当てられたシステムリソースをエンジンが解放する最後の機会となる。エンジンがこの機能から戻ると、システム自体が停止するので、これ以上の作業は実行されない。
【０１４２】
（インターネット・モビリティ・プロトコル・ハンドルの例）
少なくともいくつかの例においては、メモリ（インターネット・モビリティ・プロトコル状態情報を記憶）のアドレスを、インターネット・モビリティ・プロトコルの接続を記述するトークンとして用いるだけでは不十分である。これは主に、短い期間のうちに、ある接続が終了して別の新しい接続が開始される可能性のためである。メモリアロケータが、別の接続に前のものと同じアドレスを再配分してしまう可能性が高く、この値が前の接続と新しい接続との両方を示すことになってしまう。元々のピアが、（電源が切られていたり、サスペンドしていたり、圏外にあったりなどで）セッションの終了を認識しなかった場合、前のセッションのフレームを新しいセッションの方に送ってしまうこともあり得る。ＴＣＰの場合はこれが起こり、ピアのＩＰアドレスが同じ場合、新しいセッションを生成するためにリセットが行われる。これを避けるため、インターネット・モビリティ・プロトコルは製造ハンドル（ｍａｎｕｆａｃｔｕｒｅｄ ｈａｎｄｌｅ）を採用している。該ハンドルは２列のインデックスによって形成され、独自性を保つため一回限りのものである。テーブルは以下のようなレイアウトとなっている。
【０１４３】
テーブル１：接続オブジェクトの配列を指すポインタの配列
テーブル２：インターネット・モビリティ・プロトコル制御ブロックを指す、実ポインタを含む接続オブジェクトの配列
この技術により、初期化期間に割り当てられるメモリの量が最小化される。テーブル１は、スタートアップの際にサイズが決められ、割り当てがなされる。これにより、モバイル端末システム１０４の側では、少量のメモリの割り当てが可能になる（モビリティ管理サーバ１０２側でテーブル１が割り当てを要求するメモリは、サーバが多くの接続を有しているため少し大きなものになる）。
【０１４４】
テーブル１は必要時に設定（ｐｏｐｕｌａｔｅ）される。接続要求が出されると、インターネット・モビリティ・プロトコルは、テーブル１内でテーブル２への有効なポインタを探す。エントリポイントが見つからない場合、インターネット・モビリティ・プロトコルは、新規のテーブル２に２５６個の接続オブジェクトを割り当て、テーブル２へのポインタを、テーブル１の適切なスロットに記録する。次に、プロトコル・エンジンはテーブル２を初期化し、新しく生成されたテーブルからの接続オブジェクトを割り当てて、製造ハンドルへ戻る。他のセッションが要求された場合、インターネット・モビリティ・プロトコルは再度テーブル１中をサーチして、テーブル２への有効なポインタを見つけ、該セッション用の次の接続オブジェクトを割り当てる。この作業は、以下の二つの状態のうちのどちらかになるまで続けられる。
【０１４５】
・テーブル２から全ての接続オブジェクトが無くなった場合、新たにテーブル２が割り当てられ、初期化されて、該テーブル２を示すポインタが、テーブル１の次に利用可能なスロットに設定される。
【０１４６】
・全ての接続オブジェクトが特定のテーブル２のインスタンスに開放され、全ての要素がある特定の期間使用されなかった場合、テーブル２の上記インスタンスにおける記憶域が開放されてメモリプールに戻され、テーブル１の関連しているポインタはゼロにされて、次の接続要求が開始された際、該入口が使用可能であることを示すようになる（テーブル２の他のインスタンスで、利用可能な接続オブジェクトがない場合に限る）。
【０１４７】
二つのグローバルカウンタは、割り当てられる接続の総数を制限できるようにするために維持されている。片方のグローバルカウンタは現時点でアクティブな接続を数え、もう片方のカウンタは、割り当てられていない接続オブジェクトの数を把握する。さらに、第二のカウンタは、任意に設定された制限まで生成可能な接続オブジェクトの総数の管理も行う。新規のテーブル２が割り当てられると、該カウンタは、該新規のテーブルが表現するオブジェクトの数を把握するため、下方に調整される。反対側では、インターネット・モビリティ・プロトコルがテーブル２のインスタンスをメモリプールに開放するときに、カウンタは、開放された接続オブジェクトの数を合わせて上方修正される。
【０１４８】
（ワークフローの例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔＷｏｒｋ（）機能によって、作業はローカルクライアントから要求される。該作業が検査（ｖａｌｉｄａｔｅ）され、グローバル作業キューに加えられると、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＱｕｅｕｅＥｌｉｇｉｂｌｅ（）機能が呼び出される。スレッド化された環境であれば、インターネット・モビリティ・プロトコルのワーカースレッドに信号が送られ（適合マークがつけられ）、制御は直ちに呼び出しエンティティへと戻る。同期的な環境であれば、グローバル作業キューが直ちに実行されて、要求された作業はいかなるものであっても処理される。どちらの場合でも、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＰｒｏｃｅｓｓＷｏｒｋ（）機能が実行されることになる。これが作業処理のためのメインディスパッチ機能である。
【０１４９】
例示の実施形態では、グローバルキューからの作業をディスパッチできるのが一回に一つのスレッドのみの場合があり、再入を防ぐべくグローバルセマフォが用いられてもよい。プライベートなインターネット・モビリティ・プロトコルの作業では、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔＷｏｒｋ（）機能を使用せず、直接グローバル作業キューに作業を送ることができる。
【０１５０】
ＳＥＮＤタイプの作業オブジェクトでは、特殊な場合が想定される。信頼性の低いデータグラムのセマンティクスが保たれていることを保証するため、ＳＥＮＤタイプの作業オブジェクトをそれぞれ、有効期限あるいは再試行カウントを伴って待機させることができる。作業は該有効期限に基づいて寿命を算定される。このような所定のタイムアウトが生じた場合、作業オブジェクトは接続特定キューから除かれ、エラー状態で完了する。ＳＥＮＤオブジェクトが既にデータパスに融合されている場合、プロトコルは、再試行カウントが設定されたどのＳＥＮＤオブジェクトでも、除去を許可する。再試行カウントを超過した場合、該オブジェクトは、特定のフレームを形成する要素のリストから外され、適当なエラー状態を示しつつリクエスタへ戻される。
【０１５１】
（接続スタートアップの例）
インターネット・モビリティ・プロトコルは、ピア間の接続を確立する非常に効率的なメカニズムを有している。接続の確認は、ピア間で最低３フレームをやり取りすることでなされる。開始側は、そのピアにＩＭＰ ＳＹＮＣフレームを送って接続確立が要求されていることを警告する。受け入れ側は、ＩＭＰ ＥＳＴＡＢＬＩＳＨフレームを送って接続受け入れを確認するか、あるいはＩＭＰ ＡＢＯＲＴフレームを送ることで、接続要求が拒否されたことをピアに警告する。ユーザに接続拒否の理由を理解しやすくするため、理由および状態コードが、ＩＭＰ ＡＢＯＲＴフレームに含まれる形で送られる。接続が許可されると、確認応答フレーム（プロトコル・データ・ユニットおよび制御データがふくまれていることもある）が送られて、受け入れ側に転送され、確立フレームの受信が確認される。
【０１５２】
ネットワークのトラフィックを最小化するため、プロトコルは、ユーザおよび制御データを、接続スタートアップ時の最初のハンドシェーク機構に含まれるようにすることができる。この構成は、セキュリティが保障されていない環境や、同じデータパスでセキュリティ用の認証が二重に行われたり、暗号化処理が同じデータパスで行われたりすることによるパフォーマンスの低下を避けるよう、インターネット・モビリティ・プロトコルが調整されているというような、セキュリティが下層で扱われている環境において使用される。
【０１５３】
（データ転送の例）
インターネット・モビリティ・プロトコルは、フレームがネットワークに配信されたことを、ＮＡＬからの通知によって検知する。インターネット・モビリティ・プロトコルは、当該ネットワークリンクが絶えずフロー制御されているか否かを上記メトリクスによって判定するので、当初の要求が完了されるまで同じフレームを再伝送することはない。しかし、ネットワークドライバによっては、フレームの伝送について、誤って、該フレームをネットワークに送る前に配信を示唆してしまうものもある。セマフォの利用により、インターネット・モビリティ・プロトコル層はこれを検知し、当初の要求についてＮＡＬが返答するまでは、他のデータグラムを送信しない。
【０１５４】
フレームがインターネット・モビリティ・プロトコルに受信されると、該フレームは迅速に検査されて、適切な接続キューに加えられる。該フレームが、インターネット・モビリティ・プロトコルがその最終目的地を識別するのに足る情報を有していない場合、該フレームは、それを受信したインターネット・モビリティ・プロトコル・ソケット・キューに加えられ、該ソケット・キューは、続く処理のためにグローバル作業キューに加えられる。この最初の逆多重化により、受信した作業は、処理オーバーヘッドが限定された状態で、迅速に拡散させられる。
【０１５５】
（黙認（ａｃｑｕｉｅｓｃｉｎｇ）の例）
再伝送時のネットワーク帯域幅およびモビリティ管理サーバ１０２の処理に要する電力の最小化のため、プロトコルは、モビリティ管理サーバ１０２が接続を「黙認」できるようにする。ユーザによる設定が可能な期間の後、モビリティ管理サーバ１０２は、対応するモバイル端末システム１０４から通知が無ければ、特定の接続へのフレームの再伝送を停止する。この時、モビリティ管理サーバ１０２は、モバイル端末システム１０４が通信できない状態（圏外、サスペンドなど）であると仮定し、接続を休止状態にする。該接続へのこの後の作業は全て、後の配信のために記憶される。該接続は、以下の状況のいずれかが満たされない限り、同じ状態にとどまり続ける。
【０１５６】
・モビリティ管理サーバ１０２がモバイル端末システム１０４からフレームを受信し、接続を本来の状態に戻す、
・接続寿命タイムアウトの期限が切れる、
・休止タイムアウトの期限が切れる、または
・システム管理者によって接続が中止される
モビリティ管理サーバ１０２が、モバイル端末システム１０４からフレームを受信し、中断された所から接続が再開された場合、該接続で待機していた作業は全て転送され、状態が再同期化される。これ以外の場合、再接続がなされると、モバイル端末システム１０４には以前の接続の終了が通知され、モバイル端末システム１０４に送られることを待機していた作業は破棄される。
【０１５７】
（接続および送信要求の例）
図１０Ａ〜１０Ｃは、インターネット・モビリティ・エンジン２４４によって生成される接続および送信要求ロジックを例示する、フローチャートを形成している。ＲＰＣエンジン２４０からの命令を受信すると、インターネット・モビリティ・プロトコル・エンジン２４４は、該命令が「接続」要求かどうかを判定する（判定ブロック６０２）。該命令が「接続」要求であれば、エンジン２４４は、接続リソースの割り当てが可能かどうかを判断する（判定ブロック６０３）。十分な接続リソースが割り当てられない場合（判定ブロック６０３で「ノー」である場合）、エンジン２４４はエラーを宣言して（ブロック６０３ａ）応答する。接続リソースの割り当てが可能であれば、エンジン２４４は状態設定処理を行って、接続要求の処理に備える（ブロック６０３ｂ）。
【０１５８】
接続その他の要求に対し、エンジン２４４は該接続あるいは送信要求を待機させ、呼び出しを実行しているアプリケーションに応答する前に、グローバルイベントに通知する（ブロック６０４）。
【０１５９】
インターネット・モビリティ・プロトコルのグローバル要求キューからの接続あるいは送信要求をディスパッチするために、エンジン２４４はまず、保留されている作業の有無を判定する（判定ブロック６０５）。保留されている作業が無ければ（判定ブロック６０５で「ノー」である場合）、エンジン２４４は、図１０Ｃのブロック６２５に移って、接続用の作業を待機させるため、アプリケーションからの応答を待つ（ブロック６０５Ａ）。保留されている作業があれば（判定ブロック６０５で「イエス」の場合）、エンジン２４４は現在の状態が確立されているか否かを判定する（ブロック６０６）。状態が確立されている場合（判定ブロック６０６で「イエス」の場合）、エンジン２４４は状態確立への移行のためのステップを飛ばして、図１０Ｂの判定ブロック６１５に移る（ブロック６０６ａ）。状態が確立されていない場合、エンジン２４４は状態確立のための一連のステップを実行する必要がある（判定ブロック６０６で「ノー」である場合）。
【０１６０】
状態確立に移行するために、エンジン２４４はまず、そのピアのアドレスが既知かどうかを判定する（判定ブロック６０７）。既知でなければ、エンジン２４４は作業をさらに待機させ、図１０Ｃのブロック６２５に移って、ピアのアドレスが来るのを待つ（ブロック６０７ａ）。ピアのアドレスが既知の場合（判定ブロック６０７で「イエス」の場合）、エンジン２４４は次に、必要なセキュリティコンテキストが取得されているかどうかを判定する（判定ブロック６０８）。取得されていない場合、エンジン２４４は作業をさらに待機させ、図１０Ｃのブロック６２５に移って、セキュリティコンテキストが来るのを待つ必要がある（ブロック６０７ａ）。セキュリティコンテキストが既に取得されている場合（判定ブロック６０８で「イエス」の場合）、エンジン２４４は「状態保留」状態を宣言して（ブロック６０８ｂ）、インターネット・モビリティ・プロトコルの同期フレームを送信し（ブロック６０９）、再伝送タイマーをスタートさせる（ブロック６１０）。エンジン２４４は、対応する確立フレームが受信されたかどうかを判定する（ブロック６１１）。受信されていない場合（判定ブロック６１１で「ノー」の場合）、エンジン２４４は、再伝送時間の期限が来たかどうかを判定する（判定ブロック６１２）。再伝送時間の期限が来ていない場合（判定ブロック６１２で「ノー」の場合）、エンジン２４４は待機し、続いてステップ６２５に移ってもよい（ブロック６１３）。最終的に、確立フレームが受信されず（ブロック６１１で判定）、再伝送時間の期限が全て切れた（判定ブロック６１４）場合、接続は中止されてもよい（ブロック６１４ａ）。結局確立フレームが受信された場合（判定ブロック６１１で「イエス」の場合）、エンジン２４４は「状態確立」状態を宣言する（ブロック６１１ａ）。
【０１６１】
状態確立がなされると、エンジン２４４は新規の接続の認証がなされているかどうかを判定する（判定ブロック６１５）。なされていない場合、エンジン２４４は待機し、ステップ６２５へと移ってよい（ブロック６１６）。接続の認証がなされている場合（判定ブロック６１５で「イエス」の場合）、エンジン２４４は認証が成功したかどうかを判定する（判定ブロック６１７）。成功していない場合（判定ブロック６１７で「ノー」の場合）接続は中止される（ブロック６１４ａ）。成功している場合、エンジン２４４は、ピア伝送ウィンドウがフルになっているかどうかを判定する（判定ブロック６１８）。フルになっていれば（判定ブロック６１８で「イエス」の場合）、エンジン２４４は確認応答を待ち、ステップ６２５に進む（判定ブロック６１９）。ウィンドウがフルになっていなければ（判定ブロック６１８で「ノー」の場合）、エンジン２４４はインターネット・モビリティ・プロトコル・データフレームを生成し（ブロック６２０）、送信する（ブロック６２１）。次に、エンジン２４４は再伝送タイマーがスタートしているかどうかを判定する（判定ブロック６２２）。していない場合、エンジン２４４は再伝送タイマーをスタートさせる（ブロック６２３）。エンジン２４４は、それ以上送信するデータが無くなるまで（判定ブロック６２４で判断される）、ブロック６１８〜６２３を繰り返す。そして、エンジン２４４はスリープモードに入ってさらに作業が来るのを待ち、グローバルディスパッチャに戻る（ブロック６２５）。
【０１６２】
（中止の例）
図１１は、接続を中止するためにインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示したフローチャートである。「接続中止」要求を受けて（ブロック６２６）、該エンジンは該要求をグローバル作業キューに加え、呼び出しを行っているアプリケーションに返答する（ブロック６２６ａ）。中止要求は最終的に、実行のため、インターネット・モビリティ・プロトコルの処理グローバル作業キューからディスパッチされる（ブロック６２７）。エンジン２４４は中止要求を調べて、該要求が緊急のものであるか、あるいは余裕のあるものであるかを判定する（判定ブロック６２８）。緊急のものの場合（判定ブロック６２８で「中止」の場合）、エンジン２４４は直ちに接続を中止する（ブロック６２９）。余裕があるものであれば（判定ブロック６２８で「余裕」の場合）、エンジン２４４は「状態クローズ（ｓｔａｔｅ ｃｌｏｓｅ）」状態を宣言し（ブロック６２８ａ）、インターネット・モビリティ・プロトコルの「モーティス（Ｍｏｒｔｉｓ）」フレームを送信し（ブロック６３０）、ピアに接続がクローズされることを示唆する。次に、エンジン２４４は「モーティス」状態を宣言し（ブロック６３０ａ）、再伝送タイマーをスタートさせる（ブロック６３１）。エンジン２４４は、ピアから「ポスト・モーテム（ｐｏｓｔ ｍｏｒｔｅｍ）」フレームが応答されたかどうかを判定する（判定ブロック６３２）。応答されていなければ（判定ブロック６３２で「ノー」の場合）、エンジン２４４は、再伝送タイマーが時間切れになっているか否かを判定する（判定ブロック６３３）。まだ時間切れになっていない場合（判定ブロック６３３で「ノー」の場合）、エンジン２４４は待機し、ステップ６３７へ進む（ブロック６３４）。再伝送タイマーが時間切れになっている場合（判定ブロック６３３で「イエス」の場合）、エンジン２４４は総再伝送時間の期限が切れているかどうかを判定する（判定ブロック６３５）。まだ切れていない場合（判定ブロック６３５で「ノー」の場合）、ブロック６３０に戻り、モーティスフレームを再送する。すでに総再伝送時間の期限が切れている場合（判定ブロック６３５で「イエス」の場合）、エンジン２４４は直ちに接続を中止する（ブロック６３５ａ）。
【０１６３】
「ポスト・モーテム」応答フレームがピアから受信されると（判定ブロック６３２で「イエス」）、エンジン２４４は「ポスト・モーテム」状態を宣言して（ブロック６３２ａ）、接続リソースを開放し（ブロック６３６）、スリープ状態に戻ってさらに作業を待つ（ブロック６３７）。
【０１６４】
（再伝送の例）
図１２は、インターネット・モビリティ・プロトコル・エンジン２４４が実行する「再伝送」イベントロジックの例を示している。再伝送タイマーが時間切れを迎える（ブロック６５０）と、エンジン２４４は、保留中のフレームがあるかどうかを判定する（判定ブロック６５１）。保留中のフレームがなければ（判定ブロック６５１で「ノー」の場合）、エンジン２４４はタイマーを破棄して（ブロック６５２）スリープ状態に戻る（ブロック６６０）。逆に保留中のフレームがあれば（判定ブロック６５１で「イエス」の場合）、エンジン２４４は、再伝送期間全体（ｅｎｔｉｒｅ）が終了したかどうかを判定する（判定ブロック６５３）。まだ終了していなければ（判定ブロック６５３で「ノー」の場合）、処理は時間差のためにスリープ状態に戻る（ブロック６５４）。既に終了していれば（判定ブロック６５３で「イエス」の場合）、エンジン２４４は、総ての（ｔｏｔａｌ）再伝送期間が終了したかどうかを判定する（判定ブロック６５５）。既に終了しており（判定ブロック６５５で「イエス」）、このイベントがモビリティ管理サーバのエンジン２４４’（モバイル端末システムのエンジン２４４に対応）で実行されている場合、休眠状態が宣言される（判定ブロック６５６、ブロック６５６ａ）。同じ状態で、モバイル端末システム１０４において実行されるインターネット・モビリティ・プロトコル・エンジン２４４は、接続を中止する（ブロック６５６ｂ）。
【０１６５】
総ての再伝送期間がまだ終了していない場合（判定ブロック６５５で「ノー」の場合）、エンジン２４４はフレームを再処理して時間切れのデータを除去し（ブロック６５７）、それを再転送し（ブロック６５８）、再転送タイマーをそのまま再始動させる（ブロック６５９）。そして処理は休眠状態に入り（ブロック６６０）、次のイベントを待つ。
【０１６６】
（インターネット・モビリティ・プロトコルのＰＤＵの期限切れの例）
図１２のブロック６５７において、要求を出している上層のインターフェイスが、結合しているピアに送られるプロトコル・データ・ユニット（つまりＳＥＮＤ作業要求）５０６の期限切れに関するタイムアウトあるいは再試行カウントを特定することが可能になる。この機能により、インターネット・モビリティ・プロトコル・エンジン２４４は、信頼性の低いデータのセマンティクス維持、再伝送されたデータからの信頼性の低いデータの除去など、他の機能も果たせるようになる。上層からのＰＤＵ（プロトコル・データ・ユニット）それぞれは、最終的にインターネット・モビリティ・プロトコル・エンジン２４４によってコーリシングされる、それぞれの要素に対する有効期限タイムアウト（ｖａｌｉｄｉｔｙ ｔｉｍｅｏｕｔ）および／または再試行カウントを、特定することができる。有効期限タイムアウトおよび／または再試行カウント（アプリケーションによってはユーザによって特定可能）は、エンジン２４４による再伝送の前に、どのＰＤＵ５０６が、転送されずにフレームから除去されるべきかを決定するために使われる。
【０１６７】
ＰＤＵ５０６に関わる有効期限タイムアウトは、ＰＤＵそれぞれが伝送に際して考慮すべき、相対期間（ｒｅｌａｔｉｖｅ ｔｉｍｅ ｐｅｒｉｏｄ）を特定する。実行依頼の間、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔＷｏｒｋ機能によって有効期限の値（ｅｘｐｉｒｙ ｔｉｍｅｏｕｔ ｖａｌｕｅ）がチェックされる。該値が０で無い場合、時期タイマー（ａｇｅ ｔｉｍｅｒ）は初期化される。次に、要求されたデータは、結合しているピアに送られる他のデータと同じキューに加えられる。あるＰＤＵ５０６が、有効期限パラメータ（ｖａｌｉｄｉｔｙ ｐｅｒｉｏｄ ｐａｒａｍｅｔｅｒ）が特定する期間よりも長くキューにある場合、該キューを処理する次イベントの間に、有効期限の切れた該（全ての）ＰＤＵは除去され、フレームの再伝送時に再伝送されるのではなく、ローカルに「タイムアウトによる失敗（ｔｉｍｅｏｕｔ ｆａｉｌｕｒｅ）」のステータスコードをもって完了する。このアルゴリズムにより、ピアへの伝送のために待機している信頼性の低いデータが古くなる（ｇｒｏｗ ｓｔａｌｅ）こと、および／または際限なくシステムリソースを消費することを防ぐ。
【０１６８】
図１２Ａの例において、少なくとも３つの独立したＰＤＵ５０６が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン２４４でキューに加わっている。ＰＤＵ５０６（１）は有効期限を持たず、要求に対するタイムアウトが無い。ＰＤＵ５０６（２）は、２秒の有効期間を持ち、時系列的にＰＤＵ５０６（１）の後に並んでいる。ＰＤＵ５０６（ｎ）は、２．５秒の有効期間を持ち、時系列的にＰＤＵ５０６（２）の後に並んでいる。ＰＤＵ５０６（ｎ）の待機が、キューの処理をさせ、ＰＤＵ５０６（２）の有効期間を経過させる最初のイベントであるため、ＰＤＵ５０６（２）は作業キューから外され、ローカルに完了されて、ＰＤＵ５０６（ｎ）がリストに加えられる。有効期間がＰＤＵ５０６（ｎ）に設定されている場合、ここまでの一連のイベントが繰り返される。作業キューを操作するいかなるイベント（キューに加える、キューから外す等）によっても、古くなったＰＤＵが除去され、完了される。
【０１６９】
上記のように、ＰＤＵ５０６はインターネット・モビリティ・プロトコル・エンジン２４４の伝送ロジックによって融合され、単一のデータストリームにフォーマットされる。独立した作業要素それぞれは、有効期限タイムアウトによって期限切れになっていなければ、集められてインターネット・モビリティ・プロトコル・データフレームを形成する。インターネット・モビリティ・プロトコル・エンジン２４４は、最終的にこれらのＰＤＵ５０６をピアに送り、関係するフレームをフレーム保留リスト（Ｆｒａｍｅｓ−Ｏｕｔｓｔａｎｄｉｎｇ ｌｉｓｔ）に加える。ピアが一定期間内に該フレームを認識しなかった場合（図１２の再伝送アルゴリズムを参照）、フレームは再伝送され、失われたかあるいは破損したパケットを回復する。再伝送の直前、フレームを形成するＰＤＵリストは、再試行カウントを伴った要求が待機しているかどうかを判定すべく反復される。該再試行カウントが０ではなく、０に向かって減少してゆく場合、ＰＤＵ５０６はリストから外され、フレームヘッダはデータの消去を示すように修正される。このように、古くなったデータ、低信頼のデータ、あるいは独自の再伝送ポリシーを持つアプリケーションは、エンジン２４４’の再伝送アルゴリズムによって負担をかけられることがない。
【０１７０】
図１２Ｂの例においても、少なくとも３つの独立したＰＤＵ５０６が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン２４４でキューに加わっている。ＰＤＵ５０６（１）は再試行カウント無しでキューに加わっているが、これは、継続的な再伝送の試行と、保証された配送レベルのサービスとを示している。ＰＤＵ５０２（２）は再試行カウントが１でキューに加わり、時系列的にＰＤＵ５０６（１）の後に並ぶ。ＰＤＵ５０６（ｎ）は、ある程度の時間が経過してからＰＤＵ５０２（２）より後ろに加わる。この時点で、いくつかの外部イベント（例えば上層融合・タイマー）が、エンジン２４４’に、インターネット・モビリティ・プロトコル・データフレーム５００を生成するための作業キューから十分なＰＤＵ５０６を集めて新しいフレームを生成するための論理を送信させる。フレームヘッダ５０３が求められ、これに、フレームの最初の伝送であることを示すための、再試行ＩＤとして０が付けられる。続いてフレームは、ネットワークへの後の伝送用に、ＮＡＬ層へと送られる。このときに再伝送タイマーがスタートするが、これは、当該のフレームがペイロードを含んでいるためである。説明を容易にするため、再伝送タイマーが期限を迎える前に、様々な理由でピアからの確認応答が受け取られなかったと仮定すると、エンジン２４４の再伝送ロジックにより、当該するフレーム５００が、ネットワークへ再伝送されるのに的確であるか否かが判断される。フレームをＮＡＬ層に再送する前に、エンジン２４４’の再伝送ロジックは、関連しているＰＤＵ５０６のリストを反復する。ＰＤＵ５０６（２）それぞれの再試行カウントが調べられ、０でなければ、該カウントは減少させられる。ＰＤＵ５０６（２）の再試行カウントを減少させる処理により、該カウントは０になる。ＰＤＵ５０６（２）の再試行カウントが０になったことにより、ＰＤＵ５０６（２）はリストから外され、「再試行失敗（ｒｅｔｒｙ ｆａｉｌｕｒｅ）」のステータスをもってローカルに完了する。続いて、ＰＤＵ５０６（２）のデータが無いことを示すため、フレームヘッダ５０３のサイズが調整される。この処理は、残っている全てのＰＤＵについて繰り返される。フレーム５００全体が、「編集後」フレーム５００’の作成のために再処理されると、ヘッダの再試行ＩＤが増加させられて、生成されたデータグラムが、続く（再）伝送に向けてＮＡＬ層に送られる。
【０１７１】
（受信の例）
図１３Ａ〜１３Ｄは、「受信」イベント受信に伴ってインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。このような受信イベントは、インターネット・モビリティ・プロトコル・エンジン・フレームがネットワーク１０８から送られた際に生成される。この受信イベントを受けて、エンジン２４４は該イベントを事前検査（ｐｒｅ−ｖａｌｉｄａｔｅ）し（ブロック６７０）、インターネット・モビリティ・プロトコル・エンジン・フレームである可能性があるか否かを判定する（判定ブロック６７１）。エンジンが可能性無しと判断した場合（判定ブロック６７１で「ノー」の場合）、該フレームは破棄される（ブロック６７２）。可能性ありという判断の場合（判定ブロック６７１で「イエス」の場合）、エンジン２４４は、受信したフレームと関連する接続があるかどうかを判定する（判定フレーム６７３）。受信したフレームと関連する接続がある場合（判定ブロック６７３で「イエス」の場合）、エンジン２４４は作業を接続受信キューに加え（ブロック６７４）、該接続に受信に適格であるとマークを付け（ブロック６７５）、該接続をグローバル作業キューに加える（ブロック６７６）。まだどの接続も受信したフレームと関連していない場合（判定ブロック６７３で「ノー」の場合）、エンジン２４４は、受信したフレームをソケット受信キューに加え（ブロック６７７）、該ソケット受信キューをグローバル作業キューに加える（ブロック６７８）。どちらの場合でも、エンジン２４４はグローバル作業イベントを送る（ブロック６７９）。「受信適格」イベントをグローバル作業キューからディスパッチする際（図１３Ｂ参照）、エンジン２４４はフレームをそれぞれの受信キューから外す（ブロック６８０）。インターネット・モビリティ・プロトコル・エンジン２４４がメッセージをキューから外し始められるようになる前に、複数のＩＭＰフレームを受信し、キューに加えることが可能である。エンジン２４４は、全てのフレームがキューから外れるまで作業を繰り返す（ブロック６８１、６８２）。あるフレームがキューから外れると（判定ブロック６８１で「イエス」）、エンジン２４４は受信したフレームを検査し（ブロック６８３）、該フレームが有効かどうかを判定する（判定ブロック６８４）。該受信したフレームが無効である場合、エンジン２４４は該フレームを破棄し（ブロック６８５）、受信キューから次のフレームを外す（ブロック６８０）。上記フレームが有効である場合（判定ブロック６８４で「イエス」の場合）、エンジン２４４は、該フレームが既存の接続と関連しているか否かを判定する（ブロック６８６）。していなければ（判定ブロック６８６で「ノー」の場合）、エンジン２４４は同期フレームがあるかどうかを判定する（判定ブロック６８７）。同期フレームがなければ（判定ブロック６８７で「ノー」の場合）、該フレームは破棄される（ブロック６８５）。反対に、同期フレームが受信されていれば（判定ブロック６８７で「イエス」の場合）、エンジン２４４は、図１４Ａおよび１４Ｂを参照して説明される受動接続要求により、該フレームを処理する（ブロック６８８）。
【０１７２】
上記フレームが接続と関係していれば（判定ブロック６８６で「イエス」の場合）、エンジン２４４は接続状態が依然アクティブで、まだ「ポスト・モーテム」になっていないかどうかを判定する（判定ブロック６８９）。接続が既に「ポスト・モーテム」である場合、フレームは破棄される（ブロック６８５）。そうでない場合、エンジン２４４はフレームを解析し（ブロック６９０）、該フレームが中止フレームであるかどうかを判定する（判定ブロック６９１）。該フレームが中止フレームであれば、エンジン２４４は直ちに接続を中止する（ブロック６９１ａ）。該フレームが中止フレームでなければ（判定ブロック６９１で「イエス」の場合）、エンジン２４４は確認応答情報を処理し、全ての保留中の送信フレームを開放する（ブロック６９２）。次に、エンジン２４４は、解読の必要がある場合のため、セキュリティ用のサブシステムへと送る（ブロック６９３）。フレームがセキュリティ用のサブシステムから戻ると、エンジン２４４は全ての制御データを処理する（ブロック６９４）。続いて、エンジン２４４はフレームがアプリケーションデータを含んでいるかどうかを判定する（判定ブロック６９５）。含んでいる場合、該データはアプリケーション層においてキューに加えられる（ブロック６９６）。エンジン２４４はまた、接続が休止状態であるかどうかを判定し（ブロック６９７および６９７ａ：これは、好ましい実施形態におけるモビリティ管理サーバのエンジン２４４’にもあてはまる）、確立状態に戻す。
【０１７３】
フレームが「モーティス」フレームである可能性があれば（判定ブロック６９８で「イエス」の場合）、エンジン２４４は、アプリケーション層に「切断」を示唆し（ブロック６９９）、「モーティス」状態に入る（ブロック６９９ａ）。エンジン２４４は「ポスト・モーテム」フレームをピアに送り（ブロック７００）、「ポスト・モーテム」状態に入る（ブロック７００ａ）。続いて、エンジン２４４は接続リソースを解放し（ブロック７０１）、スリープ状態に戻って作業を待つ（ブロック７０２）。解析されたフレームが「ポスト・モーテム」フレームだった場合（判定ブロック７０３で「イエス」の場合）、ブロック７００ａ、７０１、７０２が実行される。これ以外の場合、制御はブロック６８０に戻って、次のフレームを受信キューから外す（ブロック７０４）。
【０１７４】
（受動接続の例）
図１４Ａ〜１４Ｂは、「受動接続」要求に対してインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。まず、エンジン２４４は、当該装置に他の接続が存在するかどうかを判定する（ブロック７２０）。存在すれば（判定ブロック７２０で「イエス」の場合）、該エンジンは、それが最初の接続であるか否かを判定する（判定ブロック７２１）。ピアが、新規の接続が最初の接続であると認識している場合（判定ブロック７２１で「イエス」の場合）、エンジン２４４はそれ以前の接続を中止する（ブロック７２２）。最初の接続ではない場合（判定ブロック７２１で「ノー」の場合）、エンジン２４４は、シーケンスと接続ＩＤとが対応しているかどうかを判定する（判定ブロック７２３）。対応していなければ（判定ブロック７２３で「ノー」の場合）、制御は判定ブロック７２０へ戻る。シーケンスと接続ＩＤが対応していれば（判定ブロック７２３で「イエス」の場合）、エンジン２４４は複製フレームを破棄し（ブロック７２４）、図１３Ｂのステップ６８０に戻る（ブロック７２５）。
【０１７５】
他の接続が無ければ（判定ブロック７２０で「ノー」の場合）、エンジン２４４は、接続に接続リソースを割り当て可能か否かを判定する（判定ブロック７２６）。割り当て可能でない場合、エラーが宣言され（判定ブロック７２６で「ノー」の場合、ブロック７２７）、接続が中止される（ブロック７２８）。接続リソースを割り当て可能な場合（判定ブロック７２６で「イエス」の場合）、エンジン２４４は「設定」状態を宣言し（ブロック７２６ａ）、接続についてのセキュリティコンテキストを取得する（ブロック７３０）。十分なセキュリティコンテキストの取得ができなかった場合（判定ブロック７３１で「ノー」の場合）、接続は中止される（ブロック７２８）。取得できた場合、エンジン２４４は確立フレームを送り（ブロック７３２）、接続が「確立」状態になったことを宣言する（ブロック７３２ａ）。続いて、エンジン２４４は再送部（ｒｅｔｒａｎｓｍｉｔｔｅｒ）を始動させ（ブロック７３３）、完了に向けて認証処理を待つ（ブロック７３４）。最後に、エンジン２４４は装置とユーザとが両方認証済みか否かを判定する（ブロック７３５）。装置とユーザのどちらかが認証されていない場合、接続は中止される（ブロック７３６）。それ以外の場合、エンジン２４４は監視中の（ｌｉｓｔｅｎｉｎｇ）アプリケーションへの接続を示唆し（ブロック７３７）、設定を取得する（ブロック７３８）。この２ステップのどちらかが成功しなかった場合、接続は中止される（判定ブロック７３９、ブロック７４０）。成功した場合、処理はスリープ状態に戻って作業を待つ（ブロック７４１）。
【０１７６】
（異常終了の例）
図１５Ａおよび１５Ｂは、接続「中止」要求を受けて、インターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。キューを介してディスパッチされた、上記のような要求を他の処理（ブロック９９９）から受信すると（ブロック１０００）、エンジン２４４は、接続が該要求と関係しているかどうかを判断する（判定ブロック１００１）。関係していれば（判定ブロック１００１で「イエス」の場合）、エンジン２４４は元の状態をセーブして（ブロック１００２）、「中止」状態を宣言する（ブロック１００２ａ）。次に、エンジン２４４は、接続がＲＰＣエンジンに示唆されていたか否かを判定する（判定ブロック１００３）。されていれば、エンジン２４４は切断イベントを示唆し（ブロック１００４）、「ポスト・モーテム」状態を宣言して（ブロック１００３ａ）、該接続に割り当てられていたリソースを解放し（ブロック１００５）、元の状態が保留中の状態より大きいか否かを判定する（判定ブロック１００６）。元の状態が保留中の状態より大きくなければ、（判定ブロック１００６で「ノー」の場合）、処理は、呼び出しルーチンに戻るべく、ブロック１０１２に移る（ブロック１００７）。元の状態が保留中の状態より大きい場合には、エンジン２４４は、上記要求が受信フレームと関係しているかどうかを判定する（判定ブロック１００８）。中止要求が受信フレームと関係していて、受信フレームが中止フレームである場合（判定ブロック１００９）、受信フレームは呼び出しルーチンに戻る（ブロック１０１２）前に破棄される（ブロック１０１１）。
【０１７７】
（ローミング制御の例）
再度図１を参照すると、モバイルネットワーク１０８は、それぞれ別のネットワーク相互接続（１０７ａ〜１０７ｋ、無線トランシーバ１０６ａ〜１０６ｋにそれぞれ対応）を提供する、複数のセグメントを含んでいてもよい。本発明の別の側面において、モビリティ管理サーバ１０２を含むネットワーク１０８は、モバイル端末システム１０４があるネットワーク相互接続から別のネットワーク相互接続へと移る「ローミング」状況を、余裕を持って（ｇｒａｃｅｆｕｌｌｙ）扱うことができる。一般に、ネットワーク１０８のトポロジは、管理等の理由により、いくつかのセグメント（サブネット）に分けられ、一般的には、あるセグメントにおいて、別個のネットワーク（伝送）アドレスが複数のモバイル端末システム１０４それぞれに割り当てられている。
【０１７８】
上記のようなサブネットで新規に起動したネットワーク装置は、動的ホスト構成プロトコル（ＤＨＣＰ）を使用して、自動的に設定されるのが一般的である。例えば、サブネット上のＤＨＣＰサーバは、一般的に、そのクライアントに（他のものの提供に加えて）有効なネットワークアドレスを「リース」する。ＤＨＣＰクライアントは、永続的に割り当てられた、「固定符号化された（ｈａｒｄ−ｃｏｄｅｄ）」ネットワークアドレスを有していなくてもよい。その代わり、ブート時に、ＤＨＣＰクライアントはＤＨＣＰサーバにネットワークアドレスを要求する。ＤＨＣＰサーバは、割り当てに使用可能なネットワークアドレスをプールしている。ＤＨＣＰクライアントがネットワークアドレスを要求すると、ＤＨＣＰサーバはプールしていたアドレスを、該クライアントに割り当てあるいはリースする。割り当てられたネットワークアドレスは、特定の期間（リース期間）だけ、クライアントに所有される。リース期間が終わると、ネットワークアドレスはプールに戻され、他のクライアントへの割り当てに使用できるようになる。ネットワークアドレスの自動割り当てに加え、ＤＨＣＰはネットマスク等の設定情報を、ＤＨＣＰクライアントソフトウェアを動作させているクライアントに提供する。標準的なＤＨＣＰプロトコルについての詳しい情報は、ＲＦＣ２１３１に記載されている。
【０１７９】
よって、ＤＨＣＰを使用するモバイル端末システム１０４が、サブネットからサブネットへとローミングすると、該システムは新規のネットワークアドレスを持つことになる。本発明の一側面において、モバイル端末システム１０４とモビリティ管理サーバ１０２とがＤＨＣＰの自動設定機能を利用し協調することで、モビリティ管理サーバによるモバイル端末システム１０４の「新しい」ネットワークアドレスの認識や、該アドレスと、モビリティ管理サーバがプロキシする、以前に確立されていた接続との結合が保証される。
【０１８０】
ある実施例では、モバイル端末システム１０４が別のサブネットにローミングしたり圏外に出たりしたか否かを判定するために利用される、他の標準的な方法と並んで、エコー要求−応答（ｅｃｈｏ ｒｅｑｕｅｓｔ−ｒｅｓｐｏｎｓｅ）として、標準的なクライアント／サーバ型同報通信用のＤＨＣＰ Ｄｉｓｃｏｖｅｒ／Ｏｆｆｅｒメッセージのシーケンスが使用される。標準的なＤＨＣＰプロトコルに従って、ネットワークアドレスを要求するモバイル端末システム１０４が、ＤＨＣＰ Ｄｉｓｃｏｖｅｒメッセージの一部として、クライアント識別子とハードウェアのアドレスとを定期的に同報通信すると、これに対し、ＤＨＣＰサーバはＯｆｆｅｒ応答を同報通信する（要求しているモバイル端末システムがまだネットワークアドレスを持っていないため、該システムを特定して該応答を送るというよりも、同報通信によって該応答が伝えられるという形になる）。よって、当該サブネット上の全てのモバイル端末システム１０４は、ＤＨＣＰ Ｏｆｆｅｒサーバからの、同サブネット上のどのモバイル端末システムに同報通信された応答であっても受信することになる。
【０１８１】
本実施例では、ＤＨＣＰ同報通信メッセージをモニターするＤＨＣＰリスナが設けられており、モバイル端末システム１０４が、あるサブネットから別のサブネットへローミングしているか、およびＤＨＣＰによって新規のネットワークアドレスが取得できるようになっているかが確認される。図１６は、ＤＨＣＰリスナのデータ構造の例を示している。例えば、モバイル端末システムのリスナのデータ構造９０２は、以下の要素を有していてもよい。
【０１８２】
・サーバデータ構造の連結リスト、
・整数トランザクションＩＤ番号（ｘｉｄ）、
・カウンタ（「ｐｉｎｇ」）、および
・タイムアウト値
サーバデータ構造９０４は、それぞれ別のＤＨＣＰサーバを定義するデータブロックの連結リストを有していてもよい。該データブロックそれぞれは、以下の要素を有していてもよい。
【０１８３】
・次のサーバへのポインタ、
・サーバＩＤ（ＤＨＣＰサーバのネットワークアドレス）、
・最近該ＤＨＣＰサーバと結合したＢＯＯＴＰリレーエージェントのアドレス（ｇｉａｄｄｒ）、
・「ｐｉｎｇ」値（ｓｏｃｋｅｔ−＞ｐｉｎｇ）、および
・フラグ
これらのデータ構造は、ネットワーク１０８上のＤＨＣＰ同報通信トラフィックに基づいて、持続的にアップデートされる。以下に例示の諸機能は、該データ構造の維持に使用される。
【０１８４】
・ｒｏａｍＣｒｅａｔｅ（） （変数を初期化）
・ｒｏａｍＤｅｉｎｉｔｉａｌｉｚｅ（） （全てのリスナを消去）
・ｒｏａｍＳｒａｒｔＩｎｄｉｃａｔｉｏｎｓ（） （モバイル端末システムがローミングするかインターフェイスを変更した際に、登録主体ローミング示唆（ｒｅｇｉｓｔｒａｎｔ ｒｏａｍｉｎｇ ｉｎｄｉｃａｔｉｏｎｓ）のために、供給されたコールバックルーチンを呼び出す）
・ｒｏａｍＳｔｏｐＩｎｄｉｃａｔｉｏｎｓ（） （適当なコールバックをリストから除去して登録ローミング示唆を停止）
・インターフェイス変更（インターフェイスがネットワークアドレスを変更したことを示す、ＯＳからのコールバック通知）
・リスナ信号（ローミング、圏外、圏内復帰のいずれかの状態を示す、リスナからのインターフェイスごとのコールバック）
これに加え、リフレッシュ処理が、インターフェイス変更後にリスナをアップデートするために利用されてもよい。
【０１８５】
本好ましい実施形態では、全てのモバイル端末システム１０４が、ＤＨＣＰ Ｄｉｓｃｏｖｅｒ要求によって同じクライアント識別子とハードウェアアドレスとを伝送する。これにより、リスナのデータ構造とこれに関連する処理とが、モバイル端末システムからのＤｉｓｃｏｖｅｒ要求と、他のネットワーク装置からのＤｉｓｃｏｖｅｒ要求とを、区別することができるようになる。ＤＨＣＰサーバも同様に応答を同報通信するので、どのモバイル端末システム１０４および／またはモビリティ管理サーバ１０２も、ＤＨＣＰサーバからどのモバイル端末システムに出されたＯｆｆｅｒ応答でも受け取ることができる。複数のＤＨＣＰサーバが単一のＤＨＣＰ Ｄｉｓｃｏｖｅｒ要求に応答できるため、図１６のリスナのデータ構造は、サーバからの応答それぞれを、メインハンドルに連結リスト経由で結びつけられた、個別のデータブロックに記憶する。
【０１８６】
所定のクライアントハードウェアアドレスおよびクライアント識別子を有するＤｉｓｃｏｖｅｒ要求の受信に際し、本好ましい実施形態では、該要求がモバイル端末システム１０４から送られてきたものとして認識される。該メッセージが０に設定されたＢＯＯＴＰリレーアドレスをさらに有している場合、該メッセージはリスナと同じサブネットからのものであることが示唆されている。リスナは、最近モバイル端末システム１０４から送られたＤｉｓｃｏｖｅｒメッセージのトランザクションＩＤ（ｘｉｄ）と対応したトランザクションＩＤ（ｘｉｄ）が含まれていない限り、ＤＨＣＰ Ｏｆｆｅｒ応答を無視してもよい。該リスナは、新規のＢＯＯＴＰリレーエージェントＩＤおよび／または提供されたサブネットマスクでマスクされた、提供されたネットワークアドレスを持つ、既知のサーバから応答があれば、モバイル端末システム１０４がローミングしたと判定する。リスナは、旧サーバから肯定応答を受け取って初めて、新サーバを図１６のデータ構造に加える。リスナが新サーバからの応答は受け取ったが旧サーバからは受け取っていない場合、ローミング状態が示唆される（これについては設定によって変更可能である）。リスナが新旧両サーバのどちらからも応答を受け取っていない場合、リスナは圏外にあると判定される（この判定は、アプリケーションなど上層に警告を出して、停止や、バッファ・オーバーフロー回避のためのデータ送信量の減少に利用できる）。
【０１８７】
リスナがどのサーバからも応答を受信しない場合、参照点が無いため、ローミングが行われているかどうかが判定できない。この状況は、タイムアウト後にエラー警告して、呼び出し側に処理を再試行させることによって解消される。本好ましい実施形態では、新規のＢＯＯＴＰリレーエージェントＩＤ（または提供されたサブネットマスクでマスクされた、提供されたネットワークアドレス）を持つ、既知のサーバから応答があれば、モバイル端末システム１０４がローミングしたと判定する。リスナのデータ構造に、新サーバからの応答はあったが旧サーバからのものは無い場合、ローミングが行われた可能性はあるが、旧サーバからの応答がその後あるかもしれないので、待機して通知を遅らせる。新旧どちらのサーバからも応答が無い場合、モバイル端末システム１０４は圏外にある可能性があるので、モビリティ管理サーバ１０２は該システムが圏内に戻るのを待つ。
【０１８８】
図１７は、本好ましい実施形態のリスナ処理のステップを例示したフローチャートである。同図によると、ＤＨＣＰリスナ処理は、適切なメモリをハンドルに割り当て、ＮＡＬソケットをＤＨＣＰクライアントおよびサーバＵＤＰポートに解放し、その両者に対して受信コールバックを設定することによってなされる。次にタイマーが設定され（ブロック８０２）、上記処理は「待機」状態に入ってローミング関連のイベントを待つ（ブロック８０４）。イベントは、以下の３種の外部入力によって引き起こされる。
【０１８９】
・ＤＨＣＰサーバパケットを受信する
・他のモバイル端末システムからのＤＨＣＰクライアントパケットを受信する ・タイマーの期限が切れる
ＤＨＣＰサーバパケットを受信した場合、該パケットは、そのクライアント識別子が所定のクライアントＩＤと一致するか否かを判定するために調べられる（判定ブロック８０６）。一致しなければ、該パケットは破棄される。しかし、該パケットが所定のクライアントＩＤを含んでいる場合、該パケットがＤＨＣＰ Ｏｆｆｅｒパケットであるか否かが判定される（判定ブロック８０８）。該Ｏｆｆｅｒパケットは、最近送られたＤＨＣＰ Ｄｉｓｃｏｖｅｒシーケンスに対応したトランザクションＩＤを含んでいない限り、拒絶される。
【０１９０】
パケットトランザクションＩＤが対応していれば（ブロック８１０）、ＤＨＣＰ Ｏｆｆｅｒパケットを送信したサーバが既知であるか否か（つまり、サーバＩＤが図１６のリスナのデータ構造に含まれているか否か）が判定される（ブロック８１２）。サーバＩＤがリストに無い場合（判定ブロック８１２で「ノー」の場合）、サーバＩＤがリストに加えられ、「新規」とマークされる（あるいは、リストの最初のサーバであれば、「最初」とマークされる）（ブロック８２２）。サーバが既にリストにある場合（判定ブロック８１２で「イエス」の場合）、さらに、パケットＢＯＯＴＰリレーアドレス（「ＧＩＡＤＤＲ」）がサーバアドレス（「ＧＩＡＤＤＲ」）に対応しているか否かが判定される（判定ブロック８１４）。対応していなければ、Ｏｆｆｅｒパケットは他のサブネットからのものということになるので、「ハードローミング（ｈａｒｄ ｒｏａｍ）」が実行されたと判定される（ブロック８１６）。呼び出し側のアプリケーションには、ローミングが行われたことが通知される。判定ブロック８１４でＢＯＯＴＰリレーアドレスが対応していると判定されると、ローミングは行われていないということになり、サーバ受信時間を記録し、リストの他のサーバ全てについて「新規」フラグをリセットし、現在のｐｉｎｇ番号をサーバに記憶するというリスナ処理が行われる（ブロック８１８、８２０）。続いて、処理は「待機」期間に戻る。
【０１９１】
イベントがクライアントパケットに受信されると、リスナ処理では、該パケットが所定のクライアントＩＤを有しているか、ＤＨＣＰ Ｄｉｓｃｏｖｅｒパケットか、および０のパケットＢＯＯＴＰリレーアドレス（ＧＩＡＤＤＲ）を有しているかどうかが判定される（ブロック８２４、８２６、８２８）。これらのステップにより、上記受信パケットが、リスナと同じサブネット上にある、他のモバイル端末システムから送信されたＤＨＣＰ Ｄｉｓｃｏｖｅｒメッセージであるか否かが判定される。そうであれば、リスナ処理により、上記トランザクションＩＤが、後に受信されるＤＨＣＰ Ｏｆｆｅｒパケットの比較に用いられる、ピアのトランザクションＩＤに設定され（ブロック８３０）、「ｐｉｎｇ確認」が呼び出され（ブロック８３４）、タイマーがリセットされる（ブロック８３６）。
【０１９２】
タイマーの期限切れにより、処理は「ｐｉｎｇ確認」を呼び出す（ブロック８３８）。本好ましい実施形態における「ｐｉｎｇ」は、ランダムな新規のｘｉｄを有するＤＨＣＰ Ｄｉｓｃｏｖｅｒパケットである。このｐｉｎｇ確認８３８のステップが、図１７Ａに例示されている。ｐｉｎｇ確認ルーチンの目的は、「ソフトローミング（ｓｏｆｔ ｒｏａｍ）」状態（つまり、モバイル端末システムが、一時的にサブネットとのコンタクトを失ったもののその後回復したが、まだ他のサブネットにローミングはしていない状態）が発生しているか否かの判定である。処理によって、サブネット・ローミング状態、圏外状態、あるいは「サーバ無し」状態が発生しているか否かが判定される。これらを言い換えると以下のようになる。
【０１９３】
・モバイル端末システムが、あるサブネットから別のものにローミングしたか？
・モバイル端末システムは圏外にあるか？
・ＤＨＣＰサーバは不在か？
これらの状態は、モバイル端末システムの、前「ｐｉｎｇ」応答と現「ｐｉｎｇ」応答とを比較することによって判定される（判定ブロック８４６、８５０）。例えば、現ｐｉｎｇ数から旧サーバの前ｐｉｎｇ応答を引いた数が、サブネットのサーバのｐｉｎｇよりも大きく、少なくとも一つのサーバが「新規」とマークされている場合、別のサーバへのサブネット・ローミングがあったということになる。この論理により、コーリング処理に対し、サブネット・ローミング状態、圏外状態、あるいはサーバ無し状態が示唆される（あるいはいずれも示唆されない）。
【０１９４】
図１８は、モバイル端末システム１０４のローミング制御センター（ｒｏａｍｉｎｇ ｃｏｎｔｒｏｌ ｃｅｎｔｅｒ）が実行するステップを例示したフローチャートである。モバイル端末システム１０４でのローミングを可能にするため、既知のアドレスのリストが０に初期化され（ブロック８５０）、ＯＳインターフェイス変更通知がイネーブルになり（ブロック８５２）、次に、ＯＳを呼び出して、ＤＨＣＰを利用する現在のアドレスのリストを所得する（ブロック８５４）。現在のリストから無くなった全ての既知のアドレスに対応するリスナが閉じられ（ブロック８５６）、一方、現在のリストにあるが未知のインターフェイスにあるリスナが開放される（ブロック８５８）。次に、登録主体に「ローミング」を示唆する（ブロック８６０）。
【０１９５】
図１７のリスナ処理から信号が送られると（ブロック８６２）、該信号が、「ローミング」、「圏外」、「圏内復帰」のいずれの状態を示しているかが判定される（判定ブロック８６４、８７０、８７４）。ローミング信号（判定ブロック８６４で「イエス」）により、対応するリスナ８６６が閉じられ、ＯＳがコールされて、ネットワークアドレスのＤＨＣＰリースが解放、更新される（ブロック８６８）。リスナ信号が「圏外」の場合（判定ブロック８７０）、該状態が登録主体に示唆される（ブロック８７２）。該信号が「圏内復帰」の場合（判定ブロック８７４）、該状態は全ての登録主体に示唆される（ブロック８７６）。無効のローミング命令を受信すると（ブロック８７８）、全てのリスナが閉じられ（ブロック８８０）、ＯＳインターフェイス変更通知が無効になる（ブロック８８２）。
【０１９６】
（インターフェイスによって補助されたローミングのリスナの例）
さらに、インターフェイスベースのリスナによって、同じネットワークおよび別のネットワーク媒体のネットワーク接続ポイントを横断したローミングが可能になる。該インターフェイスベースのリスナが上述のビーコン技術を要することなく動作する一方、下層の（複数の）インターフェイスが適切な信号をサポートしていない場合には、システムをビーコン状態にフォールバックさせることもできる。
【０１９７】
本実施形態において、インターフェイスベースのリスナは、ネットワーク・インターフェイス・アダプタからの（例えば低レベルのインターフェイス・ローミング・ドライバを経由した）情報を、ネットワークスタックからの情報と統合して、モバイルノードが新規のネットワーク接続ポイントに移動したか否かを判定する。図１９Ａと１９Ｂは、モバイルノードの移動パス（ｍｉｇｒａｔｉｏｎ ｐａｔｈ）を効率的に決定するのに利用される、リスナ・アルゴリズムを例示する。該処理では、単一のネットワーク媒体に接続された単一のネットワーク・インターフェイスが使用されているが、単独で、もしくは他のローミング・アルゴリズムと協働して、（例えば、冗長パスを使った自己回復インフラ構築のために）様々なネットワーク媒体やインターフェイスを横断するようにもできる。
【０１９８】
図１９Ａを参照すると、システム初期化時や、ネットワークアダプタドライバがロードする際に（図１９Ａ、ブロック２０００）、低レベルのインターフェイス・ローミング・ドライバは、図１８のローミング制御センターモジュールに登録を実行する（ブロック２０１０）。このような登録（例示の実施形態では、ｃｒＲｅｇｉｓｔｅｒＣａｒｄＨａｎｄｌｅｒ（）機能を通じて実現される）により、下記のエントリポイントが与えられる。
【０１９９】
・開
・閉
・状態（ｓｔａｔｕｓ）取得
・ドライバが登録主体に状態の変化を通知可能であれば、ブール演算を真とし、ローミング制御センターモジュールが、状態確認にタイマーベース（等）のポーリングを使わなければならない場合は、ブール演算を偽とする
実施例のｃｒＲｅｇｉｓｔｅｒＣａｒｄＨａｎｄｌｅｒ（）機能により、インターフェイス記述ストリング、あるいはローミング制御センターモジュールを正しいローミングドライバと予備的に組み合わせるために使用できるトークンが与えられる。また、デフォルトのローミングドライバが、示唆／問合せ（ｓｉｇｎａｌｉｎｇ／ｑｕｅｒｙｉｎｇ）媒体接続性およびネットワーク接続ポイントの変更に関するＯＳ包括メカニズム（Ｏ／Ｓ ｇｅｎｅｒｉｃ ｍｅｃｈａｎｉｓｍ）を使用するインターフェイスに、インストールされてもよい。
【０２００】
本実施例では、インターフェイスの状態がイネーブルになると（つまりネットワークへのアクセスが可能になると）（ブロック２０２０）、ローミング制御センターは、インターフェイス補助ローミング（ｉｎｔｅｒｆａｃｅ ａｓｓｉｓｔｅｄ ｒｏａｍｉｎｇ； ＩＡＲ）を、以下のステップに基づいて試みる（ただし、以下のステップは、ＯＳの設計および／または特定のアプリケーションに使われるホスティング装置によって、入れ替えられたり省略されたりすることがある）。
【０２０１】
１．包括ハンドラ（ｇｅｎｅｒｉｃ ｈａｎｄｌｅｒ）がインストールされている場合、包括ｃｒＯｐｅｎＩｎｓｔａｎｃｅ（）ハンドラへのコールがなされる。包括ハンドラは低レベルアダプタドライバに問合せをして、該ドライバが、媒体接続性の状態およびネットワーク接続ポイントの変更に関する信号を包括的にサポートしているか否かを判定する（ブロック２０３０）。インターフェイスドライバが該機能を包括的にサポートできない場合（判定ブロック２０３０で「ノー」の場合）、エラー状態が、コール実行側に返され、信号情報の取得に他のメカニズムを使用することが示唆される。
【０２０２】
２．包括ハンドラがエラー（判定ブロック２０３０で「ノー」）を返した場合、アクティブなインターフェイスに関する検索が、現在登録されているローミングドライバにおいて実行される（ブロック２０４０）。該インターフェイスが、ｃｒＲｅｇｉｓｔｅｒＣａｒｄＨａｎｄｌｅｒ（）フェイズ中に登録されたトークンのうちの一つと一致する場合（ブロック２０５０）、ローミング制御センターは、アダプタのインスタンスへの特定のｃｒＯｐｅｎＩｎｓｔａｎｃｅ（）をコールする。この機能は、低レベルドライバを開き、状態（媒体接続性、ネットワーク接続ポイントＩＤ）を再度ポーリングし、定期ポーリングタイマーを（可能ならば）設定することを試みるものである。低レベルドライバが、なんらかの理由で該要求をサポートしていない場合、ローミング制御センターにエラーが返されて、信号情報の取得に他のメカニズムを使用することが示唆される。
【０２０３】
３．ここまでのステップのいずれかが、要求された機能を達成できない場合、エラーがローミング制御センターに返されて、ＩＡＲ機能を使用せずに、図１７および１７Ａのビーコンリスナ（ｂｅａｃｏｎｉｎｇ ｌｉｓｔｅｎｅｒ）、モバイルＩＰ、あるいは場合により、ローミングを扱っている、現在接続されているネットワークなど、他のローミング・アルゴリズムにフォールバックすることが示唆される（判定ブロック２０５０で「ノー」の場合、ブロック２０６０）。これ以外の場合、インターフェイス補助ローミングがイネーブルになり（ブロック２０６０）、ローミング制御センターは下記のアルゴリズムに従う。
【０２０４】
まず、インターフェイスによって補助されたリスナは、現在の媒体接続性の状態と、ネットワーク接続ポイントの識別情報とを、ローカルデータストアに記録する（ブロック２０６０）。インターフェイスによって補助されたサブシステムがローミングフィードバックの供給に成功したと仮定して、該サブシステムは状態イベントを待つ（ブロック２１００）。該イベントは、例えば以下のものを有している。
【０２０５】
・低レベルローミングドライバからのコールバック、
・ポーリング間隔（ｔｉｍｅｄ ｐｏｌｌ ｉｎｔｅｒｖａｌ）（ブロック２０７０、２０９０）、あるいは
・ネットワーク・レベルの活動（つまり、伝送／受信にかかわる問題）からの示唆
インターフェイスの状態が、媒体接続性に変化が生じたか、あるいはネットワーク接続ポイントが変更されたかを示すと（図１９Ｂの判定ブロック２１１０もしくは２１２０で「イエス」の場合）、ローミング制御センターの全てのクライアントに、以下のルールに基づいて、状態の変化が知らされる。
【０２０６】
１．状態が、下層のネットワーク媒体への接続から切断へと変化したことを示し（ブロック２１２０で「イエス」）、ピアへのパスが他に無い場合、リスナは、モバイル端末システムが接続を失ったと結論付け、ローミング制御センターはそのクライアントに、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＯＵＴ＿ＯＦ＿ＣＯＮＴＡＣＴ状態を示唆する（ブロック２１４０）。
【０２０７】
２．上記状態が、インターフェイスが媒体に再接続され、ネットワーク接続ポイントが変わっていないことを示し（ブロック２１２０で「ノー」の後、ブロック２１５０で「ノー」の場合）、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＯＵＴ＿ＯＦ＿ＣＯＮＴＡＣＴが既に示唆されている場合、モバイル端末システムが、特定のネットワーク接続ポイントとのコンタクトを失ったがその後取り戻したことが示唆される。この場合、ローミング制御センターは、適切なアクセスのために登録または取得された全てのネットワークアドレスを再確認し（ブロック２１７０）、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＡＭ＿ＳＡＭＥ＿ＳＵＢＮＥＴを出して（ブロック２１８０）、ローミング制御センターのクライアントに、再接続が行われたので、トランスポート・レベルでの通信の再確立に必要な措置を全て実行するように警告する。例えば、サービス中断中にいくつかのデータが失われることがあれば、クライアントは該データを回復するために措置を講じるといったことである。
【０２０８】
３．上記状態が、インターフェイスが媒体に取り付けられているが、ネットワーク接続ポイントが変更されたことを示している場合（ブロック２１５０で「イエス」の場合）、ローミング制御センターはクライアントに、ローミング状態になったことを示唆する。ネットワーク接続ポイント間のハンドオフをさらに効率的にサポートするために、本例のローミング制御センターは、ローカルデータストアと並行して学習アルゴリズムを使用している。該データストアは、通常動的にポピュレートされている（学習している）が、パフォーマンス向上のため、該データストアに静的な情報（既に学習された情報）が準備されていてもよい。データストア自体は、ネットワーク接続ポイント識別子のリストを、ネットワークや媒体へのアクセスのアドレスやネットワークマスクなどの情報とともに維持している。この「ネットワーク・トポロジ・マップ」は、ローミング制御センターがクライアントに対して正しい信号の生成を決定できるように補助するものである。
【０２０９】
正しい信号の決定は、本実施例では以下のようにしてなされる。
【０２１０】
ａ）データストアのネットワーク・トポロジ・マップを検索して、インターフェイスが特定のネットワーク接続ポイントを訪れたか否かが判定される（ブロック２１９０）。対応が見つかれば（ブロック２２００で「イエス」）、該ネットワーク接続ポイントが、以前にインターフェイスが結合していたのと同じネットワーク・セグメントにあるか否かがさらにチェックされる。ネットワーク・セグメントが同じであれば、ローミング制御センターは、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＡＭ＿ＳＡＭＥ＿ＳＵＢＮＥＴを生成する。これにより、ローミング制御センターのクライアントに、ハンドオフが実行され、ハンドオフ中にデータのいくつかが失われた可能性があるため、直ちにトランスポート・レベルでの通信の再確立をするための可能な限りの措置を講じなければならないことが示唆される。
【０２１１】
ｂ）検索中に対応は発見されたが、新しいネットワーク接続ポイントは前と同じネットワーク・セグメントにない場合、リスナは、モバイル端末システムが別のサブネットワークにローミングしたと結論付ける。この場合、ローミング制御センターは、
・新規のネットワーク・セグメントで使用可能なアドレスを取得する（ブロック２２２０）。この動作は、現在のアドレスを新規のセグメントで有効なように登録すること、ローカルサーバからアドレスを（再）取得すること、あるいは以前に割り当てられたアドレスがまだ有効かどうか判定するヒューリスティックな手法を用いてもよい。最後のケースでは、ローミング制御センターにより、インターフェイスが所与のネットワーク接続ポイント間をローミングしていて、パフォーマンス維持の観点から、直ちにネットワークアドレスを破棄したり、その登録を抹消したりできないような状態にあるかどうかが判断される。この例では、（例えばＤＨＣＰを通じて）ネットワークでアドレスを取得することは、（モバイルＩＰの外部エージェントを通じて）ローカルネットワークでアドレスを登録することとは相違している。ローミングエンティティは、アドレスを（再）取得（例えばＤＨＣＰサーバからのリースを確立／アップデートして）するか、あるいは現アドレスを外部エージェント（モバイルＩＰ）に登録する。
【０２１２】
・別のサブネットへのローミングを示唆する、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ローミング信号を、該ローミング制御センターのクライアント向けに生成する（ブロック２２３０）。
【０２１３】
ｃ）検索の結果対応が見つからなければ（ブロック２２００で「ノー」）、ネットワーク接続ポイントの識別子、媒体アクセスアドレス、ネットワークマスクや他の補助的な情報によってポピュレートされた、新規の記録を生成する（ブロック２２１０）。次に、ローミング制御センターはブロック２２２０および２２３０を、ネットワークアドレスを取得、登録し、「ローミング」信号を生成するために実行する。
【０２１４】
上記のインターフェイスによって補助されたローミング技術により、下層のインターフェイス情報へのアクセスができるようになり、自動的かつ効率的に別の有効なネットワークパスを選択することを可能にする、（ユーザおよび／またはシステムによって定義された）付加的なポリシーパラメータが採用できるようになる。一つ以上のネットワークが同時に使用可能な場合、サブシステムは、最も負担がかからないパス（ワイドエリア・ネットワークかローカル・エリア・ネットワークかという選択）を選ぶことができる。これは、帯域幅、（１バイトあたりの）コスト、および／またはサービス品質といった様々なメトリクスによって決定可能である。この「最低負担ルーティング」技術により、ネットワーク接続の品質、効率、フレーム損失の減少などの点で効果を得ることができる。例えば、他の利用可能なヒューリスティクス（媒体接続性、信号強度、再伝送率等）による、「メークビフォアブレーク（ｍａｋｅ ｂｅｆｏｒｅ ｂｒａｋｅ）」ハンドオフ構造が提供可能で、よってローミングノードからの／に向かう継続的なパケットフローの損失を最小化できる。下記のポリシー管理についての記述を参照のこと。
【０２１５】
図２０は、インターフェイス補助ローミングトポロジのノードのデータ構造を例示している。図２０のこのデータ構造は連結リストとして実施されているが、前後のフィールドを省略した配列として表現されることもある。無線ネットワーク・インフラにおいて、「ＮＰＯＡ」は、例えば、アクセスポイントのＭＡＣアドレスあるいはモバイルノードが結合している基地局でもよい。他のネットワークにおいては、「ＮＰＯＡ」は、介入的なネットワーク相互接続（ゲートウェイ、ＩＷＦ等）の固有の識別子であってもよい。データ構造には静的な情報が予め与えられていてもよいし、動的に情報が学習されてもよい。また、ノードそれぞれと、他の情報（例えばＭＴＵのサイズ、待ち時間、コスト、利用可能かどうかなど）とが結合していてもよい。
【０２１６】
（特定の競合状態を扱う他の実施例）
さらに行われた実験から、ネットワーク・アダプタの中には、ネットワーク・セグメントに完全登録される前に、媒体と（再）接続されていると誤って信号を出すものがあることが明らかとなった。例えば、ローミングの間、ネットワーク識別子を保持する記憶領域はまだ更新されず、従って、システムがこれらのネットワーク・アダプタが同じサブネットにロームバックしたと誤解することが考えられる。最終的には、デバイスが登録を終了すると、記憶領域は新しいネットワーク識別子と共に更新され、さらに別のローミング信号が生成される。両方の情報が一緒にゲートされ、インターフェイスがネットワークでの登録を終了した時に１度だけ信号が送られると、このシナリオ通りに進む。しかし、ポーリングの際、「ネットワークと接続中」を示す信号が以前に生成された場合に、ネットワークＩＤがいつ有効になるかを判定するのは困難である。
【０２１７】
基本的に、ローミング中のノードはネットワークと媒体アクセスレベルで通信できるため、事実上媒体と接続状態にあるが、登録プロセスが完了していないので、事実上、リンクを通じていずれのアプリケーションデータを送ることはまだできない。従って、この状態を補償するのが望ましい。このような補償を行う方法の一つとして、一般にはエコー要求／応答パケットとして知られているリンク確認フレームを送ることによってピア接続を判定する方法がある。これらのエコーやｐｉｎｇフレームは１つのピア（ローミング中のノードである可能性が高い）によって生成され、双方向のピア・トゥ・ピア接続が達成可能か判定する。要求を出しているピアがその要求に対する応答フレームを受け取る場合、二重通信が実現し終了する。この時点で、次に切断状態になるまでＮＰＯＡ情報が有効であると見なされる。また、該当インターフェイス上のピアからのフレーム受領等、他の情報によって、ローミング中のノードが登録プロセスが終了し、双方向通信が達成可能であることが想定可能となる。
【０２１８】
ネットワーク・インターフェイスと内在するプロトコルスタック状況間における別の競合状態は、問題を生じることがある。デバイスは、新しいネットワーク・セグメントに移動し、以下のインターフェイスから正確に信号が送られるようにすることは可能であるが、トランスポート・スタック自体はフローするアプリケーションデータのルーティング・テーブルに必要な調整を行わないことがある。この状態を補償するために、内在するトランスポートのルーティング・テーブルに変更が生じる度に、付加的信号であるＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＵＴＥ＿ＣＨＡＮＧＥが追加されて生成される。この信号が示されると、ローミング中のサブシステムクライアントはピア・システムとの接続が達成可能かどうか判定するために必要なアクションは何でも行う。これによりローミング中のクライアントは、ルーティング修正がピアへの通信経路に影響を及ぼしたかどうか判定するために、内在するトランスポートのルーティング・テーブルを介して列挙する必要がある。また、上記記載のアルゴリズム等のように、よりイントルーシブな他のアルゴリズムが、ピア間に双方向通信経路が存在することを確認するために行われてもよい。
【０２１９】
（非接続ネットワークを通じたローミング例）
本発明の非限定的な好ましい実施形態の他の一側面として、いわゆる「非接続ネットワーキング」（ｄｉｓｊｏｉｎｔ ｎｅｔｗｏｒｋｉｎｇ）モードでＭＭＳ（モビリティ管理サーバ）にアクセスするためのアルゴリズム及び構成がある。新しいアルゴリズムによって、あるネットワークからは別のネットワークにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、ＭＭＳとの通信を確立する／持続するのに使われる、代替のネットワークアドレスを動的／静的に見つけ出すことができるようになる。
【０２２０】
一般に、アルゴリズムによって、通信中にＭＥＳ（モバイル端末システム）に送るための、ＭＭＳが利用可能な代替アドレスのリストが可能となる。このように、ＭＭＳはＭＥＳに、一つ以上のＭＭＳネットワークアドレスもしくは他のネットワークに対応した他のＭＭＳのアイデンティティを、単一のネットワークによる通信によって送る。一例として、該リストは、回路構築の際に送付可能である。また、該リストは途中で変更可能である。この場合、該リストは接続が確立されている間のいかなる時にも更新が可能である。
【０２２１】
ＭＥＳが別のネットワークへと移動するとき、ＭＥＳは新規のネットワークの接続ポイントからＭＭＳとコンタクトをとるために、ＭＭＳの「エイリアス」（ａｌｉａｓ）アドレス／アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、又はその他の情報を共有していなくても、ＭＥＳは新規のネットワーク接続を通じてＭＭＳとのコンタクトを再確立することができる。
【０２２２】
この新しい技術を簡略化したフローチャートを図２１に示す。ＭＭＳ１０２は、２つの異なる非接続ネットワーク、すなわちネットワーク・セグメントＮ１及びＮ２と接続しているものとする。ＭＥＳ１０４は、最初にＭＭＳ１０２とネットワークＮ１を介して接続されるものとする。ネットワークＮ１を介してＭＥＳ１０４とＭＭＳ１０２との間で接続が確立されるとすぐに、ＭＭＳ１０２は、ＭＥＳ１０４に対して、ＭＭＳが一以上の他のネットワーク（例えば、ネットワークＮ２）から求められるネットワークアドレスのリストＬ又は他の識別子を送ることができる。ＭＥＳ１０４は、該リストＬを受け取り、記憶する。その後、ＭＥＳ１０４は別のネットワーク（Ｎ２）に移動する時、ＭＥＳ１０４はこの記憶されたリストＬにアクセスし、それを用いて新規のネットワーク（Ｎ２）を通じたＭＭＳ１０２との通信を効果的に再確立することが可能となる。
【０２２３】
この新しいアルゴリズムには、非接続ネットワークを通じて、ＭＭＳ１０２と通信するための代替ネットワークアドレス又は他の識別子をより効率的に取得することに加え、少なくともいくつかの用途がある。その用途の一例としてネットワークオペレーションがある。例えば、図２１に示すアルゴリズムを用いて、多くのネットワーク（いくつか、又は全てが無線ネットワーク）からの安全なファイアウォール／ゲートウェイ、及びコーポレートバックボーンとしてＭＭＳ１０２が使用される安全なネットワークをセットアップでき、モバイルノード１０４が安全に、接続を切断されることなく別々のネットワーク全てに移動することが可能となる。例えば、ＭＭＳ１０２がハブとして１つの太いパイプでコーポレートネットワーク、及び論理的に分離した多くのネットワークを接続する多数の小さなスポークと接続しているとする。ネットワークは論理的に分離しているため、ＭＭＳ１０２（この例ではルータとして動作可能）を介した場合を除いて、１つのネットワーク・セグメント上のトラフィックが別のネットワーク・セグメントに達することができない。
【０２２４】
普通、ネットワーク・セグメントからネットワーク・セグメントへ移動するノードにとって、ＭＭＳ１０２との接続に使用される「メインパブリックアドレス又は初期アドレス」への戻り方を示す、各ネットワーク・セグメントに設けられた情報／経路（つまり、デフォルトルート等）をルーティングが必要となる。
接続が確立されるとすぐに、そのアドレスが接続の存続のために用いられる。ＭＥＳ１０４からフレームが送られる時、クライアント及び及び中間ノード（ルータ）におけるＩＰネットワーク（層３）のインフラストラクチャは、フレームの目的地アドレスを見て、最終目的地（ＭＭＳ１０２）にパケットを正確に送る。このことは、一般にＩＰ送信（ＩＰ ｆｏｒｗａｒｄｉｎｇ）、あるいはＩＰルーティングと呼ばれるもので行われる。この機能がオンになると、あるネットワーク・セグメントのフレーム（ブロードキャスト等）が別のネットワーク・セグメントへ流れる。ＩＰ送信をしないと、あるセグメントに送られたフレームは他のセグメントへ送られることはないので、通信パイプが切断され、あるいは非接続ネットワークができてしまう。
【０２２５】
図２１に示す代替アドレスリストは、ルーティング情報のうちの幾つかをＭＥＳ１０４に送出する、又は配布する効果を有する。従って、各セグメントは、ＭＭＳ１０２とつながっている他のセグメントの情報はない状態で離散された状態となる。ＭＥＳ１０４はＭＭＳ１０２によって認証可能であるため、ＭＭＳは認証されたＭＥＳユニット１０４にのみリストＬを送る。ＭＥＳ１０４が別のネットワーク・セグメントへ移動する時、ＭＥＳ１０４は自動的に正しいアドレスを選択し、それを用いて途中ＭＭＳとの通信を開始／継続することができる。従って、非接続ネットワークの問題は解決され、ルーティング・インフラストラクチャの変更は必要なくなる。これにより、有効なユーザに対してのみネットワークへのアクセスを有効にすることによって、より安全なコンピュータ環境を提供することが可能となる。
【０２２６】
例えば、このようにユーザレベルのセキュリティ／暗号化と組み合わせてＭＭＳ１０２を用いることで、コーポレートバックボーンからのトラフィック、及びコーポレートバックボーンへのトラフィックを、上記のローミング技術を用いてそのセグメント上のノードを目的地としたフレームのみに限定することが可能である。フレームは選択的に暗号化でき、スポーク・ネットワーク・インフラストラクチャが有効にしたデバイスによって行われる可能性のある盗聴を阻止することができる。
【０２２７】
例を図２２に示す。図２２において、ＭＭＳ１０２は通信網やルート情報を共有しない４つの別々に分かれたネットワーク（Ｉａ、Ｉｂ、Ｉｃ、Ｉｄ）と接続されている。どの点から見ても各ネットワークＩは島となっている。コーポレートバックボーン上の有線通信を用いてネットワークの一つ（例えば、Ｉｃ）とドッキングしているＭＥＳ１０４を想定する。例えば、ＭＥＳ１０４は１９２．１６８．ｘ．ｘネットワーク上のアドレスを取得してＭＭＳ１０２と通信するものとする。
【０２２８】
ある理由によりＭＥＳが１０．１．ｘ．ｘ（Ｉａ）ネットワークに渡る、又は移動する必要があるものとする。１０．１．ｘ．ｘ（Ｉａ）ネットワークは１９２．１６８．ｘ．ｘ（Ｉｂ）ネットワークのことを知らない（つまり、（Ｉｂ）ネットワークへのルートがない）ため、ＭＥＳ１０４がその領域へ移動する時に、たとえＭＭＳが通信パイプに接続されていても通信パイプは切断される。また、モバイルノード１０４が図示される他の１０．ｘネットワークのいずれかと接続する場合においても同じことが起こる。
【０２２９】
図２１に示すアルゴリズムを用いて、接続開始時間の（あるいは他の方法で）ＭＭＳ１０２は各種非接続ネットワークＩａ、Ｉｂ、Ｉｃ、Ｉｄに関するそのインターフェイスアドレスをＭＥＳ１０４と共有し、ＭＥＳはこれらを記録する。一旦記録されると、ＭＥＳ１０４は上記ネットワークのいずれか一つに移動して新しいネットワーク・セグメントに移動したことを検出する場合、ＭＥＳは適切なネットワークアドレスを選択し、そのネットワーク・セグメントでＭＭＳと通信できる。２以上のアドレスが使用される場合、ＭＥＳ１０４は適切なアドレスを選択してスピード、コスト、有効性、ホップ等、多くのメトリクスに基づき使用する。図２１と同様のリストを受け取らなかったＭＥＳ１０４は、その「ホーム」ネットワーク以外のネットワークを通じてＭＭＳと接続することができないので、種々のネットワーク間の移動を事実上阻まれることになる。
【０２３０】
他に、図２１の技術は分散型ネットワーク・インターフェイスに用いられる。今日のネットワークにおいて、ネットワーク・アドレス・トランスレータ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒｓ；ＮＡＴｓ）として知られるものが開発されている。この従来の技術を利用すれば、一つの公開ネットワークアドレスを用いるだけで多くのネットワークデバイスはインターネット上の情報へのアクセスが可能となる。この技術は、単一もしくはわずかなデバイスを介してインターネットに向けられた情報やクエリを全て送ることによって上記の機能を可能とする。該デバイスはネットワーク層で要求を記録し、その後パケットのアドレスとポート情報をデバイスのアドレス／ポートのタプルに再度対応付けし、それをその目的地に送信する。インターネット、あるいは他の当該ネットワークからフレームを受け取ると同時に、デバイスはリバースルックし、そのアドレス／ポートのタプル情報を開始デバイスのものと取り替えて、フレームを送り返す。これらの対応付けはＮＡＴにおいても静的に定義される。
【０２３１】
誰かがＬＡＮ／ＷＬＡＮの内部でＭＭＳ１０２を使用するために、それをＮＡＴに置くことを想定する。現在、ＭＭＳ１０２がＮＡＴでない限り、あるいは異なるプロキシを用いてＭＭＳと通信を全て行うことによって、誰かがイントラネットの境界範囲外に移動する時、ＭＭＳと通信するアドレスがもはやアクセス可能ではないため、ＭＭＳとはアクセス可能ではない。図２１のアルゴリズムを用いれば、ＭＭＳと直接接続されていない別のインターフェイスアドレスを静的／動的に明確にすることができる。従って、上記のアルゴリズムを使用すれば、ＭＥＳ１０４は自動的に適切な非接続アドレスを選択し、イントラネットの領域外のネットワークと接続する時にそのアドレスを使用することができる。
【０２３２】
この概要を図２３に示す。ノードがインターフェイス“ｄ”からインターフェイス“ｇ”へ渡るとする。ＭＭＳ１０２にローカルインターフェイスを供給するだけではアクセスはできない。ＭＥＳ１０４は分散されたインターフェイスの優先順位を知る必要がある。それからＭＥＳ１０４は必要なアドレスを選択してインターフェイス“ｇ”上で使用する。その後、ＮＡＴ２０００は、各パケットに関するネットワークアドレス／ポート情報を、内部インターフェイス“ｃ”アドレスへ適切に変換する。ＭＭＳ１０２からＭＥＳ１０４に送られるフレームには逆の処理が行われる。
【０２３３】
（ポリシー管理及びロケーションベースのサービス例）
本発明の他の非限定的な実施形態として、多くのメトリクスに基づき付加的なセキュリティ、コスト削減、サービスを提供することが独自にできる手法を提供する。上記のＭＭＳはＭＥＳが確立する各アプリケーションのセッションと深く関わっているため、どちらの側（すなわち、ＭＭＳおよび／またはＭＥＳ）もポリシーベースのルールを適用してＭＥＳとその最終的なピアとの間の通信を適合して制御することができる。さらに、ＭＭＳおよび／またはＭＥＳはデバイスのロケール、又は近接性（ｐｒｏｘｉｍｉｔｙ）、並びにネットワークの接続に基づきアプリケーション要求を調整又は修正することができる。例えば、ＭＭＳおよび／またはＭＥＳは学習され静的に定義されて適用されたルールエンジン、あるいは確立する各アプリケーションセッション、又は試みる要求に対するポリシーに基づく他のルールを含むことができる。ＭＭＳはさらにＭＥＳにこのようなルールの幾つか、全くなし、あるいは一部、および／または処理を配分して、メータリング（ｍｅｔｅｒｉｎｇ）、又は傍受者によるモバイルデバイスへの侵入（ｒｏｇｕｅ ａｔｔａｃｋｓ）に対するセキュリティを提供する。分散型トポロジで利用可能な特定の他のポリシー管理技術とは違い、ＭＭＳが中心となり、ルールやポリシー決定を管理し、それらを通信中いかなる時にも遠隔地のデバイスに分散させる。
【０２３４】
ルール自体は、ユーザ、ユーザ・グループ、デバイス、デバイスグループ、プロセスアプリケーションアイデンティティ、および／またはネットワークの接続ポイントに基づき構成可能である。一旦定義されると（学習されると）、ルールは組み合わされて、例えば、以下のものを含む種々の異なる事象、活動、および／またはサービスを管理し、制御する。
【０２３５】
・遠隔地のデバイスへの侵入アクセスの拒否、許可、又は調整
・アイデンティティに基づく特定のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・利用可能、又は許可された帯域幅へのアクセスの拒否、許可、又は調整
・他のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・内容又は情報の修正、調整、又は変更
このような決定は例えば、以下の要素を含む種々の異なる要素に基づいて行われる。
【０２３６】
・モバイルデバイスについての近接性、場所、高度、および／または他の特性
・日時
・アプリケーション又はプロセスアイデンティティ、アドレス等
・アプリケーション動作（例えば、帯域幅条件）
・現在のネットワーク状態
・他の静的又は動的要素
さらに分散型アーキテクチャを利用することで、ＭＭＳは同じ決定セットを適用又は共有することができる。ポリシー管理処理および／または意思決定をＭＭＳに行わせるのは、例えばモバイル装置がエンジンを実行するのに限られた処理能力を持ったり、帯域幅の限度が適用されたり、あるいはセキュリティが目的の場合に望ましい。
【０２３７】
サンプルＭＥＳの制御に使用される可能性のあるメトリクス（ルール）の幾つかを示すテーブルの例を図２４に示す。このテーブルは静的又は動的のどちらかに内容を占めてもよいし、場合によっては通信前、通信中、又は通信後に更新されてもよい。例えば、ユーザはテーブルの項目を定義するルール・エディタ（例えば、ウィザード）や他のメカニズムを使用することができる。他の構成例において、メトリクスが学習に基づくシステムによって自動的に定義され、あるいは状態の変更に基づき動的に変更される。また、ルールにはそれぞれ優先順位が割り当てられ、テーブルの場所で暗示、または割り当てによって明確に指定される。この優先順位によってエンジンが期待動作を正確に決定することができる。付加的なユーザインターフェイスの機能によって、システム管理者やデバイスのユーザはルールエンジンに問い合わせて所定のルールセットの機能を試みることが可能となる。
【０２３８】
ポリシー管理決定の基になる、以下のメトリクスをはじめとする多数のメトリクス例を示すテーブル例を図２４に示す。
【０２３９】
・ＭＥＳの通信機能（送信のみ、受信のみ、送受信）
・ＭＥＳの要求がプロキシされるか否か
・ＭＥＳのソースポート
・ＭＥＳのソースアドレス
・ＭＥＳの目的地ポート
・ＭＥＳの目的地アドレス
・ＭＥＳのプロトコル
・利用可能な帯域幅量
・プロセス名、アイデンティティ又は他の特性
・ネットワーク名、アイデンティティ又は他の特性
・ロケーション（例えば、ＧＰＳ座標又は他のロケーション情報）
・ネットワークの接続ポイント
・ユーザの識別子、アイデンティティ又は他の特性
・他のメトリクス
上記テーブル例は完全なリストではなく、本発明は上記テーブル例のメトリクス項目の範囲に限定されるものではない。ネットワークアクセス及び権利付与に関してモバイルノードの所望の動作を示すために、該項目はこの例のように具体的であり、あるいは包括的なメカニズム（例えば、ワイルドカード）であることが可能である。
【０２４０】
図２４のテーブル例には、メトリクスに基づくポリシー管理決定の結果を示す「否定要求」項目がさらに含まれる。一例として、図２４のテーブルに示す特定の項目例は、利用可能な帯域幅が一秒間で１００，０００バイト以下に低減される場合、目的地ポート２０、２１との接続は否定され、減速されることを示す。さらに、示した特定の例において、ルール（列）３、４によってネットワークトラフィックのみがＭＭＳへ、又はＭＭＳから流れることが可能となる（プロキシが行われない他の全てのネットワークトラフィックは暗に破棄される。）。
【０２４１】
一例において、各ＲＰＣ要求又はフレームが処理される前に、ルールエンジンはオペレーションの状況を決定するよう求められる。このプロセスの結果に基づき、その要求が許可、否定、あるいは遅延される。ポリシー管理決定をするためにＭＭＳおよび／またはＭＥＳによって行われる処理のフローチャート例を図２５に示す。
【０２４２】
先に概略を説明したローミング技術と、利用可能な他のロケーション又はナビゲーション情報とを組み合わせることによって、ＭＭＳはモバイル端末システムがいつ１箇所の接続ポイントから別の接続ポイントへ移動したか検出する。ネットワーク・トポロジの環境の変化を検出するために、モバイル端末システムの機能と関連してこの情報を組み合わせることによって、ロケールによって本発明はロケーションベースの傍受及びサービスの付加的なレベルを提供することができる。
【０２４３】
この情報の可能性を十分実現させるために、インターネット・モビリティ・プロトコルとＰＲＣエンジンの両方の改良点について概要を説明する。新しいＲＰＣのプロトコル及び構成の改良点が追加され、この機能が可能となる。これらを以下に挙げる。
【０２４４】
（ロケーション変更ＲＰＣ（Ｌｏｃａｔｉｏｎ Ｃｈａｎｇｅ ＲＰＣ）の例）
モバイル端末システムが、インターフェイス支援型ローミング又はグローバル・ポジショニング・システムから変更を検出するといった他の方法を用いて新しい接続ポイントへ移動したことを判断した時、モバイル端末システムは、フォーマットされた「ロケーション変更ＲＰＣ要求（Ｌｏｃａｔｉｏｎ Ｃｈａｎｇｅ ＲＰＣ Ｒｅｑｕｅｓｔ）」メッセージをそのピア、この場合モビリティ管理サーバに送る。「ロケーション変更ＲＰＣ」は、一以上の接続ポイント識別情報をタイプ、長さ、値の形式にフォーマットする。タイプは識別情報の種類を示し、対応するタイプはＡＳＣＩＩの４８ビットＩＥＥＥ ＭＡＣ アドレス、ＩＰＶ４ アドレス、ＩＰＶ６ アドレス、経度、緯度、高度、接続機構名を含むが、これらに限定されない。長さは識別データのバイト長を示し、該データは実際の接続ポイント識別子を含む。「ロケーション変更ＲＰＣ要求」を受け取ると、モビリティ管理サーバは、接続ポイント識別子、並びにモビリティ端末システムの識別子、ユーザ名、ＰＩＤ等の他の関連情報を含む「ロケーション変更警告（Ｌｏｃａｔｉｏｎ Ｃｈａｎｇｅ Ａｌｅｒｔ）」を作成する。この警告は「ロケーション変更ＲＰＣ要求」内で使用された同じタイプ、長さ、データフォーマットでフォーマットされる。その後警告サブシステムが、警告のために登録された全てのアプリケーションにロケーション変更警告と共にこの情報を送る。警告のために登録されたアプリケーションは、現在の活動状況のモニタ、長期の動作ログ、ポリシー管理エンジン、第三者アプリケーション等の監視アプリケーション、並びにネットワーク管理ツールを含んでもよい。単一のそのような第三者アプリケーションは、このロケーション情報と、ウェブベースのマップとを組み合わせてモバイル端末システム又はＭＭＳの場所についての詳細情報を提供する。そのようなアプリケーションに加えて、他の動作をロケーション変更警告と関連付けることができる。これには、電子メールの送信、メッセージの印刷、プログラムの起動、および／またはポリシー変更が含まれる。
【０２４５】
ロケーション変更ＲＰＣはそのヘッダにロケーション変更、距離変更、又は速度変更によってトリガされたかどうかを示すフィールドを含む。
【０２４６】
ある例では、ＭＥＳは自身が移動したことを知らない場合がある。ＭＥＳが接続する媒体やネットワーク・アダプタに応じて、ＭＭＳはＭＥＳが新しい接続ポイントに渡ったことを知らせる唯一のエンティティであってもよい。モバイルルータの場合を考えてみる。ルータ以降のアドレスは同じままで、ルータのアドレスだけが変わる。この場合、ＭＭＳはＭＥＳのアドレスを新しく管理することを認識する。したがって、動作の検出を完了するためには、行動検出するためのＭＥＳとＭＭＳの両方の組み合わせの動作の検出が必要となる。本実施の形態では、ソースアドレスが変更され、新しいＩＭＰメッセージが受け取られる時に、ＭＭＳはＩＭＰ層でクライアントの行動を検出する。このことが行われると、ＭＭＳは局所的にロケーション変更警告を生成する。また、ＭＭＳは接続ポイントが変更したというメッセージをＭＥＳに送る。
【０２４７】
（トポロジＲＰＣの例）
「トポロジＲＰＣ要求（Ｔｏｐｏｌｏｇｙ ＲＰＣ Ｒｅｑｕｅｓｔ）」はモビリティ管理サーバからモバイル端末システムへ送られる。このＲＰＣの受け取りと同時に、モバイル端末システムはそのローカルデータ記憶装置に記憶されるトポロジ情報を読み出して、トポロジＲＰＣ応答（Ｔｏｐｏｌｏｇｙ ＲＰＣ Ｒｅｓｐｏｎｓｅ）を作成する。トポロジＲＰＣ応答は、前後との接続のタイプ、長さ情報が後に続く全長フィールド（Ｔｏｔａｌ Ｌｅｎｇｔｈ Ｆｉｅｌｄ）、タイプ、長さ情報が後に続く接続ポイント識別子、および、サブネットおよびネットワーク情報を示す値のデータによってフォーマットされる。この情報は、サーバで提供されるモバイルネットワークの完全なトポロジカル・マップを作成するのにサーバ上で使用されてもよい。
【０２４８】
（ロケーション情報ＵＩの例）
サーバ上のユーザインターフェイスは、ロケーション情報を対応付けして表示するための方法を提供する。このロケーション情報は、各アクティブなモバイル端末システムが利用でき、長期の動作ログは全てのアクティブなモバイル端末システム及び以前アクティブだったモバイル端末システムのロケーション変更履歴を保持する。ユーザインターフェイスによって、システム管理者は接続ポイント情報を人間が読める形式に構成できる。例えば、接続ポイント情報が４８ビットのＩＥＥＥ ＭＡＣアドレスの形式で与えられると、サーバ上のユーザインターフェイスを介して提供される情報と共にこのＭＡＣアドレスが表示される。接続ポイントが「ホールマークカード（ＨａｌｌＭａｒｋ Ｃａｒｄｓ）」店のアクセスポイントを示すと、次の情報「ホールマーク、住所、市、州、郵便番号」を提示するように設定される。この情報がユーザに対して表示されることによって、「ホールマーク、住所、市、州、郵便番号」情報が提供されることになる。
【０２４９】
（ロケーションＲＰＣタイマーの例）
設定可能なタイマーがモバイル端末システムに設けられており、ロケーション変更ＲＰＣがモバイル端末システムからモビリティ管理サーバに送信される速度を制限する。タイマー間隔が接続ポイントの変更が起こる速度よりも大きい場合、モバイル端末システムはタイマー間隔が終了するまで待ってから別のロケーション変更ＲＰＣを生成する。
【０２５０】
（距離変更通知の例）
距離メトリクスは、ロケーション変更ＲＰＣの生成をトリガするために設けられる。この設定によって、ユーザが前にいた元のポイントから、ｎフィート、ｎキロメータ毎、あるいは他の適当な測定単位で３次元的に移動する時に、更新を送信するようにシステムが構成される。デフォルトによってこの設定は無効になる。この設定を可能にすることによって、設定された距離間隔を上回った時に変更通知が出される。
【０２５１】
（速度閾値通知の例）
速度変更メトリクスは、ロケーション変更ＲＰＣの生成をトリガするために設けられる。このパラメータは、一時間当たりのマイル等、一秒当たりの距離で構成される。このパラメータは、上限及び下限、並びに到達した速度を持続する必要のある時間間隔（すなわち、１０分間で０ＭＰＨ、又は１分間で７０ＭＰＨ）を特定する。このスピードに達すると、ロケーション変更通知が生成される。
【０２５２】
［応用例］
本発明は、実社会の様々な場面で応用される。例を以下に示す。
【０２５３】
（断続的に接続される携帯用コンピュータ）
多くの企業では、在宅勤務や、自宅で仕事をする社員がいることがある。そういった社員は、多くの場合、ラップトップコンピュータを使用して仕事をする。作業中に、社員は一般に自分達のラップトップコンピュータをドッキングポート又は他のコネクタを使用してイーサネット（Ｅｔｈｅｒｎｅｔ）等のローカルエリア・ネットワーク（Ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）に接続する。ＬＡＮ接続によってネットワークサービス（例えば、プリンタ、ネットワークドライブ）やネットワーク・アプリケーション（例えば、データベースアクセス、電子データサービス）にアクセスが可能となる。
【０２５４】
あるプロジェクトに取り組む社員が、晩に帰宅する必要があり、自宅で仕事を続行したいとする。この社員は、ラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「サスペンド」して、ラップトップコンピュータを片付け、そのラップトップコンピュータを自宅に持って帰ることができる。
【０２５５】
自宅に戻るとすぐに、その社員はラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「レジューム」して、ダイアルアップ接続を介して、および／またはインターネットを通じてオフィスＬＡＮと再接続する。（ラップトップコンピュータが一時的に中断された間、ネットワークに対するラップトップコンピュータとそのアプリケーションのプロキシを継続した）モビリティ管理サーバは、ラップトップコンピュータを再認証し、ラップトップコンピュータとの通信を再開する。
【０２５６】
自宅で仕事をしている社員の立場から見ると、ネットワーク・ドライブ・マッピング、印刷サービス、電子メールセッション、データベースクエリ、他のネットワークサービスやアプリケーションは全て会社で終わった状態そのままである。さらに、モビリティ管理サーバはラップトップコンピュータのセッションのプロキシを継続したため、社員の会社から自宅までの帰宅途中に、いずれのネットワーク・アプリケーションもラップトップコンピュータのセッションを終了しなかった。このように、本発明は、上記のような状況や他の状況において、高性能且つ有用な同一又は複数のネットワーク媒体を通じて効果的にセッションを持続可能とする。
【０２５７】
（モバイル在庫管理及び倉庫への応用）
大きな倉庫又は小売店チェーンを想定する。この構内において、在庫管理を行う従業員がパーソナルラップトップコンピュータ、並びにハンドヘルドデータ収集ユニットや端末装置などを搭載した乗物（すなわち、トラックやフォークリフト）を使って商品の在庫管理が行われる。
【０２５８】
倉庫や小売店の従業員は、ネットワークサブネットのわからない、管理監督の必要な不慣れなコンピュータユーザであることが多い。本発明によって倉庫ユーザがモバイルネットワークの複雑さを感じない、即使用可能なシステムの構築が可能となる。倉庫ユーザは、アクセスポイントの範囲内及び範囲外を動いたり、自分たちのモバイル端末システム１０４の中断及び再開をしたり、ホストセッション、ネットワークアドレス、又はトランスポート接続を気にせずに、位置を変えたりできる。さらに、モビリティ管理サーバ１０２の管理ソフトウェアは、従業員の生産能力を測るのに利用される処理数等のメトリクスを管理関係者に提供する。また、管理によりネットワークサブネット及びアクセスポイントを使用して従業員が最後にいたとされる物理的な位置を判定できる。
【０２５９】
（モバイル医療への応用）
無線ＬＡＮ技術を利用して幾つかの建物間でネットワーク通信を行う大きな病院を想定する。各建物は独自のサブネット上にある。本発明によって看護士や医師がハンドヘルドパーソナルコンピュータや端末を持って病室から病室を動き、病院のデータベースから患者情報の読出しや書込みが可能となる。ローカルデータベースやワールド・ワイド・ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）を通じて、薬物治療や医療処置に関する最新記事へのアクセスが即座に可能となる。本発明はモバイル端末システム１０４への連続的な接続が可能なので、病院にいる間（一方向又は双方向の）ポケットベルはもはや必要なくなる。メッセージはモバイル端末システム１０４を介して医療関係者に直接送られる。倉庫の従業員の場合と同様、医療関係者は自分たちが利用しているモバイルネットワークについてわかる必要はない。さらに、モバイル端末システム１０４によって医療関係者は無線送信が望ましくないとされるエリア内（例えば、電波の放射によって医療機器に障害が出る可能性のある場所）での無線伝送ができなくなるが、中断したところから容易に再開して再接続可能となる。
【０２６０】
（トラック輸送及び貨物輸送）
運送会社は、貨物の状況を把握するのに本発明を用いる。倉庫に入っている間は、モバイル端末システム１０４はＬＡＮ技術を使用して倉庫内の貨物数を更新する。ローカルサービスから離れている間は、モバイル端末システム１０４はＣＤＰＤやＡＲＤＩＳ等のＷｉｄｅ Ａｒｅａ ＷＡＮサービスを使用してリアルタイムで貨物の状況や位置を維持できる。モバイル端末システム１０４はネットワーク・インフラストラクチャ間を自動的に切り替えるので、輸送関係者にネットワーク・トポロジの複雑さを感じさせない。
モバイル企業
企業の社員は、８０２．１１．等のインフラストラクチャが設けられた企業構内にいる間、本発明によるシステムを使用して、電子メール、ウェブコンテント、メッセージサービスへのアクセスを行う。ポケットベルサービスや他のモバイル機器のサービスはもはや必要ないので、これらを維持するためのコストが削減される。既存のモバイル機器サービスの多くが提供する、コストのかかる「利用回数制（ｐａｙ−ｐｅｒ−ｕｓｅ）」モデルに対し、モバイルインフラストラクチャは一度の資金支出で購入できる。
【０２６１】
（ＩＰマルチプリケーション）
ある組織がインターネットに接続する必要のあるＬＡＮを有する場合、ＬＡＮの管理者には二つの選択肢がある。一つ目の選択は、ＬＡＮ上の全てのコンピュータに対して割り当てるためのグローバルアドレスを取得することであり、二つ目の選択は、グローバルアドレスをいくつか取得して、アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ１０２を使用することである。多数のＩＰアドレスを取得することは、高額であるか不可能であるかである場合が多い。インターネット・サービス・プロバイダ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｉｖｉｄｅｒ； ＩＳＰ）を利用してインターネットにアクセスする小規模の企業は、ＩＳＰが割り当てるＩＰアドレスだけを使用することになる。ＩＰアドレスの数は同時にインターネットに接続できるコンピュータの数を制限する。また、ＩＳＰは一回の接続につき課金するため、インターネット接続が必要なコンピュータが増えれば増えるほど、この方法はそれだけ費用がかかる。
【０２６２】
アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ１０２を用いれば、これらの問題の多くを解決することができる。企業は、ＩＳＰを介してインターネットに接続するためのハードウェアとしてモビリティ管理サーバ１０２を用いることができる。これにより、モバイル端末システム１０４は容易に接続することができる。インターネットへの接続は全てモビリティ管理サーバ１０２を通じて行われるため、一つのアドレスだけをＩＳＰから取得すればよい。このように、アドレス・マルチプライヤとして本発明を用いることによって、企業はわずかな数（多くの場合一つ）のアドレスとアカウントをＩＳＰから取得すればよくなり、全体のＬＡＮでインターネットへの同時接続（十分な帯域幅が備えられていることを前提として）が可能になる。
【０２６３】
以上現在最も実用的且つ好適な実施形態とされる例と共に本発明を説明したが、本発明は開示した実施形態に限定されず、添付クレームの範囲内で種々に変形、同等に構成できるものとする。
【図面の簡単な説明】
【図１】
本発明のモバイル・コンピューティング・ネットワークの全体図である。
【図２】
モバイル端末システムとモビリティ管理サーバとのソフトウェア・アーキテクチャを例示するものである。
【図２Ａ】
モバイル端末システムとモビリティ管理サーバとの間で情報伝達を実行するステップを例示している。
【図３】
モバイル・インターセプタ・アーキテクチャを例示している。
【図３Ａ】
モバイル・インターセプタによって実行されるステップを例示したフローチャートである。
【図３Ｂ】
ＲＰＣ作業要求を扱うＲＰＣエンジン（ＲＰＣ ｅｎｇｉｎｅ）によって実行されるステップを例示したフローチャートである。
【図４】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ａ】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ｂ】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ｃ】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図６】
受信された作業要求を例示している。
【図７】
受信された作業要求が、どのようにそれぞれ別の優先度のキューにディスパッチされるかを示すものである。
【図８】
上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図９】
上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図１０Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１０Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１０Ｃ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１１】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ｃ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ｃ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１４Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１４Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１５Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１５Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１６】
リスナのデータ構造を例示している。
【図１７】
モバイル相互接続ローミング（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ ｒｏａｍｉｎｇ）を提供するためのステップを例示している。
【図１７Ａ】
モバイル相互接続ローミング（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ ｒｏａｍｉｎｇ）を提供するためのステップを例示している。
【図１８】
モバイル相互接続ローミング（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ ｒｏａｍｉｎｇ）を提供するためのステップを例示している。
【図１９Ａ】
インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図１９Ｂ】
インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図２０】
インターフェイスによって補助されているローミングのトポロジ・ノード・データ構造を例示する。
【図２１】
モビリティ管理システムのネットワークアドレスを、非接続ネットワーク・トポロジにおいてモバイル端末システムに配布する技術を例示している。
【図２２】
図２１の技術を、セキュアな通信を実現するために利用した例を示している。
【図２３】
図２１の技術を、分散型ネットワーク・インターフェイス・シナリオにおけるネットワークアドレスの変換に用いた例を示している。
【図２４】
ポリシー管理テーブルを例示している。
【図２５】
ポリシー管理処理のステップを例示したフローチャートである。
Claims (125)
- ネットワーク接続ポイントを介してネットワークと接続されるモバイルコンピュータ装置を少なくとも一つ含むモバイル・コンピューティング・ネットワークであって、モバイルコンピュータ装置のロケーションを含む様々なメトリクスに基づくポリシー管理ルールを適用するポリシー管理手法を特徴とするモバイル・コンピューティング・ネットワーク。
- 前記ルールの属性についての処理は、モバイルコンピュータ装置あるいはモビリティ管理サーバのいずれか、またはその両方に対して分配され適用されることを特徴とする請求項１記載のネットワーク。
- 前記ルールの優先順位は、そのようなテーブルの項目における位置で暗示されるか、あるいは期待動作を確実にするための順序が明白に記されることを特徴とする請求項１または２記載のネットワーク。
- 前記ルールの属性のデータ保存は、中央管理サービスを介して局所的または集中的に管理されることを特徴とする請求項１、２または３記載のネットワーク。
- 特定のアプリケーションの動作は、サービス費用、ネットワーク接続ポイント、信頼関係等を含む多数のメトリクスに基づいて修正されることを特徴とする請求項１〜４のいずれか１項に記載のネットワーク。
- 動作修正の結果、前記ルールの属性に基づいて要求が許可、拒否、または遅延されることを特徴とする請求項１〜５のいずれか１項に記載のネットワーク。
- アプリケーションが既に開始されている場合でも、アプリケーションプロセスを修正するため、１つのルール、または一連のルールが呼び出されることを特徴とする請求項１〜６のいずれか１項に記載のネットワーク。
- 現在位置情報（ロケーション）は、アプリケーション動作を管理するため、あるいはモバイルコンピュータ装置の関連情報を提供するためにも使用されることを特徴とする請求項１〜７のいずれか１項に記載のネットワーク。
- 距離測定に伴う動作速度は、アプリケーションの動作または通信パスを変更するために使用されることを特徴とする請求項１〜８のいずれか１項に記載のネットワーク。
- ロケーション情報の結果としてトポロジ情報が抽出され、表示されることを特徴とする請求項１〜９のいずれか１項に記載のネットワーク。
- ネットワーク接続ポイントを介してネットワークと接続されるモバイルコンピュータ装置を少なくとも一つ含むモバイル・コンピューティング・ネットワークにおいて、ネットワーク接続ポイントの識別子の少なくとも一部分に基づき、前記モバイルコンピュータ装置が異なるネットワーク・セグメントに移動したかどうか検出するインターフェイス補助ローミングリスナを備えることを特徴とするモバイル・コンピューティング・ネットワーク。
- 前記モバイルコンピュータ装置はネットワーク・インターフェイス・アダプタを含み、前記インターフェイス補助ローミングリスナは前記ネットワーク・インターフェイス・アダプタから前記ネットワーク接続ポイントの識別子を取得することを特徴とする請求項１１記載のネットワーク。
- 前記インターフェイス補助ローミングリスナは、前記ネットワーク接続ポイントの識別子をネットワーク接続についての詳細情報に相関させる情報を記憶するネットワーク・トポロジ・マップを保持することを特徴とする請求項１１記載のネットワーク。
- 前記インターフェイス補助ローミングリスナは、前記ネットワークとの通信がいつ中断または再確立されるかを検出することを特徴とする請求項１１記載のネットワーク。
- 前記インターフェイス補助ローミングリスナは、（ａ）ネットワーク通信の中断及び再確立、及び（ｂ）前記ネットワーク接続ポイントの識別子の変化の検出を受けて、ローミング信号を生成することを特徴とする請求項１４記載のネットワーク。
- モバイルコンピュータ装置において使用されるインターフェイスベースのリスナであって、インターフェイスベースのリスナは少なくとも１つのネットワーク・インターフェイス・アダプタからの情報と、少なくとも１つのネットワークスタックから入手可能な情報を統合して、前記モバイルコンピュータ装置が新しいネットワーク接続ポイントに移動したかどうか判定することを特徴とする、インターフェイスベースのリスナ。
- ネットワーク接続ポイント情報を含むネットワーク接続情報を提供するネットワーク・トポロジ・マップを含むことを特徴とする請求項１６記載のインターフェイスベースのリスナ。
- 上記リスナは学習情報に基づき前記ネットワーク・トポロジ・マップを動的に構成することを特徴とする請求項１７記載のリスナ。
- イベント発生に基づき、ステータスをチェックするステータスチェッカーを含むことを特徴とする請求項１６記載のインターフェイスベースのリスナ。
- 前記イベントはタイマーのタイムアウト、ローレベルのローミング・ドライバ・コールバック、ネットワーク・レベル・アクティビティ・ヒントのいずれかを含むことを特徴とする請求項１６記載のインターフェイスベースのリスナ。
- モバイルコンピュータ装置が既に現在のネットワーク接続ポイントを訪れたかどうかインターフェイスに照会する接続情報探索部を含むことを特徴とする請求項１６記載のインターフェイスベースのリスナ。
- 新規のネットワーク・セグメントにおいて有効となる現行のアドレスを登録または再取得する接続構成を含むことを特徴とする請求項１６記載のインターフェイスベースのリスナ。
- インターフェイスから提供された情報の少なくとも一部分に基づいて、前記モバイルコンピュータ装置が異なるネットワーク・セグメントに移動したことの検出を受けてローミング信号を生成するローミング信号発生部を含むことを特徴とする請求項１６記載のインターフェイスベースのリスナ。
- 予め割り当てられたアドレスがまだ有効かどうかを判定するヒューリスティック・アナライザをさらに含むことを特徴とする請求項２３記載のインターフェイスベースのリスナ。
- モバイルノードが新しいネットワーク接続ポイントに移動したかどうか判定する方法であって、
（ａ）ネットワーク・インターフェイスからネットワーク接続ポイントの識別情報を受け取るステップと、
（ｂ）前記ネットワーク接続ポイントの識別情報を使用して前記モバイルノードが新しいネットワーク接続ポイントに移動したかどうかを判定するステップと、
（ｃ）前記ステップ（ｂ）を受けて信号を生成するステップとを含むことを特徴とする方法。 - 請求項２５記載の方法であって、
ネットワーク・トポロジ・マップを保持するステップ、及び前記ネットワーク・トポロジ・マップを使用して前記ステップ（ｃ）を行うステップをさらに含むことを特徴とする方法。 - 請求項２５記載の方法であって、
前記ステップ（ｃ）はローミング信号を生成するステップを含むことを特徴とする方法。 - 請求項２５記載の方法であって、
前記ステップ（ｂ）はネットワーク・アダプタから前記ネットワーク接続ポイントの識別情報を取得するステップを含むことを特徴とする方法。 - 請求項２５記載の方法であって、
一般的な信号をサポートするネットワーク・インターフェイスが利用不可の場合、選択的ローミング検出メカニズムにフォールバックするステップをさらに含むことを特徴とする方法。 - 請求項２５記載の方法であって、
前記ネットワーク接続ポイント情報の少なくとも一部に応じて、代わりになるネットワーク接続パスの中から選択するステップをさらに含むことを特徴とする方法。 - 非接続のネットワークを介したモバイルシステムとの通信を円滑にするための方法であって、
第１ネットワークを介してノードと前記モバイルシステム間の通信を確立するステップと、
前記第１ネットワークと非接続の少なくとも第２ネットワーク上の前記ノードを識別するデータを、前記第１ネットワークを介して前記モバイルシステムに送信するステップと、
前記第２ネットワークを介して前記モバイルシステムと前記ノードとの通信を確立するために前記データを使用するステップとを含むことを特徴とする方法。 - 請求項３１記載の方法であって、
前記第１ネットワークを介して前記ノードに前記データを送信する前に、前記第２ネットワークを介して前記ノードとの通信許可を付与するために前記モバイルシステムを認証するステップをさらに含むことを特徴とする請求項３１記載の方法。 - 請求項２１記載の方法であって、
前記送信ステップは、分配されるインターフェイスデータを前記第１ネットワークを介して前記モバイルシステムに送信するステップを含むことを特徴とする方法。 - 前記モバイルコンピュータ装置のネットワーク・インターフェイス・アダプタは、前記ネットワークと物理的に接続されていることを特徴とする請求項１２記載のネットワーク。
- 前記モバイルコンピュータ装置はネットワーク接続ポイントと無線で通信することを特徴とする請求項１２記載のネットワーク。
- モバイルコンピュータシステムが複数の別個のネットワーク間を移動する際、モバイルコンピュータシステムとネットワークノードとの間での通信を維持するための方法であって、
第１ネットワークセグメントを介してモバイルシステムとノード間の通信を確立するステップと、
第１ネットワークセグメントを介して、それぞれ第１ネットワークセグメントとは別個の複数のさらなるネットワーク・セグメントを介して前記ノードとの通信を再確立する際に使用される情報をモバイルコンピュータシステムに送信するステップと、
前記情報を使用して、前記別個の複数のさらなるネットワーク・セグメントのいずれかを介してモバイルコンピュータシステムとノード間の通信を再確立するステップとを含むことを特徴とする方法。 - 請求項３６記載の方法であって、
前記情報は分配されるインターフェイスデータを含むことを特徴とする方法。 - 複数の別個のセグメントを有するネットワークにおいて最少コストルーティングを提供するための方法において、
（ａ）ネットワークと、一時的に接続されたモバイルコンピュータ装置との間の通信を確立するステップと、
（ｂ）一時的に接続されたモバイルコンピュータ装置が前記複数の別個のセグメント間を移動することができるローミング機構を使用するステップと、
（ｃ）モバイル・コンピューティングのローミングに応じて、ネットワークとモバイルコンピュータ装置との間の通信を再確立するための選択的で有効なネットワークパスを効率的に自動選択可能にするように、少なくとも１つのポリシーパラメータに実行させるステップとを含むことを特徴とする方法。 - 請求項３８記載の方法であって、
前記ポリシーパラメータは、帯域幅、１データ単位当りのコスト、およびサービス品質からなるグループの中から選択された要素を含むことを特徴とする方法。 - 少なくとも１つのピア・コンピュータシステムと、物理的リンクを介してネットワークに接続された少なくとも一つのモバイルコンピュータ装置とを含むモバイル・コンピューティング・ネットワークにおいて、
ネットワークに接続されたサーバを含み、前記サーバは、モバイルコンピュータ装置への物理的リンクが一時的に中断される間に、モバイルコンピュータ装置とピア・コンピュータシステムとの間の継続的な仮想データストリーム接続を維持するために、モバイルコンピュータ装置とピア・コンピュータシステムとの間の通信をプロキシすることを特徴とするモバイル・コンピューティング・ネットワーク。 - 前記モバイルコンピュータ装置は前記ネットワーク上の位置アドレスを有し、前記ピア・コンピュータシステムは仮想アドレスを使用して前記サーバと通信し、前記サーバは前記仮想アドレスを前記位置アドレスと対応付けることを特徴とする請求項４０記載のネットワーク。
- 前記サーバは、前記モバイルコンピュータ装置がその位置アドレスをいつ変更したかを検出し、前記仮想アドレスを前記変更された位置アドレスと再び対応付けることを特徴とする請求項４１記載のネットワーク。
- 前記サーバは、前記モバイルコンピュータ装置が一時的に圏外に出たり、またはローミング中である時に、前記モバイルコンピュータ装置に代わって、キューに入れ、前記ピア・コンピュータシステムからの要求に応答することを特徴とする請求項４０記載のネットワーク。
- 前記サーバは、従来のトランスポート・プロトコルを用いて前記モバイルコンピュータ装置と通信することを特徴とする請求項４０記載のネットワーク。
- 前記サーバは、遠隔プロシージャ・コールを用いて前記モバイルコンピュータ装置と通信することを特徴とする請求項４４記載のネットワーク。
- 前記サーバは、インターネット・モビリティ・プロトコルを用いて前記モバイルコンピュータ装置と通信することを特徴とする請求項４４記載のネットワーク。
- 前記インターネット・モビリティ・プロトコルは、ユーザ設定可能なタイムアウトに基づいてデータグラムの自動除去を行うことを特徴とする請求項４６記載のネットワーク。
- 前記インターネット・モビリティ・プロトコルは、ユーザ設定可能な再試行に基づいてデータグラムの自動除去を行うことを特徴とする請求項４６記載のネットワーク。
- 前記サーバは、前記モバイルコンピュータ装置によるネットワーク・リソースの消費に関するユーザ毎のポリシー管理を行うことを特徴とする請求項４０記載のネットワーク。
- 前記サーバは、ユーザ設定可能なセッション優先順位を、前記モバイルコンピュータ装置の前記セッションに付与することを特徴とする請求項４０記載のネットワーク。
- 前記モバイルネットワークは複数のサブネットワークを含み、前記モバイルコンピュータ装置は、前記モバイルコンピュータ装置によって前記複数のサブネットワークのうちの１つから前記複数のサブネットワークの別の１つへのローミングを可能にする他の手順と共に動的ホスト構成プロトコルを用いることを特徴とする請求項４０記載のネットワーク。
- 前記サーバは、モビリティ管理サーバを含むことを特徴とする請求項４０記載のネットワーク。
- 前記モバイルコンピュータ装置と前記サーバとを接続する少なくとも１つのモバイル相互接続をさらに含むことを特徴とする請求項４０記載のネットワーク。
- モバイルコンピュータ環境において少なくとも一つのモバイルコンピュータ装置との持続的な接続を維持する方法であって、
前記モバイルコンピュータ装置と、少なくとも一つのさらなるコンピュータ装置との間の少なくとも１つのセッションを管理するステップと、
モバイルコンピュータ装置が圏外に出たり、サスペンドしたり、あるいはネットワークアドレスを変更した時に、セッションを維持するステップとを含むことを特徴とする方法。 - 請求項５４記載の方法であって、
前記セッションのために少なくとも１つのユーザ設定可能なセッション優先順位を付与するステップをさらに含むことを特徴とする方法。 - 請求項５４記載の方法であって、
前記管理ステップは、前記モバイルコンピュータ装置によるネットワーク・リソースの消費を管理するステップを含むことを特徴とする方法。 - 請求項５４記載の方法であって、
前記モバイルコンピュータ環境は複数のサブネットワークを含み、前記維持ステップでは、動的ホスト構成プロトコルを使用して前記モバイルコンピュータ装置が前記サブネットワーク間を移動する時にセッションを維持することを特徴とする方法。 - 請求項５４記載の方法であって、
前記管理ステップは、前記モバイルコンピュータ装置とデータグラムのやり取りを行い、少なくとも１つのユーザ設定可能なパラメータに基づき前記データグラムのうち信頼性の低いデータグラムを自動的に除去することを特徴とする方法。 - 請求項５８記載の方法であって、
前記ユーザ設定可能なパラメータは、タイムアウトを含むことを特徴とする方法。 - 請求項５８記載の方法であって、
前記ユーザ設定可能なパラメータは、ユーザ設定可能な再試行番号を含むことを特徴とする方法。 - 請求項５４記載の方法であって、
前記モバイルコンピュータ装置に可変の位置アドレスを付与するステップをさらに含み、前記管理ステップはセッションと関連付けされる仮想アドレスに前記位置アドレスを対応付けするステップを含むことを特徴とする方法。 - 請求項５４記載の方法であって、
前記管理ステップは、遠隔プロシージャ・コール・プロトコルを用いてモバイルコンピュータ装置と通信するステップを含むことを特徴とする方法。 - 請求項５４記載の方法であって、
前記維持ステップは、前記モバイルコンピュータ装置を前記モバイルコンピュータ環境に接続する物理的リンクの中断時に前記セッションの接続状態を維持することを特徴とする方法。 - 請求項５４記載の方法であって、
前記管理ステップは、少なくとも１つの標準的なトランスポート・プロトコルを用いて前記モバイルコンピュータ装置と通信するステップを含むことを特徴とする方法。 - 請求項５４記載の方法であって、
前記モバイルコンピュータ装置は複数のアプリケーションソースを含み、前記管理ステップは、前記複数のアプリケーションソースからのデータをストリームに融合するステップと、前記ストリームを送信するステップとを含むことを特徴とする方法。 - 請求項６５記載の方法であって、
前記ストリームから融合されたデータを逆多重化して、前記逆多重化されたデータを複数の関連する目的地に送信するステップをさらに含むことを特徴とする方法。 - 請求項６５記載の方法であって、
前記ストリームはフレームを含み、前記融合処理は、モバイルコンピュータ環境の最大伝送単位に適合するように、前記フレームに対して動的なサイズ変更を行う処理を含むことを特徴とする方法。 - 請求項６５記載の方法であって、
前記融合処理は、信頼性の低いデータのセマンティクスを維持する処理と、前記信頼性の低いデータを前記セマンティクスに基づき選択的に破棄する処理とを含むことを特徴とする方法。 - 請求項５４記載の方法であって、
前記管理ステップは、前記モバイルコンピュータ装置へのメッセージの保証配信、および／または前記モバイルコンピュータ装置からのメッセージの保証配信を行う処理を含むことを特徴とする方法。 - 請求項５４記載の方法であって、
前記管理ステップは、前記モバイルコンピュータ装置がどのネットワーク・リソースにアクセス可能かを制御する処理を含むことを特徴とする方法。 - 少なくとも一つのさらなるコンピュータ装置を含むモバイルコンピュータ環境において少なくとも一つのモバイルコンピュータ装置との持続的な接続を維持するためのサーバであって、
モバイルコンピュータ装置が圏外に出たり、サスペンドしたり、あるいはネットワークアドレスを変更した時にセッションを維持し、前記モバイルコンピュータ装置と少なくとも一つのさらなるコンピュータ装置間の少なくとも１つのセッションを管理するセッション・マネージャを含むサーバ。 - 前記セッション・マネージャは、前記セッションのためにユーザ設定可能なセッション優先順位を少なくとも１つ付与するセッション優先キューを含むことを特徴とする請求項７１記載のサーバ。
- 前記セッション・マネージャは、前記モバイルコンピュータ装置によるネットワーク・リソースの消費を管理する手段を含むことを特徴とする請求項７１記載のサーバ。
- 前記モバイルコンピュータ環境は、複数のサブネットワークを含み、前記セッション・マネージャは、動的ホスト構成プロトコルを使用して前記モバイルコンピュータ装置が前記サブネットワーク間を移動する時にセッションを維持することを特徴とする請求項７１記載のサーバ。
- 前記セッション・マネージャは、前記モバイルコンピュータ装置とデータグラムのやり取りを行い、少なくとも１つのユーザ設定可能なパラメータに基づき前記データグラムのうち信頼性の低いデータグラムを自動的に除去することを特徴とする請求項７１記載のサーバ。
- 前記ユーザ設定可能なパラメータは、タイムアウトを含むことを特徴とする請求項７５記載のサーバ。
- 前記ユーザ設定可能なパラメータは、ユーザ設定可能な再試行番号を含むことを特徴とする請求項７５記載のサーバ。
- 前記モバイルコンピュータ環境は、前記モバイルコンピュータ装置に可変の位置アドレスを付与し、前記セッション・マネージャはセッションと関連付けされる仮想アドレスに前記位置アドレスを対応付けすることを特徴とする請求項７１記載のサーバ。
- 前記セッション・マネージャは、遠隔プロシージャ・コール・プロトコルを用いてモバイルコンピュータ装置と通信することを特徴とする請求項７１記載のサーバ。
- 前記モバイルコンピュータ環境は、前記モバイルコンピュータ装置を前記モバイルコンピュータ環境に接続する少なくとも１つの物理的リンクを含み、前記セッション・マネージャは、前記物理的リンクの中断時に前記セッションの接続状態を維持することを特徴とする請求項７１記載のサーバ。
- 前記セッション・マネージャは、少なくとも１つの標準的なトランスポート・プロトコルを用いて前記モバイルコンピュータ装置と通信することを特徴とする請求項７１記載のサーバ。
- 前記モバイルコンピュータ装置は複数のアプリケーションソースを含み、前記セッション・マネージャは、前記複数のアプリケーションソースに関連するデータをストリームに融合して、前記ストリームを送信することを特徴とする請求項７１記載のサーバ。
- 前記モバイルコンピュータ装置は複数のアプリケーションソースを含み、前記セッション・マネージャは、前記複数のアプリケーションソースからの融合されたデータを逆多重化して、前記逆多重化されたデータを複数の関連する目的地に送信することを特徴とする請求項７１記載のサーバ。
- 前記セッション・マネージャは、フレームを用いて前記モバイルコンピュータ装置と通信し、モバイルコンピュータ環境の最大伝送単位に適合するように、前記フレームに対して動的なサイズ変更を行うことを特徴とする請求項７１記載のサーバ。
- 前記セッション・マネージャは、信頼性の低いデータのセマンティクスを維持し、前記信頼性の低いデータを前記セマンティクスに基づき選択的に破棄することを特徴とする請求項７１記載のサーバ。
- 前記セッション・マネージャは、前記モバイルコンピュータ装置へのメッセージの保証配信、および／または前記モバイルコンピュータ装置からのメッセージの保証配信を行うことを特徴とする請求項７１記載のサーバ。
- 前記セッション・マネージャは、前記モバイルコンピュータ装置がアクセス可能なネットワーク・リソースの制御を行うことを特徴とする請求項７１記載のサーバ。
- プロキシ・サーバを含むモバイルコンピュータ環境において、モバイルコンピュータ装置が圏外に出たり、サスペンドしたり、あるいはネットワークアドレスを変更した時に、少なくとも一つのさらなるコンピュータ装置と持続的な仮想接続を維持するモバイルコンピュータ装置であって、
トランスポート・ドライバ・インターフェイスと、
前記トランスポート・ドライバ・インターフェイスと接続されるモバイル・インターセプタを含み、
前記モバイル・インターセプタは、前記トランスポート・ドライバ・インターフェイスでのネットワークサービス要求を傍受し、前記ネットワークサービス要求に応じて、遠隔プロシージャ・コールを生成し、前記遠隔プロシージャ・コールを前記プロキシ・サーバに送信することを特徴とするモバイルコンピュータ装置。 - 前記モバイル・インターセプタは、ユーザ設定可能なセッション優先順位を少なくとも１つ付与するセッション優先キューを含むことを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、前記モバイルコンピュータ装置によるネットワーク・リソースの消費を管理する手段を含むことを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ環境は、複数のサブネットワークを含み、前記モバイルコンピュータ装置は、前記モバイルコンピュータ装置が前記サブネットワーク間を移動する時に位置アドレスを取得するために動的ホスト構成プロトコルを使用する手段をさらに含むことを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、前記プロキシ・サーバとデータグラムのやり取りを行い、少なくとも１つのユーザ設定可能なパラメータに基づき前記データグラムのうち信頼性の低いデータグラムを自動的に除去することを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記ユーザ設定可能なパラメータは、タイムアウトを含むことを特徴とする請求項９２記載のモバイルコンピュータ装置。
- 前記ユーザ設定可能なパラメータは、ユーザ設定可能な再試行番号を含むことを特徴とする請求項９２記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ装置は、前記モビリティ管理サーバを仮想アドレスと対応付ける、関連付けされた可変の位置アドレスを有することを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、遠隔プロシージャ・コール・プロトコルを用いて前記モビリティ管理サーバと通信することを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ環境は、前記モバイルコンピュータ装置を前記モバイルコンピュータ環境に接続する少なくとも１つの物理的リンクを含み、前記モバイル・インターセプタは、前記物理的リンクでの中断後に前記モビリティ管理サーバから少なくとも１つのセッションの更新された接続状態情報を受け取ることを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ装置は標準的なトランスポート・プロトコル・ハンドラを含み、前記モバイル・インターセプタは前記標準的なトランスポート・プロトコル・ハンドラを介して前記モビリティ管理サーバと通信することを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ装置は複数のアプリケーションソースを含み、前記モバイル・インターセプタは前記複数のアプリケーションソースに関連するデータをストリームに融合して、前記ストリームを前記モビリティ管理サーバに送信することを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ装置は複数のアプリケーション目的地を含み、前記モバイル・インターセプタは、前記複数のアプリケーションソースからの融合されたデータを逆多重化して、前記逆多重化されたデータを複数のアプリケーション目的地に送信することを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、フレームを用いて前記プロキシ・サーバと通信し、モバイルコンピュータ環境の最大伝送単位に適合するように、前記フレームに対して動的なサイズ変更を行うことを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、信頼性の低いデータのセマンティクスを維持し、前記信頼性の低いデータを前記セマンティクスに基づき選択的に破棄することを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、前記プロキシ・サーバへのメッセージの保証配信、および／または前記プロキシ・サーバからのメッセージの保証配信を行うことを特徴とする請求項８８記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、前記モバイルコンピュータ装置がアクセス可能なモバイルコンピュータ環境のリソースの制御を行うことを特徴とする請求項８８記載のモバイルコンピュータ装置。
- トランスポート・ドライバ・インターフェイスと、
前記トランスポート・ドライバ・インターフェイスと接続されるモバイル・インターセプタを含む少なくとも一つのモバイルコンピュータ装置を含むモバイルコンピュータ環境であって、
前記モバイル・インターセプタは、前記トランスポート・ドライバ・インターフェイスでのネットワークサービス要求を傍受し、前記ネットワークサービス要求を受けて、遠隔プロシージャ・コールを生成し、前記遠隔プロシージャ・コールを少なくとも１つのプロキシ・サーバに送信し、
前記プロキシ・サーバは、前記モバイル・インターセプタによって送信された前記遠隔プロシージャ・コールを受信及び処理するワーク・ディスパッチャを少なくとも１つ含み、前記プロキシ・サーバは、前記モバイルコンピュータ装置が前記モバイルコンピュータ環境と一時的に切断された時に、前記モバイルコンピュータ装置の代わりに仮想セッションをプロキシするプロキシ・キューを含むことを特徴とするモバイルコンピュータ環境。 - ネットワーク接続ポイントを介してネットワークと接続されるモバイルコンピュータ装置を少なくとも一つ含むモバイル・コンピューティング・ネットワークにおいて、ネットワーク接続ポイントの識別子の少なくとも一部分に基づき、前記モバイルコンピュータ装置が異なるネットワーク・セグメントに移動したかどうか検出するインターフェイス補助ローミングリスナを含むことを特徴とするモバイル・コンピューティング・ネットワーク。
- 前記モバイルコンピュータ装置はネットワーク・インターフェイス・アダプタを含み、前記リスナは前記ネットワーク・インターフェイス・アダプタから前記ネットワーク接続ポイントの識別子を取得することを特徴とする請求項１０６記載のネットワーク。
- 前記リスナは、前記ネットワーク接続ポイントの識別子をネットワーク接続についての詳細情報に相関させる情報を記憶するネットワーク・トポロジ・マップを保持することを特徴とする請求項１０６記載のネットワーク。
- 前記リスナは、前記ネットワークとの通信がいつ中断または再確立されるかを検出することを特徴とする請求項１０６記載のネットワーク。
- 前記インターフェイス補助ローミングリスナは、（ａ）ネットワーク通信の中断及び再確立、及び（ｂ）前記ネットワーク接続ポイントの識別子の変化の検出を受けて、ローミング信号を生成することを特徴とする請求項１０９記載のネットワーク。
- 前記モバイルコンピュータ装置において使用されるインターフェイスベースのリスナであって、インターフェイスベースのリスナは少なくとも１つのネットワーク・インターフェイス・アダプタからの情報と、少なくとも１つのネットワークスタックから入手可能な情報を統合して、前記モバイルコンピュータ装置が新しいネットワーク接続ポイントに移動したかどうか判定することを特徴とするインターフェイスベースのリスナ。
- ネットワーク接続ポイント情報を含むネットワーク接続情報を提供するネットワーク・トポロジ・マップを含むことを特徴とする請求項１１１記載のインターフェイスベースのリスナ。
- 上記リスナは学習情報に基づき前記ネットワーク・トポロジ・マップを動的に構成することを特徴とする請求項１１２記載のリスナ。
- イベント発生に基づき、ステータスをチェックするステータスチェッカーを含むことを特徴とする請求項１１１記載のインターフェイスベースのリスナ。
- 前記イベントはタイマーのタイムアウト、ローレベルのローミング・ドライバ・コールバック、ネットワーク・レベル・アクティビティ・ヒントのいずれかを含むことを特徴とする請求項１１１記載のインターフェイスベースのリスナ。
- モバイルコンピュータ装置が既に現在のネットワーク接続ポイントを訪れたかどうかインターフェイスに照会する接続情報探索部を含むことを特徴とする請求項１１１記載のインターフェイスベースのリスナ。
- 新しいネットワーク・セグメントにおいて有効となる現行のアドレスを登録または再取得する接続構成を含むことを特徴とする請求項１１１記載のインターフェイスベースのリスナ。
- インターフェイスから提供された情報の少なくとも一部分に基づいて、前記モバイルコンピュータ装置が異なるネットワーク・セグメントに移動したことの検出を受けてローミング信号を生成するローミング信号発生器を含むことを特徴とする請求項１１１記載のインターフェイスベースのリスナ。
- 予め割り当てられたアドレスがまだ有効かどうかを判定するヒューリスティック・アナライザをさらに含むことを特徴とする請求項１１８記載のインターフェイスベースのリスナ。
- モバイルノードが新しいネットワーク接続ポイントに移動したかどうか判定する方法であって、
（ａ）ネットワーク・インターフェイスからネットワーク接続ポイントの識別情報を受け取るステップと、
（ｂ）前記ネットワーク接続ポイントの識別情報を使用して前記モバイルノードが新しいネットワーク接続ポイントに移動したかどうかを判定するステップと、
（ｃ）前記ステップ（ｂ）を受けて信号を生成するステップを含むことを特徴とする方法。 - 請求項１２０記載の方法であって、
ネットワーク・トポロジ・マップを保持するステップ、及び前記ネットワーク・トポロジ・マップを使用して前記ステップ（ｃ）を行うステップをさらに含むことを特徴とする方法。 - 請求項１２０記載の方法であって、
前記ステップ（ｃ）はローミング信号を生成するステップを含むことを特徴とする方法。 - 請求項１２０記載の方法であって、
前記ステップ（ｂ）はネットワーク・アダプタから前記ネットワーク接続ポイントの識別情報を取得するステップを含むことを特徴とする方法。 - 請求項１２０記載の方法であって、
一般的な信号をサポートするネットワーク・インターフェイスが利用不可の場合、選択的ローミング検出機構にフォールバックするステップをさらに含むことを特徴とする方法。 - 請求項１２０記載の方法であって、
前記ネットワーク接続ポイント情報の少なくとも一部分を受けて、択一的なネットワーク接続パスから選択するステップをさらに含むことを特徴とする方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/660,500 US7293107B1 (en) | 1998-10-09 | 2000-09-12 | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
| US27461501P | 2001-03-12 | 2001-03-12 | |
| PCT/US2001/028391 WO2002023362A1 (en) | 2000-09-12 | 2001-09-12 | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004509539A true JP2004509539A (ja) | 2004-03-25 |
| JP2004509539A5 JP2004509539A5 (ja) | 2005-04-07 |
Family
ID=26956948
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002527943A Pending JP2004509539A (ja) | 2000-09-12 | 2001-09-12 | コンピュータ環境におけるモバイル他の断続的接続性を提供する方法および装置 |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP1364296A4 (ja) |
| JP (1) | JP2004509539A (ja) |
| AU (1) | AU2001289010A1 (ja) |
| CA (1) | CA2421609A1 (ja) |
| WO (1) | WO2002023362A1 (ja) |
Cited By (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006352337A (ja) * | 2005-06-14 | 2006-12-28 | Ntt Docomo Inc | 通信装置及び通信制御方法 |
| JP2007306577A (ja) * | 2002-08-01 | 2007-11-22 | Research In Motion Ltd | 常時オンのワイヤレスインターネットプロトコル通信 |
| JP2008508837A (ja) * | 2004-06-10 | 2008-03-21 | ネットモーション ワイヤレス インコーポレイテッド | コンピュータ環境におけるモバイル及び他の断続的接続性を提供する方法及び装置 |
| JP2009119849A (ja) * | 2007-10-23 | 2009-06-04 | Ricoh Co Ltd | 情報処理装置、情報処理方法及びプログラム |
| JP2009532765A (ja) * | 2006-03-31 | 2009-09-10 | アルカテル−ルーセント ユーエスエー インコーポレーテッド | 存在状態情報に基づいてセッションを維持するための方法およびデバイス |
| JP2009535873A (ja) * | 2006-04-28 | 2009-10-01 | ジェムアルト エスアー | サーバと通信オブジェクトとの間のデータ伝送 |
| US7711835B2 (en) | 2004-09-30 | 2010-05-04 | Citrix Systems, Inc. | Method and apparatus for reducing disclosure of proprietary data in a networked environment |
| US7748032B2 (en) | 2004-09-30 | 2010-06-29 | Citrix Systems, Inc. | Method and apparatus for associating tickets in a ticket hierarchy |
| US7760693B2 (en) | 2004-12-10 | 2010-07-20 | Nec Corporation | Packet distribution system, PAN registration device, PAN control device, packet transfer device, and packet distribution method |
| US7779034B2 (en) | 2005-10-07 | 2010-08-17 | Citrix Systems, Inc. | Method and system for accessing a remote file in a directory structure associated with an application program executing locally |
| US7870153B2 (en) | 2006-01-24 | 2011-01-11 | Citrix Systems, Inc. | Methods and systems for executing, by a virtual machine, an application program requested by a client machine |
| JP2011070279A (ja) * | 2009-09-24 | 2011-04-07 | Fujifilm Corp | アプリケーション・サーバおよびその動作制御方法 |
| US8024568B2 (en) | 2005-01-28 | 2011-09-20 | Citrix Systems, Inc. | Method and system for verification of an endpoint security scan |
| US8090797B2 (en) | 2009-05-02 | 2012-01-03 | Citrix Systems, Inc. | Methods and systems for launching applications into existing isolation environments |
| US8095940B2 (en) | 2005-09-19 | 2012-01-10 | Citrix Systems, Inc. | Method and system for locating and accessing resources |
| US8302101B2 (en) | 2004-09-30 | 2012-10-30 | Citrix Systems, Inc. | Methods and systems for accessing, by application programs, resources provided by an operating system |
| JP2013520138A (ja) * | 2010-02-16 | 2013-05-30 | クゥアルコム・インコーポレイテッド | インテリジェントな無線選択をレガシーおよび非レガシーアプリケーションに提供する方法および装置 |
| US8533846B2 (en) | 2006-11-08 | 2013-09-10 | Citrix Systems, Inc. | Method and system for dynamically associating access rights with a resource |
| US8731547B2 (en) | 2007-09-27 | 2014-05-20 | Panasonic Corporation | Network node and mobile terminal |
| US9009720B2 (en) | 2007-10-20 | 2015-04-14 | Citrix Systems, Inc. | Method and system for communicating between isolation environments |
| US9178965B2 (en) | 2011-03-18 | 2015-11-03 | Qualcomm Incorporated | Systems and methods for synchronization of application communications |
| US9264868B2 (en) | 2011-01-19 | 2016-02-16 | Qualcomm Incorporated | Management of network access requests |
| JP2017502394A (ja) * | 2013-12-05 | 2017-01-19 | クラウドストライク インコーポレイテッド | Ｒｐｃコールの傍受 |
Families Citing this family (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8078727B2 (en) | 1998-10-09 | 2011-12-13 | Netmotion Wireless, Inc. | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
| US7293107B1 (en) | 1998-10-09 | 2007-11-06 | Netmotion Wireless, Inc. | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
| US7562146B2 (en) * | 2003-10-10 | 2009-07-14 | Citrix Systems, Inc. | Encapsulating protocol for session persistence and reliability |
| US20050198379A1 (en) | 2001-06-13 | 2005-09-08 | Citrix Systems, Inc. | Automatically reconnecting a client across reliable and persistent communication sessions |
| WO2003061188A1 (en) * | 2002-01-14 | 2003-07-24 | Netmotion Wireless, Inc. | Method and apparatus for providing secure connectivity in mobile and other intermittent computing environments |
| US7984157B2 (en) * | 2002-02-26 | 2011-07-19 | Citrix Systems, Inc. | Persistent and reliable session securely traversing network components using an encapsulating protocol |
| US7661129B2 (en) | 2002-02-26 | 2010-02-09 | Citrix Systems, Inc. | Secure traversal of network components |
| US8068833B2 (en) * | 2002-04-26 | 2011-11-29 | Nokia Corporation | Candidate access router discovery |
| JP4290967B2 (ja) | 2002-11-26 | 2009-07-08 | Ｎｅｃインフロンティア株式会社 | 無線ＬＡＮネットワークＱｏＳ制御システム、基地局、端末、ＱｏＳ制御方法およびプログラム |
| FR2856540A1 (fr) * | 2003-06-19 | 2004-12-24 | Filfree Networks | Architecture de reseau local sans fil |
| DE10346007A1 (de) * | 2003-10-02 | 2005-04-28 | Siemens Ag | Kommunikationseinrichtung und Verfahren zum Einstellen einer Sicherheitskonfiguration einer Kommunikationseinrichtung |
| US7594018B2 (en) * | 2003-10-10 | 2009-09-22 | Citrix Systems, Inc. | Methods and apparatus for providing access to persistent application sessions |
| US7760882B2 (en) | 2004-06-28 | 2010-07-20 | Japan Communications, Inc. | Systems and methods for mutual authentication of network nodes |
| US7725716B2 (en) | 2004-06-28 | 2010-05-25 | Japan Communications, Inc. | Methods and systems for encrypting, transmitting, and storing electronic information and files |
| AU2005266945A1 (en) | 2004-07-23 | 2006-02-02 | Citrix Systems, Inc. | A method and systems for securing remote access to private networks |
| AU2005266943C1 (en) | 2004-07-23 | 2011-01-06 | Citrix Systems, Inc. | Systems and methods for optimizing communications between network nodes |
| GB2417396A (en) | 2004-08-18 | 2006-02-22 | Wecomm Ltd | Internet protocol having session identifier for mobile device internet access |
| US8613048B2 (en) | 2004-09-30 | 2013-12-17 | Citrix Systems, Inc. | Method and apparatus for providing authorized remote access to application sessions |
| US8171479B2 (en) | 2004-09-30 | 2012-05-01 | Citrix Systems, Inc. | Method and apparatus for providing an aggregate view of enumerated system resources from various isolation layers |
| US8954595B2 (en) | 2004-12-30 | 2015-02-10 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP buffering |
| US7810089B2 (en) | 2004-12-30 | 2010-10-05 | Citrix Systems, Inc. | Systems and methods for automatic installation and execution of a client-side acceleration program |
| US8255456B2 (en) | 2005-12-30 | 2012-08-28 | Citrix Systems, Inc. | System and method for performing flash caching of dynamically generated objects in a data communication network |
| US7359919B2 (en) * | 2005-03-08 | 2008-04-15 | Microsoft Corporation | Reliable request-response messaging over a request-response transport |
| US8131825B2 (en) | 2005-10-07 | 2012-03-06 | Citrix Systems, Inc. | Method and a system for responding locally to requests for file metadata associated with files stored remotely |
| US8533338B2 (en) | 2006-03-21 | 2013-09-10 | Japan Communications, Inc. | Systems and methods for providing secure communications for transactions |
| JP2008098813A (ja) * | 2006-10-10 | 2008-04-24 | Matsushita Electric Ind Co Ltd | 情報通信装置、情報通信方法、及びプログラム |
| US8701010B2 (en) | 2007-03-12 | 2014-04-15 | Citrix Systems, Inc. | Systems and methods of using the refresh button to determine freshness policy |
| US8490148B2 (en) | 2007-03-12 | 2013-07-16 | Citrix Systems, Inc | Systems and methods for managing application security profiles |
| US8631147B2 (en) | 2007-03-12 | 2014-01-14 | Citrix Systems, Inc. | Systems and methods for configuring policy bank invocations |
| US8908700B2 (en) | 2007-09-07 | 2014-12-09 | Citrix Systems, Inc. | Systems and methods for bridging a WAN accelerator with a security gateway |
| US9979797B2 (en) * | 2012-07-27 | 2018-05-22 | Nokia Technologies Oy | Methods and apparatuses for facilitating utilization of cloud services |
| US9253545B2 (en) | 2013-12-04 | 2016-02-02 | Wowza Media Systems, LLC | Routing media content based on monetary cost |
| US9113182B2 (en) | 2013-12-04 | 2015-08-18 | Wowza Media Systems, LLC | Selecting a media content source based on monetary cost |
| WO2015147860A1 (en) * | 2014-03-28 | 2015-10-01 | Hewlett-Packard Development Company, L.P. | Rescheduling a service on a node |
| US10721680B2 (en) | 2016-04-21 | 2020-07-21 | At&T Intellectual Property I, L.P. | Method and apparatus for providing a virtual network function in a network |
| EP3987843A1 (en) * | 2019-06-20 | 2022-04-27 | Koninklijke Philips N.V. | Method to enhance system analysis |
| US11469890B2 (en) * | 2020-02-06 | 2022-10-11 | Google Llc | Derived keys for connectionless network protocols |
| CN113364652B (zh) * | 2021-06-30 | 2023-07-25 | 脸萌有限公司 | 网卡流量测试方法、装置、网络设备、***及可读介质 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000115253A (ja) * | 1998-09-30 | 2000-04-21 | Toshiba Corp | 通信方法、携帯端末装置及びゲートウェイ装置 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6006090A (en) * | 1993-04-28 | 1999-12-21 | Proxim, Inc. | Providing roaming capability for mobile computers in a standard network |
| US6249818B1 (en) * | 1993-06-30 | 2001-06-19 | Compaq Computer Corporation | Network transport driver interfacing |
| JP3492865B2 (ja) * | 1996-10-16 | 2004-02-03 | 株式会社東芝 | 移動計算機装置及びパケット暗号化認証方法 |
| JP3651721B2 (ja) * | 1996-11-01 | 2005-05-25 | 株式会社東芝 | 移動計算機装置、パケット処理装置及び通信制御方法 |
| US6091951A (en) * | 1997-05-14 | 2000-07-18 | Telxon Corporation | Seamless roaming among multiple networks |
| US6230004B1 (en) * | 1997-12-01 | 2001-05-08 | Telefonaktiebolaget Lm Ericsson | Remote procedure calls using short message service |
| US6147986A (en) * | 1998-03-06 | 2000-11-14 | Lucent Technologies Inc. | Address updating of wireless mobile terminal hosts affiliated with a wired network |
| FI105978B (fi) * | 1998-05-12 | 2000-10-31 | Nokia Mobile Phones Ltd | Menetelmä langattoman päätelaitteen kytkemiseksi tiedonsiirtoverkkoon ja langaton päätelaite |
-
2001
- 2001-09-12 AU AU2001289010A patent/AU2001289010A1/en not_active Abandoned
- 2001-09-12 WO PCT/US2001/028391 patent/WO2002023362A1/en active Application Filing
- 2001-09-12 CA CA002421609A patent/CA2421609A1/en not_active Abandoned
- 2001-09-12 EP EP01968790A patent/EP1364296A4/en not_active Ceased
- 2001-09-12 JP JP2002527943A patent/JP2004509539A/ja active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000115253A (ja) * | 1998-09-30 | 2000-04-21 | Toshiba Corp | 通信方法、携帯端末装置及びゲートウェイ装置 |
Cited By (49)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4638904B2 (ja) * | 2002-08-01 | 2011-02-23 | リサーチ イン モーション リミテッド | 常時オンのワイヤレスインターネットプロトコル通信 |
| JP2007306577A (ja) * | 2002-08-01 | 2007-11-22 | Research In Motion Ltd | 常時オンのワイヤレスインターネットプロトコル通信 |
| JP2008160826A (ja) * | 2002-08-01 | 2008-07-10 | Research In Motion Ltd | 常時オンのワイヤレスインターネットプロトコル通信 |
| JP2008508837A (ja) * | 2004-06-10 | 2008-03-21 | ネットモーション ワイヤレス インコーポレイテッド | コンピュータ環境におけるモバイル及び他の断続的接続性を提供する方法及び装置 |
| US7748032B2 (en) | 2004-09-30 | 2010-06-29 | Citrix Systems, Inc. | Method and apparatus for associating tickets in a ticket hierarchy |
| US7870294B2 (en) | 2004-09-30 | 2011-01-11 | Citrix Systems, Inc. | Method and apparatus for providing policy-based document control |
| US8302101B2 (en) | 2004-09-30 | 2012-10-30 | Citrix Systems, Inc. | Methods and systems for accessing, by application programs, resources provided by an operating system |
| US7711835B2 (en) | 2004-09-30 | 2010-05-04 | Citrix Systems, Inc. | Method and apparatus for reducing disclosure of proprietary data in a networked environment |
| US8065423B2 (en) | 2004-09-30 | 2011-11-22 | Citrix Systems, Inc. | Method and system for assigning access control levels in providing access to networked content files |
| US8352964B2 (en) | 2004-09-30 | 2013-01-08 | Citrix Systems, Inc. | Method and apparatus for moving processes between isolation environments |
| US7865603B2 (en) | 2004-09-30 | 2011-01-04 | Citrix Systems, Inc. | Method and apparatus for assigning access control levels in providing access to networked content files |
| US7760693B2 (en) | 2004-12-10 | 2010-07-20 | Nec Corporation | Packet distribution system, PAN registration device, PAN control device, packet transfer device, and packet distribution method |
| US8024568B2 (en) | 2005-01-28 | 2011-09-20 | Citrix Systems, Inc. | Method and system for verification of an endpoint security scan |
| US8312261B2 (en) | 2005-01-28 | 2012-11-13 | Citrix Systems, Inc. | Method and system for verification of an endpoint security scan |
| JP2006352337A (ja) * | 2005-06-14 | 2006-12-28 | Ntt Docomo Inc | 通信装置及び通信制御方法 |
| JP4628194B2 (ja) * | 2005-06-14 | 2011-02-09 | 株式会社エヌ・ティ・ティ・ドコモ | 通信装置、所要時間測定方法及び通信制御方法 |
| US8095940B2 (en) | 2005-09-19 | 2012-01-10 | Citrix Systems, Inc. | Method and system for locating and accessing resources |
| US7779034B2 (en) | 2005-10-07 | 2010-08-17 | Citrix Systems, Inc. | Method and system for accessing a remote file in a directory structure associated with an application program executing locally |
| US7870153B2 (en) | 2006-01-24 | 2011-01-11 | Citrix Systems, Inc. | Methods and systems for executing, by a virtual machine, an application program requested by a client machine |
| US8355407B2 (en) | 2006-01-24 | 2013-01-15 | Citrix Systems, Inc. | Methods and systems for interacting, via a hypermedium page, with a virtual machine executing in a terminal services session |
| US7954150B2 (en) | 2006-01-24 | 2011-05-31 | Citrix Systems, Inc. | Methods and systems for assigning access control levels in providing access to resources via virtual machines |
| US8051180B2 (en) | 2006-01-24 | 2011-11-01 | Citrix Systems, Inc. | Methods and servers for establishing a connection between a client system and a virtual machine executing in a terminal services session and hosting a requested computing environment |
| US7949677B2 (en) | 2006-01-24 | 2011-05-24 | Citrix Systems, Inc. | Methods and systems for providing authorized remote access to a computing environment provided by a virtual machine |
| US8010679B2 (en) | 2006-01-24 | 2011-08-30 | Citrix Systems, Inc. | Methods and systems for providing access to a computing environment provided by a virtual machine executing in a hypervisor executing in a terminal services session |
| US8117314B2 (en) | 2006-01-24 | 2012-02-14 | Citrix Systems, Inc. | Methods and systems for providing remote access to a computing environment provided by a virtual machine |
| US8341270B2 (en) | 2006-01-24 | 2012-12-25 | Citrix Systems, Inc. | Methods and systems for providing access to a computing environment |
| US8341732B2 (en) | 2006-01-24 | 2012-12-25 | Citrix Systems, Inc. | Methods and systems for selecting a method for execution, by a virtual machine, of an application program |
| KR101372011B1 (ko) * | 2006-03-31 | 2014-03-26 | 알카텔-루센트 유에스에이 인코포레이티드 | 세션 유지 방법, 하나 이상의 세션과 연관된 하나 이상의 그룹 형성 방법, 및 온라인 게임 세션 유지 시스템 |
| JP2009532765A (ja) * | 2006-03-31 | 2009-09-10 | アルカテル−ルーセント ユーエスエー インコーポレーテッド | 存在状態情報に基づいてセッションを維持するための方法およびデバイス |
| JP2009535873A (ja) * | 2006-04-28 | 2009-10-01 | ジェムアルト エスアー | サーバと通信オブジェクトとの間のデータ伝送 |
| US8533846B2 (en) | 2006-11-08 | 2013-09-10 | Citrix Systems, Inc. | Method and system for dynamically associating access rights with a resource |
| US10028190B2 (en) | 2007-09-27 | 2018-07-17 | Sun Patent Trust | Mobile terminal |
| US11082852B2 (en) | 2007-09-27 | 2021-08-03 | Sun Patent Trust | Mobile terminal |
| US10484920B2 (en) | 2007-09-27 | 2019-11-19 | Sun Patent Trust | Mobile terminal |
| US8731547B2 (en) | 2007-09-27 | 2014-05-20 | Panasonic Corporation | Network node and mobile terminal |
| US9178803B2 (en) | 2007-09-27 | 2015-11-03 | Panasonic Intellectual Property Corporation Of America | Network node and mobile terminal |
| US9642057B2 (en) | 2007-09-27 | 2017-05-02 | Sun Patent Trust | Network node and mobile terminal |
| US9009720B2 (en) | 2007-10-20 | 2015-04-14 | Citrix Systems, Inc. | Method and system for communicating between isolation environments |
| JP2009119849A (ja) * | 2007-10-23 | 2009-06-04 | Ricoh Co Ltd | 情報処理装置、情報処理方法及びプログラム |
| US8090797B2 (en) | 2009-05-02 | 2012-01-03 | Citrix Systems, Inc. | Methods and systems for launching applications into existing isolation environments |
| JP2011070279A (ja) * | 2009-09-24 | 2011-04-07 | Fujifilm Corp | アプリケーション・サーバおよびその動作制御方法 |
| JP2013520138A (ja) * | 2010-02-16 | 2013-05-30 | クゥアルコム・インコーポレイテッド | インテリジェントな無線選択をレガシーおよび非レガシーアプリケーションに提供する方法および装置 |
| US9603085B2 (en) | 2010-02-16 | 2017-03-21 | Qualcomm Incorporated | Methods and apparatus providing intelligent radio selection for legacy and non-legacy applications |
| US9264868B2 (en) | 2011-01-19 | 2016-02-16 | Qualcomm Incorporated | Management of network access requests |
| US9178965B2 (en) | 2011-03-18 | 2015-11-03 | Qualcomm Incorporated | Systems and methods for synchronization of application communications |
| US11876784B2 (en) | 2013-12-05 | 2024-01-16 | Crowdstrike, Inc. | RPC call interception |
| US10356047B2 (en) | 2013-12-05 | 2019-07-16 | Crowdstrike, Inc. | RPC call interception |
| US11082404B2 (en) | 2013-12-05 | 2021-08-03 | Crowdstrike, Inc. | RPC call interception |
| JP2017502394A (ja) * | 2013-12-05 | 2017-01-19 | クラウドストライク インコーポレイテッド | Ｒｐｃコールの傍受 |
Also Published As
| Publication number | Publication date |
|---|---|
| AU2001289010A1 (en) | 2002-03-26 |
| EP1364296A4 (en) | 2004-09-15 |
| EP1364296A1 (en) | 2003-11-26 |
| WO2002023362A1 (en) | 2002-03-21 |
| CA2421609A1 (en) | 2002-03-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004509539A (ja) | コンピュータ環境におけるモバイル他の断続的接続性を提供する方法および装置 | |
| US7778260B2 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
| US7136645B2 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
| US7644171B2 (en) | Mobile networking system and method using IPv4 and IPv6 | |
| US7293107B1 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
| US8078727B2 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
| US6546425B1 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
| US8060656B2 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
| JP2008508837A (ja) | コンピュータ環境におけるモバイル及び他の断続的接続性を提供する方法及び装置 | |
| US8909743B2 (en) | Dynamic session maintenance for mobile computing devices | |
| US7984492B2 (en) | Methods and apparatus for policy enforcement in a wireless communication system | |
| US7107609B2 (en) | Stateful packet forwarding in a firewall cluster | |
| US20160156507A1 (en) | System and Method for Developing Applications in Wireless and Wireline Environments | |
| US20020164952A1 (en) | Location-aware service proxies in a short-range wireless environment | |
| US20050243857A1 (en) | Simultaneously routing data over multiple wireless networks | |
| JP2004509539A5 (ja) | ||
| AU2007235059A1 (en) | Session persistence on a wireless network | |
| CN110830461B (zh) | 基于tls长连接的跨区的rpc服务调用方法及*** | |
| US7447905B2 (en) | System and method of unacknowledged network layer service access point identifier (NSAPI) recovery in sub-network dependent convergence protocol (SNDCP) communication | |
| Bhagwat et al. | MSOCKS+: an architecture for transport layer mobility |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080709 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110607 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20111101 |