(57)【要約】  トラステッド媒体を介した非トラステッド媒体（たとえば、無線）デバイス構成の拡張可能アーキテクチャが記載される。このアーキテクチャは、有線接続等のトラステッド媒体を使用して接続デバイスとホストデバイスとの間の無線ユニバーサルシリアルバス（ＷＵＳＢ）接続を確立するためのシステム及び方法を含む。一実施態様では、接続デバイスは、トラステッド媒体を通じてホストデバイスへアソシエーション要求を送信する。このアソシエーション要求は、接続デバイスのＷＵＳＢコンポーネントに関連付けられたデバイス属性を含む。これに応答して、ホストデバイスは、アソシエーション要求を解析してその有効性を確認し、ＷＵＳＢを使用して接続するための接続属性を決定する。ホストデバイスは、トラステッド媒体を通じて接続デバイスへ、接続属性を有する応答を送信する。接続デバイスは、接続属性を使用して、ＷＵＳＢコンポーネントを構成し、ホストデバイスとのＷＵＳＢ接続を確立する。
2008547250.tif 000002
【特許請求の範囲】
【請求項１】
以下のステップを実行するためのデバイス実行可能命令でコード化された１つ又は２つ以上のデバイス可読媒体であって、ステップとして、
トラステッド媒体を介して無線ユニバーサルシリアルバス（ＷＵＳＢ）デバイスからのアソシエーション要求を識別するステップ、
前記アソシエーション要求を解析するステップ、
前記ＷＵＳＢデバイスを記述するデバイス属性を生成するステップ、
ＷＵＳＢデバイスのハンドラへ前記デバイス属性を送信するステップ、
前記ハンドラから接続属性を受信するステップ、及び
前記トラステッド媒体を介して前記ＷＵＳＢデバイスへ前記接続属性を送信するステップ
を含む、１つ又は２つ以上のデバイス可読媒体。
【請求項２】
請求項１に記載の１つ又は２つ以上のデバイス可読媒体であって、ステップとして、
前記アソシエーション要求に含まれるアソシエーションタイプ識別子を識別するステップ、
要求されている前記アソシエーションのタイプがＷＵＳＢであると判断するステップ、及び
前記タイプに基づいて前記ハンドラを識別するステップ
をさらに含む、デバイス可読媒体。
【請求項３】
請求項１に記載の１つ又は２つ以上のデバイス可読媒体であって、ステップとして、
ＷＵＳＢに関連付けられた標準規格に基づいて、前記解析されたアソシエーション要求の有効性を確認するステップをさらに含む、デバイス可読媒体。
【請求項４】
請求項１に記載の１つ又は２つ以上のデバイス可読媒体であって、ステップとして、
前記ＷＵＳＢデバイスが、前記接続属性に従い無線媒体を通じて接続することを可能にするステップをさらに含む、デバイス可読媒体。
【請求項５】
請求項１に記載の１つ又は２つ以上のデバイス可読媒体において、
前記トラステッド媒体は有線媒体である、デバイス可読媒体。
【請求項６】
請求項１に記載の１つ又は２つ以上のデバイス可読媒体において、
前記トラステッド媒体は、有線ＵＳＢ接続、ファイアワイヤ（firewire）接続、Ｅｔｈｅｒｎｅｔ接続、シリアル接続、パラレル接続、無線接続、近接通信（ＮＦＣ）接続、又は赤外線（ＩＲ）接続の少なくとも１つを含む、デバイス可読媒体。
【請求項７】
請求項１に記載の１つ又は２つ以上のデバイス可読媒体において、
前記デバイス属性は、アソシエーションタイプ識別子、接続デバイス識別子、接続鍵識別子、デバイスセットアップクラスＧＵＩＤ、サポートされた帯域グループ、又はインテグレータサイトＵＲＬの少なくとも１つを含む、デバイス可読媒体。
【請求項８】
請求項１に記載の１つ又は２つ以上のデバイス可読媒体において、
前記接続属性は、接続ホスト識別子、接続デバイス識別子、接続鍵識別子、好ましいチャネル、又はホスト領域の少なくとも１つを含む、デバイス可読媒体。
【請求項９】
無線ユニバーサルシリアルバス（ＷＵＳＢ）コンポーネントを備える接続デバイスであって、該接続デバイスは、トラステッド媒体を通じてホストデバイスへアソシエーション要求を送信するように構成され、該アソシエーション要求は、該接続デバイスに関係したデバイス属性を含み、該接続デバイスは、前記ホストデバイスから接続属性を受信すると共に前記接続属性を使用して前記ホストデバイスとＷＵＳＢ接続を確立するようにさらに構成される、接続デバイス。
【請求項１０】
請求項９に記載の接続デバイスにおいて、
前記トラステッド媒体は有線接続である、接続デバイス。
【請求項１１】
請求項１０に記載の接続デバイスであって、
前記有線接続を通じて前記ホストデバイスと通信するように構成される有線コンポーネントをさらに備える、接続デバイス。
【請求項１２】
請求項１１に記載の接続デバイスにおいて、
前記有線接続は、有線ＵＳＢ接続、ファイアワイヤ接続、Ｅｔｈｅｒｎｅｔ接続、シリアル接続、又はパラレル接続の少なくとも１つを含む、接続デバイス。
【請求項１３】
請求項１０に記載の接続デバイスにおいて、
前記デバイス属性は、アソシエーションタイプ識別子、接続デバイス識別子、接続鍵識別子、デバイスセットアップクラスＧＵＩＤ、サポートされた帯域グループ、又はインテグレータサイトＵＲＬの少なくとも１つを含む、接続デバイス。
【請求項１４】
請求項１０に記載の接続デバイスにおいて、
前記接続属性は、接続ホスト識別子、接続デバイス識別子、接続鍵識別子、好ましいチャネル、又はホスト領域の少なくとも１つを含む、接続デバイス。
【請求項１５】
請求項１０に記載の接続デバイスにおいて、
前記接続デバイスは、前記ＷＵＳＢコンポーネントを配置すると共に前記接続属性を使用して前記ホストデバイスに接続するようにさらに構成される、接続デバイス。
【請求項１６】
接続デバイスとホストデバイスとの間の通信方法であって、該接続デバイス及び該ホストデバイスは、有線媒体と接続されており、該方法は、
前記接続デバイスから前記ホストデバイスへ前記有線媒体を通じて、該接続デバイスのＷＵＳＢコンポーネントに関係したデバイス属性を含むアソシエーション要求を送信するステップ、
前記ホストデバイスによって、ＷＵＳＢ接続に関係した接続属性を決定するステップ、
前記ホストデバイスから前記接続デバイスへ前記有線媒体を通じて、前記接続属性を含む応答を送信するステップ、及び
前記接続デバイスにより、前記接続属性を使用して前記ホストデバイスとの接続を確立するステップ、
を含む、接続デバイスとホストデバイスとの間の通信方法。
【請求項１７】
請求項１６に記載の接続デバイスとホストデバイスとの間の通信方法において、
前記デバイス属性は、アソシエーションタイプ識別子、接続デバイス識別子、接続鍵識別子、デバイスセットアップクラスＧＵＩＤ、サポートされた帯域グループ、又はインテグレータサイトＵＲＬの少なくとも１つを含む、通信方法。
【請求項１８】
請求項１６に記載の接続デバイスとホストデバイスとの間の通信方法において、
前記接続属性は、接続ホスト識別子、接続デバイス識別子、接続鍵識別子、好ましいチャネル、又はホスト領域の少なくとも１つを含む、通信方法。
【発明の詳細な説明】
【発明の開示】
【０００１】
本発明のいくつかの態様の基本的な理解を提供するために、以下に、本発明の簡単化した概要を提示する。この概要は、本発明を広範にわたって概観するものではない。この概要は、本発明の重要／決定的な要素を識別することを意図したものでもなければ、本発明の範囲を画定することを意図したものでもない。この概要の唯一の目的は、後に提示するより詳細な説明の前置きとして、本発明のいくつかの概念を簡単化した形で提示することである。
【０００２】
以下では、トラステッド媒体（trusted media）を介した非トラステッド媒体（untrusted media）（たとえば、無線）デバイス構成の拡張可能アーキテクチャが説明される。このアーキテクチャは、非トラステッド媒体（たとえば、無線接続）を利用するデバイスを関連付けるのに用いることができる。関連付けは、たとえば有線接続といったトラステッド媒体を使用して達成される。
【０００３】
このアーキテクチャは、有線接続等のトラステッド媒体を使用して接続デバイスとホストデバイスとの間の無線ユニバーサルシリアルバス（ＷＵＳＢ）接続を確立するためのシステム及び方法を含む。一実施態様では、接続デバイスは、トラステッド媒体を通じてホストデバイスへアソシエーション要求を送信する。このアソシエーション要求は、接続デバイスのＷＵＳＭコンポーネントに関連付けられたデバイス属性を含む。これに応答して、ホストデバイスは、アソシエーション要求を解析してその有効性を確認し、ＷＵＳＢを使用して接続するための接続属性を決定する。ホストデバイスは、トラステッド媒体を通じて接続デバイスへ、接続属性を有する応答を送信する。接続デバイスは、接続属性を使用して、ＷＵＳＢコンポーネントを構成し、ホストデバイスとのＷＵＳＢ接続を確立する。
【発明を実施するための最良の形態】
【０００４】
次に、図面を参照して本発明を説明する。図面では、同じ参照符号は、図面全体を通じて同じ要素を指すのに使用されている。以下の説明では、説明の目的上、本発明の徹底した理解を提供するために、多数の具体的な詳細が述べられている。しかしながら、本発明は、これらの具体的な詳細がなくても実施できることが明らかな場合がある。それ以外の場合には、既知の構造及びデバイスは、本発明の説明を円滑にするためにブロック図の形で示されている。
【０００５】
この出願で使用されるように、「コンポーネント」、「ハンドラ」、「モデル」、「システム」等の用語は、ハードウェア、ハードウェア及びソフトウェアの組み合わせ、ソフトウェア、又は実行中のソフトウェアのいずれかのコンピュータ関連エンティティを指すことを意図している。たとえば、コンポーネントは、プロセッサ上で実行されるプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、及び／又はコンピュータとすることができるが、これらに限定されるものではない。例示として、サーバ上で実行されるアプリケーション及びそのサーバは、共に、コンポーネントとすることができる。１つ又は２つ以上のコンポーネントが、１つのプロセス及び／又は実行スレッド内に存在することができ、１つのコンポーネントが、１つのコンピュータに局在化することができ、且つ／又は、２つ若しくは３つ以上のコンピュータ間に分散することができる。また、これらのコンポーネントは、さまざまなデータ構造体が記憶されているさまざまなコンピュータ可読媒体から実行することもできる。コンポーネントは、１つ又は２つ以上のデータパケット（たとえば、ローカルシステム、分散システムにおいて別のコンポーネントと相互作用する或るコンポーネントからのデータ、及び／又は、インターネット等のネットワークにわたり信号を介して他のシステムと相互作用する或るコンポーネントからのデータ）を有する信号等に従い、ローカルプロセス及び／又はリモートプロセスを介して通信することができる。コンピュータコンポーネントは、たとえば、本発明によるコンピュータ可読媒体に記憶することができる。このコンピュータ可読媒体には、ＡＳＩＣ（特定用途向け集積回路）、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタルビデオディスク）、ＲＯＭ（読み出し専用メモリ）、フロッピー（登録商標）ディスク、ハードディスク、ＥＥＰＲＯＭ（電気的消去可能プログラマブル読み出し専用メモリ）、及びメモリスティックが含まれるが、これらに限定されるものではない。
【０００６】
さらに、「トラステッド媒体」は、非トラステッド媒体を関連付けるために関連情報を転送できる、トラステッド接続を指す。トラステッド媒体の例には、シリアル接続、パラレル接続、及び／又はユニバーサルシリアルバス（ＵＳＢ）接続が含まれるが、これらに限定されるものではない。「非トラステッド媒体」は、信頼を確立するために関連付けられている媒体を指す。Ｂｌｕｅｔｏｏｔｈ及び／又はＩＥＥＥ８０２．１１等の無線接続（複数可）は、非トラステッド媒体の例である。
【０００７】
図１を参照して、本発明の一態様によるアソシエーションアーキテクチャ１００が示されている。このアーキテクチャ１００は、非トラステッド媒体（たとえば、無線接続）を利用するデバイス１１０を関連付けるのに用いることができる。関連付けは、たとえば有線接続といったトラステッド媒体を使用して達成される。
【０００８】
「アソシエーション要求」は、関連付けを開始するためにデバイス１１０からドライバ１２０へ送信されるデータブロックを指す。アソシエーション要求は、その後、アソシエーションマネージャ１３０へ転送することができる。アソシエーションマネージャ１３０は、アソシエーション要求を適切なハンドラ１４０へ転送する。「アソシエーション応答」は、（たとえば、成功した及び／又は不成功の）関連付けを完了するためにドライバ１２０からデバイス１１０へ送信されるデータブロックを指す。
【０００９】
アーキテクチャ１００は、非トラステッド媒体（たとえば、無線接続）を介して（たとえば、安全に）通信するようにデバイス１１０の構成を容易にすることができる。デバイス１１０の構成は、トラステッド媒体（たとえば、有線接続）を介して交換される情報に少なくとも部分的に基づくことができる。一例では、デバイス１１０は、アソシエーション要求をドライバ１２０へ送信し、ドライバ１２０からアソシエーション応答を受信する。関連付けが成功した場合、アソシエーション応答は、たとえば、デバイス１１０が非トラステッド媒体を介して（たとえば、安全に）通信することを可能にする構成情報（たとえば、暗号化鍵）を含むことができる。関連付けが不成功である場合、アソシエーション応答は、たとえば、エラー情報を含むことができる。
【００１０】
一例では、デバイス１１０は、ＵＳＢ接続も含む無線使用可能デジタルカメラである。ＵＳＢ接続（トラステッド媒体）は、デジタルカメラの無線接続（非トラステッド媒体）を構成するのに用いることができる。たとえば、「found new hardware」（新しいハードウェアの検出）ウィザードを用いて、アーキテクチャ１００を介してデジタルカメラへ転送する無線プロファイルを選択し且つ／又は作成することができる。このプロファイル情報が、ＵＳＢ接続を介してデジタルカメラへ転送されると、ＵＳＢ接続を接続解除することができ、デジタルカメラは、無線接続を介して通信することができる。
【００１１】
たとえば、ドライバ１２０は、トラステッド媒体を介して受信されたアソシエーション要求をアソシエーションマネージャ１３０へチャネル送信することができる。ドライバ１２０は、さらに、アソシエーションマネージャ１３０から受信したアソシエーション応答をトラステッド媒体を介してデバイス１１０へ提供することができる。別の例では、ドライバ１２０は、アソシエーション要求を生成して、これをアソシエーションマネージャ１３０に提供する。オプションとして、ドライバ１２０は、さらに、アソシエーション要求を発行するための適切な時刻を決定することもできる。
【００１２】
さらに別の例では、特定のドライバ１２０を用いて、複数の非トラステッド媒体を構成することができる。たとえば、ドライバ１２０を用いて、複数の非トラステッド媒体を介して通信する複数のデバイス１１０へＵＳＢ接続を介して通信することができる。
【００１３】
アソシエーションマネージャ１３０は、アソシエーションデータを適切なコンピュータに提供する。アソシエーションマネージャ１３０は、ドライバ１２０からアソシエーション要求を受信することができる。アソシエーション要求のルーティング情報に少なくとも部分的に基づいて、アソシエーションマネージャ１３０は、アソシエーション要求に関連付けられた情報を、処理のために特定のハンドラ１４０に提供することができる。この特定のハンドラ１４０がアソシエーション要求の処理を完了すると、このハンドラ１４０は、アソシエーションマネージャ１３０にアソシエーション応答を提供することができる。アソシエーション応答のルーティング情報に少なくとも部分的に基づいて、アソシエーションマネージャ１３０は、要求側ドライバ１２０にアソシエーション応答を提供することができる。
【００１４】
ハンドラ１４０は、デバイスインストールを実施するサービス（図示せず）とインターフェースしている。一例では、ハンドラ１４０は、アソシエーション要求の明示的な知識を有するアーキテクチャ１００の唯一のコンポーネントである。ハンドラ１４０は、以下でより詳細に説明するように、アソシエーション要求の内容に少なくとも部分的に基づいて動作を行う。たとえば、この動作（複数可）は、アソシエーション要求によって確立されようとする接続タイプに依存することができる。特定のハンドラ１４０がアソシエーション要求の処理を完了すると、このハンドラ１４０は、アソシエーションマネージャ１３０にアソシエーション応答を提供することができる。
【００１５】
アーキテクチャ１００は、１つ又は２つ以上のハンドラ１４０に関連付けられた識別情報を記憶するハンドラレジストリ１５０を含むことができる。アソシエーションマネージャ１３０は、ハンドラレジストリ１５０に記憶された識別情報を用いて、複数のハンドラ１４０のいずれに特定のアソシエーション要求を提供するのかを決定することができる。
【００１６】
さらに、アーキテクチャ１００は、オプションとして、１つ又は２つ以上のドライバ１２０に関連付けられた識別情報を記憶するドライバレジストリ１６０を含むことができる。アソシエーションマネージャ１３０は、（以下で解説するように）ドライバレジストリ１６０に記憶された識別情報を用いて、たとえば初期化中に、１つ又は２つ以上のドライバ１２０のうちのいずれのインスタンスを作成するのかを決定することができる。
【００１７】
デバイス１１０は、単一のエンティティとして示されているが、アソシエーション要求を送信及び／又は受信するオブジェクト、及び、最終的にはホストに関連付けられるオブジェクト（たとえば、ターゲットデバイス）を含むことができる。
【００１８】
一例では、アーキテクチャ１００は、１つのアソシエーション要求及び１つの関連付けられたアソシエーション応答しかサポートしない。この例では、関連付けを容易にするためにデバイス１１０から必要とされる情報が、アソシエーション要求に埋め込まれている。同様に、関連付けを容易にするためにデバイス１１０にとって必要とされる情報も、アソシエーション応答に埋め込まれている。
【００１９】
図２を参照すると、本発明の一態様によるアソシエーション要求２００が示されている。アソシエーション要求２００は、アソシエーション要求ヘッダ２１０並びに１つ又は２つ以上のアソシエーション要求属性（複数可）２２０（たとえば、属性タイプ、長さ、及びデータ）を含む。属性は、アソシエーション要求内且つ／又はアソシエーション応答内の単一のアイテムである。たとえば、アソシエーション要求ヘッダ２１０は、アソシエーション要求属性（複数可）２２０について以下で説明する属性と同様のフォーマットの一組のグローバルに定義された要求属性（複数可）を含むことができる。
【００２０】
一例では、アソシエーション要求（複数可）及び／又はアソシエーション応答（複数可）は、解析可能なストリームで編成される。このストリームは、一連の属性（複数可）を備え、各属性は、定義されたタイプ及び関連付けられたデータを有する。これによって、アーキテクチャの柔軟性及び拡張性が促進される。１つの例示的な属性構造を表１に明記する。
【００２１】
【表１】
2008547250.tif 000003
この例示的な属性構造は、たとえば、以下のように定義することができる。
【００２２】
【表２】
2008547250.tif 000004
一例では、システムそれ自体によって使用されることが意図され（たとえば、多くのアソシエーションタイプに共通である）、且つ、どの特定のアソシエーションタイプにも特有ではない、いくつかの予め定義された属性タイプがある。
【００２３】
【表３】
2008547250.tif 000005
例示的なアソシエーションステータス値は以下の通りである。
【００２４】
【表４】
2008547250.tif 000006
アソシエーション要求
この例では、アソシエーション要求は、一連の属性である。第１の属性は、AssociationType（アソシエーションタイプ）である。これは、どのハンドラに要求を送信するのかを識別するのに使用される。この例では、この値は、ハンドラ（又はハンドラに関連付けられた或る仕様）によって定義されたＧＵＩＤである。たとえば、Ｂｌｕｅｔｏｏｔｈデバイスを関連付けるために、Ｂｌｕｅｔｏｏｔｈ特有のＧＵＩＤ、及び、その特定のＧＵＩＤをハンドリングすることを指定したハンドラが存在し得る。
【００２５】
アソシエーション要求の第２の属性はlength（長さ）である。これは、AssociationTypeフィールド及びLengthフィールド自体を含むこの要求の属性のすべての全長である。これは、解析の支援に使用され、その結果、或るコンポーネントが或る特定のAssociationTypeに関係がない場合、そのコンポーネントは、要求内の各属性を解析しなければならないのとは対照的に、要求全体をスキップすることができる。
【００２６】
この例では、最小限の処理で基本的な関連付けを実施できる単純なデバイス（たとえば、ファームウェアを有しないシリコンのみのソリューションを有するデバイス（複数可））を容易にするために、lengthの直後に続く属性（複数可）が慎重に定義される。これを達成するために、所望のデータを抽出するために構造内で予め定義されたオフセットへ単純にジャンプできることが助けになる可能性がある。したがって、この例では、Lengthの直後に続く属性は、基本的な関連付けを実行するのに必要とされる最小限のデータ量を含む。さらに、属性は、予め定義された順序に並べることができ、常に存在することができる。一例では、この必要なデータのほぼすべてが、単一の属性内に含まれる。この例では、どの可変長フィールドも、アソシエーション要求内のオフセットに影響を与えないように、これらの基本的な属性の最後に配置される。
【００２７】
別の例では、それぞれが少量のデータを含むいくつかの属性が使用される。したがって、たとえば拡張された機能を提供するための属性が後に続く場合には、任意の個数の属性を後に続けられることが理解されるべきである。
アソシエーション応答
図３を参照すると、本発明の一態様によるアソシエーション応答３００が示されている。アソシエーション応答３００は、アソシエーション応答ヘッダ３１０、及び、０個、１つ又は２つ以上のアソシエーション応答属性（複数可）３２０を含む。たとえば、アソシエーション応答ヘッダ３１０は、アソシエーション応答属性（複数可）３２０について以下で説明する属性と同様のフォーマットの一組のグローバルに定義された要求属性（複数可）を含むことができる。
【００２８】
アソシエーション応答属性３２０は、属性タイプ、長さ、及びデータを含む１つのデータである。上述したアソシエーション要求と同様に、一例では、アソシエーション応答は一連の属性である。この例では、第１の属性はAssocitaionTypeである。これは、この応答をもたらしたアソシエーション要求のAssociationTypeをエコーするのに使用される。
【００２９】
アソシエーション応答の第２の属性はlengthである。これは、AssociationTypeフィールド及びlengthフィールド自体を含むこの要求の属性のすべての全長である。これは、解析の支援に使用され、その結果、或るコンポーネントが或る特定のAssociationTypeに関係がない場合、そのコンポーネントは、要求内の各属性を解析しなければならないのとは対照的に、要求をスキップすることができる。
【００３０】
アソシエーション応答の第３の属性は、AssociationStatus（アソシエーションステータス）である。これは、アソシエーション要求の結果についてデバイスに通知するためのものである。この例では、アソシエーションプロセスが成功した場合、この値は、０ｘ００００となり、デバイスがアソシエーション応答の属性を引き続き読み出すことができることを意味する。値が０ｘｃ０００１の場合、ホストは、指定されたAssociationTypeをハンドリングできるハンドラを見つけることができなかった。この場合、デバイスは、アソシエーション応答のさらなる属性について何らの仮定もすべきではない。
【００３１】
単純なデバイスが最小限の処理で基本的な関連付けを実施できることを可能にするために、上述したように、AssociationStatusの直後に続く属性（複数可）を慎重に定義することができる。この例では、これを達成するために、所望のデータを抽出するために構造内で予め定義されたオフセットへ単純にジャンプできることが必要である。そのため、これらの属性は、基本的な関連付けを実行するのに必要な最小限の量のデータを含む。また、これらの属性は、この例では、予め定義された順序に並べられ、常に存在する。どの可変長フィールドも、アソシエーション要求内のオフセットに影響を与えないように、これらの基本的な属性の最後に配置される。拡張された機能を提供するための属性が後に続く場合には、任意の個数の属性を後に続けることができる。
【００３２】
図４を参照すると、本発明の一態様によるアソシエーション管理システム４００が示されている。アソシエーション管理システム４００は、マネージャ通信コンポーネント４２０及びハンドラ識別コンポーネント４３０を有するアソシエーションマネージャ４１０を含む。システム４００は、ハンドラレジストリ１５０及びオプションとしてドライバレジストリ１６０をさらに含む。
【００３３】
アソシエーションマネージャ４１０は、アソシエーションデータ（たとえば、アソシエーション要求（複数可）及び／又はアソシエーション応答（複数可））を適切なコンポーネント（たとえば、ハンドラ及び／又はドライバ）に提供することを担当する。マネージャ通信コンポーネント４２０は、ドライバ（複数可）（図示せず）からアソシエーション要求（複数可）を受信することができる。マネージャ通信コンポーネント４２０は、アソシエーション要求の少なくとも一部（たとえば、アソシエーション要求ヘッダ）をハンドラ識別コンポーネント４３０に提供することができる。
【００３４】
マネージャ通信コンポーネント４２０によって提供される情報及びハンドラレジストリ１５０に記憶された識別情報に基づいて、ハンドラ識別コンポーネント４３０は、アソシエーション要求が提供される特定のハンドラ（図示せず）を識別する。一例では、アソシエーションマネージャ４１０は、ハンドラ識別コンポーネント４３０によって識別されたハンドラをロードする。別の例では、ハンドラ（複数可）は、（以下でさらに詳細に解説するように）初期化時にロードされる。その後、マネージャ通信コンポーネント４２０は、アソシエーション要求に関連付けられた情報を、ハンドラ識別コンポーネント４３０によって識別されたハンドラに提供する。
【００３５】
ハンドラは、アソシエーション要求を処理すると、マネージャ通信コンポーネント４２０にアソシエーション応答を提供する。次に、マネージャ通信コンポーネント４２０は、このアソシエーション応答を要求ドライバに提供する。
【００３６】
一例では、アソシエーションマネージャ４１０は、アソシエーション要求の有効性を確認する。たとえば、アソシエーションマネージャ４１０は、整合形式（well-formed）であるか否かを判断することができる。要求が整合形式でない場合、アソシエーションマネージャ４１０は、このアソシエーション要求が非整合形式（malformed）であることを示すアソシエーション応答（たとえば、ERROR_MALFORMED_ASSOCIATION_REQUEST（非整合形式であるアソシエーション要求エラー）に設定されたステータス属性）を生成し、このアソシエーション応答を要求側ドライバに提供することができる。この例では、アソシエーションマネージャ４１０は、以下の判定基準を利用して、アソシエーション要求が整合形式であるか否かを判断する。
【００３７】
ａ．要求の長さが、少なくともAssociationType属性及びLength属性を保持するのに十分な大きさ（たとえば、３６バイト）である。
【００３８】
ｂ．第１の属性がAssociationTypeであり、その長さが（たとえば、特定のハンドラに関連付けられたグローバル一意識別子（ＧＵＩＤ）に基づく）適切なサイズを有する。
【００３９】
ｃ．第２の属性がLengthであり、適切なサイズ（たとえば、ULONG）を有する。
【００４０】
ｄ．Length属性の値が、AssociationType属性及びLength属性（たとえば、３６バイト）よりも大きく、その要求の長さ以下である。
【００４１】
ｅ．後に続く各属性が、その属性が要求における当該属性の現在の位置に加えられたときに、Length属性の値よりも大きな値とならない長さを有する。
【００４２】
ｆ．正確に１つのAssociationType属性及び正確に１つのLength属性が、要求に存在する。
【００４３】
次に、アソシエーションマネージャ４１０は、アソシエーション要求に含まれる指定されたアソシエーションタイプ（たとえば、ハンドラレジストリ１５０に記憶されたＧＵＩＤ）について登録されたハンドラがあるか否かを判断する。ハンドラが見つからない場合、アソシエーションマネージャ４１０は、要求されたアソシエーションタイプがサポートされていないことを示すアソシエーション応答を生成し、このアソシエーション応答を要求側ドライバに提供することができる。
【００４４】
ハンドラが見つかった場合、この例では、アソシエーションマネージャ４１０は、アソシエーション要求を解析し、属性（複数可）のリストを抽出することができる。次に、アソシエーションマネージャ４１０は、抽出された属性（複数可）のリストをその特定のハンドラに提供することができる。
【００４５】
アソシエーションマネージャ４１０が、抽出された属性（複数可）のリストを特定のハンドラに提供することに失敗した場合、アソシエーションマネージャ４１０は、その特定のハンドラが応答しなかったことを示すアソシエーション応答を生成し、このアソシエーション応答を要求側ドライバに提供することができる。
【００４６】
アソシエーションマネージャ４１０が、抽出された属性（複数可）のリストを特定のハンドラに提供することに成功した場合、ハンドラによる処理が完了時に、この例では、アソシエーションマネージャ４１０は、アソシエーション応答属性リストをハンドラから受信する。アソシエーションマネージャ４１０は、アソシエーション応答属性リストが整合形式であるか否かを判断することができる。たとえば、
ａ．正確に１つのステータス属性がある。
【００４７】
ｂ．（たとえば、アソシエーションマネージャ４１０によって追加される）Length属性及びAssociationType属性が存在しない。
【００４８】
ｃ．アソシエーション要求がMaximumResponseLength属性を含んでいた場合には、これらの属性の全体サイズがその値よりも小さくなければならない。
【００４９】
応答が整合形式である場合、アソシエーションマネージャ４１０は、アソシエーション応答属性リストに少なくとも部分的に基づいて、アソシエーション応答（たとえば、バイトアレイ）を生成する。たとえば、アソシエーションマネージャ４１０は、以下のことを行うことができる。
【００５０】
ａ．応答属性リストのすべての属性の全体サイズを合計する。
【００５１】
ｂ．AssociationType属性及びLength属性に必要なサイズを追加する。
【００５２】
ｃ．その応答を保持するのに十分な大きさのバッファを割り当てる。
【００５３】
ｄ．そのバッファの第１の属性を、そのアソシエーション要求からのAssociationTypeに設定する。
【００５４】
ｅ．計算された応答の長さを使用してLength属性をバッファに追加する。
【００５５】
ｆ．AssociationStatus属性を追加する。
【００５６】
ｇ．各追加属性を、それらの属性が属性リストに存在したときの順番で追加する。
【００５７】
次に、アソシエーションマネージャ４１０は、アソシエーション応答を要求側ドライバに提供することができる。
【００５８】
一例では、アソシエーションマネージャは、以下のインターフェースを実施する。
【００５９】
【表５】
2008547250.tif 000007
SendAssociationRequest()（アソシエーション要求送信）は、アソシエーションプロセスを開始するためにドライバ（複数可）によってコールされる。アソシエーション応答は、デバイスに容易に返信できるバイトアレイとして返される。一例では、AssociationResponse（アソシエーション応答）を解放することがドライバの責務である。
【００６０】
図５を参照すると、本発明の一態様によるアソシエーション管理システム５００が示されている。システム５００は、アソシエーションマネージャ５１０、ハンドラレジストリ１５０、ドライバレジストリ１６０、及び初期化コンポーネント５２０を含む。
【００６１】
前述したように、アソシエーションマネージャ５１０は、アソシエーションデータ（たとえば、アソシエーション要求（複数可）及び／又はアソシエーション応答（複数可））を適切なコンポーネント（たとえば、ハンドラ及び／又はドライバ）に提供することを担当する。一方、この例では、初期化コンポーネント５２０は、ドライバレジストリ１６０に記憶された情報を使用して、たとえばシステム５００の初期化中に、１つ又は２つ以上のドライバ（図示せず）のうちのいずれのドライバのインスタンスを生成するのかを決定する。たとえば、ドライバ（複数可）を、コンピュータシステム（図示せず）の構成中に（たとえば、手動で且つ／又は自動的に）登録することができる。
【００６２】
一例では、システム初期化時に、初期化コンポーネント５２０は、ドライバレジストリ１６０及びハンドラレジストリ１５０にそれぞれ記憶された情報に少なくとも部分的に基づいて、ドライバ（複数可）及びハンドラ（複数可）を識別する。その後、初期化コンポーネント５２０は、識別されたハンドラ（複数可）及び識別されたドライバ（複数可）のインスタンスを生成する。
【００６３】
この例では、ハンドラのそれぞれについて、アソシエーションマネージャ５１０は、アソシエーションタイプカウントを取り出し、関連付けられた記憶バッファ（たとえば、アソシエーションタイプカウント×sizeof(GUID)）を割り当てることができる。このバッファは、ハンドラからアソシエーションタイプを取り出すのに使用することができる。別の例では、ハンドラが、記憶空間を割り当て、その記憶空間をアソシエーションマネージャに提供する。
【００６４】
アソシエーションタイプは、ハンドラがサポートする特定のアソシエーションタイプを表すＧＵＩＤのアレイとすることができる。取り出されたＧＵＩＤのそれぞれについて、ハンドラレジストリに記憶されたＧＵＩＤからハンドラへのマッピング（Handler mappings）にエントリーを追加することができる。たとえば、
【００６５】
【表６】
2008547250.tif 000008
次に、このマッピングリストは、アソシエーションマネージャ５１０が、適切なハンドラへのアソシエーション要求のルーティングを決定するのに用いることができる。
【００６６】
この例では、ハンドラが生成され、且つ、それらのアソシエーションタイプが発見されると、初期化コンポーネント５２０は、ドライバをアクティブ化する。ハンドラが発見されてロードされるまで、アソシエーション要求（複数可）が受信されないことを確実にするために、アクティブ化は、ハンドラがロードされて初期化された後に行われる。たとえば、ドライバをアクティブ化するために、「Start()」メソッドを起動することができる。
【００６７】
次に図６を参照すると、本発明の一態様によるアソシエーションハンドラシステム６００が示されている。このシステム６００は、要求コンポーネント６２０、応答コンポーネント６３０、及びアソシエーションプロセッサを備えたハンドラ６１０を含む。
【００６８】
ハンドラ６１０は、（おそらく他のコンポーネント（複数可）（図示せず）と共に）アソシエーション要求を消費し、アソシエーション応答に関連付けられた情報を生成する。
【００６９】
たとえば、要求コンポーネント６２０は、アソシエーション要求に関連付けられた情報（たとえば、アソシエーション要求及び／又は解析された属性リスト）をアソシエーションマネージャ（図示せず）から受信することができる。要求コンポーネント６２０は、アソシエーション要求に関連付けられた情報の内容を解析して、どのような動作（複数可）を行うのかを決定することができる。アソシエーションプロセッサ６４０は、サービス６５０を介して動作（複数可）を容易にする。この動作（複数可）は、たとえば、確立しようとする接続タイプに依存することができる。動作（複数可）が完了すると、アソシエーションプロセッサ６４０は、この関連付けに関する情報を応答コンポーネント６３０に提供することができる。次に、応答コンポーネント６３０は、アソシエーション応答に関連付けられた情報（たとえば、アソシエーション応答及び／又は属性リスト）を生成することができる。この情報は、アソシエーションマネージャに提供することができる。
【００７０】
一例では、複数のハンドラ６１０が、以下のＣＯＭインターフェースを実施する。
【００７１】
【表７】
2008547250.tif 000009
この例では、「manager」（マネージャ）は、アソシエーションマネージャへのインターフェースポインタである。さらに、「AssociationTypes」は、ＰＯＮＧハンドラがハンドリングできるAssociationType GUIDのアレイを返す。同様に、「AssociationTypeCount」（アソシエーションタイプカウント）は、ＰＯＮＧハンドラがハンドリングできるAssociationTypeの個数である。「HandleAssociationRequest()」は、ハンドラ６１０がサポートしたことを報告したアソシエーション要求をアソシエーションマネージャが受信した時に、そのアソシエーションマネージャによってコールされる。「RequestAttributes」は、属性構造のリストである。ハンドラ６１０は、デバイス（図示せず）に返される属性である属性構造体のリストであるResponseAttributesを返すのに必要なメモリを割り当てることが期待されている。
【００７２】
別の例では、ハンドラ６１０は、デバイスがターゲット媒体上で発見されると、デバイスについての情報を、今後のインストールのためにたとえばデータベースに記憶する。たとえば、特定のハンドラ６１０をＷｉ−Ｆｉターゲット媒体に関係付けることができる。この例では、Ｗｉ−Ｆｉターゲット媒体を用いることを所望するデバイス（複数可）が、アソシエーション要求（複数可）を送信し、属性リストの形でアソシエーション応答（複数可）を受信する。属性リストは、ハンドラ６１０がアソシエーションマネージャに提供することができ、アソシエーションマネージャは、次に、アソシエーション応答を形成することができる。
【００７３】
以下の表９、表１０、及び表１１について、「属性」は、属性要素に関連付けられた親しみやすい名称を指す。「属性ＩＤ」は、属性リストの属性要素を識別するのに使用される識別子（たとえば、番号）である。「長さ」は、属性要素のデータの長さを指す。属性の長さは、可変長且つ／又は固定長とすることができ、この例では、バイトで表される。長さの値は、最大長を指定することもできる。アソシエーション応答では、一例において、この値に対するオフセットが必ず存在するように固定長を使用することができ、それによって、デバイスが応答を解析する能力が支援される。属性の実際の値は、そのデータに割り当てられた長さ全体を使い切らない場合がある。これらの場合には、追加フィールドが、属性データの実際の長さを指定することができる。「許容値」は、デバイスによってサポートされる値を記述する許容値フィールドを指す。許容値が必要とされる場合、このことは、その値が属性リストに含まれるときに、デバイスがその値をサポートしなければならないことを意味する。表９、表１０、及び／又は表１１に明記されていない限り、値は必要であるとみなすべきである。許容値がオプションである場合、デバイスは、その値をサポートする必要はないが、その値が属性リストに含まれることに対応できるように準備されているべきである。オプションの値は、この仕様の今後のバージョンで必要とされる可能性がある。
無線プロトコル
ＩＥＥＥ８０２．１１標準規格セットは、暗号化ネットワーク（たとえば、ＷＥＰネットワーク）及び非暗号化ネットワークの２つのネットワークタイプを定義している。ＷＥＰプロトコルの既知の弱点のために、無線業界は、ＷＥＰプロトコルの主要な不備に対処するためのメカニズムとしてＩＥＥＥ８０２．１ｘ標準規格に対するサポートを実施した。これらの主要な不備は、ユーザ認証、暗号化鍵管理、及び暗号化鍵配布である。ＷＥＰ暗号化ネットワークでは、ユーザが暗号化鍵を提供する必要があり、８０２．１ｘ使用可能ネットワークでは、ユーザが有効な信用証明書（たとえば、デジタル証明書又はユーザ名及びパスワード等）を有する場合には、暗号化鍵は自動的に提供される。暗号化された８０２．１１ネットワークでは、このことは、ユーザビリティの問題を提示する。その理由は、ユーザがＷＥＰ鍵を入力する必要があるのか、それとも、ネットワークが８０２．１ｘをサポートしていて、その場合に、ユーザがＷＥＰ鍵を入力する必要がないのかをアプリオリに判断することが、現在のところ可能ではないからである。
【００７４】
ＷＥＰアルゴリズムは、暗号的に弱点があることが示されてきているが、ＷＥＰアルゴリズムのこの根本的な弱点に対処するために、Ｗｉ−Ｆｉ保護アクセス（Wi-Fi Protected Access）（ＷＰＡ）と呼ばれる、８０２．１１標準規格セットに対するセキュリティ強化が導入された。また、ＷＰＡは、ＷＰＡ対応アクセスポイントが自身のビーコンフレームに含む情報要素を指定することによって、元の８０２．１１標準規格のユーザビリティ問題のいくつかにも対処している。この情報要素は、とりわけ、ネットワークがユーザに暗号化鍵を入力するように要求する（ＷＰＡ事前共有鍵モード（ＷＰＡ−ＰＳＫ）と呼ばれる）のか、それとも、鍵は、ユーザの信用証明書によって自動的に提供される（「ＷＰＡモード」と呼ばれる）のかを記述する。
有線同等プライバシー
ＷＥＰは、ＩＥＥＥ８０２．１１標準規格によって定義され、有線ネットワークと同等のデータ機密性レベルを提供することを目的としている。無線ＬＡＮネットワークの性質のために、このネットワークへの物理アクセスを監視するセキュリティインフラストラクチャを実施することは難しくなる可能性がある。物理接続が必要とされる有線ネットワークとは異なり、無線アクセスポイント（ＡＰ）の範囲内にいる者は誰でも、おそらく、フレームを送受信することができるだけでなく、送信中の他のフレームに耳を澄ませることができる。これによって、無線ＬＡＮフレームの盗聴及びリモートスニフィングが非常に容易になる。
【００７５】
ＷＥＰは、無線ノード間で送信されるデータを暗号化することによってデータ機密性サービスを提供する。８０２．１１フレームのＷＥＰ暗号化は、８０２．１１フレームのＭＡＣヘッダのＷＥＰフラグを設定することによって示される。ＷＥＰは、無線フレームの暗号化された部分に完全性チェック値（ＩＣＶ）を含めることによって、確率誤差に対するデータ完全性を提供する。
【００７６】
以下の表は、ＷＥＰが定義する２つの共有鍵を示す。
【００７７】
【表８】
2008547250.tif 000010
ＷＥＰ暗号化は、４０ビット及び１０４ビットの暗号化鍵を用いたＲＣ４対称ストリーム暗号を使用する。
Ｗｉ−Ｆｉ保護アクセス
ＷＰＡは、ＷＥＰのセキュリティ機能を改良するように設計されたとえばＷｉ−Ｆｉ標準規格である。ＷＥＰとは異なり、ＷＰＡでは、８０２．１ｘ認証が必要とされる。ＷＰＡでは、ユニキャスト暗号化鍵及びグローバル暗号化鍵の双方のリキー（rekeying）が必要とされる。ユニキャスト暗号化鍵では、一時的鍵完全性プロトコル（Temporal Key Integrity Protocol）（ＴＫＩＰ）が、フレームごとに鍵を変更し、この変更は、無線クライアントと無線アクセスポイント（ＡＰ）との間で同期される。グローバル暗号化鍵では、ＷＰＡが、無線ＡＰが変更された鍵を接続された無線クライアントに広告するための機構を含む。
【００７８】
ＴＫＩＰは、ＷＥＰを、ＷＥＰアルゴリズムよりも強力な暗号化アルゴリズムに置き換える。また、ＴＫＩＰは、暗号化鍵が決定された後のセキュリティ構成の検証、各フレームのユニキャスト暗号化鍵の同期された変更、及び、各事前共用鍵認証について一意の開始ユニキャスト暗号化鍵の決定も提供する。
【００７９】
ＷＰＡは、さらに、８バイトのメッセージ完全性コード（ＭＩＣ）を計算するアルゴリズムを推定する「Ｍｉｃｈａｅｌ」として知られたメソッドも使用する。ＭＩＣは、ＩＥＥＥ８０２．１１フレームのデータ部分と、４バイトの完全性チェック値（ＩＣＶ）との間に置かれる。ＭＩＣフィールドは、フレームデータ及びＩＣＶと共に暗号化される。
【００８０】
ＷＰＡは、ＩＥＥＥ８０２．１１ｉ標準規格完成時には、ＩＥＥＥ８０２．１１ｉ標準規格に置き換えられる暫定的な標準規格である。
Ｗｉ−Ｆｉハンドラ
アソシエーションタイプは、アソシエーション要求及びアソシエーション応答のヘッダセクションに含まれる属性であり、データ属性から分離されている。この属性は、アソシエーションマネージャが、アソシエーション要求（複数可）を正しいハンドラへ転送するのに使用される。この例では、Ｗｉ−Ｆｉハンドラ４１０は、以下の必要なアソシエーションタイプを有する。
【００８１】
【表９】
2008547250.tif 000011
アソシエーション要求のデータセクションは、その属性タイプに特有の属性を含む。以下の表は、アソシエーションマネージャがＷｉ−Ｆｉハンドラ６１０へ転送することができる例示的な属性を識別する。
【００８２】
【表１０】
2008547250.tif 000012
ＭＡＣアドレス
ＭＡＣアドレスは、４８ビット値のＭＡＣアドレスを含む６バイト値である。たとえば、０ｘ００  ０ｘ０７  ０ｘＥ９  ０ｘ４Ｃ  ０ｘＡ８  ０ｘ１Ｃである。
ネットワーク認証タイプフラグ
このフラグセットは、どの「ネットワーク認証タイプ」のタイプがサポートされているのかを信号で伝えることをデバイスに可能にする。この情報は、診断目的に使用することができる。デバイスが、必要とされる属性をサポートしていない場合、ユーザに対して、このことを通知することができ、この問題を是正するための実行可能な指令を与えることができる。この例では、このフィールドの値は、以下の値のうちの１つ又は２つ以上のビットごとのＯＲである。
【００８３】
０ｘ０００１＝Ｏｐｅｎ（オープン）
０ｘ０００２＝ＷＰＡＰＳＫ
０ｘ０００４＝Ｓｈａｒｅｄ（共有）
０ｘ０００８＝ＷＰＡ
０ｘ００１０＝ＷＰＡ−ＮＯＮＥ
０ｘ００２０＝ＷＰＡ２
この例では、他の値は予備であり、０に設定される。
データ暗号化タイプフラグ
このフラグセットは、どの「データ暗号化タイプ」のタイプがサポートされているのかを信号で伝えることをデバイスに可能にする。この情報は、診断目的に使用することができる。デバイスが、必要とされる属性をサポートしていない場合、ユーザに対して、このことを通知することができ、この問題を是正するための実行可能な指令を与えることができる。この例では、このフィールドの値は、以下の値のうちの１つ又は２つ以上のビットごとのＯＲである。
【００８４】
０ｘ０００１＝ＷＥＰ
０ｘ０００２＝ＴＫＩＰ
０ｘ０００４＝ＡＥＳ
この場合も、この例では、他の値は予備であり、０に設定される。
接続タイプフラグ
このフラグセットは、どの「接続タイプ」のタイプがサポートされているのかを信号で伝えることをデバイスに可能にする。この情報は、診断目的に使用することができる。デバイスが、必要とされる属性をサポートしていない場合、ユーザに対して、このことを通知することができ、この問題を是正するための実行可能な指示をユーザに与えることができる。この例では、このフィールドの値は、以下の値のうちの１つ又は２つ以上のビットごとのＯＲである。
【００８５】
０ｘ０１＝ＥＳＳ（拡張サービスセット（Extended Service Set））
０ｘ０２＝ＩＢＳＳ（独立基本サービスセット（Independent Basic Service Set））
この例では、他の値は予備であり、０に設定される。
【００８６】
ハンドラ６１０のサービス６５０との相互作用に少なくとも部分的に基づいて、応答コンポーネント６３０は、アソシエーション応答に関連付けられた情報を生成する。Ｗｉ−Ｆｉハンドラの例を続けて、表１１は、例示的なアソシエーション応答属性を識別するものである。この例の属性リストにおける属性の長さは固定である。したがって、デバイス製品は、適切なオフセットへ容易にジャンプして、応答におけるどの所与の属性の値も読み出すことができる。オフセットは、属性の先頭を参照する。
【００８７】
【表１１】
2008547250.tif 000013
ＳＳＩＤ
ＳＳＩＤは、前述したように、ブロードキャスト無線ネットワークで使用される文字列である。
ネットワーク鍵
ネットワーク鍵は、ネットワークを安全にするのに使用される文字列である。この例では、以下の属性が、ネットワーク鍵の許容値に対する制約条件として置かれる。デバイスは、以下の構成を受け入れるか又は拒否する準備がされていなければならない。
【００８８】
【表１２】
2008547250.tif 000014
ＷＥＰ鍵
データ認証タイプがＷＥＰであるとき、ネットワーク鍵は、４０ビット又は１０４ビットのＷＥＰ鍵のＡＳＣＩＩ表現又はＨＥＸ表現である。このタイプは、文字列の長さによって決定することができる。
ＷＰＡＰＳＫパスフレーズ
ネットワーク鍵属性が０文字〜６３文字のＡＳＣＩＩ文字列であり、且つ、「ネットワーク認証タイプ」属性がＷＰＡである場合、ネットワーク鍵属性は、ＷＰＡバイナリ鍵を導出するパスフレーズとして使用される。
自動提供鍵（Key Provided Automatically）（８０２．１ｘ）
「自動提供鍵（８０２．１ｘ）」属性は、ネットワーク鍵が８０１．ｘを介して提供されるか否かを指示する。ＷＰＡ−ＰＳＫ又はＷＥＰが、無線ネットワークを安全にするのに使用される場合、これは、通常は０に設定される。
ネットワーク認証タイプ
ネットワーク認証タイプは、どのタイプのセキュリティメカニズムが、特定のネットワークに参加するのに必要とされるのかを示す。このフラグセットは、以下のメカニズムのうちのいずれが使用されるのかを指定する。
【００８９】
０ｘ０００１＝Ｏｐｅｎ
０ｘ０００２＝ＷＰＡＰＳＫ
０ｘ０００４＝Ｓｈａｒｅｄ
０ｘ０００８＝ＷＰＡ
０ｘ００１０＝ＷＰＡ−ＮＯＮＥ
０ｘ００２０＝ＷＰＡ２
この例では、他の値は予備であり、０に設定される。重要なことには、アソシエーション要求とは異なり、これらのフラグは、相互に排他的であり、一度に１つのフラグしか設定することができない。
データ暗号化タイプ
この値は、無線ネットワークによって配備される暗号化メカニズムを指定する。このフラグセットは、以下のメカニズムのうちのいずれが使用されるのかを指定する。
【００９０】
０ｘ０００１＝ＷＥＰ
０ｘ０００２＝ＴＫＩＰ
０ｘ０００４＝ＡＥＳ
他のすべての値は予備であり、０に設定される。重要なことには、アソシエーション要求とは異なり、これらのフラグは相互に排他的であり、一度に１つのフラグしか設定することができない。
接続タイプ
接続タイプは、無線ネットワークのタイプを定義する。このフラグセットは、以下のメカニズムのうちのいずれが使用されるのかを指定する。
【００９１】
０ｘ０１＝ＥＳＳ
０ｘ０２＝ＩＢＳＳ
他のすべての値は予備であり、０に設定される。これらのフラグは相互に排他的である。
【００９２】
次に図７を参照すると、本発明の一態様によるアソシエーションドライバシステム７００が示されている。システム７００は、トラステッド媒体通信コンポーネント７２０及びドライバ通信コンポーネント７３０を備えたドライバ７１０を含む。
【００９３】
トラステッド媒体通信コンポーネント７２０は、トラステッド媒体（たとえば、ＵＳＢ接続）を介してデバイス７４０とインターフェースする。一例では、トラステッド媒体通信コンポーネント７２０は、装置７４０からアソシエーション要求（たとえば、デバイス列挙とは時間非依存で開始されたアソシエーション要求）を受信する。別の例では、トラステッド媒体通信コンポーネント７２０は、アソシエーション要求を発行する要求の通知を受信する。その後、ドライバ７１０は、ドライバ通信コンポーネント７３０を介してアソシエーションマネージャ（図示せず）へ送信されるアソシエーション要求を生成する。
【００９４】
一例では、ドライバ（複数可）７１０は、以下のインターフェースを実施する。
【００９５】
【表１３】
2008547250.tif 000015
「Manager」は、アソシエーションマネージャへのインターフェースポインタであり、それによって、ドライバは、SendAssociationRequest（アソシエーション要求送信）をコールすることができるようになっている。Start()は、新しいアソシエーション要求の検出及び発行をドライバに開始してほしいときにアソシエーションマネージャによってコールされる。Stop()は、新しいアソシエーション要求の発行をドライバに停止してほしいとき（たとえば、ユーザが特定のトラステッド媒体上で関連付けを無効にしたいとき）に、アソシエーションマネージャによってコールされる。
【００９６】
一例では、特定のドライバ７１０をＵＳＢトラステッド媒体に関係付けることができる。この例では、非トラステッド媒体を用いたいデバイス（複数可）が、ドライバ７１０を通じて安全にアソシエーション要求（複数可）を送信し、アソシエーション応答（複数可）を受信する。
【００９７】
動的アソシエーション機能を実施するデバイス（複数可）では、アソシエーション要求をデバイス列挙とは独立に生成できるが、このデバイス（複数可）の場合に、一例では、オプションの割り込みＩＮエンドポイントが存在する。このエンドポイントによって、新しいアソシエーション要求の通知が容易にされる。このオプションのエンドポイントの標準エンドポイント記述子は、表１４に見ることができる。
【００９８】
【表１４】
2008547250.tif 000016
デバイスのインターフェースが、オプションのエンドポイントを含まない場合、関連付けは、列挙時にのみ行われる。このようなデバイスがアソシエーションプロセスを開始したい場合、デバイスは、デバイスが開始するＵＳＢリセットを行わなければならない。これによって、デバイスは、ホストにより再列挙され、その時点で、ホストは、デバイスからアソシエーション要求（複数可）を取り出す。別の例では、デバイスは、ＨＵＢ機能も実施して、そのデバイスの希望に応じてアソシエーション機能を往来させる（come and go）ことができる。
【００９９】
この制御エンドポイントは、アソシエーションインターフェースをサポートするデバイスの唯一の必須のエンドポイントであるので、必要なデータ転送は、そのエンドポイント上で行われる。この例では、これらの転送は、アソシエーションクラス要求の形である。
【０１００】
表１５は、一例において、デバイスがサポートしなければならないアソシエーションクラス要求のリストを示している。
【０１０１】
【表１５】
2008547250.tif 000017
GET_ASSOCIATION_INFORMATION（アソシエーション情報取得）
この要求は、デバイスからアソシエーション情報構造体を取り出す。このアソシエーション情報は、REQUEST_INFO（要求情報）ブロックのリストを含む。各REQUEST_INFOブロックは、デバイスが発行したい単一のアソシエーション要求に関するものである。
【０１０２】
【表１６】
2008547250.tif 000018
表１７は、例示的なASSOCIATION_INFORMATION構造体を示している。
【０１０３】
【表１７】
2008547250.tif 000019
表１８は、例示的なアソシエーション情報フラグ情報を提供する。
【０１０４】
【表１８】
2008547250.tif 000020
表１９は、例示的なREQUEST_INFO（要求情報）構造体を示している。
【０１０５】
【表１９】
2008547250.tif 000021
GET_ASSOCIATION_REQUEST（アソシエーション要求取得）
この要求は、デバイスから特定のアソシエーションを取り出す。この要求は、wValue（ｗ値）フィールド内のRequestID（要求ＩＤ）値によって識別される。
【０１０６】
【表２０】
2008547250.tif 000022
この例では、要求ブロックは、４ＫＢのデータブロックである。制御転送の最大転送サイズは６４ＫＢであり、その結果、理論的には、各GET_ASSOCIATION_REQUESTにおいて１６個の要求ブロックを転送することができる。転送される実際のデータ量は、wLength（ｗ長さ）フィールドによって指定される。wValueフィールドで指定されたBlockNumber（ブロック番号）は、この制御転送の開始ブロック番号を識別する。その結果、この例では、デバイス５４０は、RequestIDによって指定される要求のアソシエーション要求データを、オフセットBlockNumber×４ＫＢから開始して、wLengthバイトを転送して返すはずである。
SET_ASSOCIATION_RESPONSE（アソシエーション応答設定）
この要求は、wValueフィールドのRequestID値によって識別される特定のアソシエーション要求に対する応答を送信する。
【０１０７】
【表２１】
2008547250.tif 000023
この例では、TrasferFlags（転送フラグ）値は、表２２に見られる値の０個以上の値のビットごとのＯＲである。
【０１０８】
【表２２】
2008547250.tif 000024
アソシエーション割り込みＩＮメッセージ（複数可）
NewAssociationRequest（新しいアソシエーション要求）
この割り込みＩＮメッセージは、デバイスが、処理する必要がある新しいアソシエーション要求（複数可）又は変更されたアソシエーション要求（複数可）を有することをホストに示す。ホストは、このメッセージを受信すると、GET_ASSOCIATION_INFORMATION要求を発行することができ、それに応じてこれらの要求を処理することができる。
【０１０９】
【表２３】
2008547250.tif 000025
システム１００、デバイス１１０、アソシエーションマネージャ１２０、ハンドラ１３０、ドライバ１４０、ハンドラレジストリ１５０、ドライバレジストリ１６０、システム４００、アソシエーションマネージャ４１０、マネージャ通信コンポーネント４２０、ハンドラ識別コンポーネント４３０、アソシエーションマネージャ５１０、初期化コンポーネント５２０、システム６００、ハンドラ６１０、要求コンポーネント６２０、応答コンポーネント６３０、アソシエーションプロセッサ６４０、サービス６５０、システム７００、ドライバ７１０、トラステッド媒体通信コンポーネント７２０、ドライバ通信コンポーネント７３０、及び／又はデバイス７４０は、その用語が本明細書に定義された通りのコンピュータコンポーネントとすることができることが認識されるべきである。
【０１１０】
図８〜図１８を簡単に参照すると、本発明に従って実施できる方法論が示されている。説明を簡単にするために、これらの方法論は、一連のブロックとして図示されて説明されるが、本発明によれば、いくつかのブロックは、本明細書に図示されて説明されるものとは異なる順序で行うことができ、且つ／又は、他のブロックと同時に行うことができるので、本発明は、ブロックの順序によって限定されるものではないことが理解されるべきであり、また、認識されるべきである。その上、示されたすべてのブロックが、本発明による方法論を実施するのに必要とされるとは限らない場合もある。
【０１１１】
本発明は、１つ又は２つ以上のコンポーネントによって実行されるプログラムモジュール等のコンピュータ実行可能命令の一般的な状況で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するか又は特定の抽象データタイプを実施するルーチン、プログラム、オブジェクト、データ構造体等を含む。通常、プログラムモジュールの機能は、さまざまな実施形態において、要望に応じ組み合わせることもできるし、分散させることもできる。
【０１１２】
図８を参照すると、本発明の一態様による、デバイスを関連付ける方法８００が示されている。８１０において、（たとえば、デバイスの）接続が、トラステッド媒体（たとえば、ＵＳＢ）を介して確立される。８２０において、アソシエーション要求が、たとえばデバイス及び／又は関連付けられたドライバによって発行される。８３０において、アソシエーション応答に関連付けられた情報が、（たとえば、ドライバから）受信される。この情報は、たとえば、アソシエーションマネージャから受信されたアソシエーション応答を含むことができる。代替的に、この情報は、アソシエーションマネージャから受信されたアソシエーション応答の一部を含むことができる。
【０１１３】
８４０において、関連付けが成功したのか否かに関する判断が行われる。８４０における判断がＮＯ（いいえ）である場合には、それ以上の処理は行われない。８４０における判断がＹＥＳ（はい）である場合には、８５０において、アソシエーション応答に関連付けられた情報を用いて、非トラステッド媒体（たとえば、無線接続）を介して（たとえば、デバイスの）接続が行われる。
【０１１４】
次に図９を参照すると、本発明の一態様による、デバイスの関連付けを容易にする方法９００が示されている。９１０において、アソシエーション要求に関連付けられた情報が受信される。９２０において、アソシエーション要求が受信されたか否かに関する判断が行われる。９２０における判断がＮＯである場合には、９３０において、アソシエーション要求が生成され、処理は９４０に続く。９２０における判断がＹＥＳである場合には、９４０において、受信されたアソシエーション要求は、たとえば、アソシエーションマネージャへ送信される。
【０１１５】
９５０において、アソシエーション応答が、たとえばアソシエーションマネージャから受信される。９６０において、アソシエーション応答に関連付けられた情報が、要求側デバイスに提供される。たとえば、この情報は、アソシエーション応答全体及び／又はアソシエーション応答の一部を含むことができる。その後、それ以上の処理は行われない。
【０１１６】
次に、図１０〜図１２を参照すると、本発明の一態様による、ＵＳＢ接続を介してデバイスを関連付ける方法１０００が示されている。１００４において、デバイスが列挙され、且つ／又は、新しいアソシエーション要求イベントが発行される。１００８において、GET_ASSOCIATION_INFORMATION要求が、たとえばドライバによってデバイスへ送信される。１０１２において、アソシエーション情報全体のサイズが、たとえばドライバによって求められる（たとえば、サイズ＝３＋sizeof (REQUEST_INFO)×PendingRequestCount）。
【０１１７】
１０１６において、アソシエーション情報のほぼすべてが、たとえばドライバによって受信されたか否かに関する判断が行われる。１０１６における判断がＮＯである場合には、処理は１００８に続く。１０１６における判断がＹＥＳである場合には、１０２０において、PendingRequestCountが０よりも大きいか否かに関する判断が行われる。１０２０における判断がＮＯである場合には、それ以上の処理は行われない。
【０１１８】
１０２０における判断がＹＥＳである場合には、１０２４において、（たとえばドライバにより）ハンドリングする要求が識別される。１０２８において、転送（たとえば、アソシエーション要求）のサイズが求められる。１０３２において、GET_ASSOCIATION_REQUESTが送信される。１０３６において、要求データがそれ以上あるか否かに関する判断が行われる。１０３６における判断がＹＥＳである場合には、プロセスは１０２８に続く。１０３６における判断がＮＯである場合には、１０４０において、要求されたアソシエーションがハンドリングされ、アソシエーション応答が（たとえば、アソシエーションマネージャ及び／又はハンドラによって）生成される。
【０１１９】
１０４０において、アソシエーション応答の転送サイズが求められる。１０４８において、SET_ASSOCIATION_RESPONSEが送信される。１０５２において、応答データがそれ以上あるか否かに関する判断が行われる。１０５２における判断がＹＥＳである場合には、処理は１０４４に続く。１０５２における判断がＮＯである場合には、１０５６において、要求がそれ以上あるか否かに関する判断が行われる。
【０１２０】
１０５６における判断がＹＥＳである場合には、処理は１０２４に続く。１０５６における判断がＮＯである場合には、１０６０において、追加の要求フラグがアソシエーション情報で送信されているか否かに関する判断が行われる。１０６０における判断がＹＥＳである場合には、処理は１００８に続く。１０６０における判断がＮＯである場合には、それ以上の処理は行われない。
【０１２１】
次に図１３を参照すると、本発明の一態様によるアソシエーション管理方法１３００が示されている。１３１０において、アソシエーション要求が、たとえばドライバから受信される。１３２０において、そのアソシエーション要求のハンドラが識別される。１３４０において、そのアソシエーション要求のハンドラが存在するか否かに関する判断が行われる。１３４０における判断がＮＯである場合には、１３５０において、アソシエーション応答の失敗が生成され、処理は１３６０に続く。
【０１２２】
１３４０における判断がＹＥＳである場合には、１３７０において、アソシエーション要求に関連付けられた情報が、ハンドラへ送信される。たとえば、この情報は、アソシエーション要求及び／又はアソシエーション要求の一部（たとえば、属性リスト（複数可））を含むことができる。
【０１２３】
１３８０において、アソシエーション応答に関連付けられた情報が、ハンドラから受信される。１３６０において、アソシエーション応答が、要求側ドライバに提供される。
【０１２４】
図１４〜図１６を参照すると、本発明の一態様によるアソシエーション管理方法１４００が示されている。１４０４において、アソシエーション要求が、たとえばドライバから受信される。１４０８において、このアソシエーション要求の有効性が確認される。１４１２において、このアソシエーション要求が整合形式であるか否かに関する判断が行われる。１４１２における判断がＮＯである場合には、１４１６において、非整合形式のアソシエーション要求を示すアソシエーション応答が生成され、処理は１４２０に続く。
【０１２５】
１４１２における判断がＹＥＳである場合には、１４２４において、アソシエーション要求のハンドラが突き止められる。１４２８において、ハンドラが見つかっているか否かに関する判断が行われる。１４２８における判断がＮＯである場合には、１４３２において、サポートされていないアソシエーションタイプを示すアソシエーション応答が生成され、処理は１４２０に続く。
【０１２６】
１４２８における判断がＹＥＳである場合には、１４３６において、アソシエーション要求が解析され、属性（複数可）のリストが構築される。１４４０において、この属性リストは、識別されたハンドラへ送信される。１４４４において、応答情報がハンドラから受信される。１４４８において、関連付けが成功したか否かに関する判断が行われる。１４４８における判断がＮＯである場合には、１４５２において、適切なエラーステータスを示すアソシエーション応答が生成され、処理は１４２０に続く。
【０１２７】
１４４８における判断がＹＥＳである場合には、１４５６において、応答フォーマットの有効性が確認される。１４６０において、応答が整合形式であるか否かに関する判断が行われる。１４６０における判断がＮＯである場合には、１４６４において、適切なエラーステータスを示すアソシエーション応答が生成され、処理は１４２０に続く。
【０１２８】
１４６０における判断がＹＥＳである場合には、１４６８において、アソシエーション応答が、ハンドラからの応答に基づいて生成される。１４２０において、このアソシエーション応答は、要求側ドライバに提供され、それ以上の処理は行われない。
【０１２９】
図１７を参照すると、本発明の一態様によるアソシエーションハンドラ方法１７００が示されている。１７１０において、アソシエーション要求に関連付けられた情報（たとえば、属性リスト）が、たとえばアソシエーションマネージャから受信される。１７２０において、アソシエーション要求が処理される。１７３０において、応答情報が、アソシエーションマネージャに提供される。
【０１３０】
本発明のさまざまな態様に追加の状況を提供するために、図１８及び以下の解説は、本発明のさまざまな態様を実施できる適した動作環境１８１０の簡単で一般的な説明を提供することを目的としている。本発明は、１つ若又は２つ以上のコンピュータ若しくは他のデバイスによって実行されるプログラムモジュール等のコンピュータ実行可能命令の一般的な状況で説明されるが、本発明は、他のプログラムモジュールと組み合わせて実施でき、且つ／又は、ハードウェア及びソフトウェアの組み合わせとして実施できることも当業者には認識されよう。一方、一般に、プログラムモジュールは、特定のタスクを実行するか又は特定のデータタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体等を含む。動作環境１８１０は、適した動作環境の一例にすぎず、本発明の使用範囲又は機能の範囲に関する制限を示唆することを意図したものではない。本発明と共に使用するのに適し得る他の既知のコンピュータシステム、環境、及び／又は構成には、上記のシステム又はデバイスを含むパーソナルコンピュータ、ハンドヘルドデバイス又はラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、プログラマブル家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、分散コンピューティング環境等が含まれるが、これらに限定されるものではない。
【０１３１】
図１８を参照すると、本発明のさまざまな態様を実施するための１つの例示的な環境１８１０は、コンピュータ１８１２を含む。コンピュータ１８１２は、処理ユニット１８１４、システムメモリ１８１６、及びシステムバス１８１８を含む。システムバス１８１８は、システムコンポーネントを処理ユニット１８１４に結合する。システムコンポーネントには、システムメモリ１８１６が含まれるが、これに限定されるものではない。処理ユニット１８１４は、利用可能なさまざまなプロセッサの任意のものとすることができる。デュアルマイクロプロセッサ及び他のマイクロプロセッサアーキテクチャを処理ユニット１８１４として用いることもできる。
【０１３２】
システムバス１８１８は、あらゆる利用可能なさまざまなバスアーキテクチャを使用したメモリバス若しくはメモリコントローラ、周辺バス若しくは外部バス、及び／又はローカルバスを含むいくつかのタイプのバス構造（複数可）の任意のものとすることができる。バスアーキテクチャには、８ビットバス、業界標準アーキテクチャ（ＩＳＡ）、マイクロチャネルアーキテクチャ（ＭＳＡ）、拡張ＩＳＡ（ＥＩＳＡ）、インテリジェントドライブエレクトロニクス（ＩＤＥ）、ＶＥＳＡローカルバス（ＶＬＢ）、周辺機器相互接続（ＰＣＩ）、ユニバーサルシリアルバス（ＵＳＢ）、アドバンストグラフィックスポート（ＡＧＰ）、パーソナルコンピュータメモリカード国際協会バス（ＰＣＭＣＩＡ）、及び小型コンピュータシステムインターフェース（ＳＣＳＩ）が含まれるが、これらに限定されるものではない。
【０１３３】
システムメモリ１８１６は、揮発性メモリ１８２０及び不揮発性メモリ１８２２を含む。起動中等にコンピュータ１８１２内の要素間で情報を転送する基本ルーチンを含んだ基本入出力システム（ＢＩＯＳ）は、不揮発性メモリ１８２２に記憶される。限定ではなく例示として、不揮発性メモリ１８２２には、読み出し専用メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、又はフラッシュメモリが含まれ得る。揮発性メモリ１８２０には、ランダムアクセスメモリ（ＲＡＭ）も含まれる。ＲＡＭは、外部キャッシュメモリとして働く。限定ではなく例示として、ＲＡＭは、シンクロナスＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ  ＳＤＲＡＭ）、エンハンストＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンクＤＲＡＭ（ＳＬＤＲＡＭ）、ダイレクトラムバスＲＡＭ（ＤＲＲＡＭ）等の多くの形で利用可能である。
【０１３４】
また、コンピュータ１８１２は、着脱可能／着脱不能な揮発性／不揮発性コンピュータストレージ媒体も含む。図１８は、たとえば、ディスクストレージデバイス１８２４を示している。ディスクストレージ１８２４には、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、又はメモリスティックのようなデバイスが含まれるが、これらに限定されるものではない。加えて、ディスクストレージ１８２４は、他のストレージ媒体とは別個のストレージ媒体又は他のストレージ媒体と組み合わされたストレージ媒体も含むことができる。これらのストレージ媒体には、コンパクトディスクＲＯＭデバイス（ＣＤ−ＲＯＭ）、ＣＤレコーダブルドライブ（ＣＤ−Ｒドライブ）、ＣＤ書き換え可能ドライブ（ＣＤ−ＲＷドライブ）、デジタル多用途ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）等の光ディスクドライブが含まれるが、これらに限定されるものではない。ディスクストレージデバイス１８２４のシステムバス１８１８への接続を容易にするために、インターフェース１８２６等の着脱可能インターフェース又は着脱不能インターフェースが、通常、使用される。
【０１３５】
図１８は、ユーザと、適した動作環境１８１０で説明した基本的なコンピュータ資源との間の仲介手段として働くソフトウェアを説明していることが認識されるべきである。このようなソフトウェアには、オペレーティングシステム１８２８が含まれる。オペレーティングシステム１８２８は、ディスクストレージデバイス１８２４上に記憶することができ、コンピュータシステム１８１２の資源を制御して割り当てるように働く。システムアプリケーション１８３０は、システムメモリ１８１６又はディスクストレージデバイス１８２４のいずれかに記憶されたプログラムモジュール１８３２及びプログラムデータ１８３４を通じて、オペレーティングシステム１８２８による資源の管理を活用する。本発明は、さまざまなオペレーティングシステム又はオペレーティングシステムの組み合わせと共に実施できることが認識されるべきである。
【０１３６】
ユーザは、入力デバイス（複数可）を通じてコンピュータ１８１２内にコマンド又は情報を入力する。入力デバイス１８３６は、マウス等のポインティングデバイス、トラックボール、スタイラス、タッチパッド、キーボード、マイク、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラ等が含まれるが、これらに限定されるものではない。これらの入力デバイス及び他の入力デバイスは、インターフェースポート（複数可）１８３８を介しシステムバス１８１８を通じて処理ユニット１８１４に接続する。インターフェースポート（複数可）１８３８には、シリアルポート、パラレルポート、ゲームポート、及びユニバーサルシリアルバス（ＵＳＢ）が含まれるが、これらに限定されるものではない。出力デバイス（複数可）１８４０は、入力デバイス（複数可）１８３６と同じタイプのポートのいくつかを使用する。したがって、たとえば、ＵＳＢポートを使用して、コンピュータ１８１２に入力を提供することができ、コンピュータ１８１２から出力デバイス１８４０へ情報を出力することができる。出力アダプタ１８４２は、他の出力デバイス１８４０の中でも、専用のアダプタを必要とするモニタ、スピーカ、及びプリンタのようないくつかの出力デバイス１８４０があることを示すために設けられている。出力アダプタ１８４２には、限定ではなく例示として、出力デバイス１８４０とシステムバス１８１８との間の接続手段を提供するビデオカード及びサウンドカードが含まれる。リモートコンピュータ（複数可）１８４４等、他のデバイス及び／又はデバイスのシステムは、入力機能及び出力機能の双方を提供することに留意すべきである。
【０１３７】
コンピュータ１８１２は、リモートコンピュータ（複数可）１８４４等の１つ又は２つ以上のリモートコンピュータへの論理接続を使用するネットワーク接続環境で動作することができる。リモートコンピュータ（複数可）１８４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベース電気器具、ピアデバイス、又は他の一般的なネットワークノード等とすることができ、通常は、コンピュータ１８１２について説明した要素の多く又は全部を含む。簡潔にするために、リモートコンピュータ（複数可）１８４４と共にメモリストレージデバイス１８４６しか示されていない。リモートコンピュータ（複数可）１８４４は、ネットワークインターフェース１８４８を通じてコンピュータ１８１２に論理接続され、次いで、通信接続１８５０を介して物理接続される。ネットワークインターフェース１８４８は、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）等の通信ネットワークを包含する。ＬＡＮ技術には、ファイバ配線データインターフェース（ＦＤＤＩ）、銅配線データインターフェース（ＣＤＤＩ）、Ｅｔｈｅｒｎｅｔ／ＩＥＥＥ８０２．３、トークンリング／ＩＥＥＥ８０２．５等が含まれる。ＷＡＮ技術には、ポイントツーポイントリンク、サービス統合デジタル網（ＩＳＤＮ）及びその変形のような回線交換ネットワーク、パケット交換ネットワーク、並びにデジタル加入者線（ＤＳＬ）が含まれるが、これらに限定されるものではない。
【０１３８】
通信接続（複数可）１８５０は、ネットワークインターフェース１８４８をバス１８１８に接続するのに用いられるハードウェア／ソフトウェアを指す。通信接続１８５０は、図を明瞭にするために、コンピュータ１８１２の内部に示されているが、通信接続１８５０は、コンピュータ１８１２の外部に存在することもできる。ネットワークインターフェース１８４８に接続するのに必要なハードウェア／ソフトウェアには、単なる例示として、モデム、ＩＳＤＮアダプタ、Ｅｔｈｅｒｎｅｔ（登録商標）カード等の内部技術及び外部技術が含まれる。モデムには、通常の電話グレードのモデム、ケーブルモデム、及びＤＳＬモデムを含まれる。
【０１３９】
一例の実施形態では、無線ユニバーサルシリアルバス（ＷＵＳＢ）サポートを含むプラグンゴー（Plug and Go）（ＰＯＮＧ）アーキテクチャとして拡張可能アーキテクチャを実施することができる。図１９は、ＰＯＮＧシステム１９００の一例を示している。マネージャ１９０５は、データを正しい相手に渡すことを容易にするように構成される中央コンポーネントである。マネージャ１９０５は、（ｄｌｌ等の）ドライバデータをプロセス内にロードすることができる。たとえば、マネージャ１９０５は、ドライバ登録に基づいてドライバデータをロードすることができる。マネージャ１９０５は、ドライバから要求ブロックを受信すると、要求ブロックヘッダを見ることができ、その要求タイプの適切なハンドラをロードすることができる。ハンドラ又はドライバは、システム起動時にロードすることができる。要求ブロックは、処理のためにハンドラに与えられる。ハンドラが完了すると、応答ブロックが、マネージャ１９０５を通じてドライバへ返される。
【０１４０】
ドライバ１９２０〜１９２２は、或る形のハードウェア又は別のソフトウェアコンポーネントのいずれかとインターフェースすることを担当する。ドライバ１９２０〜１９２２は、トラステッド媒体によりマネージャ１９０５からデバイスへ要求をチャネルで送ることを担当する。
【０１４１】
ドライバ１９２０〜１９２２のそれぞれは、新しい要求が発行されるべき時に検出することができ、ドライバは、その要求を取り出すか又は生成する。この要求は、マネージャ１９０５に渡され、マネージャ１９０５は、後に、ドライバへ応答を返す。
【０１４２】
複数のハンドラが、同じドライバを使用することができる（すなわち、複数のターゲット媒体が、同じトラステッド媒体を使用することができる）。ドライバ１９２０〜１９２２は、要求ブロック又は応答ブロックの詳細についての知識を必要としない場合がある。
【０１４３】
ハンドラ１９１０〜１９１２は、デバイスのインストール／アソシエーションを実施するサービスとインターフェースすることを担当する。ハンドラ１９１０〜１９１２は、ターゲット媒体に直接関係付けることができ、その特定のターゲット媒体の要求ブロックの属性についての明示の知識を有する必要がある唯一のコンポーネントとすることができる。他のコンポーネントも使用できるグローバルな属性が存在する。
【０１４４】
ハンドラ１９１０〜１９１２は、無線媒体等のあらゆるタイプのターゲット媒体をハンドリングするように構成することができる。図１９に示すように、ハンドラ１９１２は、ＷＵＳＢ媒体をハンドリングするように構成される。ＷＵＳＢは、無線ＵＳＢ周辺機器を無線ＵＳＢホストに接続するためのＵＳＢインプリメンターズフォーラム（USB Implementers Forum）によって定義された無線プロトコルである。ＷＵＳＢプロトコルは、超広帯域（ＵＷＢ）の上にあるマルチバンドＯＦＤＭアライアンス（ＭＢＯＡ）の媒体アクセス制御（ＭＡＣ）レイヤ上で機能するように仕様が定められている。ハンドラ１９１０〜１９１２のいずれか１つがマネージャ１９０５から要求ブロックを受信すると、そのハンドラは、その内容を解析して、適切な動作を決定する。
【０１４５】
ＰＯＮＧシステム１９００は、ＷＵＳＢに関連付けられた属性を含む要求及び応答をデバイスが送信することを可能にする。デバイスからハンドラに渡された要求では、属性リストは、アソシエーションタイプ、接続デバイスＩＤ、接続鍵、デバイスセットアップクラスＧＵＩＤ、サポートされる帯域グループ、インテグレータ（integrator）サイトＵＲＬ等を含むことができる。アソシエーションタイプは、要求及び応答のヘッダセクションに含まれる属性であり、データ属性から分離されている。アソシエーションタイプ属性は、正しいハンドラへ要求を転送するためにマネージャによって使用される。表２４は、アソシエーションタイプ属性の一例の仕様を示している。
【０１４６】
【表２４】
2008547250.tif 000026
表２４及び以下の表の用語は、次のように定義される。
【０１４７】
属性名：属性要素に関連付けられた親しみやすい名称。
【０１４８】
属性ＩＤ：この番号は、属性リストの属性要素を識別するのに使用される。
【０１４９】
長さ：属性要素のデータの長さ。属性の長さは、可変長又は固定長とすることでき、バイトで表される。長さの値は、最大長を指定することもできる。応答では、この値に対するオフセットが必ず存在するように固定長を使用することができ、それによって、デバイスが応答を解析する能力が支援される。属性の実際の値は、そのデータに割り当てられた長さ全体を使い切らない場合がある。これらの場合には、追加フィールドが、属性データの実際の長さを指定する。
【０１５０】
Ｍ／Ｏ：このフィールドは、変数が必須であるのか、又はオプションであるのかを知らせる。必須の属性要素は、属性リストに常に含まれる。オプションの値は、必ずしも存在するとは限らない。「必須」（Mandatory）はＭで表され、「オプション」（Option）はＯで表される。
【０１５１】
許容値：許容値フィールドは、デバイスによってサポートされる値を記述する。許容値が必要とされる場合、このことは、その値が属性リストに含まれるときに、デバイスがその値をサポートすることを意味する。表に明記されていない限り、値は必要であるとみなすべきである。許容値がオプションである場合、デバイスは、その値をサポートする必要はないが、その値が属性リストに含まれることに対応できるように準備されているべきである。オプションの値は、この仕様の今後のバージョンで必要とされる可能性がある。
【０１５２】
要求のデータセクションは、属性タイプに特有の属性を含むことができる。表２５は、ＷＵＳＢハンドラへ転送できる要求属性の例を示している。
【０１５３】
【表２５】
2008547250.tif 000027
接続デバイスＩＤ（ＣＤＩＤ）は、無線ＵＳＢデバイスのデバイスＩＤである。デバイスＩＤが、（工場、前の関連付けの試み、ユーザ入力等からのいずれであろうと）デバイスに事前に割り当てられていた場合、デバイスは、同じＩＤを利用したい場合がある。既存のＩＤを再利用することによって、ホストは、そのデバイスに以前出会ったことがあることを知って、異なって振る舞うことができる。また、既存のＩＤを再利用することにより、ホストが異なって振る舞うことが、複数のホストに同時に関連付けることができるデバイスに対してより容易になる。たとえば、デバイスが複数のホストにわたって同じＣＤＩＤを保持したい場合又はデバイスがこのホストにすでに関連付けられていることを示したい場合に、ＣＤＩＤは、デバイスが送信することができる。ホストは、この値を上書きすることもできるし、この値を再利用することもできる。
【０１５４】
この属性が欠落している場合、又は、その値がすべて０である場合、ホストは、デバイスが新しいデバイスＩＤを必要としているものと仮定する。ホストは、この一意のＩＤを生成して、そのＩＤをアソシエーション応答でデバイスに返す。
【０１５５】
接続鍵（ＣＫ）は、ＷＵＳＢ仕様に記述されているように、相互認証を容易にし、且つ、セッション暗号化鍵を生成するのに使用される鍵である。デバイスが、ハードコード化された接続鍵を有する必要がある場合に、ＣＫは、デバイスが送信することができる。デバイスは、生成された鍵を記憶できない（ＮＶＲＡＭを有しない）場合に、この属性を要求に含めたい場合がある。しかしながら、デバイスがこれらの鍵をハードコード化することは推奨されず、逆に、デバイスは、より安全にするために、ホストがそれらの鍵を生成することを可能にすべきである。
【０１５６】
この属性が欠落している場合、又は、その値がすべて０である場合、ホストは、デバイスがＣＫの生成を必要としているものと仮定し、ＣＫをアソシエーション応答で返す。
【０１５７】
デバイスセットアップクラスＧＵＩＤは、サポートされるセットアップクラスＧＵＩＤのうちの１つである。この値をアソシエーション要求で提供することによって、デバイスの適切なアイコンの表示が可能になったり、或るシステムポリシー又はユーザ定義のポリシーの実施が可能になったりする。この値は、どのようなタイプのデバイスが関連付けられているのかを求めるのに使用することができる。ＧＵＩＤは、ホスト上にインストールされたデバイスセットアップクラスとの照合を行ってアイコン、説明等の事物を決定するのに使用することができる。また、これは、あらゆるＵＩに適切な情報を表示するのを助け、それによって、ユーザが特定のデバイスを識別するのを助ける。
【０１５８】
サポートされた帯域グループは、ホスト無線が、チャネルを選ぶ時にどのチャネルから選ぶべきかを決定するのに使用することができる。たとえば、サポートされた帯域グループは、ホストが使用できるのはどのようなＰＨＹチャネルであるのかを決定するためにホストが使用することができる。デバイスからのこの情報がない場合、帯域グループ１が、すべてのデバイスによってサポートされる必要がある唯一の帯域グループであるので、ホストは、帯域グループ１のチャネルへ変更する必要がある。これによって、すべてのホスト及びデバイスが、帯域グループ１を使用することを選ぶことになり、したがって、それらのチャネルに殺到し、他の帯域グループの値を小さくすることになる。この情報が、関連付け時にホストへ通信される場合、ホストは、おそらく自身に接続し得るすべてのデバイスのサポートされたチャネルを知ることになり、したがって、それにより、ホストは、おそらく、他の帯域グループのチャネルを選ぶことが可能になる。
【０１５９】
或るビット位置における１は、関連付けられたＰＨＹ帯域グループの帯域及びチャネルのすべてがサポートされていることを示す。ビット位置０における１は、帯域グループ１のすべての帯域がサポートされていることを示す。
【０１６０】
インテグレータサイトＵＲＬは、ＵＳＢ−ＩＦウェブサイトにおけるデバイスの詳細へのリンクを提供することによってデバイスについての情報をユーザに提供するために、ＵＩにおいて使用することができる。
【０１６１】
表２６は、ＷＵＳＢデバイスへ転送できる応答属性の例を示している。この表には、オフセットの例が示されている。また、ヘッダ属性は、属性リストの最初の１９バイトを占めることができる。
【０１６２】
【表２６】
2008547250.tif 000028
ハンドラからデバイスへ渡される応答では、属性リストは、接続ホストＩＤ、接続デバイスＩＤ、接続鍵、好ましいチャネル、ホスト領域等を含むことができる。接続ホストＩＤ（ＣＨＩＤ）は、一意のホストＩＤである。デバイスは、このＩＤを使用して、ホストのビーコンを突き止めることができ、それによって、ホストを突き止めることができる。接続デバイスＩＤ（ＣＤＩＤ）は、一意のデバイスＩＤである。このＩＤは、ＣＨＩＤによって指定されたホストに対してデバイスを一意に識別する。複数のホストにわたって一意であることは保証されていない。接続鍵（ＣＫ）は、この状況を使用して再接続を確立するためのものである。ＣＫは、１２８ビットＣＣＭ鍵とすることができる。
【０１６３】
好ましいチャネルは、ホストが使用している好ましいチャネルの順序をデバイスに通知するために、ホスト応答において指定することができる。これは、ホストがいずれかの所与のチャネル上に存在する相対尤度についてのヒントをデバイスに与えることによって、ホストの検索プロセスを最適化することができる。デバイスは、ホストが指定した順序でホストを検索することができ、したがって、デバイスが、線形順序でスキャンするのではなく、スキャンされた最初の数個のチャネルの１つにおいてホストを見つける可能性をより高くすることができる。
【０１６４】
ホスト領域は、ホストがどの領域で動作しているのかについてデバイスに通知するために、ホスト応答において指定することができる。デバイスは、この情報を使用して、その無線動作特性を領域特有の値に変更することができる。
【０１６５】
一実施形態では、属性リストの属性の長さは、固定とすることができる。したがって、デバイス製造者は、適切なオフセットに容易にジャンプして、応答におけるどの所与の属性の値も読み出すことができる。オフセットは、属性の始点を参照する。
【０１６６】
他の属性は、デバイスとハンドラとの間の要求及び応答に使用することができる。これらの他の属性には、ハードウェア及び互換ＩＤ、チャネルＩＤ、帯域グループ、デバイス製造者文字列、デバイス記述文字列、ホスト文字列、デバイスクラスＧＵＩＤ、製造者ＵＲＬ、デバイスアイコン、アソシエーション秘密鍵等が含まれ得る。アソシエーション秘密鍵は、デバイスに書き込まれるＰＯＮＧ特有の鍵である。デバイスは、通常、ＰＯＮＧを通じた場合を除き、アソシエーション秘密鍵を明らかにしない。デバイスが次に取り付けられた時、アソシエーション秘密鍵が取り出され、デバイスを認証するのに使用される。アソシエーション秘密鍵を使用することによって、ユーザに尋ねることなく、アソシエーション情報を黙って更新する等のタスクを行うことを可能にすることができ、それによって、デバイスが自身のＣＤＩＤ等を保持することを可能にすることができる。アソシエーション鍵を使用しない場合、（たとえば、別のホストから取得されたり、別のデバイスから盗難されたり等した）同じＣＤＩＤを有する２つのデバイスは、それらのデバイスのＰＣに接続する能力に影響を与える可能性があり得る。
【０１６７】
以下は、上述したアーキテクチャ及びＷＵＳＢ接続メカニズムを使用して達成できる２つのシナリオの例である。
シナリオ１−ＰＣを伴ったＷＵＳＢポータブルプレイヤ
トッドは、Ｗｉｎｄｏｗｓ（登録商標） Ｍｅｄｉａ  Ｐｌａｙｅｒと連動して同期する新しい有線＋無線ＵＳＢポータブルプレイヤを入手した。トッドは、箱を開けた際に、そのプレイヤを取り外し、含まれている再充電可能バッテリーをプレイヤに加える。次に、彼は、サードパーティのソフトウェアをインストールする指示に従い、次に、有線ＵＳＢケーブルを使用してプレイヤをＰＣに取り付け、バッテリーを充電する。バッテリーの充電中、プレイヤは、無線ＵＳＢ接続を得るためにＰＣにも結合され、有線ＵＳＢによりデバイス同期も開始する。
【０１６８】
ケーブルのプラグ接続が解除され、デバイスが圏内にいると、ユーザには、無線ＵＳＢデバイス検出用の新しいダイアログが見えないはずであり、デバイスは、単に作業を開始するはずである。
シナリオ２−ＰＣを伴った携帯電話及びストレージ
ジャックは、事前に関連付けられているＰＣ及びＷＵＳＢストレージデバイスを有する。ジャックが、自身のＷＵＳＢ携帯電話をＰＣに関連付けるとき、ジャックは、他のＷＵＳＢデバイス（１つの空いている接続スロットを有する場合がある）も携帯電話に関連付けるオプションを得る。これは、ＰＣの価値を増大させ、エンドユーザの接続経験を簡単にする。
【０１６９】
以下には、例示のため、ＷＵＳＢデバイスを関連付けるための４つのアソシエーションモデルの例が含まれている。
【０１７０】
ＵＩ手法−（デバイスが近接すると）双方のシステム上の接続ボタンを使用し、近接したペアにできるデバイスのＵＩリストからデバイスを識別する。
【０１７１】
シリアル番号手法−これは、ＵＩ手法と非常に類似しているが、ユーザが、ＵＩからデバイスを識別すると、ユーザは、セキュリティを有効にするために、デバイスからホストへシリアル番号をタイプ入力しなければならない。
【０１７２】
ＵＳＢケーブル手法−汎用ＵＳＢケーブルを使用して、無線ＵＳＢデバイスを、関連付けたいホストにプラグ接続する。ワイヤは、通常のオペレーションに使用することもできるし、関連付けと共に充電することに使用することもできる。
【０１７３】
ＵＳＢフラッシュ鍵−汎用ＵＳＢ大容量記憶装置（たとえば、ＵＳＢフラッシュデバイス）を使用して、デバイスとホストとの間で識別情報及びセキュリティ情報を記憶及び交換する。
【０１７４】
図１９に示すＰＯＮＧシステム１９００は、特に、ＵＳＢをサポートするように構成することができる。図２０は、オペレーティングシステムのデバイスマネージャアーキテクチャの一例のＵＳＢドライバスタック２０００を示している。ドライバスタック２０００は、ＰＯＮＧシステム１９００でトラステッド媒体としてＵＳＢをサポートするように実施することができる。コンポーネント２０１３〜２０１７は、オペレーティングシステムの既存のＵＳＢスタックである。コンポーネント２０１０は、ＰＯＮＧ  ＵＳＢドライバのカーネルコンポーネントである。コンポーネント２００６は、全ＰＯＮＧマネージャ１９０５によってカプセル化されたユーザモードのＰＯＮＧドライバである。
【０１７５】
図２１は、ＷＵＳＢデバイス２１１２がホストデバイス２１００に接続するためのオペレーションの例を示している。接続ＷＵＳＢデバイス２１１２は、ＷＵＳＢを使用して通信できる任意のデバイスとすることができる。通常、接続ＷＵＳＢデバイス２１１２は、トラステッド媒体を使用して通信することもできる。上述したように、トラステッド媒体には、有線ＵＳＢ、シリアル、パラレル、ファイアワイヤ、Ｅｔｈｅｒｎｅｔ（登録商標）等の有線接続が含まれ得る。また、トラステッド媒体には、近接通信（ＮＦＣ）、赤外線（ＩＲ）、他の確立された無線接続等の無線接続も含まれ得る。ホストデバイス２１００は、図１９と共に上述したようなマネージャ１９０５、ＷＵＳＢハンドラ１９１２、及びドライバ１９１２を含む。図２１に示すように、ホストデバイス２１００は、ＷＵＳＢを使用して外部デバイスに接続するためのＷＵＳＢコンポーネント２１０３、及び、有線コンポーネントを使用してデバイスに接続するための有線コンポーネント２１０５も含む。
【０１７６】
ホストデバイス２１００に接続するために、接続ＷＵＳＢデバイスは、有線コンポーネント２１０５を通じてドライバ１９２１へ要求を送信する。たとえば、接続ＷＵＳＢデバイス２１１２は、有線ＵＳＢケーブルを通じて有線コンポーネント２１０５に接続することができる。この要求は、上述した属性等、ＷＵＳＢデバイス２１１２をホストデバイス２１００に関連付けるための情報を含む。
【０１７７】
ドライバ１９２１は、マネージャ１９０５へ要求を送信する。マネージャ１９０５は、要求の情報を解析してその有効性を確認する。詳細には、マネージャ１９０５は、要求における接続のタイプ、及び、要求の情報が、接続に関係した標準規格について有効であるか否かを判断することができる。この例では、マネージャ１９０５は、要求がＷＵＳＢ接続に関連付けられているものと判断する。マネージャ１９０５は、要求のデバイス属性の有効性を確認する。要求が有効である場合、マネージャ１９０５は、デバイス属性等のＷＵＳＢ接続情報をＷＵＳＢハンドラ１９１２に提供する。
【０１７８】
ＷＵＳＢハンドラ１９１２は、接続情報を処理し、要求に応答して、ホスト接続情報をマネージャ１９０５に提供する。ホスト接続情報は、ＷＵＳＢを使用して接続するのに使用される接続属性を含む。マネージャ１９０５は、接続属性を有するホスト接続情報をドライバ１９２１に提供する。ドライバ１９２１は、有線コンポーネント２１０５を通じて接続情報を接続ＷＵＳＢデバイス２１１２へ送信する。次に、接続ＷＵＳＢデバイス２１１２は、接続情報を自己構成及びホストデバイス２１００への接続に使用する。たとえば、接続ＷＵＳＢデバイス２１１２は、チャネル、領域等、ホストデバイス２１００によって必要とされる構成にＷＵＳＢコンポーネントを調整することができる。また、接続ＷＵＳＢデバイス２１１２は、受信された接続情報において識別された鍵、ホストＩＤ、及びデバイスＩＤを有する情報もホストデバイス２１００へ送信することができる。
【０１７９】
図２２は、本明細書で説明したシステムを使用してＷＵＳＢデバイスをホストデバイスと接続するための一例のプロセス２２００を示している。たとえば、プロセス２２００は、マネージャ１９０２が実施することができる。ブロック２２０２において、ＷＵＳＢデバイスからのアソシエーション要求が識別される。このアソシエーション要求は、有線媒体等の信頼媒体を通じて受信することができる。ブロック２２０４において、要求が解析され、その内容の有効性が確認される。要求を解析することによって、要求に含まれるアソシエーションのタイプの決定が可能になる。要求の有効性は、そのタイプに対応する標準規格に基づいて確認される。この例では、アソシエーションのタイプはＷＵＳＢであり、要求の有効性は、ＷＵＳＢ標準規格と対比して確認される。有効性が確認された要求は、ＷＵＳＢ標準規格によって指定されるデバイス属性を含むべきである。
【０１８０】
ブロック２２０６において、ＷＵＳＢデバイス属性が、ＷＵＳＢハンドラへ送信される。ブロック２２０８において、接続属性が、ＷＵＳＢハンドラから受信される。これらの接続属性によって、ＷＵＳＢデバイスは、ホストデバイスに接続することが可能になる。ブロック２２１０において、接続属性が、トラステッド媒体を通じてＷＵＳＢデバイスへ送信される。
【０１８１】
以下のセクションＡ〜Ｃは、ＵＳＢトラステッド媒体上でＰＯＮＧシステムによって使用されるプロトコルに特有のものであり、ＰＯＮＧターゲットデバイスにおいてＵＳＢ上でＰＯＮＧを実施するのに必要とされるさまざまなインターフェース記述子及びエンドポイント記述子のレイアウトを示している。
Ａ．ＰＯＮＧデバイスインターフェース
表２７は、インターフェース記述子を表したものであり、ＵＳＢ上でＰＯＮＧデバイスについて記入される値の詳細を提供する。ほとんどの行について、特定の値又は特定の一組の値が設けられている。ベンダは、指定された範囲から選択することができ、他のすべての値は、今後の使用のためにＲＥＳＥＲＶＥＤ（予備）とすることができる。
【０１８２】
【表２７】
2008547250.tif 000029
関連付け中のデバイスを識別するのに文字列を使用することができる。この文字列は、ＵＳＢ文字列記述子に局在化させることができる。良い文字列の一例は、「ＰＯＮＧ−Wireless USB Mouse」（ＰＯＮＧ−無線ＵＳＢマウス）である。一例の実施形態では、ＰＯＮＧインターフェースは、インターフェースアソシエーション記述子でグループ化されない。ＵＳＢデバイスは、１つの構成当たり２つ以上のＰＯＮＧインターフェースを有するように構成することはできない。
Ｂ．ＰＯＮＧデバイスエンドポイント
本当に安いデバイスを可能にするために、制御エンドポイントを使用することができ、割り込みエンドポイントは（拡張機能では）オプションである。制御エンドポイントを使用することによって、低速ＵＳＢデバイスも可能になる。制御エンドポイント（エンドポイント０ｘ００）は、インターフェース記述子の下では記述される必要はなく、すべてのＵＳＢデバイスに存在しなければならない。
【０１８３】
スマートデバイスは、デバイス列挙が完了した後にアソシエーション機能を実施することを選ぶことができる。これを達成するために、デバイスは、オプションの割り込みＩＮエンドポイントを実施することができる。このエンドポイントによって、新しいアソシエーション要求の通知が容易になる。このオプションのエンドポイントの標準的なエンドポイント記述子の一例が、割り込みＩＮエンドポイント記述子として表２８に示されている。
【０１８４】
【表２８】
2008547250.tif 000030
デバイスのＰＯＮＧインターフェースが、オプションのエンドポイントを含まない場合、関連付けは、列挙時に行うことができる。このようなデバイスがアソシエーションプロセスを開始したい場合、デバイスは、デバイスが開始するＵＳＢリセットを行うことができる。これによって、デバイスをホストにより再列挙することができ、その時点で、ホストは、デバイスからアソシエーション要求を取り出すことができる。また、デバイスは、ＨＵＢ機能も実施して、そのデバイスを往来させることができる。
Ｃ．ＰＯＮＧクラス特有の要求
すべてのＰＯＮＧデータ転送は、制御エンドポイント上で行われる。これらの転送は、ＰＯＮＧクラス要求の形とすることができる。表２９は、ＰＯＮＧデバイスによってサポートされるＰＯＮＧクラス要求のリストを示している。bRequestの有効な値が示されている。
【０１８５】
【表２９】
2008547250.tif 000031
Ｃ．１．GET_ASSOCIATION_INFORMATION
この要求は、デバイスからassociation_information（アソシエーション情報）構造体を取り出す。このassociation_informationは、REQUEST_INFOブロックのリストを含む。各REQUEST_INFOブロックは、デバイスが発行したい単一のアソシエーション要求に関するものである。表３０は、一例のGET_ASSOCIATION_INFORMATION要求を示している。
【０１８６】
【表３０】
2008547250.tif 000032
表３１は、association_informationデータ構造体の一例を示している。このデータ構造体の最初の数バイト（たとえば、３バイト）は、ヘッダセクションとすることができる。
【０１８７】
【表３１】
2008547250.tif 000033
表３２は、association_informationフラグの例を示している。
【０１８８】
【表３２】
2008547250.tif 000034
表３３は、request_info（要求情報）構造体を示している。
【０１８９】
【表３３】
2008547250.tif 000035
Ｃ．２．GET_ASSOCIATION_REQUEST
この要求は、デバイスから特定のアソシエーション要求を取り出す。この要求は、wValueフィールド内のRequestID値によって識別される。表３４は、一例のGET_ASSOCIATION_REQUEST要求を示している。
【０１９０】
【表３４】
2008547250.tif 000036
要求ブロックは、４ＫＢのデータブロックとすることができる。制御転送の最大転送サイズは、６４ＫＢに設定することができる。したがって、理論的には、各GET_ASSOCIATION_REQUESTにおいて１６個の要求ブロックを転送することができる。転送される実際のデータ量は、wLengthフィールドによって指定される。wValueフィールドで指定されたBlockNumberは、この制御転送の開始ブロック番号を識別する。デバイスは、RequestIDによって指定される要求のアソシエーション要求データを、オフセットBlockNumber×４ＫＢから開始して、wLengthバイトを転送して返すことができる。
Ｃ．３．SET_ASSOCIATION_RESPONSE
この要求は、wValueフィールドのRequestID値によって識別される特定のアソシエーション要求に対する応答を送信する。表３5は、一例のSET_ASSOCIATION_RESPONSEを示している。
【０１９１】
【表３５】
2008547250.tif 000037
TransferFlags値は、値の０個以上のビットごとのＯＲである。一例のTransferFlags値が表３６に示されている。
【０１９２】
【表３６】
2008547250.tif 000038
ＰＯＮＧシステムは、割り込みＩＮメッセージを実施することができる。たとえば、NewAssociationRequest（新アソシエーション要求）は、デバイスが、処理する必要がある新しいアソシエーション要求又は変更されたアソシエーション要求を有することをホストに示すのに使用できる割り込みＩＮメッセージである。ホストは、このメッセージを受信すると、GET_ASSOCIATION_INFORMATION要求を発行し、それに応じてこれらの要求を処理する。表３７は、一例のNewAssociationRequestを示している。
【０１９３】
【表３７】
2008547250.tif 000039
図２３は、本明細書で説明した特定のデータ構造体を使用してデバイスを関連付けるための一例のプロセス２３００を示している。この一例のプロセス２３００は、ＨＯＳＴがＵＳＢでデバイスを構成するためのＰＯＮＧシステム等の拡張可能アーキテクチャにおいて実施することができる。プロセス２３００は、上述した要求及び応答と共に実施することができる。
【０１９４】
ブロック２３０４において、GET_ASSOCIATION_INFORMATIONが送信される。一実施態様では、要求は、少なくとも３バイトのデータを含む。ブロック２３０６において、アソシエーション情報全体のサイズが求められる。このサイズは、
サイズ＝３＋sizeof (REQUEST_INFO)×PendingRequestCount
によって求めることができる。
【０１９５】
判定ブロック２３０８において、すべてのアソシエーション情報が受信されているか否かの判断が行われる。すべてのアソシエーション情報が受信されていない場合には、プロセス２３００はブロック２３０４に戻る。すべてのアソシエーション情報が受信されている場合、プロセス２３００は、判定ブロック２３１０に移動する。判定ブロック２３１０において、保留中の要求が存在するか否かの判断が行われる。たとえば、この判断は、PendingRequestCountデータ構造体が０よりも大きいか否かを判断することによって行うことができる。保留中の要求が存在しない場合には（たとえば、PendingRequestCount＝０）、プロセス２３００は終了する。保留中の要求が存在する場合には、プロセス２３００はブロック２３１２に進み、ブロック２３１２において、プロセスは、ハンドリングする要求を選ぶ。
【０１９６】
ブロック２３１４において、転送のサイズが求められる。このサイズは、
サイズ＝max（残っているバイト，Ｎ×４ＫＢ（ここで、０＜Ｎ≦１６））
によって求めることができる。
【０１９７】
ブロック２３１６において、GET_ASSOCIATION_REQUESTが、適切なデータ量について送信される。RequestIDは、アソシエーション情報のRequestIDと一致すべきである。BlockNumberは、返される開始ブロック番号であるべきである。判定ブロック２３１８において、要求データがそれ以上あるか否かの判断が行われる。要求データがある場合には、プロセス２３００は、ブロック２３１４に戻る。要求データがない場合には、プロセスは、ブロック２３２０に進み、ブロック２３２０において、アソシエーション要求がハンドリングされ、応答が生成される。
【０１９８】
ブロック２３２２において、応答転送のサイズが求められる。ブロック２３２４において、GET_ASSOCIATION_RESPONSEが、適切なデータ量について送信される。RequestIDは、要求のRequestIDと一致すべきである。この転送が応答の最後のバイトを含む場合、LastBlock（最後のブロック）が設定されるべきである。判定ブロック２３２６において、データがそれ以上あるか否かの判断が行われる。データがある場合には、プロセス２３００はブロック２３２２に戻る。データがそれ以上ない場合には、プロセスは判定ブロック２３２８に続き、ブロック２３２８において、要求がそれ以上あるか否かの判断が行われる。要求がある場合には、プロセス２３００は、ブロック２３１２に戻る。要求がそれ以上ない場合には、プロセスは、判定ブロック２３３０に移動し、判定ブロック２３３０において、AdditionalRequests（追加要求）フラグがアソシエーション情報において設定されていたか否かの判断が行われる。AdditionalRequestsフラグが設定されていた場合には、プロセス２３００はブロック２３０４に戻る。このフラグが設定されていない場合には、プロセスは終了する。
【０１９９】
ＰＯＮＧインターフェースをサポートするデバイスが、デバイス列挙の時にＰＯＮＧアソシエーション要求を送信する準備が実際にはできていない可能性があり得る。たとえば、おそらく、デバイスは、実際には、或る独自のインターフェース上でＰＯＮＧをサポートする他のデバイス用の或るタイプのクレードル(cradle)である。ＵＳＢ  ＰＯＮＧデバイスは、ターゲットデバイスがそのクレードルに挿入されるずっと以前からすでに列挙済みである。上述したシステム及び技法は、ＰＯＮＧドライバが新しいアソシエーション情報を取り出す必要があることをそのＰＯＮＧドライバに通知するメカニズムを提供する。
【０２００】
また、一定のデバイス（たとえば、複数のターゲット媒体を有するデバイス）が複数のアソシエーション要求をサポートすることが必要な場合もある。これらの個々のアソシエーション要求は、互いに依存している可能性もあるし、全体的に独立している可能性もある。独立した関連付けは、デバイスが、ターゲット媒体を関連付ける順序について注意することなく、複数のターゲット媒体を一斉に関連付けたい場合である。上述したシステム及び技法は、ホストからアソシエーション応答を受信した後に、デバイスが、その応答の結果として新しいアソシエーション要求を発行することを決定するシナリオをサポートする。
【０２０１】
上述したものは、説明した本発明の例を含む。もちろん、本発明を説明するために、コンポーネント又は方法論の考えられるあらゆる組み合わせを記載することは不可能であるが、当業者は、本発明のさらに別の多くの組み合わせ及び変形が可能であることを認識することができる。したがって、本発明は、添付の特許請求の範囲の趣旨及び範囲に含まれるこのようなすべての変更、修正、及び変形を包含することが意図されている。さらに、詳細な説明又は特許請求の範囲において用語「含む（includes）」が使用される点において、このような用語は、「備える（comprising）」が特許請求の範囲で移行語として使用されるときに解釈されるように、用語「備える」と同様にして包括的であることが意図されている。
【図面の簡単な説明】
【０２０２】
【図１】本発明の一態様によるアソシエーションアーキテクチャのブロック図である。
【図２】本発明の一態様によるアソシエーション要求の図である。
【図３】本発明の一態様によるアソシエーション応答の図である。
【図４】本発明の一態様によるアソシエーション管理システムのブロック図である。
【図５】本発明の一態様によるアソシエーション管理システムのブロック図である。
【図６】本発明の一態様によるアソシエーションハンドラシステムのブロック図である。
【図７】本発明の一態様によるアソシエーションドライバシステムのブロック図である。
【図８】本発明の一態様による、デバイスを関連付ける方法のフローチャートである。
【図９】本発明の一態様による、デバイスの関連付けを容易にする方法のフローチャートである。
【図１０】本発明の一態様による、ＵＳＢ接続を介してデバイスを関連付ける方法のフローチャートである。
【図１１】図１０の方法をさらに示すフローチャートである。
【図１２】図１０及び図１１の方法をさらに示すフローチャートである。
【図１３】本発明の一態様によるアソシエーション管理方法のフローチャートである。
【図１４】本発明の一態様によるアソシエーション管理方法のフローチャートである。
【図１５】図１４の方法をさらに示すフローチャートである。
【図１６】図１４及び図１５の方法をさらに示すフローチャートである。
【図１７】本発明の一態様によるアソシエーションハンドラ方法のフローチャートである。
【図１８】本発明が機能できる一例の動作環境を示す図である。
【図１９】ＰＯＮＧシステムの一例を示す図である。
【図２０】オペレーティングシステムのデバイスマネージャアーキテクチャの一例のＵＳＢドライバスタックを示す図である。
【図２１】ＷＵＳＢデバイスがホストデバイスに接続するためのオペレーションの例を示す図である。
【図２２】本明細書で説明したシステムを使用してＷＵＳＢデバイスをホストデバイスと接続するための一例のプロセスを示す図である。
【図２３】本明細書で説明した特定のデータ構造体を使用してデバイスを関連付けるための一例のプロセスを示す図である。
【図１】
2008547250.tif 000040
【図２】
2008547250.tif 000041
【図３】
2008547250.tif 000042
【図４】
2008547250.tif 000043
【図５】
2008547250.tif 000044
【図６】
2008547250.tif 000045
【図７】
2008547250.tif 000046
【図８】
2008547250.tif 000047
【図９】
2008547250.tif 000048
【図１０】
2008547250.tif 000049
【図１１】
2008547250.tif 000050
【図１２】
2008547250.tif 000051
【図１３】
2008547250.tif 000052
【図１４】
2008547250.tif 000053
【図１５】
2008547250.tif 000054
【図１６】
2008547250.tif 000055
【図１７】
2008547250.tif 000056
【図１８】
2008547250.tif 000057
【図１９】
2008547250.tif 000058
【図２０】
2008547250.tif 000059
【図２１】
2008547250.tif 000060
【図２２】
2008547250.tif 000061
【図２３】
2008547250.tif 000062