JP4210059B2 - デバイスドライバの生成 - Google Patents

Description

【０００１】
（関連出願の相互参照）
本出願は、ともに参照により本明細書に完全に組み込む、２０００年４月２４日に出願した「Ｂｌｕｅｔｏｏｔｈ Ｃｏｍｐｌｉａｎｔ Ｗｉｒｅｌｅｓｓ Ｄｅｖｉｃｅ Ｃｏｎｎｅｃｔｉｏｎｓ Ａｓ Ｍｏｄｅｍｓ Ｏｒ Ｓｏｃｋｅｔｓ（モデムまたはソケットとしての、ブルートゥース準拠ワイヤレス装置接続）」という名称の米国出願第０９／５５６，５６７号（整理番号２０４８４３）、および２０００年４月２４日に出願した「Ｂｌｕｅｔｏｏｔｈ ＭｉｎｉＰｏｒｔ Ｄｒｉｖｅｒ Ｍｏｄｅｌ（ブルートゥースミニポートドライバモデル）」という名称の米国出願第５５６，５６８号（整理番号２０４８５８）に関連する。
【０００２】
（技術分野）
本発明は、一般に、ワイヤレスインターフェース技術に関し、より詳細には、コンピュータソフトウェアアプリケーションと、ブルートゥース仕様に従って動作するワイヤレス装置の間のインターフェースに関する。
【０００３】
（発明の背景）
コンピュータシステム上でソフトウェアコンポーネントとハードウェアコンポーネントの間の適合性を最大限に高めるために、コンピュータのオペレーティングシステムは、特定のインターフェースを定義している。このインターフェースに対して、ソフトウェアコンポーネントのプログラマがアクセスし、これを使用することができ、ハードウェアコンポーネントの設計者がこのインターフェースを提供およびサポートできる。したがって、この定義されたインターフェースを使用することによって、ソフトウェアコンポーネントは、そのインターフェースをサポートするすべてのハードウェアコンポーネントと確実に適合できるようになる。同様に、ハードウェアコンポーネントが特定のインターフェースを提供することにより、このハードウェアコンポーネントがインターフェースを介して提供する機能をソフトウェアコンポーネントが確実に検出しアクセスできるようになる。
【０００４】
一般に、コンピュータおよびその他の電子装置は、物理的なケーブルまたはワイヤを介して相互接続されている。これらの通信経路によって、このような装置間のデータまたは制御情報の交換が可能になる。しかし、装置を相互接続するためのケーブルおよびワイヤを除去することによりある種の利点が得られるとの認識が強まっている。このような利点には、物理媒体を物理的に追加、除去、または移動する必要性がなくなることによって、構成および再構成が容易になるということが含まれる。さらに、従来は装置の相互接続媒体のために使用されていたスペースを、他用途に供することができる。さらに、ワイヤレス接続の使用により、装置の可動性が向上する。
【０００５】
装置間のワイヤレス接続を提供するある方法は、諸装置をリンクさせるために電磁スペクトルの赤外領域中の光波を使用する。ＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ（赤外線データ協会））プロトコルは、このような接続メカニズムの１つを定義している。残念なことに、このようなメカニズムは、通常、光軸（ｌｉｎｅ ｏｆ ｓｉｇｈｔ）を合わせた方法で動作しなければならない。すなわち、送信機と受信機の間に不透明な障害物があると、正しい動作が妨げられる。さらに、ＩＲ送信機は、一般に、通信装置に組み込まれた場合には全方向性ではなく、したがって、正しく動作させるためには、３０度など、ある公称偏差の範囲内で、ほぼ受信機の方向に向けなければならない。最後に、ＩＲ送信機は、一般に、きわめて低電力の装置であり、したがって、ＩＲリンクの範囲は、通常、約１メートルに限定される。
【０００６】
無線周波リンクは、赤外線リンクに固有の問題の多くを解決する。しかし、適切なインターフェースを提供する接続メカニズムを介して様々なアプリケーションが無線リンクに容易にアクセスすることができるような無線周波接続スキームが必要とされている。無線周波リンクを介したワイヤレス装置間の通信を定義する１つのプロトコルが、ブルートゥース仕様である。ブルートゥース装置は、動作するのに、互いが有する視野線を必要とはせず、その範囲は、ＩＲリンクよりも著しく広くできる。しかし、ブルートゥース仕様の１つの難点は、ブルートゥース準拠装置との通信用に書かれたコンピュータソフトウェアプログラムがきわめて少ないことである。ブルートゥース仕様のもう１つの難点は、ブルートゥース仕様に準拠したＲＦリンク上で動作するような設計の、高レベルのネットワーキングプロトコルが非常に少ないことである。
【０００７】
（発明の概要）
したがって、本発明は、ブルートゥース仕様に準拠したＲＦリンクを介して、バス独立型で、本来はバス付加型ネットワーキング装置のために設計されたネットワークメッセージプロトコルを提供するための方法およびコンピュータプログラムプロダクトを提供する。このような方法で、ハードワイヤード（またはバス付加型）ネットワークで動作するように設計された多くのコンピュータソフトウェアプロダクトを、ブルートゥースワイヤレスネットワーク上で使用することもできる。
【０００８】
本発明のさらなる特徴および利点は、添付の図面を参照しながら記載する、以下の例示的実施形態の詳細な説明から明らかであろう。
【０００９】
添付の特許請求の範囲に、本発明の特徴を詳細に記載してあるが、添付の図面とともに以下の詳細な説明を読めば、本発明を、その目的および利点とともに最もよく理解することができるであろう。
【００１０】
（発明の詳細な説明）
図面を参照すると、同一参照番号が同一エレメントを示しており、本発明を、適切なコンピューティング環境で実施したものとして図示してある。必要とはしないが、本発明を、プログラムモジュールなど、パーソナルコンピュータによって実行されるコンピュータ実行可能命令という一般的状況において説明する。一般に、プログラムモジュールには、特定のタスクを実行し、または特定の抽象タイプのデータを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらに、当業者は、本発明が、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な消費者電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含めて、その他のコンピュータシステム構成で実施できることを理解されよう。本発明はまた、タスクが、通信ネットワークを介してリンクされているリモート処理装置によって実行される、分散コンピューティング環境においても実施することができる。分散コンピューティング環境では、プログラムモジュールをローカルおよびリモート、両方のメモリ記憶装置に配置することができる。
【００１１】
図１を参照すると、本発明を実施するための例示的システムは、処理装置２１、システムメモリ２２、および、システムメモリを含めて、様々なシステムコンポーネントを処理装置２１に結合するシステムバス２３を含む、従来のパーソナルコンピュータ２０という形の汎用コンピューティング装置を含む。システムバス２３は、様々なバスアーキテクチャのいずれかを使用した、メモリバスまたはメモリコントローラ、周辺バス、ローカルバスを含めて、何種類かのバス構造のうちのいずれかでよい。システムメモリは、読出し専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。起動中などに、パーソナルコンピュータ２０内のエレメント間の情報の転送を援助する基本ルーチンを含む、基本入出力システム（ＢＩＯＳ）２６は、ＲＯＭ２４中に記憶されている。パーソナルコンピュータ２０は、ハードディスク６０からの読出しおよびそれへの書込みを行うためのハードディスクドライブ２７、リムーバブル磁気ディスク２９からの読出しおよびそれへの書込みを行うための磁気ディスクドライブ２８、および、ＣＤ ＲＯＭまたはその他の光媒体など、リムーバル光ディスク３１からの読出しおよびそれへの書込みを行う光ディスクドライブ３０をさらに含む。
【００１２】
ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれ、ハードディスクドライブインターフェース３２、磁気ディスクドライブインターフェース３３、および光ディスクドライブインターフェース３４によって、システムバス２３に接続されている。ドライブおよびそれらの関連するコンピュータ可読媒体は、パーソナルコンピュータ２０に、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性記憶を提供する。本明細書で説明している例示的環境では、ハードディスク６０、リムーバブル磁気ディスク２９、およびリムーバブル光ディスク３１を使用しているが、当業者は、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイ（Ｂｅｒｎｏｕｌｌｉ）カートリッジ、ランダムアクセスメモリ、読出し専用メモリなど、コンピュータがアクセス可能なデータを記憶することができる他のタイプのコンピュータ可読媒体も、例示の動作環境で使用できることを理解されよう。
【００１３】
ハードディスク６０、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５には、オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、その他のプログラムモジュール３７、およびプログラムデータ３８を含めて、いくつかのプログラムモジュールを記憶することができる。ユーザは、キーボード４０やポインティング装置４２などの入力装置を介して、パーソナルコンピュータ２０にコマンドおよび情報を入力することができる。その他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含めることができる。これらおよびその他の入力装置は、システムバスに結合されたシリアルポートインターフェース４６を介して処理装置２１に接続されていることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など、その他のインターフェースで接続することもできる。モニタ４７または他のタイプのディスプレイ装置も、ビデオアダプタ４８などのインターフェースを介してシステムバス２３に接続される。モニタに加えて、パーソナルコンピュータは、一般に、スピーカやプリンタなど、図示してはいないが、その他の周辺出力装置も含む。
【００１４】
パーソナルコンピュータ２０は、リモートコンピュータ４９やＲＦ装置６４など、１つまたは複数のリモートコンピュータまたは装置への論理接続を使って、ネットワーク化された環境で動作することができる。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般のネットワークノードでよく、一般に、パーソナルコンピュータ２０に関連して上記に説明したエレメントの多くまたはすべてを含む。ただし、図１では、記憶装置５０しか図示していない。無線周波（ＲＦ）装置６４は、セルラフォン、デジタルカメラ、別のパーソナルコンピュータ、またはＲＦスペクトルを介して通信を行う機能を含むその他の装置でよい。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２、およびＲＦ接続６３を含む。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネットおよびインターネットでは普通である。
【００１５】
パーソナルコンピュータ２０は、ＬＡＮネットワーキング環境で使用される場合は、ネットワークインターフェースまたはアダプタ５３を介して、ローカルネットワーク５１に接続される。パーソナルコンピュータ２０は、ＷＡＮネットワーキング環境で使用される場合は、一般に、モデム５４、またはＷＡＮ５２を介して通信を確立するためのその他の手段を含む。モデム５４は、内部装置でも外部装置でもよく、シリアルポートインターフェース４６を介してシステムバス２３に接続される。パーソナルコンピュータ２０は、ＲＦ接続６３と共に使用される場合は、ＲＦインターフェース６２を含む。ネットワーク化された環境では、パーソナルコンピュータ２０またはその部分に関連して示しているプログラムモジュールを、リモート記憶装置に記憶することができる。図示しているネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段も使用できることを理解されよう。
【００１６】
以下の記載では、別途記載がない限り、本発明を、１つまたは複数のコンピュータによって実行される、動作およびオペレーションの記号表示を参照して説明する。したがって、時々、コンピュータによって実行される、と述べるこのような動作およびオペレーションには、コンピュータの処理装置による、構造化した形のデータを表す電気信号の操作も含まれることを理解されたい。この操作は、データを変形し、またはコンピュータのメモリシステム中のロケーションに保持し、それによって、コンピュータのオペレーションを、当業者によく理解されている方法で、再構成あるいは変更する。データが保持されるデータ構造とは、データのフォーマットによって定義される特定のプロパティを有するメモリの物理的ロケーションである。しかし、本発明を前述の状況で説明しているが、以下に記載の様々な動作およびオペレーションは、ハードウェアでも実施できることが当業者にはわかるように、それは限定することを意図したものではない。
【００１７】
本発明に従って、図２を参照すると、オープンシステム間相互接続（ＯＳＩ）の７層モデルを示してある。このモデルは、コンピュータネットワーキングの業界標準抽象化である。応用層１００は、直接、エンドユーザにサービスし、ユーザが相互作用し合うソフトウェアアプリケーションをサポートする。プレゼンテーション層１０２は、あるコンピュータ上の応用層１００から別のコンピュータ上の応用層に送られてきたデータを解釈するメカニズムを提供する。セション層１０４は、転送されてきたデータの構成を記述する。トランスポート層１０６は、最終的なエラー訂正層として動作し、データが正確に正しい順序で、損失や重複なく確実に引き渡されるようにする。ネットワーク層１０８は、ネットワーク上でのデータのアドレス指定および経路指定を定義する。それは、ローカルサブネットワークのオペレーションを制御し、また、データがどの物理的経路をとるべきか、所与のネットワーク条件、サービスの優先順位、およびその他の要因を決定する。データリンク層１１０は、ネットワークを介したデータブロックまたはパケットの送信を制御し、より基本的なエラー訂正を行う。データリンク層１１０は、論理リンク制御（ＬＬＣ）副層および媒体アクセス制御（ＭＡＣ）副層の２つの副層（ｓｕｂｌａｙｅｒ）に分けられる。ＬＬＣ副層は、論理リンクを保持し、フレームフローを制御し、フレームの順番を付け、フレームに肯定応答し、肯定応答しなかったフレームを再送信することによって、エラーのないデータフレーム送信を保証する。ＭＡＣ副層は、ネットワークへのアクセスを管理し、フレームエラーをチェックし、受け取ったフレームの認識を行う。ＬＬＣ副層を含むプロトコルは、最小限のトランスポート層１０６だけが必要である。最後に、物理層１１２は、ネットワーク接続１１４に送られる信号を搬送する。一般に、物理層１１２は、コンピュータ２０をネットワーク接続１１４に接続するハードウェアで実施される。
【００１８】
ネットワーク装置インターフェース仕様（ＮＤＩＳ）１１６は、ネットワーク層１０８とデータリンク層１１０の間に常駐することができる。ＮＤＩＳ１１６は、ソフトウェアコンポーネントとハードウェアコンポーネントの間のインターフェースのライブラリを提供することができる。ＮＤＩＳ１１６は、ネットワークインターフェースカード（ＮＩＣ）ドライバが実行する必要があるすべての外部機能にルーチンを提供することによって、ＮＩＣドライバ開発のための完全に抽象化された環境を定義することができる。したがって、ＮＤＩＳ１１６は、ＮＩＣドライバと上部のプロトコルドライバの間、およびＮＩＣドライバと下部のＮＩＣハードウェア自体の間で通信を行うためのインターフェースを提供することができる。
【００１９】
一般に、応用層１００、プレゼンテーション層１０２、セション層１０４、トランスポート層１０６、およびネットワーク層１０８は、コンピュータ上で動作するソフトウェアコンポーネントで実施される。データリンク層１１０および物理層１１２は、一般に、ネットワークインターフェースカードなどのハードウェアコンポーネントで実施される。ＮＤＩＳ１１６ライブラリは、トランスポート層１１０で実施されたソフトウェアドライバが、データリンク層１１０で実施されたネットワークインターフェースカードドライバと通信を行うために使用することができる。トランスポート層ドライバは、一般に、インターネット上で使用される、よく知られているＴＣＰ／ＩＰ（Ｔｒａｎｓｆｅｒ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（転送制御プロトコル／インターネットプロトコル））スタックなどの、ネットワークプロトコルスタックを実施する。トランスポート層ソフトウェアドライバは、送信すべきデータパケットを持っている場合、ＮＤＩＳ１１６ライブラリからのインターフェースを使ってＮＩＣドライバを呼び出し、転送すべきパケットを下に渡すことができる。同様に、ＮＩＣドライバは、ＮＤＩＳ１１６のインターフェースを使って、ネットワークを介して送信するように、パケットをＮＩＣ自体に渡すことができる。ＮＤＩＳ１１６インターフェースは、ＮＩＣで送信を実行する、オペレーティングシステム固有のコンポーネントを呼び出すことができる。また、ＮＩＣドライバは、ＮＤＩＳ１１６インターフェースを使って、トランスポート層ソフトウェアドライバと通信し、受け取ったデータパケットまたはその他の情報を上に渡すこともできる。
【００２０】
物理層１１２の一例が、ワイヤレス無線周波（ＲＦ）装置６４である。装置６４とコンピュータ２０の間のワイヤレス通信のための、ますます人気を集めつつあるＲＦプロトコルが、ブルートゥースプロトコルである。これについては、参照により本明細書に完全に組み込まれている「Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ Ｂｌｕｅｔｏｏｔｈ Ｓｙｓｔｅｍ（ブルートゥースシステムの仕様）」第１．０Ｂ版（１９９９年１２月１日）に、より詳細に記載されている。また、付録Ｂに提示の「Ｗｉｎｄｏｗｓ（登録商標） Ｗｉｒｅｌｅｓｓ Ａｒｃｈｉｔｅｃｔｕｒｅ（Ｗｉｎｄｏｗｓ（登録商標）ワイヤレスアーキテクチャ）」、付録Ｃに提示の「Ｂｌｕｅｔｏｏｔｈ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｏｖｅｒｖｉｅｗ（ブルートゥースアーキテクチャの概要）」、付録Ｄに提示の「Ｂｌｕｅｔｏｏｔｈ Ｅｘｐｅｒｉｅｎｃｅ ｉｎ Ｗｉｎｄｏｗｓ（登録商標）（Ｗｉｎｄｏｗｓ（登録商標）でのブルートゥースの経験）」、および付録Ｅに提示の「Ｂｌｕｅｔｏｏｔｈ Ｓｔａｃｋ ｉｎ Ｗｉｎｄｏｗｓ（登録商標）（Ｗｉｎｄｏｗｓ（登録商標）でのブルートゥーススタック）」も参照されたい。ブルートゥース仕様に記載されているように、Ｌ２ＣＡＰ（Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ ａｎｄ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（論理リンク制御および適合用プロトコル））は、高水準プロトコルがブルートゥース準拠のＲＦリンクを介して動作できるようにする。Ｌ２ＣＡＰ層については、付録Ａに添付し、参照により本明細書に完全に組み込まれている、「Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ ａｎｄ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（論理リンク制御および適合用プロトコル仕様）」というタイトルの「Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ Ｂｌｕｅｔｏｏｔｈ Ｓｙｓｔｅｍ（ブルートゥースシステムの仕様）」第１．ＯＢ版、パートＤ（１９９９年１２月１日）に、より詳細に記載されている。このようなより高水準のメッセージングプロトコルの１つに、マイクロソフト社のリモートＮＤＩＳ（リモートネットワーク装置インターフェース仕様）がある。これについては、１９９９年４月３０日に出願され、本出願の譲受人に譲渡されて、参照により本明細書に完全に組み込まれている、Ｈｙｄｅｒ等による、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ａｂｓｔｒａｃｔｉｎｇ Ｎｅｔｗｏｒｋ Ｄｅｖｉｃｅ Ｄｒｉｖｅｒｓ（ネットワークデバイスドライバを抽象化する方法およびシステム）」という名称の同時係属出願第０９／３０２，７３５号により詳細に記載されている。この同時係属出願に記載されているように、リモートＮＤＩＳは、バス固有のメッセージトランスポートメカニズムを変更することなく拡張可能性を提供し、それによって、物理層１１２によって実施される、比較的多種にわたるこのようなトランスポートメカニズムへの実施が可能になる。また、リモートＮＤＩＳは、ネットワーキングと外部バス装置モデルの両方について証明されているドライバアーキテクチャも提供する。
【００２１】
本発明がなければ、ハードウェアのメーカは、２つのドライバ、ＮＤＩＳ ミニポートドライバと、バスまたはネットワークインターフェースを書かなければならない。しかし、この２つのドライバを、単一のバイナリとして配布することができる。第１のドライバ、ＮＤＩＳミニポートドライバは、ＮＤＩＳ１１６と情報を交換し、あるベンダ固有のＡＰＩを介して、バスまたはネットワークインターフェースドライバと通信を行う。バスまたはネットワークインターフェースドライバは、バス固有またはネットワーク固有であり、適切なバスまたはネットワークドライバを介してハードウェアと通信を行う。ＮＤＩＳミニポートドライバ、およびバスまたはネットワークインターフェースドライバは、両ドライバとも、アクセスされているネットワーク装置のメーカが書いたものであるため、ベンダ固有のＡＰＩを介して通信を行う。したがって、ＮＤＩＳミニポートが、ＮＤＩＳ層１１６と通信するためにはＮＤＩＳ ＡＰＩに準拠しなければならず、また、バスまたはネットワークインターフェースが、情報をネットワーク装置に渡す際に、該当するバスまたはネットワークドライバに従わなければならない一方で、ＮＤＩＳミニポートと、バスまたはネットワークインターフェースの間の相互作用は、完全にハードウェアメーカに一任されている。装置メーカに、彼らが市場に出している各機器ごとに２つのドライバを書くことを要求することは、いくつかのきわめて重大な問題を生じさせる。例えば、デバイスドライバの純粋な数を管理することは、ハードウェアメーカおよびソフトウェアとともにある種のデバイスドライバを配布する可能性があるオペレーティングシステム開発会社の両方にとって、困難かつ費用がかかることである。さらに、メーカが、ＮＤＩＳへの接続とバスまたはネットワークインターフェースの両方を提供するため、ネットワークの機能と特定のバスの特性が結合される可能性があり、一方を、もう一方なしに更新することが不可能になる。これらの問題を解決することにより、リモートに接続されるネットワーキング装置の配置をより速く行うことができ、また、ホストベースのドライバの開発コストをより低くすることができる。
【００２２】
ＮＤＩＳミニポートドライバ、およびバスまたはネットワークインターフェースは、ともに装置ハードウェアメーカが提供しており、リモートＮＤＩＳミニポート層およびバス固有またはネットワーク固有のマイクロポートと交換することができる。リモートＮＤＩＳミニポート層、およびバス固有またはネットワーク固有のマイクロポートは、アクセスされる特定の装置とは独立しており、したがって、オペレーティングシステムの一部として含めることができる。したがって、リモートＮＤＩＳ仕様に添ってドライバを書くハードウェアメーカは、自分たちの装置のためにホストベースのドライバを書く必要がなくなる。
【００２３】
リモートＮＤＩＳは、接続不可知または接続独立のメッセージセットを、そのメッセージセットが、特定のバスやネットワークなど特定の接続を介してどのように動作するかという記載とともに、定義する。リモートＮＤＩＳインターフェースは標準化されているので、コアセットのホストドライバは、取り付けられているネットワーキング装置をいくつでもサポートすることができる。それによって、新しいネットワーク装置をサポートするために新しいドライバをインストールする必要がなくなるので、システムの安定性とユーザの満足度が向上する。リモートＮＤＩＳアーキテクチャは、リモートＮＤＩＳメッセージセットを理解し、バス固有またはネットワーク固有のマイクロポートドライバと通信を行う、リモートＮＤＩＳミニポートドライバを含む。特に、リモートＮＤＩＳミニポート層は、ＮＤＩＳ ＯＩＤ（オブジェクト識別子）とＮＤＩＳデータパケットを、修正なしにネットワーキング装置に渡すことができるデータ構造にカプセル化する。このデータ構造はリモートＮＤＩＳメッセージとして知られる。
【００２４】
バス固有またはネットワーク固有のマイクロポートドライバは、メッセージを装置に渡す責任を有するバスまたはネットワークを理解する中間層を表す。したがって、マイクロポート層は、リモートＮＤＩＳメッセージを受け取って、それらをバスまたはネットワークドライバ層の対応するエレメントに渡す。次いで、バスまたはネットワークドライバ層は、そのリモートＮＤＩＳメッセージを、リモートＮＤＩＳ装置に渡す。ネットワークプロトコルメカニズムは、バスまたはネットワーク固有のマイクロポート層よりも上で抽象化されるため、新しいネットワーク機能の追加は、リモートＮＤＩＳミニポート層のみを変更するだけで行うことができる。マイクロポート層は、リモートＮＤＩＳメッセージにカプセル化されたＮＤＩＳ ＯＩＤおよびＮＤＩＳデータパケットを渡すメッセージトランスポートメカニズムにすぎないので、変更されないままである。さらに、すべてのバスまたはネットワークマイクロポートは、単一のリモートＮＤＩＳミニポート層がそれらすべてにサービスすることができるので、ネットワーク機能を新しいＮＤＩＳ ＯＩＤの形で追加することが利用可能である。本発明はまた、後方互換性も維持する。新しいＮＤＩＳ ＯＩＤが追加されると、リモートＮＤＩＳ装置が、それがそのＮＤＩＳ ＯＩＤを理解できず、したがって、その新しいネットワーク機能をサポートしないと応答することもある。
【００２５】
図３を見ると、Ｌ２ＣＡＰチャネル１６０など、単一のＬ２ＣＡＰチャネルを、リモートＮＤＩＳ制御通信のために使用することができる。このような制御通信には、制御メッセージ、これらのメッセージへの応答、および装置１６２が、それによって状態の変化を示すことができるメッセージが含まれる。別のＬ２ＣＡＰチャネル１５０を使って、リモートＮＤＩＳデータパケットを交換することができる。データメッセージは、長さが１５００バイトまで可能であり、これは、全ブルートゥース帯域幅を使用した場合には約２０ｍｓかかるが、データメッセージが他のトラフィックと帯域幅を共用しなければならない場合にはこれよりもずっとかかる。したがって、制御メッセージを送る際の待ち時間を制限するために、別個のＬ２ＣＡＰチャネル１６０が提供されている。装置１６２上に存在する可能性がある複数のネットワーキングチャネルに対処するために、追加Ｌ２ＣＡＰチャネルを加えることができる。
【００２６】
上記に、図２を参照して説明したように、制御メッセージは、図３に示す制御層１５８に直接送られ、一方、データは、まず媒体アクセス制御層１５４が受け取り、次に、物理層１５６で、物理的ネットワークを介して送信するためにカプセル化することができる。応答および状態信号の送信を容易にするために、また、即時制御を可能にするために、制御層１５８を、媒体アクセス制御層１５４および物理層１５６の両方に直接、接続する。
【００２７】
ネットワークデータは、Ｌ２ＣＡＰチャネル１５０を介して、ホスト１６４と装置１６２の間で渡される。このデータは、ＮＤＩＳネットワークスタックがすでに使用しているモデル上で、ＮＤＩＳパケットメカニズムにカプセル化することができる。Ｌ２ＣＡＰがサポートするパケットの最大長は、媒体の最大ＭＴＵから、ＲＮＩＤＳヘッダサイズを差し引いたものであり得る。装置１５２は、それが送ることができる最大Ｌ２ＣＡＰメッセージ（サイズ）までのＭａｘＴｒａｎｓｆｅｒＳｉｚｅ値を、ＮＤＩＳファンクションコールに記入することができる。ホスト１６４は、そのＬ２ＣＡＰ最大メッセージサイズがそれよりも小さい場合、戻された情報をそれ自体の最大メッセージサイズで上書きすることができる。ホスト１６４または装置１６２のいずれかが、制御およびデータＬ２ＣＡＰチャネルの両方のセットアップを開始することができる。
【００２８】
ブルートゥースリモートＮＤＩＳ装置に使用することができる、最小のサービスディスカバリプロトコル（ＳＤＰ）レコードは、下記の表１に示すようになり得る。見てわかるように、リモートＮＤＩＳ装置は、標準サービスディスカバリ記述を使用する。パーソナルエリアネットワーク（ＰＡＮ）サービスは、互いに通信を行うことができる。ブルートゥース装置が複数のＰＡＮサービスを有することも可能である。例えば、セルラフォンが、セルラデータネットワークへのブルートゥース装置のアクセスを可能にするワイヤレスＷＡＮサーバを有することもあり得る。このような場合、ＳｅｒｖｉｃｅＮａｍｅは「ＷＷＡＮ」、またはより説明的な名前であってよい。あるいは、セルラフォンが、装置間でピアツーピアの通信を行うための内部ＰＡＮサービスを可能にする、ＰＡＮサービスを有することもあり得る。このような場合、ＳｅｒｖｉｃｅＮａｍｅは、「ＰＥＥＲ」に設定すればよい。装置は、ＰＥＥＲというＳｅｒｖｉｃｅＮａｍｅを持つＰＡＮプロファイルを、２つ以上アドバタイズするべきではない。
【００２９】
【表１】

【００３０】
リモートＮＤＩＳブルートゥース装置は、２つ以上のＬ２ＣＡＰチャネル、すなわち１つの制御チャネル、および１つまたは複数のデータチャネルを開始または受信することができる。装置１６２へのメッセージは、Ｌ２ＣＡＰパケットデータユニット（ＰＤＵ）の形で送ることができる。この装置には、ホスト１６４から制御チャネル１６０でメッセージを送ることができ、また、この装置は、次いで、その同じ制御チャネルで応答を送ることができる。ブルートゥースＲＮＤＩＳ装置のこのような典型的なトランザクションの一例として、以下のような場合があり得る。ホスト１６４は、ＮｄｉｓＱｕｅｒｙＲｅｑｕｅｓｔ型で構成された内容で、制御チャネル上にブルートゥースＷＲＩＴＥを発行する。ＮｄｉｓＱｕｅｒｙＲｅｑｕｅｓｔのＲＮＤＩＳ＿ＯＩＤ値は、ＯＩＤ＿ＧＥＮ＿ＭＥＤＩＡ＿ＣＯＮＮＥＣＴ＿ＳＴＡＴＵＳに設定され得る。装置１６２は、ブルートゥースデータを受け取ると、ＮｄｉｓＱｕｅｒｙＲｅｑｕｓｔを復号し、必要なアクションを行って、接続ステータスを判断する。装置は、ホストが要求している情報をＮｄｉｓＱｕｅｒｙＲｅｑｕｅｓｔ中に持っていると、制御チャネル１６０上に、ＮｄｉｓＱｕｅｒｙＲｅｓｐｏｎｓｅから成るブルートゥースＷＲＩＴＥを発行する。この場合、ＮｄｉｓＱｕｅｒｙＲｅｓｐｏｎｓｅはＯＩＤ＿ＧＥＮ＿ＭＥＤＩＡ＿ＣＯＮＮＥＣＴＩＯＮ＿ＳＴＡＴＵＳに設定され得る。
【００３１】
ブルートゥースは、ピアツーピアシステムである。さらに、ＳＤＰレコードは、ホストと装置システムの違いを定義しない。したがって、ブルートゥースマイクロポートがそれ自体に対して作動できることがあり得る。ホストのみのＲＮＤＩＳマイクロポートは、ある種のメッセージを開始する必要があるだけであり、ある種のメッセージを受け取るだけである。しかし、マイクロポートは、ホスト、装置、またはその両方であり得るので、ホストまたは装置のいずれかが受け取ることができるあらゆるメッセージを処理することができる。したがって、マイクロポートは、これらのメッセージを扱うことができなければならない。ブルートゥースマイクロポートは、例えばセルラフォンに接続されている場合には、ホストマイクロポートとしてのみ動作することができ、また、同じくマイクロポートを走らせている別のマシンに接続されている場合には、ホスト／装置の両方として動作することができる。マイクロポートは、メッセージを処理する際に振動が起きないように設計しなければならない。
【００３２】
リモートＮＤＩＳは、ＮＤＩＳ ＯＯＢおよびパケットごとの情報のフィールドをトランスポートするためのスペースを含めて、ＲＥＭＯＴＥ＿ＮＤＩＳ＿ＰＡＣＫＥＴメッセージのフォーマットを定義する。パケットごとの情報のファイルは、ＮＤＩＳが、それがその機能をサポートすることをリモートドライバが指定している場合に、供給することができる。ＯＯＢ情報は、特定の媒体タイプについてサポートされ得る。例えば、イーサネット（登録商標）の場合は、ピアツーピアのエミュレーションフィールドは必要ではない。このような場合、４４バイトのオフセットおよびパケット情報フィールドの長さは必要とされない。したがって、１５１４バイトのイーサネット（登録商標）ＭＴＵの場合、Ｌ２ＣＡＰのＭＴＵは最小１５５４バイトであることが可能であり、ブルートゥース帯域幅の約３％が無駄になる。これは、低速リンクの場合には問題になる。これは、ＤａｔａＯｆｆｓｅｔが４であるならば、ＲＮＤＩＳ＿ＰＡＣＫＥＴヘッダの残りがヌルであると想定して、最適化することができる。これによって、データのオーバヘッドを、１６バイトすなわち１％減少させることができる。
【００３３】
オペレーション中に、ＰＡＮサービスをサポートするリモートブルートゥース装置が範囲内にあり、通信することが可能な場合には、ブルートゥースマイクロポートをロードすることができる。マイクロポートをロードすることによって、マイクロポートから初期化メッセージが送られるようにすることができる。リモート装置が例えばセルラフォンである場合、それは、初期化完了メッセージで応答することができる。別の例として、リモート装置が別のＷｉｎｄｏｗｓ（登録商標）マシンの場合、これもまた初期化メッセージを生成することができる。マイクロポートは、ＲＥＭＯＴＥ＿ＮＤＩＳ＿ＩＮＩＴＩＡＬＩＺＥ＿ＭＳＧ、ＲＥＭＯＴＥ＿ＮＤＩＳ＿ＱＵＥＲＹ＿ＭＳＧ、ＲＥＭＯＴＥ＿ＮＤＩＳ＿ＳＥＴ＿ＭＳＧ、ＲＥＭＯＴＥ＿ＮＤＩＳ＿ＲＥＳＥＴ＿ＭＳＧ、ＲＥＭＯＴＥ＿ＮＤＩＳ＿ＫＥＥＰＡＬＩＶＥ＿ＭＳＧなどの特別なメッセージを受け取ることもできる。これらのメッセージについては、２０００年３月２０日付けの「Ｒｅｍｏｔｅ ＮＤＩＳ Ｏｖｅｒ Ｂｌｕｅｔｏｏｔｈ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ブルートゥース仕様を介したリモートＮＤＩＳ）」というタイトルの論文に、より詳細に説明されている。これは付録Ｆに添付した。
【００３４】
特許、特許出願、出版物を含めて、本明細書で挙げている参考文献はすべて、参照により本明細書に完全に組み込まれている。
【００３５】
本発明の原理を適用することができる多くの可能な実施形態を考えると、本明細書で図面を参照して説明している実施形態は例示にすぎず、発明の範囲を限定するものとして解釈するべきではないことを理解されたい。例えば、当業者は、ソフトウェアとして示してある例示の実施形態のエレメントが、ハードウェアとして実施でき、またその反対も可能であること、または、例示の実施形態が、本発明の趣旨から逸脱することなく、構成および細部において修正可能であることを理解されるであろう。したがって、本明細書に記載している本発明は、すべてのこのような実施形態を、特許請求の範囲およびその同等物の範囲内に入るものとしてみなすものである。
【図面の簡単な説明】
【図１】 本発明が存在する例示的コンピュータシステムを全体的に示す構成図である。
【図２】 ７層ネットワークモデルを全体的に示す構成図である。
【図３】 本発明が動作することができる層モデルを、全体的に示す構成図である。

Claims (18)

1. ネットワーク装置を使用する方法であって、前記ネットワーク装置は、ネットワーク接続およびワイヤレス接続を有する方法において、
   装置制御コマンドおよびデータを装置独立フォーマットに抽象化するステップと、
   接続独立ドライバ層を使用して、抽象化された前記装置制御コマンドおよびデータを接続独立フォーマットにカプセル化するステップと、
   中間ドライバ層を使用して、カプセル化された前記装置制御コマンドおよびデータを接続固有の装置制御コマンドおよびデータに変換するステップと、
   接続固有のドライバ層を使用して、前記接続固有の装置制御コマンドおよびデータを前記ネットワーク装置にワイヤレスで送信するステップであって、そこでは前記ネットワーク装置は前記接続固有の装置制御コマンドおよびデータを前記ワイヤレス接続を介して受信し、前記ネットワーク接続を介して前記データを送信するステップと
   を含むことを特徴とする方法。
2. 前記ワイヤレス接続が、ブルートゥース接続であり、前記接続固有の装置制御コマンドおよびデータが、前記ブルートゥースプロトコルに準拠することを特徴とする請求項１に記載の方法。
3. 前記接続固有のドライバ層が、前記接続固有の装置制御コマンドおよびデータを、少なくとも１つのＬ２ＣＡＰチャネルを介して前記ネットワーク装置に送信することを特徴とする請求項１に記載の方法。
4. 前記接続固有のドライバ層が、第１のＬ２ＣＡＰチャネルを介して前記接続固有の装置制御コマンドを送信し、第２のＬ２ＣＡＰチャネルを介して前記接続固有のデータを送信することを特徴とする請求項３に記載の方法。
5. 前記中間ドライバ層がカプセル化された前記装置制御コマンドおよびデータを、サービスディスカバリプロトコルレコードを参照して、接続固有の装置制御コマンドおよびデータに変換することを特徴とする請求項１に記載の方法。
6. 前記接続固有のドライバ層が、前記接続固有の装置制御コマンドおよびデータを、前記ネットワーク装置のワイヤレス接続が使用するワイヤレスプロトコルの最大送信単位よりも小さいパケットにセグメント化することによって送信することを特徴とする請求項１に記載の方法。
7. ワイヤレス装置を介してネットワーク接続するコンピュータにおいて、
   装置制御コマンドおよびデータを装置独立フォーマットに抽象化する装置独立ドライバ層、
   抽象化された前記装置制御コマンドおよびデータを接続独立フォーマットにカプセル化する接続独立ドライバ層、
   カプセル化された前記装置制御コマンドおよびデータを接続固有の装置制御コマンドおよびデータに変換する中間ドライバ層、
   前記接続固有の装置制御コマンドおよびデータを前記ワイヤレス装置に送信する接続固有のドライバ層、および
   前記接続固有のドライバ層を使用して、前記接続固有の装置制御コマンドおよびデータを前記ワイヤレス装置に送信するワイヤレス通信機器
   を備えたことを特徴とするコンピュータ。
8. 前記ワイヤレス通信機器は、ブルートゥースプロトコルを使用し、前記接続固有の装置制御コマンドおよびデータが、前記ブルートゥースプロトコルに準拠することを特徴とする請求項７に記載のコンピュータ。
9. 前記接続固有のドライバ層は、前記接続固有の装置制御コマンドおよびデータを、少なくとも１つのＬ２ＣＡＰチャネルを介して前記ワイヤレス装置に送信することを特徴とする請求項７に記載のコンピュータ。
10. 前記接続固有のドライバ層は、前記接続固有の装置制御コマンドを第１のＬ２ＣＡＰチャネルを介して送信し、前記接続固有のデータを第２のＬ２ＣＡＰチャネルを介して送信することを特徴とする請求項９に記載のコンピュータ。
11. 前記中間ドライバ層は、前記カプセル化された装置制御コマンドおよびデータを前記接続固有の装置制御コマンドおよびデータに変換している間、サービスディスカバリプロトコルレコードを参照することを特徴とする請求項７に記載のコンピュータ。
12. 前記接続固有のドライバ層は、前記接続固有の装置制御コマンドおよびデータを、前記ワイヤレス通信機器が使用するワイヤレスプロトコルの最大送信単位よりも小さいパケットにセグメント化することを特徴とする請求項７に記載のコンピュータ。
13. ネットワーク接続およびワイヤレス接続を有するネットワーク装置を使用し、コンピュータ実行可能命令を有するコンピュータプログラムを記憶したコンピュータ読み取り可能な記憶媒体であって、前記コンピュータ実行可能命令は、
    装置制御コマンドおよびデータを装置独立フォーマットに抽象化するステップ、
    前記装置制御コマンドおよびデータを接続独立フォーマットにカプセル化するステップ、
    当該カプセル化された装置制御コマンドおよびデータを接続固有の装置制御コマンドおよびデータに変換するステップ、および、
    前記接続固有の装置制御コマンドおよびデータをワイヤレスに前記ネットワーク装置のワイヤレス接続に送信するステップであって、そこでは前記データは前記ネットワーク接続を介して前記ネットワーク装置により送信されるステップ
    を実行することを特徴とするコンピュータ読み取り可能な記憶媒体。
14. 前記ワイヤレス接続は、ブルートゥース接続であり、前記接続固有の装置制御コマンドおよびデータが、前記ブルートゥースプロトコルに準拠することを特徴とする請求項１３に記載のコンピュータ読み取り可能な記憶媒体。
15. 前記接続固有の装置制御コマンドおよびデータの前記ネットワーク装置への送信は、少なくとも１つのＬ２ＣＡＰチャネルを介して行われることを特徴とする請求項１３に記載のコンピュータ読み取り可能な記憶媒体。
16. 前記少なくとも１つのＬ２ＣＡＰチャネルを介した前記接続固有の装置制御コマンドおよびデータの送信では、第１のＬ２ＣＡＰチャネルを介して前記接続固有の装置制御コマンドを送信し、第２のＬ２ＣＡＰチャネルを介して前記接続固有のデータを送信することを特徴とする請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
17. 前記カプセル化された装置制御コマンドおよびデータを前記接続固有の装置制御コマンドおよびデータに変換するステップでは、サービスディスカバリプロトコルレコードを参照することを特徴とする請求項１３に記載のコンピュータ読み取り可能な記憶媒体。
18. 前記接続固有の装置制御コマンドおよびデータを変換するステップでは、前記ワイヤレス装置が使用するワイヤレスプロトコルの最大送信単位よりも小さいパケットにセグメント化することを特徴とする請求項１３に記載のコンピュータ読み取り可能な記憶媒体。

Images