(57)【要約】データパケットルータは、モバイル通信装置が、インターネットのようなWANに接続されたPCを介して、WANにアクセすることを可能にする。ルータは、異なるベアラによるモバイル通信装置とコンピュータ間の接続を可能にする複数のベアラプラグインモジュールを備える。そこで、PCは、一般的なベアラ（USB、RS232、Bluetooth無線ほか）を使用してPCに接続するモバイル通信装置用のインターネットアクセスポイントとして利用される。それ故、携帯電話は、一般的なWAPを利用したウェブアクセスを成し遂げる、あるいは、本発明により、手頃なベアラを使用するPCへ接続することもでき、そのPCを介してインターネットアクセスを成し遂げる。ルータがベアラプラグインモジュールを使用するので、新規のベアラが開発されると新規のベアラモジュールを書いて即座にルータに追加することで実装をアップグレードすることができる。これは、新しい接続標準（かつおよび旧標準の拡張）は引き続き開発中であるから、有用である。
2005501478.tif 000002
【特許請求の範囲】
【請求項１】
WANに接続されたコンピュータ上で稼動可能で、モバイル通信装置による前記コンピュータを介した前記WANへのアクセスを可能にするデータパケットルータであって、
それぞれが異なるベアラを介した前記モバイル通信装置と前記コンピュータの間の接続を可能にする複数のベアラプラグインモジュールを有することを特徴とするルータ。
【請求項２】
ローカルリンクプロトコルとしてPPPを使用して、前記モバイル通信装置と前記コンピュータの間の前記接続を介して通過するデータをカプセル化することで、前記ベアラをシリアルデータベアラとして処理可能にすることを特徴とする請求項1に記載されたルータ。
【請求項３】
前記ベアラプラグインモジュールのそれぞれは、(i) シリアルCOMポートを介するダイレクトケーブル、(ii) USB、(iii) IR、(iv) 短距離無線のうちの一つのベアラを介する接続を可能にすることを特徴とする請求項1に記載されたルータ。
【請求項４】
新規のベアラ用の新規のベアラ抽象化コードにより増補可能な拡張性ベアラ抽象化レイヤを有することを特徴とする請求項1に記載されたルータ。
【請求項５】
新規のベアラのインスタンス（インストールされたベアラプラグインモジュールに関連）がコンピュータに付加されると、前記インスタンスを動的かつ自動的に認識し利用可能にするベアラ発見モジュールを有することを特徴とする請求項1に記載されたルータ。
【請求項６】
さらに、TCP/IP接続プロトコルを介した前記モバイル通信装置と前記コンピュータの間の接続を可能にするプロトコルプラグインを有することを特徴とする請求項1に記載されたルータ。
【請求項７】
前記コンピュータおよび前記モバイル通信装置に機能を共有させることを特徴とする請求項1に記載されたルータ。
【請求項８】
(a) 前記コンピュータを介するインターネット接続ルーティングを用いて前記モバイルコンピューティング装置上で稼動中のブラウザからインターネットをブラウズすること、(b) 前記モバイルコンピューティング装置と前記コンピュータの間で連絡先エントリおよびスケジュールエントリを同期させること、(c) 前記モバイルコンピューティング装置上のデータをインターネットベースのバックアップサーバまたは前記コンピュータへバックアップすること、(d) 前記コンピュータから前記モバイルコンピューティング装置上のデータをブラウズし、前記コンピュータ上のアプリケーションにおいて前記データを直接使用すること、(e)前記コンピュータ上のメッセージングアプリケーションによりメッセージを書き、前記モバイルコンピューティング装置から前記メッセージを送信すること、のうちの一つ以上の動作を可能にすることを特徴とする請求項7に記載されたルータ。
【請求項９】
(i) EPOCPLP、(ii) UDP/IPのうちの一つのプロトコルを介して、前記モバイル通信装置と前記コンピュータの間の接続を可能にする複数のプロトコルプラグインを有することを特徴とする請求項1に記載されたルータ。
【請求項１０】
前記モバイルコンピューティング装置は既存のシリアルデータ接続機能を使用するだけでよく、前記ルータに特有の任意のソフトウェアを前記モバイルコンピューティング装置上にロードする、あるいは、前記装置上で稼動させることなく、前記モバイル通信装置による前記コンピュータを介した前記WANへのアクセスを可能にすることを特徴とする請求項2に記載されたルータ。
【請求項１１】
実行時に、前記モバイルコンピューティング装置上へ任意のソフトウェアのインストールする、あるいは、第三者に依存することなく、前記コンピュータに接続されたリムーバブルな記憶媒体からのみ稼動させることができることを特徴とする請求項1に記載されたルータ。
【請求項１２】
IPパケットはデータおよび/または音声を搬送することを特徴とする請求項6に記載されたルータ。
【請求項１３】
前記コンピュータ上の一つ以上のシリアルポートがモデムとして開き、前記コンピュータに接続された前記モバイルコンピューティング装置のプロキシとして動作することを特徴とする請求項1に記載されたルータ。
【請求項１４】
前記コンピュータはLANにも接続され、前記モバイル通信装置による前記コンピュータを介した前記LANへのアクセスを可能にすることを特徴とする請求項1に記載されたルータ。
【請求項１５】
テンポラリなルーティング不能の仮想IPアドレスを、ローカル接続された幾つかのモバイル通信装置へ割り当てることを特徴とする請求項1に記載されたルータ。
【請求項１６】
ある特定のチャネルに着信するすべてのデータパケットをインターセプトし、前記データパケットを前記チャネルに関連付けられた、正しいローカル接続された装置へ転送することを特徴とする請求項15に記載されたルータ。
【請求項１７】
さらに、異なるホスト/ローカル接続可能なモバイル通信装置ごとにプラグインモジュールを有する請求項1に記載されたルータ。
【請求項１８】
WANに接続されたコンピュータの一部を形成するデータパケットルータを使用して、モバイルコンピューティング装置による前記WANへのアクセスを可能にする方法であって、
それぞれが所望のベアラを介した前記モバイル通信装置と前記コンピュータの間の接続を可能にする一組の利用可能なベアラプラグインモジュールから、ベアラプラグインモジュールを選択することを特徴とする方法。
【請求項１９】
さらに、前記ルータにより、ローカルリンクプロトコルとしてPPPを使用して前記モバイル通信装置と前記コンピュータの間の前記接続を介して通過するデータをカプセル化することで、前記ベアラをシリアルデータベアラとして処理可能にすることを特徴とする請求項18に記載された方法。
【請求項２０】
前記ベアラプラグインモジュールのそれぞれは、(i) シリアルCOMポートを介するダイレクトケーブル、(ii) USB、(iii) IR、(iv) 短距離無線のうちの一つのベアラを介する接続を可能にすることを特徴とする請求項18に記載された方法。
【請求項２１】
新規のベアラ用の新規のベアラ抽象化コードにより、前記ルータにおける拡張性ベアラ抽象化レイヤを増補することを特徴とする請求項18に記載された方法。
【請求項２２】
新規のベアラのインスタンス（インストールされたベアラプラグインモジュールに関連）がコンピュータに付加されると、ベアラ発見モジュールにより、前記インスタンスを動的かつ自動的に認識し利用可能にすることを特徴とする請求項18に記載された方法。
【請求項２３】
前記ルータによるプロトコルプラグインの使用により、TCP/IP接続プロトコルを介した前記モバイル通信装置と前記コンピュータの間の接続を可能にすることを特徴とする請求項18に記載された方法。
【請求項２４】
前記コンピュータおよび前記モバイル通信装置に機能を共有させることを特徴とする請求項18に記載された方法。
【請求項２５】
(a) 前記コンピュータを介するインターネット接続ルーティングを用いて前記モバイルコンピューティング装置上で稼動中のブラウザからインターネットをブラウズすること、(b) 前記モバイルコンピューティング装置と前記コンピュータの間で連絡先エントリおよびスケジュールエントリを同期させること、(c) 前記モバイルコンピューティング装置上のデータをインターネットベースのバックアップサーバまたは前記コンピュータへバックアップすること、(d) 前記コンピュータから前記モバイルコンピューティング装置上のデータをブラウズし、前記コンピュータ上のアプリケーションにおいて前記データを直接使用すること、(e)前記コンピュータ上のメッセージングアプリケーションによりメッセージを書き、前記モバイルコンピューティング装置から前記メッセージを送信すること、のうちの一つ以上の動作を実行することを特徴とする請求項24に記載された方法。
【請求項２６】
(i) EPOCPLP、(ii) UDP/IPのうちの一つのプロトコルを介して、前記モバイル通信装置と前記コンピュータの間の接続を可能にする一組のプロトコルプラグインから、前記ルータがさらにプロトコルプラグインを選択することを特徴とする請求項18に記載された方法。
【請求項２７】
前記モバイル通信装置が、前記モバイルコンピューティング装置上で稼動中の前記ルータに特有の任意のソフトウェアを使用する代わりに、既存のシリアルデータ接続機能を使用し、前記コンピュータを介して前記WANにアクセスすることを特徴とする請求項19に記載された方法。
【請求項２８】
実行時に、前記モバイルコンピューティング装置上へ任意のソフトウェアのインストールする、あるいは、第三者に依存性することなく、前記コンピュータに接続されたリムーバブルな記憶媒体からのみ前記ルータを稼動させることを特徴とする請求項18に記載された方法。
【請求項２９】
IPパケットによりデータおよび/または音声を搬送することを特徴とする請求項23に記載された方法。
【請求項３０】
前記ルータにより、前記コンピュータ上の一つ以上のシリアルポートをモデムとして開き、前記コンピュータに接続された前記モバイルコンピューティング装置のプロキシとして動作することを特徴とする請求項18に記載された方法。
【請求項３１】
前記モバイルコンピューティング装置が前記コンピュータを介してLANにアクセスすることを特徴とする請求項18に記載された方法。
【請求項３２】
前記ルータにより、テンポラリなルーティング不能の仮想IPアドレスを、ローカル接続された幾つかのモバイル通信装置へ割り当てることを特徴とする請求項18に記載された方法。
【請求項３３】
前記ルータにより、ある特定のチャネルに着信するすべてのデータパケットをインターセプトし、前記データパケットを前記チャネルに関連付けられた、正しいローカル接続された装置へ転送することを特徴とする請求項32に記載された方法。
【請求項３４】
前記ルータにより、異なるホスト/ローカルに接続可能なモバイル通信装置ごとに特有のプラグインモジュールの組から、前期ルータがプラグインモジュールを選択することを特徴とする請求項18に記載された方法。
【請求項３５】
キャリア媒体に記憶される場合のコンピュータソフトウェアであって、
データパケットルータが、コンピュータ上で稼動する場合に、請求項18に記載された方法を実行可能にすることを特徴とするコンピュータソフトウェア。
【請求項３６】
ネットワークを経て送信される場合のコンピュータソフトウェアであって、
データパケットルータが、コンピュータ上で稼動する場合に、請求項18に記載された方法を実行可能にすることを特徴とするコンピュータソフトウェア。
【請求項３７】
請求項1に記載されたルータを有することを特徴とするコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モバイル通信装置用のデータパケットルータに関する。データパケットルータは、データパケット（例えばIPパケット）を特定のアドレスを有する装置へルーティングするハードウェアまたはソフトウェアである。モバイルコンピューティング装置には制限がなく、ハンドヘルドコンピュータ、ラップトップコンピュータ、携帯電話、電子手帳、および無線情報装置が含まれる。
【背景技術】
【０００２】
モバイル通信装置は、通常、二つの方法のうちの一つによりWAN（インターネットなど）へ接続する。第一に、一部の装置は内蔵モデムを使用してPSTNを介してインターネットへ接続することができる。例えば、ラップトップコンピュータはPSTNを介してインターネットにアクセスできるようにする内蔵モデムを有するであろう。インターネットへのアクセスに対するこのアプローチには幾つかの欠点がある。(i) ユーザはラップトップからつながる電話ジャック用の余分の電話ソケットを配置しなければならないし、(ii) 内蔵モデムは費用がかかる。第二のアプローチは、インターネットへ接続されるゲートウェイ（例えば、WAPゲートウェイ）に到達するために装置自体が備えるであろう任意の長距離無線通信機能（例えば、GSMまたはUMTSなど）を使用することである。しかし、GSMなどの無線ベアラ（bearer、運ぶもの）の使用は、信頼性が低く低速である可能性がある。UMTSなどの高帯域幅のシステムは費用がかかる可能性が高い。
【０００３】
モバイル通信装置が、有線のゲートウェイまたはインターネットへのアクセスポイントにアクセスできるようにし、その結果、このゲートウェイの範囲内にある場合に有線ネットワークの低いデータアクセスコスト、高い帯域幅および信頼性を活かすことに関しては、多くの推測が行われてきた。例えば、Bluetooth(TM)などの短距離無線機能を備えた状態でGSMまたはUMTSの携帯電話を使用できるようにすることが提案されている。その結果、この携帯電話が有線でインターネットへ接続されるアクセスポイント（Bluetoothの「ポッド」）の範囲に入ると、GSM WAPアプローチを使用する場合とは対照的にBluetoothのポッドを介してインターネットへ優先的に接続することができる。範囲から出ると、従来のGSM WAPアプローチへ戻る。同様に、802.11対応のモバイル通信装置は、LAN用の802.11アクセスポイントへダイヤルすることができる。アクセスポイントは、通常、無線トランシーバを備えるスタンドアロンユニットである。このユニット自体は、インターネットへ直接に有線接続されても、インターネットへ有線接続されたPCに接続されてもよい。これにより、802.11対応のモバイル通信装置は、アクセスポイントを介してインターネットにアクセスすることができる。しかし、このアプローチでは、新規のハードウェアアクセスポイントへの追加のインフラ投資が必要であり、大半の組織に存在する既存のPCベースのインフラを低コストで充分に活用することができない。
【０００４】
従来のPCは、内蔵または外付けのモデムを介してPSTNの地上線越しに直接ダイヤルする、あるいは、モデムを使用してPSTNの地上線越しにダイヤル可能な、または、専用線を介して永続的に接続されるサーバにLANを介して接続することによって、インターネットなどのWANに接続することができる。多くの企業は、LANの開発およびインターネットへのサーバゲートウェイに相当の額を費やしている。両者は、今ではコンピュータまたは通信インフラの一部として一般的化している。このインフラを使用してモバイル通信装置をインターネットにアクセスできるようにすることは、興味深い概念である。従来技術では、モバイル通信装置は、インターネットに接続される（例えば、直接またはサーバを介して）PC自体を介してインターネットにアクセスする。すなわち、広く普及したPC自体をアクセスポイントとして使用することが可能である。例えば、WO 01/90853およびEP 1028560への参照が行われてもよい。しかし、これらの開示は、そのようなシステムを実際に実現する方法についての詳細はほとんど述べられていない。
【０００５】
遠隔のPCが、Micorosoft(R) Remote Access Server (RAS)を使用してPSTNを介してサーバへダイヤルすることもできる。しかし、この方法は、外部の装置に対して組織のコンピュータインフラを調べることを許可することと実質的に等しい。既存のインフラを使用して無線のコンピューティング装置がRASを介して外側のインターネットを見ることができるようにするのとは対照的である。理論上は、RASは、モバイルコンピューティング装置がRASを稼動中のPCを介してインターネットに接続できるようにするのに使用できるが、この方法は構成が困難であり柔軟性に欠ける。
【０００６】
【特許文献１】
WO 01/90853
【特許文献２】
EP 1028560
【発明の開示】
【０００７】
本発明の第一の面では、WANに接続されたコンピュータ上で稼動することができ、モバイル通信装置がコンピュータを介してWANにアクセスできるようにするデータパケットルータにおいて、それぞれが異なるベアラを介したモバイル通信装置とコンピュータとの間の接続を可能にする複数のベアラプラグインモジュールを備えるルータが提供される。
【０００８】
このため、本発明は、一実現例において、モバイル通信装置用のインターネットアクセスポイントとしてPCなどのコンピュータを使用することを想定する。携帯電話は、従来のWAPを使用してウェブアクセスを獲得することもできる。本発明においては、携帯電話をPCに接続し、適切なベアラプラグインモジュールを使用することで利用可能な最も便利なベアラを使用するPCを介してインターネットにアクセスすることができるだろう。
【０００９】
ベアラプラグインモジュールのそれぞれは、(i) シリアルCOMポートを介するダイレクトケーブル、(ii) USB、(iii) IR、(iv) 短距離無線のうちの一つのベアラを介する接続を可能にするであろう。
【００１０】
他の種類のベアラに対するプラグインモジュールも配置することができる。上述のリストは網羅的ではなく、現時点で最も一般的なベアラの種別を表す。ルータは、新規のベアラ用の新規のベアラ抽象化コードにより増補可能な拡張性ベアラ抽象化レイヤを備えてもよい。例えば、ベアラ抽象化レイヤは各ベアラプラグインモジュールに含まれてもよい。従って、これらのモジュールは、拡張可能なベアラ抽象化レイヤを構成してもよい。
【００１１】
ルータはベアラプラグインを使用するので、新規のベアラが開発されている限り新規のベアラモジュールを書くことができ、これを直ちに追加して既存の実現例を更新することができる。新しい接続標準（および旧標準の拡張）は引き続き開発中であるため、これは有用である。一例として、Firewire(R)と同様に、拡張USBが近年開発されてきている。これらのそれぞれに対してベアラプラグインを書いて配置し、既存の実現例を更新することができる。
【００１２】
追加の特徴は、新規のベアラのインスタンス（インストールされたベアラプラグインモジュールに関連）がコンピュータに付加されたときに、そのインスタンスを動的かつ自動的に認識し利用可能にすることができるベアラ発見モジュールが存在してもよいことである。RASなどの従来のシステムとは異なり、ユーザ構成は全く不要である。ベアラ発見モジュールは、ある特定のベアラ種別に特有のものであってもよい。
【００１３】
ルータは、ローカルリンクプロトコルとしてPPPなどのシリアルデータリンクプロトコルを使用してモバイル通信装置とコンピュータとの間の接続を介して通過するデータをカプセル化し、ベアラがシリアルデータベアラとして処理できるようにしてもよい。
【００１４】
また、ルータは、TCP/IP接続プロトコルを介したモバイル通信装置とコンピュータとの間の接続を可能にする動的プロトコルプラグインを備えてもよい。
【００１５】
このため、ルータによりルーティングされるデータはデータおよび/または音声を搬送するIPパケットであってもよい。従って、本発明の実現例では低コストのVoIPが可能である。携帯電話は、上述のようなルータを有するPCが利用可能でない場合、音声に対して比較的費用のかかるUMTSを使用することもできるが、より低コストのVoIPを使用するためにこのようなPCに接続することもできる。
【００１６】
さらに、ルータは、(i) EPOCPLP、(ii) UDP/IPのうちの一つのプロトコルを介してモバイル通信装置とコンピュータとの間の接続を可能にする複数のプロトコルプラグインを備えてもよい。
【００１７】
一実現例では、ルータに特有のソフトウェアをモバイルコンピューティング装置上にロードする、あるいは、装置上で稼動させる必要がない。このため、ルータ機能は、実行時に、モバイルコンピューティング装置上へ任意のソフトウェアのインストールする、あるいは、サードパーティに依存することなく、ディスク、CD、またはPC上で稼動中の他の取り外し可能な媒体からのみ稼動させることができる。
【００１８】
さらに、モバイル通信装置からPCへのアクセスを可能にするのに、PC自体がモバイル通信装置に関する情報を知っている必要はない。
【００１９】
ルータは、PC上の一つ以上のシリアルポートがモデムとして開くようにし、PCに接続されたモバイルコンピューティング装置に対するプロキシとして動作する。ルータは、一時的なルーティング不能な仮想IPアドレスを幾つかのローカルに接続されたモバイル通信装置へ割り当てることができる。ルータは、ある特定のチャネルに着信するすべてのデータパケットをインターセプトし、そのデータパケットをチャネルに関連付けられた、正しいローカル接続された装置へ転送することができる。
【００２０】
さらに、ルータは、異なるホスト/ローカルに接続可能なモバイル通信装置ごとにプラグインモジュールを備えてもよい。
【００２１】
ルータによりモバイル通信装置がPCを介してLANにアクセスできるように、PCはLANに接続されてもよい。
【００２２】
本発明の幾つかの利用例は次のとおりである。(a) コンピュータを介するインターネット接続ルーティングを用いてモバイルコンピューティング装置上で稼動中のブラウザからインターネットをブラウズすること、(b) モバイルコンピューティング装置とコンピュータとの間で連絡先エントリおよびスケジュールエントリを同期させること、(c) モバイルコンピューティング装置上のデータをインターネットベースのバックアップサーバまたはコンピュータへバックアップすること、(d) コンピュータからモバイルコンピューティング装置上のデータをブラウズし、コンピュータ上のアプリケーションにおいてデータを直接使用すること、(e) コンピュータ上のメッセージングアプリケーションでメッセージを書き、モバイルコンピューティング装置からメッセージを送信すること。
【００２３】
従って、本発明は、大半の組織に既に存在する既存のPCベースのインターネット通信インフラに対して影響を及ぼし、マイクロブラウザを使用して携帯電話により従来のウェブページを見ることができるようにする（すなわち、現在限られたコンテンツしか提供しない比較的少数のWAP対応サイトには限定されない）。これは、無線ネットワークの料金が発生しないことを意味する。モバイルのプロフェッショナルにとっては、既存の有線ベースのPCインフラを使用して確実かつ安価にインターネットにアクセスできることは非常に有用である。多くの場合、本人以外のPCを簡単に利用することができても、本人の無線装置を使用してデータをブラウズ・格納することを希望するからである。本発明によればこれが可能である。さらに、本発明により、ユーザのモバイルコンピューティング装置および普通のコンピュータ（例えば、デスクトップPC）の組み合わせを機能を共有する単一のシームレスな装置として動作させることができるようになる。
【００２４】
第二の面では、モバイルコンピューティング装置が、WANに接続されたコンピュータの一部を形成するデータパケットルータを使用して前記WANにアクセスできるようにする方法において、ベアラプラグインモジュールを選択して所望のベアラを介したモバイル通信装置とコンピュータとの間の接続を可能にする過程からなる方法が提供される。
【００２５】
第三の面では、キャリア媒体に記憶される場合のコンピュータソフトウェアにおいて、データパケットルータが、前記コンピュータ上で稼動する場合に上述の方法を実行できるようにするコンピュータソフトウェアが提供される。
【００２６】
第四の面では、ネットワークを介して送信される場合のコンピュータソフトウェアにおいて、データパケットルータが、前記コンピュータ上で稼動する場合に上述の方法を実行できるようにするコンピュータソフトウェアが提供される。
【００２７】
最後の面では、第一の面において定義されたルータを備えるコンピュータが提供される。
【発明を実施するための最良の形態】
【００２８】
本発明は、英国ロンドンのIntuwave製のm-Router(TM)ソフトウェアベースのルータ製品として実現される。m-Routerは、ホストPCへの直接的な有線または無線のリンクを介するTCP/IP & UDP接続をモバイルコンピューティング装置に対して提供する。m-Routerは、ホストPC上でのみ稼動するソフトウェアから構成される。取り付けられた装置上にインストールされたソフトウェアには変更または追加を行う必要がない。
【００２９】
m-Routerは使い易い標準に基づくPC実現例であり、モバイル装置がホストPCおよび到達可能な場合にはPCが接続されるインターネット/ネットワークにアクセスできるようにするのに使用されるファイアウォール/PPPサーバの実現例である。PPPをモバイル装置とPCとの間のローカルリンクプロトコルとして使用することにより、無線によるシナリオおよびデスクトップベースのシナリオの双方に対してこれらの装置に対する接続性に基づくソリューションを再利用することができる。接続性がいずれもRS232ベースであった場合、あるいは、ベアラごとに異なっていた場合、ベアラプラグイン（拡張可能なハードウェア抽象化レイヤ）およびプロトコルプラグイン（構成可能なプロトコルスタックレイヤ）を提供することによって、USBおよびBluetoothなどのベアラを使用することができる。m-Routerにより提供されるソリューションにより、すべてのハードウェアベアラは一様に処理されるようになり、開発の労力が軽減される。開発者は、通常、一つのプロトコル-TCP/IP-のみを理解すればよいからである。m-Routerの主なパラダイムのうちの一つは自動構成であり、消費者に対する透明性であるので、標準に基づく接続性の利点がソフトウェアにもたらされる。しかし、熟練したシステムマンガーに限定されない。
【００３０】
m-Routerは現在二つのバージョン、すなわち、m-RouterRuntimeおよびm-RouterDeveloperが提供されている。
【００３１】
［m-RouterRuntime］
このバージョンのm-Routerは、シリアルケーブルを介してPCへ取り付けられるSymbian OS装置がPPP上のTCP/IPを使用してホストPCを介してネットワーク/インターネットにアクセスできるようにする。m-Routerは、何れかの機能を提供するのにRAS（遠隔アクセスサービス）または他のWindows構成要素を必要としない。m-Routerはユーザインタフェイスなしの共有サーバである。プログラムは、二つの主な機能を提供する。
【００３２】
●取り付けられたモバイルコンピューティング装置は、固有のウェブブラウザおよび電子メールプログラムを使用してm-Routerのホストとして動作するPCを介してインターネットへ接続することができる。
●取り付けられた装置はIPアドレスを知らなくてもホストPC上のhttpサーバにアクセスすることができる。標準のウェブアドレス(http://wsockhost.mrouter/... ?)を使用してホストPC上のファイルをアクセスする。
構成オプションは提供されない。
【００３３】
［m-RouterDeveloper］
m-RouterDeveloperは、m-RouterRuntimeに追加の機能を提供する。m-RouterDeveloperは、ユーザインタフェイスを介して設定可能である。この機能により、装置（図1のA）またはPC (B)上の装置は、ホストPC (C)を介して装置D上のHTTPサーバへアクセスすることができる。m-RouterはAをBへ接続し、CをDへ接続する。装置D上のHTTPサーバはm-Surfと呼ばれ、付録1において説明される。
【００３４】
また、このバージョンはユーザインタフェイスを含み、これにより、以下のパラメータを設定することができる。
・リスニングポート番号
・ログファイル名およびディレクトリ
・COMポートの有効/無効化
・ソフトウェア登録番号の入力
【００３５】
インタフェイスにより、ソフトウェアの稼動中に種々のパラメータを表示させることができる。
【００３６】
より詳細に説明すると、m-Routerは、サブシステムの中程度に複雑な集合である。図2はこれらのサブシステムが相互に関係する方法の概要である。
【００３７】
一つ以上の製品がm-Routerを含んでも/使用してもよい。これらの製品は、状態を露呈し、m-RouterControllerと呼ばれる共有メモリ構成要素を介する操作を可能にする共有ランタイム(m-RouterRuntime.exe)の単一のインスタンスを共有する。
【００３８】
m-RouterRuntime G内で、一組のホスト発見モジュールCがロードされる。これらのモジュールは共通のインタフェイスを露呈し、拡張可能である。例えば、関連するUSB装置の挿入、Bluetoothシリアルポートの追加/削除などのように、新規のハードウェアが利用可能/利用不可能になるのを監視する。変化が検出されると、モジュールはコールバックインタフェイスを介してm-RouterRuntime Gに通知し、「現在利用可能な」ハードウェアベアラ装置を列挙するように要求される。この装置はベアラプラグインAにより定義される。各ベアラプラグインAは、利用可能なハードウェアベアラ（例えば、USB、ダイレクトケーブル、IR、Bluetoothなど）を定義する。プラグインはシリアルデバイス抽象化レイヤとして動作する。
【００３９】
M RouterGateway Dは、仮想ホスト（ホストハンドラと呼ばれることもある）の内部のセットを管理する。各ホストは、関連付けられたルーティング不能なIPアドレスを有する。ホストの大半は、「現在利用可能な」ハードウェアベアラAのリストの変更に応じてm-RouterRuntimeの要求により作成される。Link Host Eと呼ばれるクラス（m-RouterSerialモジュール内に含まれる）がこのホストを実現する。このクラスのインスタンスは、種々のハードウェアベアラAをシリアルデータストリームとして抽象化する追加のモジュールを使用する。インスタンスは、接続された装置から生のデータバイトを読み書きし、PPPスタックBを使用して想定されるPPPデータを内部のパケット/フレームのシーケンスへ変換する。PCのTCPソケットフレームワークとインタフェイスするWinsock Host Fと呼ばれるホストの単一のインスタンスがある。データのフレームは、システム周辺の、フレームにおいて指定されたソースエンドポイントと宛先エンドポイントとの間で、m-RouterGateway Dにより渡される。種々のホストは、このフレームに対するエンドポイントを内部的に管理する。エンドポイントはポートハンドラと呼ばれる。Winsock Host Fにおいて、これらのポート（灰色の円として示される）は、pc上のソケット接続（場合によっては、インターネット上の他のマシン、あるいは、m-Routerと同じPC上のアプリケーション）に対応する。Link Host Eでは、これらのポートは接続されたモバイル装置上のソケットに対応し、遠隔のポートへの/からのフレームのコンテンツは、抽象化されたハードウェアベアラ上でPPPを介して転送される。
【００４０】
外部のユーザインタフェイス構成要素が、必要に応じて、波線のリンク、チェックボックス、およびその他の形態のフィードバックをユーザに対して表示できるように、現在の利用可能なホストに関する種々の統計値がm-RouterControllerを介して「発行」される。他の統計値は、内部使用のためにm-RouterRuntimeが利用できるようになる。m-RouterRuntimeは、開発者用の構成において、m-RouterPropPages.dllをロードし、バイトレベルの診断ロギングを表示することができる。
【００４１】
モバイル装置は、m-Routerを介してPCへ接続するとともに、このPCが接続されるネットワークへも接続する。また、TCPを介してm-RouterAccessPoint Gと呼ばれるサービスに接続することを選択できる。この処理を選択する場合、モバイル装置は、m-RouterAccessPoint Gに一連のプロパティを渡す。モバイル装置はログインしているものと考えられる。m-RouterAccessPoint Gは、プログラミングAPIを露呈し、接続された装置およびその関連するプロパティを列挙する。また、m-RouterAccessPoint Gにより、接続されたモバイル装置上のポートに対するプログラム的なルート作成が可能になる。これらの装置は、m-Routerにより実現されるルーティング不能なネットワークの一部であり、それがなければPCにより到達することはできないだろう。m-RouterAccessPoint GはローカルなPCソケットリスナを作成することができ、このリスナがデータを選択された装置上の目標ポートへ転送することになる。
【００４２】
m-RouterWinsock FはPC上のソケットAPIとm-Routerの内部のポートとの間のインタフェイスとして動作する。m-RouterWinsock Fは、単純なネットワークアドレス変換を実行し、単純なファイアウォールとしてふるまう。m-RouterAccessPoint Gにより、このファイアウォールの背後に隠れた装置へのプログラム的なアクセスが可能になる。
【００４３】
［ホスト、ポート、ストリーム、フレーム、アドレスおよびポート］
m-Routerシステムは、「ホスト」として知られる仮想マシンの仮想ネットワークを管理する。各ホストは、「アドレス」である32ビットの識別子を割り当てられる。すべてのホストは、m-RouterHostHandlerに対するインタフェイスを実現しなければならない。ホストをロードするために、ランタイムユーザインタフェイスは、システムオブジェクト上でLoadHost関数を呼び出し、ロードするCOMオブジェクトのCLSIDにおいて、ホストに割り当てるアドレスとロード後にホストへ渡される初期化文字列とを渡す。一部のホストは使用時に「ブロックする」可能性があるので、LoadHost関数は、ホストが存在/稼動するスレッドをホストに対して指定できるようにする。すべてのホストは、以下に示すように、同じスレッドまたは別々のスレッドに存在することができる。なお、ホストの複数のインスタンスをロードしてもよい（一意的なアドレスが割り当てられる場合）。例えば、後述するように、ホストの幾つかのインスタンス（CLSIDにより指定される）は、それぞれ、単一の異なるコンポートを管理するためにロードされてもよい。図3は、システム/ホスト構造の概略図である。「ゲートウェイ」はm-Routerシステムに対応する。これを「システム」と呼ぶ。
【００４４】
システムを介してホスト間でデータが渡される。データはm-RouterFrameで包まれる。m-RouterFrameとは、一連のバイトを表すCOMオブジェクトである。COMオブジェクトは、コンテンツに付加するとともにフレームのコンテンツを直接指し示すポインタを取得するための関数を提供する。これにより、m-RouterFrameは「工程中の」使用に制限されるが、速度およびメモリにおいては性能上の利点が得られる。通常、ホスト間で渡されるデータは、一つ以上のヘッダにおいて関連付けられた追加のデータを有する。m-RouterFrameオブジェクトは、他のm-RouterFrameオブジェクトを子としてメインオブジェクトへ付加できるようにすることでこのヘッダデータをサポートする。これは、実質的に、m-RouterFrameが、各ノードが生バイトのシーケンスを含むことができるツリーであることを意味する。各子は32ビット値により識別される。例えば、TCP/IPフレームは図4に示すようにパッケージ化することができるだろう。m-Routerフレームは、どのヘッダ/データなどを使用すべきかを指図していない。このような取決めは、送信者と受信側のホストオブジェクトとの間に存在するべきである。m-Routerが実行することは、フレームを一台のホストから別のホストへ逐次的に配信する（あるいは、必要に応じて、元のホストへ戻す）ことだけである。
【００４５】
ホストは、一つ以上のm-RouterPortHandlerを作成し、これらのフレームを送受信する。各ポートには、作成したホストのドメイン内で一意的な16ビット識別子が割り当てられる。
【００４６】
要約すると、フレームは、m-RouterHostHandlerにより作成されるm-RouterPortHandler間で渡され、m-RouterGatewayはこれらのフレームをバッファリングし、ソースポートから宛先ポートへルーティングする。システムは、転送するフレームをディスクリートストリームへ編成する。各ストリームオブジェクトは一意的なidおよび二つの関連するポートオブジェクトを有する。ストリームはフレームのコンテンツを理解しておらず、フレームを目標ポートへ渡すだけである。図5がこれを示す。
【００４７】
［サイト、ロギング、ネーム空間、モニタ］
システムは、駆動中のユーザインタフェイス並びにホストおよびポートからアクセス可能な追加のサービスを提供する。初期化時、各ホストおよびポートには、フレームの送信、あるいは、システムにより提供されるヘルパオブジェクトの取得に使用することができるSiteObjectが渡される。この動作により、ホストおよびポートは、ユーザインタフェイスに対して露呈される全機能を隠しながらシステムに要求を行うことができる。これは、システムの制御下では、誤ったホストまたはポートは別のホストまたはポートへ直接アクセスできないことを意味する。
【００４８】
サイトオブジェクトにより提供される第一のヘルパサービスはロギングである。テキスト情報を付加するのにm-RouterLoggerオブジェクトを使用することができる。この情報の性質は、ロガーを使用するオブジェクトによって決まる。また、32ビットカウンタを設定することができる。このカウンタはIdによりアクセスされるが、一部の共通のidは予め定義される。ロガーオブジェクトはブロッブデータを保持するのにも使用することができる。例えば、後述するwinsockホストは、リスナのリストを維持管理する。ユーザインタフェイスは、特定のホストなどに割り当てられたロガーを要求し、テキストバッファのコンテンツ、カウンタ、およびブロッブの何れかを問い合わせることができる。ロガーオブジェクトに配置されるテキストは、今後の診断閲覧のために、テキストファイルへ追加的にログ記録することができる。
【００４９】
ホストまたはポートが他のモジュールに関して行なければならない想定を最小限にするために、システムは、名前付きのデータをアドレス、サービスなどの小規模な共有の動的辞書として格納・問合せすることができるネーム空間を提供する。後述のTCPモジュールは、この辞書を使用してwww.intuwave.comなどの名前を32ビットのインターネットアドレスへ変換する。最後に、ユーザインタフェイスまたは他のホスト/ポートがロギングオブジェクトおよびネーム空間オブジェクトに変更があるか否かをポーリングするのを防止するために、双方のオブジェクトはクライアントが提供したモニタオブジェクトを登録し、何か変化があれば呼び戻せるようにする。これにより、ユーザインタフェイスは状態の変化に対応するとともに、変化発生時には表示を更新することができる。監視サービス、ロギングサービス、およびネーム空間サービスは、典型的なアプリケーションにとって問題とならず無視することができるように、スレッド間の問題を内部的に管理する。
【００５０】
［プロトコル認識装置、ストリームモニタ、PortObject］
m-RouterGatewayは、フレームのコンテンツについて何の規則も課さないが、ある特定のフレームを正しいストリームへ割り当てるためにこのフレームに対するソースおよび宛先を抽出する必要がある。このため、m-Routerは、フレームからプロトコル/ソース/宛先情報を抽出するProtocolRecognizerを使用する。ユーザインタフェイスがシステムインタフェイス上で適切な関数を呼び出すことによって、プロトコルサポートをシステムから追加・削除することができる。一度「ストリームの詳細」がフレームから抽出されると、この詳細が既存のストリームと比較されるか、あるいは、新規のストリームが作成される。新規のストリームが作成される場合、適切なホストを使用してストリームに対するポートハンドラが作成される。プロトコル特有のロギングを可能にするために、プロトコル認識装置が使用され、宛先ポートへの送信前にストリームを介して送信される各フレームへ渡されるストリームモニタが作成される。このモニタストリームオブジェクトは、ストリームに対するロガーオブジェクトをアクセスすることができるので、16進ダンプおよび入出力バイトのカウント値を提供することができる。また、ストリームモニタは、ウォッチドッグタイマを介して、あるいは、プロトコルにとって適切な場合には終端フレームを待つことによって、いつストリームが閉じられるのかを判定することができる。
【００５１】
最後に、コードを再利用するために、m-RouterはPortObjectと呼ばれるオブジェクトを使用する。プロトコルモジュールは、サポートするプロトコルに対してポートハンドラのデフォルトの実現例を提供し、格段に単純なPortObjectインタフェイスを使用する。このため、各ホストは同様のプロトコル特有のコードを実現する必要がない。単純なポートオブジェクトを提供すればよく、使用中のプロトコルの内部機構を認識しなくてもよいからである。
【００５２】
単一のストリームに対する簡略化された構造が図6に示される。
【００５３】
［リンクホスト−m-RouterSerial.dll]
一部のハンドヘルド装置は、シリアルケーブルを使用して他のコンピュータへ取り付けられる。装置はフレームをシリアルデータへ変換するのにプロトコルスタックを使用し、このデータを往復で伝送する。このようなプロトコルの例としてはPPPおよびPLPがある。m-RouterSerialモジュールは、このような装置をサポートするm-RouterHostHandlerオブジェクトを実現する。このホストの複数のインスタンスは、サポート対象のシリアルポートごとに一つずつ、システムによりロードすることができる。
【００５４】
［シリアルデバイス抽象化レイヤ］
データは、SerialDeviceと呼ばれるCOMオブジェクトを介してハードウェアへ読み書きされる。これにより、必要に応じて、他のSerialDeviceインタフェイスを書くことができる。例えば、m-RouterEmulator.dllは、メモリバッファを介してER5エミュレータまたはQuartz Symbian OSエミュレータの内部で稼動するDLLへ直接話したSerialDeviceを実現する。これは、物理的なケーブルなしにシリアル接続をシミュレートする。m-RouterSerialモジュールにおいてデフォルトで実現・使用される標準のSerialDeviceは以下の動作を行う。
・WIN32により露呈されるシリアルポートCOM xに対して話す。これは、IRおよびbluetoothが透過的にサポートされるべきであることを意味する。
・DSR/DTR線を使用して装置接続/接続解除を検出できるようにする。
・強制または要求されなくても、CTS/RTSハンドシェーキングをサポートする。
・最大限に効率化するために、ワーカースレッドおよび入出力キューの循環バッファを使用する。
・m-RouterSerialが処理するシリアルポートへ現実に接続される場合に、実際にモデムを介してISPにダイヤルしているものと装置が信じるように、モデムを模倣する。
【００５５】
m-RouterSerialホストは、読み書きされるバイトのカウント値および接続の状態を維持管理する。これらのすべては、適切なm-RouterLoggerオブジェクト上でカウンタを介して露呈される。ホストの状態、使用するシリアルポート、およびボーレートは、すべて駆動中のユーザインタフェイスにより構成することができる。これは、システム関数SendStringToHostを使用してコマンド文字列をホストへ送信することにより達成される。例えば、以下の文字列は、シリアルホストへ送信することができる既存のコマンドのサブセットを表す。
"ENABLE;"
"DISABLE;"
"CONNECT;"
"DEVICECLSID={DB701106-BB66-11D4-941D-00104B45013A}"
"BAUD=115200"
【００５６】
［プロトコルスタック］
シリアルデバイスから読み出されると、データは、処理するプロトコルスタックのうちの一つに渡される。プロトコルスタックは、COMインタフェイスとしてユーザインタフェイスにより判定されたシリアルモジュールへロードされる。プロトコルスタックは送信されたデータを読み、以下の動作のうちの零個以上を行ってもよい。
・応答データをシリアルホストへ戻し、シリアルデバイスに対してキューを形成する。
・論理的な接続が取り決められた、あるいは、終了させられたことを通知することでシリアルホストの状態を変更する。
・一つ以上のm-RouterFrameオブジェクトをシリアルホストへ渡し、さらに、他のホストへルーティングするためにシステムに渡す。
【００５７】
このようにして、シリアルホストおよびシリアルデバイスとは関係なく、シリアルプロトコルに対するサポートを追加・削除することができる
【００５８】
［要約］
要約は図7において提供される。
【００５９】
［TCP/UDP/IPサポート−m-RouterTCP.dll］
このモジュールは、m-Routerの種々の部分へロードし、tcp/ip/udpサポートを提供することができる様々なインタフェイスを提供する。
【００６０】
［参照］
以下のRFCは、このモジュールの詳細を理解したい場合に読むと有用であると思われる背景である。
RFC1661  RFC1172  RFC1331  RFC1332  RFC1570
RFC1144  RFC1700  RFC1994  RFC791   RFC792
RFC793   RFC950   RFC1813  RFC1962  RFC768
RFC2118  RFC2153  RFC2284  RFC2433  RFC2508
【００６１】
［認識装置、ストリームモニタおよびポートハンドラ］
m-RouterTcpモジュールは、IPヘッダおよびTCPまたはUDPヘッダに対する「子/ヘッダ」m-RouterFrameが存在するm-RouterFrameオブジェクトからルーティング情報を認識・抽出するプロトコル認識装置を提供する。
【００６２】
m-RouterTcpモジュールは、ストリームモニタを提供し、これらのフレームのバイトコンテンツを適切なロガーオブジェクトへログ記録する。また、ロガーは各接続の状態の追跡を試みる。TCPモニタは、TCPヘッダの「フラグ」が交換されるのを監視することによりこれを行うが、UDPモニタは、ウォッチドッグタイマを維持管理し、接続が使用されなくなったときを判定するだけである。
【００６３】
TCPは、特に、単純なハンドシェークを使用するとともにメカニズムを確認するので、このモジュールは、他のホストおよびモジュールにおいてPortHandlerを実現するのに使用可能なオブジェクトを提供する。例えば、DNSホストおよびwinsockホストがこれらのオブジェクトを使用する。このオブジェクトは、バッファリングおよびプロトコルハウスキーピングをカプセル化するが、実際の生データ処理を他のクライアントが提供したオブジェクトへ委ねる。
【００６４】
［PPPスタック］
モジュールは、先に述べたシリアルモジュールによりロード可能なプロトコルスタックを提供する。このスタックは、LCPおよびIPCPに関して基本的な接続管理をサポートする。また、スタックはIP/TCP/UDPパケットを復号し、m-RouterFrameへ変換する。これらのフレームは、既に述べたプロトコル認識装置、ストリームモニタおよびヘルパポートハンドラにより後で処理されてもよい。スタックは、m-RouterFrameをシリアルケーブルを介する伝送に適したパケットへ戻す。このモジュールは、ファンヤコブソン圧縮をサポートするが、認証はいまだサポートしていない。図8は概略的な表現である。
【００６５】
［DNS−ネームサーバホスト］
TCP/UDPクライアントアプリケーションは、通常、www.intuwave.comなどのネームアドレスを123.45.67.89などの32ビットのインターネットアドレスへ変換する必要がある。これを行うために、ドメインネームサービス(DNS)として知られるサーバに対して標準が存在する。m-RouterTCPモジュールは、装置が名前のルックアップを求めることができるようにこの標準のサブセットを提供するm-RouterHostHandlerの実現例を提供する。これらのホストはシステムのネーム空間を使用する。初期化時、これは、m-Routerの内部アドレスの値でシードされる(seeded)。未知のアドレス（既知でないもの）に対する要求が行われる場合、DNSホストは要求をシステムの他の部分へ渡して更なる援助を求める。通常の構成では、コマンド文字列が後述のwinsockモジュールへ送信される。ルックアップを実行して答えが分かっている場合、その情報をシステムネーム空間に配置する。DNSホストは、このネーム空間に対する変化を監視し、正しい答えを伴って任意の未処理の問合せに応答することができる。通常、DNS問合せはUDPにより作成されるが、TCP接続を介して作成することもできる。DNSホストは双方のメカニズムをサポートする。これを行うためには、上述のPortHandlerオブジェクトを使用する。
【００６６】
［Winsockサポート−m-RouterWinsock］
mWinsockモジュールにより、m-Routerホストおよびこれに接続される各装置は、m-Routerが稼動中のpcのインターネット接続をピギーバックすることによって他のREALインターネット装置と通信を行うことができる。理論的には、m-Routerのホストとして動作するpcがインターネット接続を持たない場合でも、winsockモジュールをロードせずにm-Routerを稼動させることができるので、TCPモジュールからは離れている。
【００６７】
［アドレス変換］
既に説明したm-Routerは、論理的なホストのネットワークを内部的に実現する。各ホストには32ビットアドレスが割り当てられるが、現実のインターネットにおいては、ルーティングの問題を回避するために、このようなアドレスは慎重に割り当てられ、制御されなければならない。また、PCは、通常、これらの「REAL」アドレスのうちの一つのみを有する。これらの二つの問題を克服するために、m-Routerのm-RouterWinsockモジュールは、内部のホストの代わりに接続を作成する。例えば、winsockモジュールがアドレスwwwを有し、ホストDDD上の装置がREALインターネットアドレスAAAへ話すことを希望するものと想定する場合、以下のことが起こる。m-Routerが稼動中のPCがBBBの実アドレスを有することも想定する。
・DDDにおけるホストはDDDからのAAAに対するフレームを構築する。
・m-RouterFrameは、システムによりホストDDDからwinsockホストWWWへルーティングされる（システムはデフォルトのルーティング情報を伴って構成される）。
・winsockモジュールはフレーム中のヘッダを見て、win32ベースのAAAへの接続を作成し、データをフレーム（ヘッダではない）に含めて送信する。
・AAAにおける実計算機は、REALアドレスBBBを伴ってPCからデータを受信する。
・AAAにおける実計算機は、REALアドレスBBBを伴ってPCへデータを送り返す。
・データはwinsockホストにより受信され、winsockホストはWWWからDDDまでのm-RouterFrameを構築し、このフレームをシステムへ送信する。
・システムはm-RouterFrameをホストDDD上の装置へ送信する。装置は（誤って）AAAから直接届いたものであると考える。
【００６８】
なお、AAAにおけるホストは、すべての真実を知る訳ではなく、BBBにおけるPCに対してのみ話しているものと思う（厳密な意味において、インターネットサービスはすべてそうである）。
【００６９】
これは通常は申し分がないが、このアプローチに関しては一つの問題がある。一部のアプリケーションは、IPアドレスまたはポート番号を出力フレームに入れてピア（peer、対等のもの）へ送信してもよい。ピアは、逆の接続を試みてもよい。上述の例において、装置DDDがアドレスDDDをフレーム内部の実アドレスAAAへ送信する場合、実アドレスAAAは、REALアドレスDDDへの応答を試みるであろう。しかし、実アドレスDDDは全く存在しなくてもよい。
【００７０】
これは、アドレス変換を行うあらゆるファイアウォールにとっての問題であり、共通のソリューションは「SOCKS」と呼ばれるプロトコルである。
【００７１】
［リスナ］
winsockモジュールは、アウトバウンド接続およびその応答に対してアドレス変換を容易に行うことができるが、インターネットからの要求していない入力接続をどこへ送信すべきかを自動的に推量することはできない。実際、正しいポート上で特定的に検出を試みない限り、接続を完全に検出し損ねる可能性がある。この問題を克服するために、駆動中のユーザインタフェイスは、特定のTCPポートまたはUDPポート上で検出を開始し、すべての入力接続を指定のホストへルーティングする（場合によっては、ポート番号を変更）ように指示するコマンド文字列をwinsockホストへ送信することができる。これは、特別なアドレス「com?.m-Router」であり、これにより、フレームは、ANY接続されたシリアルポート上の任意の装置へ転送されることになる。接続されたシリアルポート上に二台の装置がある場合、結果は明らかに未定義である。
【００７２】
［付録1］
＜M-Surf＞
m-Surfは、モバイル装置上で保持されるアプリケーション特有のデータをアクセスする標準に基づく手段として使用することができるモバイルコンピューティング装置に常駐する軽量のHTTPサーバであり、通常、装置自体に限られるデータの遠隔閲覧および遠隔操作を接続される装置（他のモバイルコンピューティング装置、デスクトップPCなど）からでも行えるようにする。図9はこれを概略的に示す。「標準に基づく」のは、装置（例えば、Symbian OS形式またはMicrosoft(R) Pocket PC形式）上の一つ以上の固有の著作権のあるバイナリデータ形式（例えば、モバイルコンピューティング装置の小型の記憶装置および低電力消費という必要条件のために最適化される）のアプリケーション特有のデータを装置において稼動中の標準に基づくアプリケーション（例えば、標準に基づく形式がHTMLの場合はウェブブラウザ）と、有線または無線ネットワークにより接続される外部の装置とによってレンダリングすることができる標準に基づく形式へ変換するからである。
【００７３】
mSurf 2.0の設計はモジュール方式であり、システムの個別の部分を実行するより単純なプラグインモジュールのパイプラインの概念に基づいている。モジュールは、mStreamと呼ばれるフレームワークによりロード・管理される。mStreamは、パイプおよびデータ共有オブジェクトを提供する。mStreamは、適切なモジュールをロード・リンクし、論理的なパイプラインを形成するメカニズムを提供する。この構造により、個々のモジュールを交換したり代替のシステムにおいて使用したりすることができ、新規のシステムを効率的かつ迅速に設計することができる。
【００７４】
システムにおいて最も外側の構成要素は、このパイプラインへのゲートウェイであると考えられる。これは、他の種々のmStreamベースのパイプラインへのアクセスを提供するのに使用される別の再利用可能な構成要素である。最も内側の構成要素は、m-Surfへ渡されるアプリケーション特有のデータに対する要求のURLおよび詳細に基づいて動的に判定されるデータ変換プラグインモジュールである。例えば、特定のソース（すなわち、装置ファイリングシステムの限られたサブセット）からデータ、すなわち、PIM連絡先情報、メッセージ、またはワープロで作成された文書などを得て、所要の標準に基づく形式へ変換するプラグインモジュールであっても、あるいは、追加のレイヤへ呼び出されて他のアプリケーション特有の問合せを実行するモジュールであってもよい。あるシステムには、最も内側のモジュールが複数存在するであろう。
【００７５】
パイプラインは図10に示される。ウェブブラウザアプリケーション（TCP/IPクライアント）1が、どのデータが必要であるか、所望の形式などを定義するデータ要求2を、通常、3で示されるm-Surfウェブサーバへ送信する。合意した形式は明示的に要求することも、暗示的なデフォルト選択にすることもできる。m-Surfウェブサーバ3は、実質的に、メモリ4の関連するソースから著作権のあるコンパクトな形式で装置に格納されたアプリケーション特有のデータを取り出し、HTTPを使用して符号化された合意の形式へ変換し、処理/レンダリングを行うために、要求元の構成要素（この場合、ウェブブラウザ1）へ戻す。
【００７６】
重要な特徴は次の通りである。(a) 要求元のアプリケーション/構成要素1の位置は重要ではない。装置自体の内部に配置することも、外部に配置することも可能である。このような構成要素は複数存在させることができる。(b) m-Surfは、任意の合意した標準形式のデータを要求元の構成要素へ出力して戻すことができる（例えば、ウェブブラウザでレンダリングする場合にはHTMLであり、他のアプリケーションの場合はテキスト文字列の可能性もある）。(c) ブラウザアプリケーション1は、メモリ4にデータを書き込んだり、既存のデータを変更したりすることができる。このため、装置上のウェブブラウザは、装置に格納されたスケジュール情報を表示するのに使用することができるだろう。ユーザは、ブラウザを介して新規のカレンダーエントリを追加することができ、この情報は形態データとしてm-Surfへ送信される。m-Surfは、装置がカレンダーデータを格納するために使用する著作権のある固有のデータ形式へ変換する。
【００７７】
m-Surf 3内の構成要素は、簡潔にいうと、TcpListener 5である。TcpListener 5は入力のデータ要求を検出し、論理的なデータストリームとしてHttpSvr 6へ渡す。HttpSvr 6は、入力のデータ要求を読み、操作可能な内部構造へ変換し、その出力をHTTPとして符号化する。ローカルURLリゾルバ7が、どのモジュール「X」8へ要求を送信すべきかを考え、合意した形式でデータが戻って来ることを確認する。モジュール「X」8は関連するデータを獲得し、合意した形式（例えば、HTML、テキスト文字列、JPEGなどの画像ファイル形式、またはWAVなどの音声ファイル形式など）へ変換する。データはm-Surfを介して戻され、要求元のアプリケーション1へ送信される。アプリケーション1への最後のパスは、ピコネットあるいはGPRSまたは3G携帯ネットワークなどのWANを介して外部にあってもよい。
【００７８】
パイプラインの種々の部分をより詳細に述べる。
【００７９】
TcpListener 5：この再利用可能な構成要素は、指定のTCPポート（通常、80）上で検出を試みるように構成される。接続が形成されると、新規の接続から読み書きするモジュール内にオブジェクトが作成される。オブジェクトは、このポートに対する予め選択されたモジュール（この場合、HttpSvr.dll）の新規のインスタンスを開始し、これを一対のパイプへ渡す。このパイプを介して要求データが交換されることになる。また、オブジェクトは、HttpSvrがTCP接続に関する詳細を見つけるのに使用することができるプロパティの集合（バンドル）を渡す。TcpListenerモジュールは、外部のTCP双方向データストリームとHttpSvrへ供給される単方向のパイプの内部の対との間のアダプタとして機能する。
【００８０】
HttpSvr 6：HttpSvrの各インスタンスは、（複数の可能性のある）テキストHTTP要求を入力パイプから読み、これをヘッダ値の集合（バンドル）およびnullの可能性のある要求コンテンツストリームへ解析する。各インスタンスは、mStreamを使用してLocalUrlResolverのインスタンスを作成し、これを一対のパイプへ渡し、ヘッダの集合はTcpListenerから受信した集合と併合される。各インスタンスは、要求コンテンツをLocalUrlResolverへ渡し、LocalUrlResolverは、パイプを介して応答コンテンツを戻す。各インスタンスは、この応答をHTTP応答ヘッダ/コンテンツへ書式化し、結果をTcpListernerへ戻す。なお、HttpSvrは、単一のデータストリームから幾つかの個々の要求を解析してもよく、LocalUrlResolverの新規のインスタンスを作成して、各要求を処理することになる。要求の分割および応答の連結はHttpSvrの内部にある。
【００８１】
概略を述べると、HttpSvrは以下の機能を実行する。
◆入力ストリームヘッダを解析し、すべての認識されるヘッダを入力パラメータへ変換する。
◆入力ストリーム本文を解析し、そのデータのみを含むバイナリストリームへ変換する。
◆さらに変換し、「より有用な」形式を有する追加のヘッダを作成する。
◆モジュールXから応答パラメータおよびデータを読み、http要求へ書式化する。
◆要求および結果の要約をテキストログファイルへログ記録する。
◆要求のプロトコルバージョン、すなわち、http1.0/1.1でクライアントに応答する。
◆クライアント（入出力レイヤ）の接続解除を正常に処理する。
◆下位のレイヤに依存せずにトレースコマンドをサポートする。
◆I/Oレイヤが要求に対してクライアントアドレス情報を供給できるようにする。
【００８２】
LocalUrlResolver 7：この再利用可能な構成要素は、ヘッダおよびnullの可能性のある要求ストリームの集合（バンドル）を入力として受け取る。LocalUrlResolver7はURLを検査し、処理するためにどのモジュールに要求を渡さなければならないかに関して設定可能な決定プロセスを使用する。LocalUrlResolver 7は適切なモジュールをロードし、処理をそのモジュールへ委ねる。
【００８３】
モジュール「X」8：これは、要求のヘッダおよびコンテンツを処理し、応答を戻す。例えば、IFileRequestと呼ばれるモジュールは、装置ファイリングシステムの限られたサブセットからファイルを取得し、HTMLディレクトリリストを動的に生成することができる。より一般的には、モジュールXは、アプリケーション特有のデータを著作権のあるコンパクトな固有のデータ形式から装置上の別のアプリケーション（例えば、ウェブブラウザ）または別の装置により処理/レンダリングすることが可能な合意した標準形式へ変換する。
【００８４】
従って、MODULE「X」iFileRequest機能は次のとおりである。
◆アクセス制御DLLを使用して入力パスを物理的なパスへマップし、許可を求めて問合せを行う。
◆アクセスDLLにより許可される場合、ファイルを「GET」/「PUT」/「DELETE」する。
◆アクセスDLLにより許可されたときにディレクトリリストを取得し、htmlページを戻す。
◆アクセスDLLにより許可される場合、「HEAD」動詞（日付のみファイル修正）をサポートする。
◆可能な限り、ファイルを「readonlydenynone」として、再試行に失敗したものとして開く。
【００８５】
モジュールXはプラグインである。装置はこのようなモジュールを複数有し、モジュールにより処理されるデータに対する要求をm-Surfが受信すると、適切なモジュールを動的に選択するであろう。複数のモジュールを活動状態にすることができるので、幾つかの異なるデータソースから要求元のアプリケーションへデータを配信することができる。
【００８６】
モジュールXは、生データ取得とは別にまたはこれに加えて、ユーザインタフェイスのカスタマイズを可能にする。例えば、装置上で稼動するウェブブラウザは、ある特定のユーザ（すなわち、装置の供給元またはネットワークオペレータ）がスタートアップのホームページ（例えば、連絡先、スケジュール、装置の機能メニュー、オペレータのホームページへのリンク）において望ましいと定義するであろう異なるデータソースのすべてからm-Surfを介してデータを要求することができる。このブラウザは、実質的に装置に対するグラフィカルユーザインタフェイスの全体になる。企業のロゴをグラフィカルユーザインタフェイスへ追加することは簡単であり、特定の装置のメーカー、ネットワークオペレータ、または企業の経営者に対して装置に商標を付けることができる。マスタテンプレートを使用して、ユーザインタフェイスの全体の構造を定義することができる。幾つかのソースからのデータに対する複数の要求が開始され、ユーザインタフェイスが構築される。ユーザインタフェイスは、例えば、トップレベルのメニュー項目（例えば、連絡先およびスケジュール）のユーザ定義のリストから構成することができ、ユーザ定義のメニュー階層を組み込むことができるだろう。装置に対するユーザインタフェイスは、ユーザプリファレンスを考慮したり、あるいは、製品の差別化の拡大を可能にするために、空中を介して動的に変更、更新、またはカスタマイズすることができる。
【００８７】
モジュール5、6、7、8のそれぞれは、通常、上述の状況のように使用されるが、テストファイルまたは他のソースから/へリダイレクトされる入力/出力パイプを有することもできる。
【００８８】
特に、m-Surfの一部という訳ではないが、システムに対する拡張として、プラグインモジュールを呼び出し、テンプレートファイルを使用して戻されたデータを書式化し、HTMLおよび他の形式のコンテンツを生成することができる単純なテンプレートモジュールも使用されてきている。
【００８９】
設計をモジュール化することによって、WAPおよびSOAPのような代替の関連する技術を構造化された効率的な方法で統合することもできる。
【図面の簡単な説明】
【００９０】
【図１】m-RouterTMと呼ばれる実現例が、モバイルコンピューティング装置をPCおよび他のモバイルコンピューティング装置へ接続できるようにする方法の概略図、
【図２】m-Router構成要素の概略図、
【図３】システム/ホスト構造の概要図、
【図４】TCP/IPフレームがm-Routerによりパッケージ化できるようになる方法を示す図、
【図５】システムが転送するフレームをディスクリートストリームへ編成する方法を示す図、
【図６】単一のストリームに対する簡略化された構造を示す図、
【図７】プロトコルスタックを示す図、
【図８】PPPスタックを示す図、
【図９】図1のネットワークで使用されるm-Surfウェブサーバを示す図、
【図１０】m-Surfのhttpウェブサーバの内部の詳細を示す図である。
【図１】
2005501478.tif 000003
【図２】
2005501478.tif 000004
【図３】
2005501478.tif 000005
【図４】
2005501478.tif 000006
【図５】
2005501478.tif 000007
【図６】
2005501478.tif 000008
【図７】
2005501478.tif 000009
【図８】
2005501478.tif 000010
【図９】
2005501478.tif 000011
【図１０】
2005501478.tif 000012
【国際公開パンフレット】
2005501478.tif 000013
2005501478.tif 000014
2005501478.tif 000015
2005501478.tif 000016
2005501478.tif 000017
2005501478.tif 000018
2005501478.tif 000019
2005501478.tif 000020
2005501478.tif 000021
2005501478.tif 000022
2005501478.tif 000023
2005501478.tif 000024
2005501478.tif 000025
2005501478.tif 000026
2005501478.tif 000027
2005501478.tif 000028
2005501478.tif 000029
2005501478.tif 000030
2005501478.tif 000031
2005501478.tif 000032
2005501478.tif 000033
2005501478.tif 000034
2005501478.tif 000035
2005501478.tif 000036
2005501478.tif 000037
2005501478.tif 000038
2005501478.tif 000039
2005501478.tif 000040
2005501478.tif 000041
2005501478.tif 000042
2005501478.tif 000043
2005501478.tif 000044
2005501478.tif 000045
2005501478.tif 000046
2005501478.tif 000047
2005501478.tif 000048
2005501478.tif 000049
2005501478.tif 000050
2005501478.tif 000051
2005501478.tif 000052
【国際公開パンフレット（コレクトバージョン）】
2005501478.tif 000053
2005501478.tif 000054
【国際公開パンフレット（コレクトバージョン）】
2005501478.tif 000055
2005501478.tif 000056
2005501478.tif 000057
2005501478.tif 000058
2005501478.tif 000059
2005501478.tif 000060
2005501478.tif 000061
2005501478.tif 000062
2005501478.tif 000063
2005501478.tif 000064
2005501478.tif 000065
2005501478.tif 000066
2005501478.tif 000067
2005501478.tif 000068
2005501478.tif 000069
2005501478.tif 000070
2005501478.tif 000071
2005501478.tif 000072
2005501478.tif 000073
2005501478.tif 000074
2005501478.tif 000075
2005501478.tif 000076
2005501478.tif 000077
2005501478.tif 000078
2005501478.tif 000079
2005501478.tif 000080
2005501478.tif 000081
2005501478.tif 000082
2005501478.tif 000083
2005501478.tif 000084
2005501478.tif 000085
2005501478.tif 000086
2005501478.tif 000087
2005501478.tif 000088
2005501478.tif 000089
2005501478.tif 000090
2005501478.tif 000091
2005501478.tif 000092
2005501478.tif 000093
2005501478.tif 000094
2005501478.tif 000095
【国際調査報告】
2005501478.tif 000096
2005501478.tif 000097
2005501478.tif 000098