JP2006228195A - 信用媒体を介した非信用媒体装置構成のための拡張可能なアーキテクチャ - Google Patents

Abstract

【課題】信用媒体を介した非信用媒体（例えば無線）装置構成の拡張可能なアーキテクチャを提供すること。
【解決手段】このアーキテクチャを使用して、非信用媒体を利用する装置を関連づけることができる。アソシエーションは信用媒体、例えば有線接続を使用して達成される。このアーキテクチャは、非信用媒体を介して（例えば安全に）通信する装置の構成を容易にできる。装置の構成は、信用媒体（例えば有線接続）を介して交換される情報に少なくとも部分的に基づくことができる。装置は、アソシエーション要求をドライバに送り、そのドライバからアソシエーション応答を受け取ることができる。アソシエーションが成功した場合、アソシエーション応答は例えば、非信用媒体を介して装置が通信することを可能にする構成情報（例えば暗号化鍵）を含むことができる。アソシエーションが不成功の場合、アソシエーション応答は例えばエラー情報を含める。
【選択図】図１

Description

本発明は一般にコンピュータシステムに関し、詳細には、信用媒体（ｔｒｕｓｔｅｄ ｍｅｄｉｕｍ）による非信用媒体（ｕｎｔｒｕｓｔｅｄ ｍｅｄｉｕｍ）（例えば無線）装置構成のための拡張可能なアーキテクチャに関する。

近年、コンピュータシステムで無線装置を使用することに人気が集まっている。例えば、多くの装置が、ＷｉＦｉ（ＩＥＥＥ８０２．１１）および／またはＢｌｕｅｔｏｏｔｈなどの無線バスを介して通信する。

「Ｂｌｕｅｔｏｏｔｈ」は、装置間の無線接続を可能にする、装置間の短距離（例えば約１０メートル）周波数ホッピング無線リンクのプロトコルを指す。Ｂｌｕｅｔｏｏｔｈは、ガウス周波数偏移変調を使用してデータを２．４ＧＨｚ付近の周波数に変調するものであり、ポイントツーポイントまたはポイントツーマルチポイント通信が可能である。この柔軟性は、心拍数モニタ、ＰＤＡ（パーソナルデジタルアシスタント）、ヒューマンインターフェース装置（ＨＩＤ）、例えばキーボードなどの様々な応用の市場に、Ｂｌｕｅｔｏｏｔｈの無線技術が浸透することを可能にする。

ＷｉＦｉでは一般に、ユーザが無線ネットワークの範囲に入ると、クライアント装置は、そのネットワークに接続することなくそのネットワークについての２つの情報を（例えば無線ネットワークビーコンから）識別することができる：（１）そのネットワークのＳＳＩＤ（ｓｅｖｉｃｅ ｓｅｔ ｉｄｅｎｔｉｆｉｅｒ）（例えば実質的にその名称）、および（２）そのネットワークがデータを暗号化するどうかについての情報。そのネットワークが暗号化を使用する場合、暗号化鍵が必要となる。暗号化鍵はユーザが手入力し、かつ／または８０２．１ｘプロトコルに従って送信することができる。

クライアント装置が無線ネットワークビーコンから取り出すことができる情報を使用して、クライアント装置は一般に、そのネットワークが非暗号化タイプなのか、または暗号化タイプなのかを判定し、あるいは、さらにＷＰＡ（Ｗｉ−Ｆｉ Ｐｒｏｔｅｃｔｅｄ Ａｃｃｅｓｓ）情報要素を使用して、ＷＰＡ事前共有鍵（ｐｒｅ−ｓｈａｒｅｄ ｋｅｙ）を使用した暗号化タイプなのか、またはＷＰＡを使用した暗号化タイプなのかを判定することができる。そのネットワークが非暗号化タイプの場合、ユーザは、そのネットワークが安全でないこと、およびこの情報にもかかわらずそのネットワークの使用を望んでいることのみを認識する必要がある。しかし、それが暗号化されており、ＷＰＡを使用しない場合、そのネットワークは、ＷＥＰ（Ｗｉｒｅｄ Ｅｑｕｉｖａｌｅｎｔ Ｐｒｉｖａｃｙ）鍵を入力することをユーザに要求するか、またはそのネットワークが、（接続を完了するために８０２．１ｘ認証を使用可能にすることをクライアントコンピュータに要求する）８０２．１ｘが使用可能な、ＷＥＰ鍵を自動的に配布するネットワークである。

コンピュータシステムでの無線装置の使用は有線装置の使用とは著しく異なる。例えば、無線装置のユーザは、無線装置がどのコンピュータシステムおよび／またはネットワークと通信してほしいのかを指示する必要がある。さらに、ユーザおよび／または無線装置は暗号化された通信を容易にするために秘密鍵を提供することができる。さらに、コンピュータシステムおよび／または無線装置は相互認証に没頭し、かつ／または範囲から出て再び現れる装置をさばく。

無線装置の使用に関係したセキュリティ上の多くの問題がある。例えば、無線装置のユーザが、ユーザが選択したコンピュータシステムおよび／またはネットワークに無線装置を関連づける（ａｓｓｏｃｉａｔｅ）前に、悪意のコンピュータシステムおよび／またはネットワークはその無線装置に接続することができる。さらに、従来のシステムでは、特定のコンピュータシステムおよび／またはネットワークとの無線装置のアソシエーション（ａｓｓｏｃｉａｔｉｏｎ）に過大な時間（例えば５分）がかかることがある。

本発明のいくつかの態様の基本的な理解を提供するため、以下に、本発明の単純化された概要を提示する。この概要は本発明を広範に概観するものではない。この概要は、本発明の鍵となる／決定的に重要な要素を識別することを意図したものでも、または本発明の範囲を画定することを意図したものではない。この概要の唯一の目的は、後に提示するより詳細な説明の序章として、本発明のいくつかの概念を単純化された形で提示することにある。

本発明は、信用媒体を介した非信用媒体（例えば無線）装置構成のための拡張可能なアーキテクチャを提供する。このアーキテクチャを使用して、非信用媒体（例えば無線接続）を利用する装置を関連づけることができる。アソシエーションは、信用媒体、例えば有線接続を使用して達成される。

このアーキテクチャは、非信用媒体（例えば無線接続）を介して（例えば安全に）通信するための装置の構成を容易にすることができる。装置の構成は、信用媒体（例えば有線接続）を介して交換される情報に少なくとも部分的に基づいて実施することができる。例えばこの装置は、アソシエーション要求（ａｓｓｏｃｉａｔｉｏｎ ｒｅｑｕｅｓｔ）をドライバ（ｄｒｉｖｅｒ）に送り、そのドライバからアソシエーション応答（ａｓｓｏｃｉａｔｉｏｎ ｒｅｓｐｏｎｓｅ）を受け取る。「アソシエーション要求」は、アソシエーションを開始するために装置からドライバへ送られるデータブロックを指す。「アソシエーション応答」は、（例えば成功および／または不成功の）アソシエーションを完了させるためにドライバから装置へ送られるデータブロックを指す。

アソシエーションが成功の場合、アソシエーション応答は例えば、装置が非信用媒体を介して（例えば安全に）通信することを可能にする構成情報（例えば暗号化鍵）を含むことができる。アソシエーションが不成功の場合、アソシエーション応答は例えばエラー情報を含むことができる。

本発明の一態様によれば、ドライバは、信用媒体を介して装置から受け取ったアソシエーション要求をアソシエーションマネージャ（ａｓｓｏｃｉａｔｉｏｎ ｍａｎａｇｅｒ）へ送る。ドライバはさらに、アソシエーションマネージャから受け取ったアソシエーション応答を信用媒体を介して装置に提供することができる。ドライバはあるいは、アソシエーション要求を生成し、アソシエーションマネージャに提供することができる。任意選択で、ドライバはさらに、アソシエーション要求の発行のための適当な時間を決定することができる。

本発明の他の態様では、アソシエーションマネージャがアソシエーションデータを適当なコンポーネントへ導く。アソシエーションマネージャはドライバからアソシエーション要求を受け取ることができる。アソシエーション要求の中の経路指定情報に少なくとも部分的に基づいて、アソシエーションマネージャは、このアソシエーション要求に関連づけられた情報を、処理のために特定のハンドラ（ｈａｎｄｌｅｒ）に提供することができる。この特定のハンドラがアソシエーション要求の処理を完了した後、ハンドラは、アソシエーションマネージャにアソシエーション応答を提供することができる。アソシエーションマネージャは、このアソシエーション応答を、これを要求しているドライバ（要求ドライバ）に提供することができる。

本発明の他の態様は、（おそらくは他のコンポーネント（図示せず）と一緒に）アソシエーション要求を消費するハンドラを提供し、アソシエーション応答に関連づけられた情報を生成する。ハンドラは、後により詳細に説明するように、アソシエーション要求の内容に少なくとも部分的に基づいてアクションを起こす。この１つまたは複数のアクションは例えば、そのアソシエーション要求によって確立しようとする接続のタイプによって決まる。アソシエーション要求の処理を完了した後、この特定のハンドラは、アソシエーションマネージャにアソシエーション応答を提供することができる。

このアーキテクチャは、１つまたは複数のハンドラに関連づけられた識別情報を記憶したハンドラレジストリ（ｈａｎｄｌｅｒ ｒｅｇｉｓｔｒｙ）を含むことができる。アソシエーションマネージャは、ハンドラレジストリの中に記憶された識別情報を使用して、複数のハンドラのうちのどのハンドラに特定のアソシエーション要求を提供するのかを決定することができる。

このアーキテクチャはさらに、任意選択で、１つまたは複数のドライバに関連づけられた識別情報を記憶したドライバレジストリ（ｄｒｉｖｅｒ ｒｅｇｉｓｔｒｙ）を含むことができる。アソシエーションマネージャは、ドライバレジストリの中に記憶された識別情報を使用して、例えば初期化中に、１つまたは複数のドライバのうちのどのドライバのインスタンスを生成するのかを決定することができる。

以上の目的および関係する目的を達成するため、本明細書では、本発明の例示的ないくつかの態様を、以下の説明および添付図面に関して説明する。しかしこれらの態様は、本発明の原理を使用することができる様々な方法のうちのいくつかを示すものでしかなく、本発明は、このようなすべての態様およびそれらの等価物を含む。本発明の他の利点および新規の特徴は、本発明の以下の詳細な説明を添付図面とともに検討したときに明白となろう。

次に、図面を参照して本発明を説明する。全図面を通じて同様の参照符号は同様の要素を指すために使用される。以下の説明では、説明の目的上、本発明の完全な理解を提供するために多くの具体的な詳細が記載される。しかし、これらの具体的な詳細がなくても本発明を実施できることは明白である。また、本発明の説明を容易にするために周知の構造および装置がブロック図の形態で示される。

本出願で使用されるとき、「コンポーネント」、「ハンドラ」、「モデル」、「システム」などの用語は、コンピュータに関係したエンティティ（ｅｎｔｉｔｙ）、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアを指すことを意図したものである。例えば、コンポーネントは、プロセッサ上で実行中の処理、プロセッサ、オブジェクト（ｏｂｊｅｃｔ）、実行可能物（ｅｘｅｃｕｔａｂｌｅ）、実行スレッド（ｔｈｒｅａｄ ｏｆ ｅｘｅｃｕｔｉｏｎ）、プログラムおよび／またはコンピュータであることができる。ただしこれらに限定されるわけではない。実例として、サーバ上で実行中のアプリケーションとこのサーバの両方がコンポーネントでありえる。処理および／または実行スレッド内には１つまたは複数のコンポーネントが存在することができ、１つのコンポーネントは、１つのコンピュータ上に置かれ、かつ／または２つ以上のコンピュータ間に分散されることができる。また、これらのコンポーネントは、その上に様々なデータ構造が記憶された様々なコンピュータ可読媒体から実行することができる。これらのコンポーネントは、ローカルおよび／またはリモート処理によって、例えば１つまたは複数のデータパケット（例えばローカルシステム、分散システム内の他のコンポーネントと対話しているコンポーネントからのデータ、および／またはインターネットなどのネットワーク上で信号を介して他のシステムと対話しているコンポーネントからのデータ）を有する信号に従って通信することができる。本発明によれば、コンピュータコンポーネントは、例えばＡＳＩＣ（特定用途向けＩＣ）、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタルビデオディスク）、ＲＯＭ（リードオンリーメモリ）、フロッピー（登録商標）ディスク、ハードディスク、ＥＥＰＲＯＭ（電気的に消去可能なプログラマブルＲＯＭ）およびメモリスティックを含むコンピュータ可読媒体上に記憶されることができる。ただしコンピュータ可読媒体はこれらに限定されるわけではない。

さらに、「信用媒体」は、非信用媒体を関連づけるためにそれを介してアソシエーション情報を転送することができる信用できる接続を指す。信用媒体の例には、シリアル接続、パラレル接続および／またはユニバーサルシリアルバス（ＵＳＢ）接続が含まれる。ただしこれらに限定されるわけではない。「非信用媒体」は、信用を確立するために関連づけられている媒体を指す。Ｂｌｕｅｔｏｏｔｈおよび／またはＩＥＥＥ８０２．１１などの無線接続は非信用媒体の例である。

図１を参照すると、本発明の一態様に基づくアソシエーションアーキテクチャ１００が示されている。このアーキテクチャ１００を使用して、非信用媒体（例えば無線接続）を利用する装置１１０を関連づけることができる。アソシエーションは、信用媒体、例えば有線接続を使用して達成される。

「アソシエーション要求」は、アソシエーションを開始するために装置１１０からドライバ１２０へ送られるデータブロックを指す。次いでこのアソシエーション要求をアソシエーションマネージャ１３０に転送することができ、アソシエーションマネージャ１３０は、このアソシエーション要求を適当なハンドラ１４０に転送する。「アソシエーション応答」は、（例えば成功および／または不成功の）アソシエーションを完了させるためにドライバ１２０から装置１１０へ送られるデータブロックを指す。

アーキテクチャ１００は、非信用媒体（例えば無線接続）を介して（例えば安全に）通信するための装置１１０の構成を容易にすることができる。装置１１０の構成は、信用媒体（例えば有線の接続）を介して交換される情報に少なくとも部分的に基づくことができる。一例では、装置１１０がアソシエーション要求をドライバ１２０に送り、アソシエーション応答をドライバ１２０から受け取る。アソシエーションが成功の場合、アソシエーション応答は例えば、装置１１０が非信用媒体を介して（例えば安全に）通信することを可能にする構成情報（例えば暗号化鍵）を含むことができる。アソシエーションが不成功の場合、アソシエーション応答は例えばエラー情報を含むことができる。

一例では、装置１１０が、無線が使用可能でかつＵＳＢ接続をも含むデジタルカメラである。ＵＳＢ接続（信用媒体）を使用して、このデジタルカメラの無線接続（非信用媒体）を構成することができる。例えば、「ｆｏｕｎｄ ｎｅｗ ｈａｒｄｗａｒｅ」ウィザードを使用して、アーキテクチャ１００を介してデジタルカメラへ転送するための無線プロファイルを選択し、かつ／または生成することができる。このプロファイル情報がＵＳＢ接続を介してデジタルカメラへ転送された後、ＵＳＢ接続を切断し、デジタルカメラは無線接続を介して通信することができる。

例えば、ドライバ１２０は、装置１１０から信用媒体を介して受け取ったアソシエーション要求をアソシエーションマネージャ１３０に送ることができる。ドライバ１２０はさらに、アソシエーションマネージャ１３０から受け取ったアソシエーション応答を信用媒体を介して装置１１０に提供することができる。他の例では、ドライバ１２０がアソシエーション要求を生成し、アソシエーションマネージャ１３０に提供する。任意選択で、ドライバ１２０はさらに、アソシエーション要求の発行のための適当な時間を決定することができる。

他の例では、特定のドライバ１２０を使用して、複数の非信用媒体を構成することができる。例えば、ドライバ１２０を使用して、複数の非信用媒体を介して通信する複数の装置１１０とＵＳＢ接続を介して通信することができる。

アソシエーションマネージャ１３０は適当なコンポーネントにアソシエーションデータを提供する。アソシエーションマネージャ１３０は、ドライバ１２０からアソシエーション要求を受け取ることができる。アソシエーション要求の中の経路指定情報に少なくとも部分的に基づいて、アソシエーションマネージャ１３０は、このアソシエーション要求に関連づけられた情報を、処理のために特定のハンドラ１４０に提供することができる。この特定のハンドラ１４０がアソシエーション要求の処理を完了した後、ハンドラ１４０は、アソシエーションマネージャ１３０にアソシエーション応答を提供することができる。アソシエーション応答の中の経路指定情報に少なくとも部分的に基づいて、アソシエーションマネージャ１３０は、このアソシエーション応答を要求ドライバ１２０に提供することができる。

ハンドラ１４０は、装置インストレーション（ｉｎｓｔａｌｌａｔｉｏｎ）を実現するサービス（図示せず）とインターフェースする。一例では、ハンドラ１４０が、アソシエーション要求についての明示の知識を有するアーキテクチャ１００の唯一のコンポーネントである。ハンドラ１４０は、後により詳細に説明するように、アソシエーション要求の内容に少なくとも部分的に基づいてアクションを起こす。この１つまたは複数のアクションは例えば、そのアソシエーション要求によって確立しようとする接続のタイプによって決まる。アソシエーション要求の処理を完了した後、この特定のハンドラ１４０は、アソシエーションマネージャ１３０にアソシエーション応答を提供することができる。

アーキテクチャ１００は、１つまたは複数のハンドラ１４０に関連づけられた識別情報を記憶したハンドラレジストリ１５０を含むことができる。アソシエーションマネージャ１３０は、ハンドラレジストリ１５０の中に記憶された識別情報を使用して、複数のハンドラ１４０のうちのどのハンドラに特定のアソシエーション要求を提供するのかを決定することができる。

アーキテクチャ１００はさらに、任意選択で、１つまたは複数のドライバ１２０に関連づけられた識別情報を記憶したドライバレジストリ１６０を含むことができる。アソシエーションマネージャ１３０は、ドライバレジストリ１６０の中に記憶された識別情報を使用して、例えば初期化中に、１つまたは複数のドライバ１２０のうちのどのドライバのインスタンスを生成するのかを決定することができる（後に論じる）。

単一のエンティティとして示されているが、装置１１０は、アソシエーション要求を送り、かつ／または受け取るオブジェクトと、最終的にホストに関係づけられるオブジェクト（例えば標的装置）とを含むことができることを当業者は理解されたい。

一例では、アーキテクチャ１００が、１つのアソシエーション要求および関連づけられたアソシエーション応答だけをサポートする。この例では、アソシエーションを容易にするために、装置１１０からの必要な情報がアソシエーション要求の中に埋め込まれている。同様に、アソシエーションを容易にするために、装置１１０のために必要な情報が、アソシエーション応答の中に埋め込まれている。

図２を参照すると、本発明の一態様に基づくアソシエーション要求２００が示されている。アソシエーション要求２００は、アソシエーション要求ヘッダ２１０と、１つまたは複数のアソシエーション要求属性２２０（例えば属性タイプ、長さおよびデータ）とを含む。属性は、アソシエーション要求および／または応答中の単一の項目である。例えば、アソシエーション要求ヘッダ２１０は、アソシエーション要求属性２２０に関して後に説明する属性と同様のフォーマットの、大域的に定義された一組の要求属性を含むことができる。

一例では、アソシエーション要求および／またはアソシエーション応答が、構文解析可能なストリーム（ｓｔｒｅａｍ）として編成される。このストリームは、定義されたタイプおよび関連づけられたデータをそれぞれが有する一連の属性を含む。これは、このアーキテクチャの柔軟性および拡張性を助長する。例示的な属性構造を表１に示す。

この例示的な属性構造は例えば以下のように定義することができる。

一例では、システム自体によって使用されることが意図され（例えば多くのアソシエーションタイプに共通の）、特定のアソシエーションタイプに対して固有のものではない、予め定義されたいくつかの属性タイプがある。

例示的なアソシエーションステータス値を以下に示す。

アソシエーション要求
この例では、アソシエーション要求が一連の属性である。最初の属性はＡｓｓｏｃｉａｔｉｏｎＴｙｐｅである。これは、要求を差し向けなければならないハンドラを識別するために使用される。この例では、この値が、そのハンドラ（またはハンドラに関連づけられたある仕様）によって定義されたＧＵＩＤである。例えば、Ｂｌｕｅｔｏｏｔｈ装置を関連づけるために、Ｂｌｕｅｔｏｏｔｈ専用のＧＵＩＤがあり、その特定のＧＵＩＤを処理すると指定されたハンドラがある。

アソシエーション要求の中の第２の属性はＬｅｎｇｔｈである。これは、ＡｓｓｏｃｉａｔｉｏｎＴｙｐｅおよびＬｅｎｇｔｈフィールド自体を含むこの要求の中のすべての属性の全長である。これを用いて構文解析を助け、その結果、あるコンポーネントがある特定のＡｓｓｏｃｉａｔｉｏｎＴｙｐｅに関心がない場合に、その要求の中のそれぞれの属性を構文解析しなければならないのとは対照的に、そのコンポーネントがその要求全体をスキップできる。

この例では、最小の処理で基本的なアソシエーションを実現できる単純な装置（例えばファームウェアを用いないシリコンのみのソリューションを有する装置）を容易にするために、Ｌｅｎｇｔｈのすぐ後に続く１つまたは複数の属性が慎重に定義される。これを達成するため、所望のデータを抽出するために構造内の予め決められたオフセットまで単純にジャンプすることができることは有用である。したがって、この例では、Ｌｅｎｇｔｈのすぐ後に続く属性は、基本的なアソシエーションを実施するために必要な最小量のデータを含む。さらに、これらの属性は、予め決められた順序に並べることができ、常に存在することができる。一例では、この必要なデータのほぼすべてが単一の属性に含まれる。この例では、アソシエーション要求内のオフセットに影響を及ぼさないように、可変長フィールドはすべて、これらの基本的な属性の終わりに配置される。

他の例では、それぞれが少量のデータを含むいくつかの属性が使用される。したがって、例えば拡張された機能を提供するために、後に続く属性がある場合には、任意の数の属性が後に続くことができることを理解されたい。

アソシエーション応答
図３を参照すると、本発明の一態様に基づくアソシエート応答３００が示されている。アソシエーション応答３００は、アソシエーション応答ヘッダ３１０と、０、１または複数のアソシエーション応答属性３２０とを含む。例えば、アソシエーション応答ヘッダ３１０は、アソシエーション応答属性３２０に関して後に説明する属性と同様のフォーマットの、大域的に定義された一組の要求属性を含むことができる。

アソシエーション応答属性３２０は、属性タイプ、長さおよびデータを含む１つのデータである。先に論じたアソシエーション要求と同様に、一例ではアソシエーション応答が一連の属性である。この例では、最初の属性がＡｓｓｏｃｉａｔｉｏｎＴｙｐｅである。これは、この応答をもたらすアソシエーション要求のＡｓｓｏｃｉａｔｉｏｎＴｙｐｅをエコー（ｅｃｈｏ）するために使用される。

アソシエーション応答の中の第２の属性はＬｅｎｇｔｈである。これは、ＡｓｓｏｃｉａｔｉｏｎＴｙｐｅおよびＬｅｎｇｔｈフィールド自体を含むこの要求の中のすべての属性の全長である。これを用いて構文解析を助け、その結果、あるコンポーネントがある特定のＡｓｓｏｃｉａｔｉｏｎＴｙｐｅに関心がない場合に、その要求の中のそれぞれの属性を構文解析しなければならないのとは対照的に、そのコンポーネントがその要求をスキップできる。

アソシエーション応答の第３の属性はＡｓｓｏｃｉａｔｉｏｎＳｔａｔｕｓである。これは、アソシエーション要求の結果について装置に通知するためのものである。この例では、アソシエーション処理が成功した場合にはこの値が０ｘ００００であり、これは、そのアソシエーション応答の中の属性を装置が読み続けることができることを意味する。値が０ｘｃ０００１の場合、指定されたＡｓｓｏｃｉａｔｉｏｎＴｙｐｅを処理できるハンドラをホストが見つけられなかったことを意味する。この場合、装置は、アソシエーション応答の中の他の属性について一切仮定してならない。

最小の処理で基本的なアソシエーションを実現できる単純な装置を可能にするために、先に論じたとおり、ＡｓｓｏｃｉａｔｉｏｎＳｔａｔｕｓのすぐ後に続く１つまたは複数の属性を慎重に定義することができる。この例では、これを達成するために、所望のデータを抽出するために構造内の予め決められたオフセットまで単純にジャンプすることができる必要がある。そのため、これらの属性は、基本的なアソシエーションを実施するために必要な最小量のデータを含む。この例ではさらに、これらの属性が予め決められた順序に並べられ、常に存在する。アソシエーション要求内のオフセットに影響を及ぼさないように、可変長フィールドはすべて、これらの基本的な属性の終わりに配置される。拡張された機能を提供するために、後に続く属性がある場合には、任意の数の属性が後に続くことができる。

図４を参照すると、本発明の一態様に基づくアソシエーション管理システム４００が示されている。アソシエーション管理システム４００は、マネージャ通信コンポーネント４２０およびハンドラ識別コンポーネント４３０を有するアソシエーションマネージャ４１０を含む。システム４００はさらにハンドラレジストリ１５０および任意選択のドライバレジストリ１６０を含む。

アソシエーションマネージャ４１０は、アソシエーションデータ（例えばアソシエーション要求および／またはアソシエーション応答）を適当なコンポーネント（例えばハンドラおよび／またはドライバ）に提供する役割を担う。マネージャ通信コンポーネント４２０は、ドライバ（図示せず）からアソシエーション要求を受け取ることができる。マネージャ通信コンポーネント４２０はアソシエーション要求の少なくとも一部（例えばアソシエーション要求ヘッダ）を、ハンドラ識別コンポーネント４３０に提供することができる。

マネージャ通信コンポーネント４２０によって提供される情報およびハンドラレジストリ１５０の中に記憶された識別情報に基づいて、ハンドラ識別コンポーネント４３０は、アソシエーション要求を提供する先の特定のハンドラ（図示せず）を識別する。一例では、アソシエーションマネージャ４１０は、ハンドラ識別コンポーネント４３０によって識別されたハンドラをロードする。他の例では、初期化時に１つまたは複数のハンドラがロードされる（後に詳細に論じる）。その後、マネージャ通信コンポーネント４２０は、アソシエーション要求に関連づけられた情報を、ハンドラ識別コンポーネント４３０によって識別されたハンドラに提供する。

アソシエーション要求を処理した後、ハンドラは、マネージャ通信コンポーネント４２０にアソシエーション応答を提供する。マネージャ通信コンポーネント４２０は次いでこのアソシエーション応答を要求ドライバに提供する。

一例では、アソシエーションマネージャ４１０がアソシエーション要求の妥当性を検査する。例えば、アソシエーションマネージャ４１０は適格（ｗｅｌｌ−ｆｏｒｍｅｄ）であるかどうかを判定することができる。要求が適格でない場合、アソシエーションマネージャ４１０は、このアソシエーション要求が不適格（ｍａｌｆｏｒｍｅｄ）であることを指示するアソシエーション応答（例えばＥＲＲＯＲ＿ＭＡＬＦＯＲＭＥＤ＿ＡＳＳＯＣＩＡＴＩＯＮ＿ＲＥＱＵＥＳＴにセットされたステータス属性）を生成し、このアソシエーション応答を要求ドライバに提供することができる。この例では、アソシエーション要求が適格かどうかを判定するためにアソシエーションマネージャ４１０が以下の判定基準を利用する。

ａ．要求の長さが少なくとも、ＡｓｓｏｃｉａｔｉｏｎＴｙｐｅおよびＬｅｎｇｔｈ属性を保持する大きさ（例えば３６バイト）である。
ｂ．最初の属性がＡｓｓｏｃｉａｔｉｏｎＴｙｐｅであり、その長さが（例えば特定のハンドラに関連づけられたと大域的に固有の識別子（ＧＵＩＤ）に基づいて）適当なサイズである。
ｃ．第２の属性がＬｅｎｇｔｈであり、それが適当なサイズ（例えばＵＬＯＮＧ）である。
ｄ．Ｌｅｎｇｔｈ属性の値が、ＡｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性およびＬｅｎｇｔｈ属性よりも大きく（例えば３６バイト）、その要求の長さ以下である。
ｅ．後に続くそれぞれの属性の長さが、その長さを要求の中の現在の位置に加えたときに、Ｌｅｎｇｔｈ属性の値よりも大きくならない。
ｆ．厳密に１つのＡｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性および厳密に１つのＬｅｎｇｔｈ属性が要求の中に存在する。

次にアソシエーションマネージャ４１０は、アソシエーション要求の中に含まれる指定されたアソシエーションタイプに対して登録されたハンドラ（例えばハンドラレジストリ１５０の中に記憶されたＧＵＩＤ）があるかどうかを判定する。ハンドラが見つからない場合、アソシエーションマネージャ４１０は、要求されたアソシエーションタイプがサポートされていないことを指示するアソシエーション応答を生成し、このアソシエーション応答を要求ドライバに提供することができる。

ハンドラが見つかった場合、この例では、アソシエーションマネージャ４１０がアソシエーション要求を構文解析し、属性のリストを抽出することができる。アソシエーションマネージャ４１０は次いで、抽出された属性のリストをその特定のハンドラに提供することができる。

抽出された属性のリストを特定のハンドラに提供することにアソシエーションマネージャ４１０が失敗した場合、アソシエーションマネージャ４１０は、その特定のハンドラが応答しなかったことを指示するアソシエーション応答を生成し、このアソシエーション応答を要求ドライバに提供することができる。

抽出された属性のリストを特定のハンドラに提供することにアソシエーションマネージャ４１０が成功した場合、ハンドラによる処理が完了した後に、この例ではアソシエーションマネージャ４１０がアソシエーション応答属性リストをハンドラから受け取る。アソシエーションマネージャ４１０は、アソシエーション応答属性リストが適格かどうかを判定することができる。例えば、
ａ．厳密に１つのステータス属性がある。
ｂ．（例えばアソシエーションマネージャ４１０によって加えられる）Ｌｅｎｇｔｈ属性およびＡｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性が存在しない。
ｃ．アソシエーション要求がＭａｘｉｍｕｍＲｅｓｐｏｎｓｅＬｅｎｇｔｈ属性を含んでいた場合には、これらの全属性の全体のサイズがその値よりも小さくなければならない。

応答が適格な場合、アソシエーションマネージャ４１０は、アソシエーション応答属性リストに少なくても部分的に基づいて、アソシエーション応答（例えばバイトアレイ）を生成する。例えば、アソシエーションマネージャ４１０は、
ａ．応答属性リストの中のすべての属性の全体サイズを合計し、
ｂ．ＡｓｓｏｃｉａｔｉｏｎＴｙｐｅおよびＬｅｎｇｔｈ属性のために必要なサイズを加え、
ｃ．その応答を保持するのに十分な大きさのバッファを割り当て、
ｄ．そのバッファの中の最初の属性を、そのアソシエーション要求からのＡｓｓｏｃｉａｔｉｏｎＴｙｐｅにセットし、
ｅ．計算された応答の長さを使用してＬｅｎｇｔｈ属性をバッファに加え、
ｆ．ＡｓｓｏｃｉａｔｉｏｎＳｔａｔｕｓ属性を加え、
ｇ．追加の属性をそれぞれ、それぞれが属性リストにあったときの順番で加える
ことができる。

アソシエーションマネージャ４１０は次いで、このアソシエーション応答を要求ドライバに提供することができる。

一例では、アソシエーションマネージャが以下のインターフェースを実装する。

ＳｅｎｄＡｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔ（）は、アソシエーション処理を開始するためにドライバによって呼び出される。装置に容易に送り返すことができるバイトアレイとしてアソシエーション応答が返される。一例では、ＡｓｓｏｃｉａｔｉｏｎＲｅｓｐｏｎｓｅを解放することがドライバの責務である。

図５を参照すると、本発明の一態様に基づくアソシエーション管理システム５００が示されている。システム５００は、アソシエーションマネージャ５１０、ハンドラレジストリ１５０、ドライバレジストリ１６０および初期化コンポーネント５２０を含む。

以前に論じたとおり、アソシエーションマネージャ５１０は、アソシエーションデータ（例えばアソシエーション要求および／またはアソシエーション応答）を適当なコンポーネント（例えばハンドラおよび／またはドライバ）に提供する役割を担う。しかし、この例では、初期化コンポーネント５２０が、ドライバレジストリ１６０の中に記憶された情報を使用して、例えばシステム５００の初期化中に、１つまたは複数のドライバ（図示せず）のうちのどのドライバのインスタンスを生成するのかを決定する。例えば、ドライバは、コンピュータシステム（図示せず）の構成の間に（例えば手動かつ／または自動で）登録することができる。

一例では、システム初期化中に、ドライバレジストリ１６０およびハンドラレジストリ１５０の中に記憶された情報に少なくとも部分的に基づいて、初期化コンポーネント５２０がドライバおよびハンドラを識別する。その後、初期化コンポーネント５２０は、識別されたハンドラおよび識別されたドライバのインスタンスを生成する。

この例では、ハンドラごとに、アソシエーションマネージャ５１０が、アソシエーションタイプカウント（ａｓｓｏｃｉａｔｉｏｎ ｔｙｐｅ ｃｏｕｎｔ）を取り出し、関連づけられた記憶バッファ（例えばアソシエーションタイプカウント×ｓｉｚｅｏｆ（ＧＵ１Ｄ））を割り当てることができる。このバッファを使用して、ハンドラからアソシエーションタイプを取り出すことができる。他の例では、ハンドラが記憶空間を割り当て、それをアソシエーションマネージャに提供する。

アソシエーションタイプは、ハンドラがサポートする特定のアソシエーションタイプを表すＧＵＩＤのアレイであることができる。取り出されたＧＵＩＤごとに、ハンドラレジストリの中に記憶されたＧＵＩＤ−ハンドラマッピングのリストにエントリ（ｅｎｔｒｙ）を加えることができる。例えば、

次いでマッピングのこのリストはアソシエーションマネージャ５１０によって使用されて、適当なハンドラへのアソシエーション要求の経路指定を決定することができる。

この例では、ハンドラが生成され、それらのアソシエーションタイプが分かった後に、初期化コンポーネント５２０がドライバを活動化する。ハンドラが見つかりロードされるまでアソシエーション要求が受け取られないことを保証するため、活動化は、ハンドラがロードされ、初期化された後に実施される。例えば、ドライバを活動化するために、「Ｓｔａｒｔ（）」メソッドを呼び出すことができる。

次に図６を参照すると、本発明の一態様に基づくアソシエーションハンドラシステム６００が示されている。システム６００は、要求コンポーネント６２０、応答コンポーネント６３０およびアソシエーションプロセッサを備えたハンドラ６１０を含む。

ハンドラ６１０は（おそらく他のコンポーネント（図示せず）とともに）、アソシエーション要求を消費し、アソシエーション応答に関連づけられた情報を生成する。

例えば、要求コンポーネント６２０は、アソシエーション要求に関連づけられた情報（例えばアソシエーション要求および／または構文解析された属性のリスト）をアソシエーションマネージャ（図示せず）から受け取ることができる。要求コンポーネント６２０は、アソシエーション要求に関連づけられた情報の内容を構文解析して、どんなアクションを起こすのかを決定することができる。アソシエーションプロセッサ６４０は、サービス６５０を介してアクションを容易にする。この１つまたは複数のアクションは例えば、確立しようとする接続のタイプによって決まる。アクションが完了した後、アソシエーションプロセッサ６４０は、このアソシエーションに関する情報を応答コンポーネント６３０に提供することができる。応答コンポーネント６３０は次いで、アソシエーション応答に関連づけられた情報（例えばアソシエーション応答および／または属性のリスト）を生成することができ、この情報を、アソシエーションマネージャに提供することができる。

一例では、複数のハンドラ６１０は、以下のＣＯＭインターフェースを実装する。

この例では、「ｍａｎａｇｅｒ」が、アソシエーションマネージャを指すインターフェースポインタである。また、「ＡｓｓｏｃｉａｔｉｏｎＴｙｐｅｓ」は、ＰＯＮＧハンドラが処理することができるＡｓｓｏｃｉａｔｉｏｎＴｙｐｅ ＧＵＩＤのアレイを返す。同様に、「ＡｓｓｏｃｉａｔｉｏｎＴｙｐｅＣｏｕｎｔ」は、ＰＯＮＧハンドラが処理することができるＡｓｓｏｃｉａｔｉｏｎＴｙｐｅｓの数である。「ＨａｎｄｌｅＡｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔ（）」は、その要求をサポートしているとハンドラ６１０が報告したアソシエーション要求を受け取るときにアソシエーションマネージャによって呼び出される。「ＲｅｑｕｅｓｔＡｔｔｒｉｂｕｔｅｓ」は属性構造のリストである。ハンドラ６１０は、装置（図示せず）に返される属性である属性構造のリストＲｅｓｐｏｎｓｅＡｔｔｒｉｂｕｔｅｓを返すのに必要なメモリを割り当てると予想される。

他の例では、ハンドラ６１０が、標的媒体上で装置が発見された後に装置についての情報を、将来のインストレーションのために例えばデータベースに記憶する。例えば、特定のハンドラ６１０を、Ｗｉ−Ｆｉ標的媒体に関係づけることができる。この例では、Ｗｉ−Ｆｉ標的媒体を使用したい装置が、アソシエーション要求を送り、属性リストの形態のアソシエーション応答を受け取る。属性リストは、ハンドラ６１０によってアソシエーションマネージャに提供することができ、アソシエーションマネージャは次いでアソシエーション応答を形成することができる。

下表９、１０および１１に関して、「属性」は、属性要素に関連づけられた親しみやすい名称を指す。「属性ＩＤ」は、属性リストの中の属性要素を識別するために使用される識別子（例えば番号）である。「長さ」は、属性要素の中のデータの長さを指す。属性の長さは可変および／または固定であることができ、この例では属性の長さがバイトで表される。長さの値は最大長を指定することもできる。アソシエーション応答では、一例において、その値までのオフセットが決定的となり、応答を構文解析する装置の能力に役立つように、固定長を使用することができる。属性の実際の値が、そのデータに割り当てられた長さ全体を使い切ならにことがある。このようなケースでは、追加のフィールドが、属性データの実際の長さを指定することができる。「許容値」は、装置によってサポートされる値を記述する許容値フィールドを指す。許容値が必要な場合、それが属性リストに含まれる場合に装置がその値をサポートしていなければならないことを意味する。表９、１０および／または１１に明記されていない限り、値は必要であると考えなければならない。許容値が任意選択である場合、装置はその値をサポートする必要はないが、属性リストにそれが含まれることに対して準備がされていなければならない。この仕様の将来のバージョンでは任意選択の値が必要となる可能性がある。

無線プロトコル
ＩＥＥＥ８０２．１１規格セットは、暗号化ネットワーク（例えばＷＥＰネットワーク）と非暗号化ネットワークの２つのネットワークタイプを定義する。ＷＥＰプロトコルの周知の弱点のため、無線業界は、ＷＥＰプロトコルの主要な欠陥に対処するための機構として、ＩＥＥＥ８０２．１ｘ規格に対するサポートを実装した。ユーザ認証、暗号化鍵管理および暗号化鍵配布である。ＷＥＰ暗号化ネットワークではユーザが暗号化鍵を提供する必要があり、８０２．１ｘ使用可能ネットワークでは、ユーザが有効な信用証明書（例えばデジタル証明書またはユーザ名およびパスワードなど）を有する場合には、暗号化鍵が自動的に提供される。暗号化された８０２．１１ネットワークでは、現在のところ、ユーザがＷＥＰ鍵を入力する必要があるのか、またはネットワークが８０２．１ｘをサポートしており、ＷＥＰ鍵を入力する必要がないのかを即座に判定することができないので、これが、ユーザビリティ（ｕｓａｂｉｌｉｔｙ）の問題を提示する。

暗号的に弱いことが示されているＷＥＰアルゴリズムの根底にあるこの弱点に対処するため、ＷＰＡ（Ｗｉ−Ｆｉ Ｐｒｏｔｅｃｔｅｄ Ａｃｃｅｓｓ）と呼ばれる８０２．１１規格セットに対するセキュリティ上の強化が導入された。ＷＰＡはさらに、ＷＰＡが可能なアクセスポイントがそれらのビーコンフレームの中に含む情報要素を指定することによって、本来の８０２．１１規格のユーザビリティ問題のいくつかに対処する。この情報要素はとりわけ、ユーザが暗号化鍵を入力することをネットワークが要求する（ＷＰＡ事前共有鍵モード（ＷＰＡ−ＰＳＫ）と呼ばれる）のか、またはユーザの信用証明書によって暗号化鍵が自動的に提供される（「ＷＰＡモード」と呼ばれる）のかを記述する。

ＷＥＰ（Ｗｉｒｅｄ Ｅｑｕｉｖａｌｅｎｔ Ｐｒｉｖａｃｙ）
ＷＥＰは、ＩＥＥＥ８０２．１１規格によって定義され、有線ネットワークと同等のデータ機密性レベルを提供することを意図したものである。無線ＬＡＮネットワークの持つ性質のため、このネットワークへの物理アクセスを監視するセキュリティインフラストラクチャを実装することは難しい。物理接続が必要な有線ネットワークとは異なり、無線アクセスポイント（ＡＰ）の範囲に入れば誰でもおそらくフレームを送受信することができ、送信中の他のフレームを盗み見ることができる。これは、無線ＬＡＮフレームの盗聴および遠隔検出を非常に容易にする。

ＷＥＰは、無線ノード間で送られるデータを暗号化することによってデータ機密性サービスを提供する。８０２．１１フレームに対するＷＥＰ暗号化は、８０２．１１フレームのＭＡＣヘッダの中のＷＥＰフラグをセットすることによって指示される。ＷＥＰは、無線フレームの暗号化された部分の中に完全性チェック値（ｉｎｔｅｇｒｉｔｙ ｃｈｅｃｋ ｖａｌｕｅ：ＩＣＶ）を含めることによって、ランダム誤差に対するデータ完全性を提供する。

以下の表はＷＥＰが定義する２つの共有鍵を示す。

ＷＥＰ暗号化は、４０ビットおよび１０４ビット暗号化鍵を用いたＲＣ４対称ストリーム暗号を使用する。

ＷＰＡ（Ｗｉ−Ｆｉ Ｐｒｏｔｅｃｔｅｄ Ａｃｃｅｓｓ）
ＷＰＡは、ＷＥＰのセキュリティ機能を上回るように設計されたＷｉ−Ｆｉ規格である。ＷＥＰとは異なり、ＷＰＡでは８０２．１ｘ認証が必要となる。ＷＰＡでは、ユニキャスト暗号化鍵とグローバル暗号化鍵の両方のリキーイング（ｒｅｋｅｙｉｎｇ）が必要である。ユニキャスト暗号化鍵では、ＴＫＩＰ（Ｔｅｍｐｏｒａｌ Ｋｅｙ Ｉｎｔｅｇｒｉｔｙ Ｐｒｏｔｏｃｏｌ）がフレームごとに鍵を変更し、この変更は、無線クライアントと無線アクセスポイント（ＡＰ）の間で同期される。グローバル暗号化鍵では、無線ＡＰが、接続された無線クライアントに変更された鍵を知らせる機能を、ＷＰＡが含む。

ＴＫＩＰは、ＷＥＰを、ＷＥＰアルゴリズムよりも強い暗号化アルゴリズムに置き換える。ＴＫＩＰはさらに、暗号化鍵が決定された後のセキュリティ構成の検証、それぞれのフレームのユニキャスト暗号化鍵の同期された変更、およびそれぞれの事前共用鍵認証のための一意の出発ユニキャスト暗号化鍵の決定を提供する。

ＷＰＡはさらに、８バイトのメッセージ完全性コード（ｍｅｓｓａｇｅ ｉｎｔｅｇｒｉｔｙ ｃｏｄｅ：ＭＩＣ）を計算するアルゴリズムを指定する「Ｍｉｃｈａｅｌ」として知られる方法を使用する。ＭＩＣは、ＩＥＥＥ８０２．１１フレームのデータ部分と４バイトの完全性チェック値（ＩＣＶ）の間に置かれる。ＭＩＣフィールドは、フレームデータおよびＩＣＶとともに暗号化される。

ＷＰＡは、その完成時にはＩＥＥＥ８０２．１１ｉ規格に置き換えられる暫定的な規格である。

Ｗｉ−Ｆｉハンドラ
アソシエーションタイプは、アソシエーション要求およびアソシエーション応答のヘッダセクションの中に含まれる属性であり、データ属性からは分離されている。この属性は、アソシエーション要求を適切なハンドラに転送するためにアソシエーションマネージャによって使用される。この例では、Ｗｉ−Ｆｉハンドラ４１０が以下の必要なアソシエーションタイプを有する。

アソシエーション要求のデータセクションは、その属性タイプに固有の属性を含む。以下の表は、アソシエーションマネージャがＷｉ−Ｆｉハンドラ６１０に転送することができる例示的な属性を識別する。

ＭＡＣアドレス
ＭＡＣアドレスは、ＭＡＣアドレスの４８ビット値を含む６バイト値である。例えば、０ｘ００ ０ｘ０７ ０ｘＥ９ ０ｘ４Ｃ ０ｘＡ８ ０ｘ１Ｃ。

ネットワーク認証タイプフラグ
このフラグセットは、どの「ネットワーク認証タイプ」タイプがサポートされているのを装置が知らせることを可能にする。この情報は診断目的に使用することができる。装置が必要な属性をサポートしていない場合、このことをユーザに通知し、この問題を除くための使用可能な指示をユーザに与えることができる。この例では、このフィールドの値が、以下の１つまたは複数の値のビットごとのＯＲである。
０ｘ０００１＝Ｏｐｅｎ
０ｘ０００２＝ＷＰＡＰＳＫ
０ｘ０００４＝Ｓｈａｒｅｄ
０ｘ０００８＝ＷＰＡ
０ｘ００１０＝ＷＰＡ−ＮＯＮＥ
０ｘ００２０＝ＷＰＡ２
この例では他の値は予備であり、０にセットされる。

データ暗号化タイプフラグ
このフラグセットは、どの「データ暗号化タイプ」タイプがサポートされているのかを装置が知らせることを可能にする。この情報は診断目的に使用することができる。装置が必要な属性をサポートしていない場合、このことをユーザに通知し、この問題を除くための使用可能な指示をユーザに与えることができる。この例では、このフィールドの値が、以下の１つまたは複数の値のビットごとのＯＲである。
０ｘ０００１＝ＷＥＰ
０ｘ０００２＝ＴＫＩＰ
０ｘ０００４＝ＡＥＳ
この例でも他の値は予備であり、０にセットされる。

接続タイプフラグ
このフラグセットは、どの「接続タイプ」タイプがサポートされているのかを装置が知らせることを可能にする。この情報は診断目的に使用される。装置が必要な属性をサポートしていない場合、このことをユーザに通知し、この問題を除くための使用可能な指示をユーザに与えることができる。このフィールドの値は、以下の１つまたは複数の値のビットごとのＯＲである。
０ｘ０１＝ＥＳＳ（Ｅｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｓｅｔ）
０ｘ０２＝ＩＢＳＳ（Ｉｎｄｅｐｅｎｄｅｎｔ Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）
この例では他の値は予備であり、０にセットされる。

ハンドラ６１０とサービス６５０の対話に少なくとも部分的に基づいて、応答コンポーネント６３０は、アソシエーション応答に関連づけられた情報を生成する。Ｗｉ−Ｆｉハンドラの例を続けると、表１１は、例示的なアソシエーション応答属性を識別する。この例の属性リストの中の属性の長さは固定である。したがって、装置製品は、適当なオフセットまで容易にジャンプして、応答の中の与えられた任意の属性の値を読むことができる。オフセットは属性の先頭を指す。

ＳＳＩＤ
以前に論じたとおり、ＳＳＩＤは、ブロードキャスト無線ネットワークで使用される文字列である。

ネットワーク鍵
ネットワーク鍵はネットワークを安全にするために使用される文字列である。この例では、ネットワーク鍵の許容値に対する制約条件として以下の属性が置かれる。装置は、以下の構成を受け入れまたは拒絶する準備がされていなければならない。

ＷＥＰ鍵
データ認証タイプがＷＥＰのとき、ネットワーク鍵は、４０ビットまたは１０４ビットＷＥＰ鍵のＡＳＣＩＩまたはＨＥＸ表現である。このタイプは、文字列の長さによって決定することができる。

ＷＰＡＰＳＫパスフレーズ
ネットワーク鍵属性が０〜６３文字のＡＳＣＩＩ文字列であり、「ネットワーク認証タイプ」属性がＷＰＡである場合、ネットワーク鍵属性は、ＷＰＡ２進鍵を得るパスフレーズ（ｐａｓｓ ｐｈｒａｓｅ）として使用される。

Ｋｅｙ Ｐｒｏｖｉｄｅｄ Ａｕｔｏｍａｔｉｃａｌｌｙ（８０２．１ｘ）
「Ｋｅｙ Ｐｒｏｖｉｄｅｄ Ａｕｔｏｍａｔｉｃａｌｌｙ（８０２．１ｘ）」属性は、ネットワーク鍵が８０１．ｘによって提供されるか否かを指図する。無線ネットワークを安全にするためにＷＰＡ−ＰＳＫまたはＷＥＰが使用される場合、これは一般に０にセットされる。

ネットワーク認証タイプ
ネットワーク認証タイプは、特定のネットワークに加わるためにどのタイプのセキュリティ機構が必要かを指示する。このフラグセットは、以下のどの機構が使用されるのかを指定する。
０ｘ０００１＝Ｏｐｅｎ
０ｘ０００２＝ＷＰＡＰＳＫ
０ｘ０００４＝Ｓｈａｒｅｄ
０ｘ０００８＝ＷＰＡ
０ｘ００１０＝ＷＰＡ−ＮＯＮＥ
０ｘ００２０＝ＷＰＡ２
この例では他の値が予備であり、０にセットされる。重要には、アソシエーション要求とは異なり、これらのフラグは相互排除であり、一度に１つのフラグしかセットすることができない。

データ暗号化タイプ
この値は、その無線ネットワークによって使用される暗号化機構を指定する。

このフラグセットは、以下のどの機構が使用されるのかを指定する。

０ｘ０００１＝ＷＥＰ
０ｘ０００２＝ＴＫＩＰ
０ｘ０００４＝ＡＥＳ
他の値はすべて予備であり、０にセットされる。重要には、アソシエーション要求とは異なり、これらのフラグは相互排除であり、一度に１つのフラグしかセットすることができない。

接続タイプ
接続タイプは無線ネットワークのタイプを定義する。このフラグセットは以下のどの機構が使用されるのかを指定する。
０ｘ０１＝ＥＳＳ
０ｘ０２＝ＩＢＳＳ
他の値はすべて予備であり、０にセットされる。これらのフラグは相互排除である。

次に図７を参照すると、本発明の一態様に基づくアソシエーションドライバシステム７００が示されている。システム７００は、信用媒体通信コンポーネント７２０およびドライバ通信コンポーネント７３０を備えたドライバ７１０を含む。

信用媒体通信コンポーネント７２０は、信用媒体（例えばＵＳＢ接続）を介して装置７４０とインターフェースする。一例では、信用媒体通信コンポーネント７２０が、装置７４０からアソシエーション要求（例えば装置列挙（ｅｎｕｍｅｒａｔｉｏｎ）の時刻とは独立に開始されたアソシエーション要求）を受け取る。他の例では、信用媒体通信コンポーネント７２０が、アソシエーション要求の発行を要求する通知を受け取る。その後、ドライバ７１０は、ドライバ通信コンポーネント７３０を介してアソシエーションマネージャ（図示せず）に送られるアソシエーション要求を生成する。

一例では、ドライバ７１０が以下のインターフェースを実装する。

「Ｍａｎａｇｅｒ」は、アソシエーションマネージャを指すインターフェースポインタであり、それによってドライバはＳｅｎｄＡｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔを呼び出すことができる。Ｓｔａｒｔ（）は、新しいアソシエーション要求の検出および発行をドライバに開始させたいときにアソシエーションマネージャによって呼び出される。Ｓｔｏｐ（）は、新しいアソシエーション要求の発行をドライバに停止させたいとき（例えば、ユーザが、特定の信用媒体上でのアソシエーションを無効にしたいとき）に、アソシエーションマネージャによって呼び出される。

一例では、特定のドライバ７１０をＵＳＢ信用媒体に関係づけることができる。この例では、非信用媒体を使用したい装置が、ドライバ７１０を通して安全にアソシエーション要求を送り、アソシエーション応答を受け取る。

装置の列挙とは独立にアソシエーション要求を生成することができる、動的アソシエーション機能を実装した装置に関しては、一例において、任意選択の割込みＩＮエンドポイント（ｅｎｄｐｏｉｎｔ）がある。このエンドポイントは、新しいアソシエーション要求の通知を容易にする。この任意選択のエンドポイントに対する標準エンドポイント記述子が表１４に示されている。

装置のインターフェースがこの任意選択のエンドポイントを含まない場合、アソシエーションは列挙時にしか実施されない。そのような装置がアソシエーション処理を開始したい場合には、装置によって開始されるＵＳＢリセットを実施しなければならない。これによって、装置はホストによって再列挙され、そのポイントで、ホストは、装置からアソシエーション要求を取り出す。他の例では、装置がさらに、装置の希望に応じてアソシエーション機能を呼び出すＨＵＢ機能を実装することができる。

この制御エンドポイントは、アソシエーションインターフェースをサポートする装置の唯一の必須のエンドポイントなので、必要なデータ転送はそのエンドポイントで実施される。この例では、これらの転送がアソシエーションクラス要求の形態をとる。

表１５に、一例では装置によってサポートされなければならないアソシエーションクラス要求のリストを示す。

ＧＥＴ＿ＡＳＳＯＣＩＡＴＩＯＮ＿ＩＮＦＯＲＭＡＴＩＯＮ
この要求はアソシエーション情報構造を装置から取り出す。アソシエーション情報は、ＲＥＱＵＥＳＴ＿ＩＮＦＯブロックのリストを含む。それぞれのＲＥＱＵＥＳＴ＿ＩＮＦＯブロックは、装置が発行したい単一のアソシエーション要求に関する。

表１７は、例示的なＡＳＳＯＣＩＡＴＩＯＮ＿ＩＮＦＯＲＭＡＴＩＯＮ構造を示す。

表１８は、例示的なアソシエーション情報フラグ情報を提供する。

表１９は、例示的なＲＥＱＵＥＳＴ＿ＩＮＦＯ構造を示す。

ＧＥＴ＿ＡＳＳＯＣＩＡＴＩＯＮ＿ＲＥＱＵＥＳＴ
この要求は、特定のアソシエーション要求を装置から取り出す。この要求は、ｗＶａｌｕｅフィールド内のＲｅｑｕｅｓｔＩＤ値によって識別される。

この例では、要求ブロックが４ＫＢデータブロックである。制御転送の最大転送サイズは６４ＫＢであり、そのため理論的には、ＧＥＴ＿ＡＳＳＯＣＩＡＴＩＯＮ＿ＲＥＱＵＥＳＴごとに１６個の要求ブロックを転送することができる。転送される実際のデータ量はｗＬｅｎｇｔｈフィールドによって指定される。ｗＶａｌｕｅフィールド内に指定されたＢｌｏｃｋＮｕｍｂｅｒは、この制御転送の出発ブロック番号を識別する。そのためこの例では、装置５４０が、オフセットＢｌｏｃｋＮｕｍｂｅｒ×４ＫＢから始まるＲｅｑｕｅｓｔＩＤによって指定され、ｗＬｅｎｇｔｈバイトを転送する、その要求のアソシエーション要求データを返さなければならない。

ＳＥＴ＿ＡＳＳＯＣＩＡＴＩＯＮ＿ＲＥＳＰＯＮＳＥ
この要求は、ｗＶａｌｕｅフィールド内のＲｅｑｕｅｓｔＩＤ値によって識別される特定のアソシエーション要求に対する応答を送る。

この例では、ＴｒａｎｓｆｅｒＦｌａｇｓ値が、表２２に示された０以上の値のビットごとのＯＲである。

アソシエーション割込みＩＮメッセージ
ＮｅｗＡｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔ
この割込みＩＮメッセージは、処理する必要がある新しいまたは変更されたアソシエーション要求を装置が有することをホストに指示する。このメッセージを受け取ると、ホストは、ＧＥＴ＿ＡＳＳＯＣＩＡＴＩＯＮ＿ＩＮＦＯＲＭＡＴＩＯＮ要求を発行し、それに応じてこれらのアソシエーション要求を処理することができる。

システム１００、装置１１０、アソシエーションマネージャ１２０、ハンドラ１３０、ドライバ１４０、ハンドラレジストリ１５０、ドライバレジストリ１６０、システム４００、アソシエーションマネージャ４１０、マネージャ通信コンポーネント４２０、ハンドラ識別コンポーネント４３０、アソシエーションマネージャ５１０、初期化コンポーネント５２０、システム６００、ハンドラ６１０、要求コンポーネント６２０、応答コンポーネント６３０、アソシエーションプロセッサ６４０、サービス６５０、システム７００、ドライバ７１０、信用媒体通信コンポーネント７２０、ドライバ通信コンポーネント７３０および／または装置７４０は、その用語が本明細書に定義されたコンピュータコンポーネントであることができることを理解されたい。

図８〜１８を簡単に参照すると、本発明に従って実施することができる方法が示されている。説明を簡単にするためにこれらの方法は一連のブロックとして示され記述されるが、本発明によれば、いくつかのブロックは、本明細書に示され記述されるものとは異なる順序で実施し、かつ／または他のブロックと同時に実施することができるので、本発明は、ブロックの順序によって限定されないことを理解されたい。また、本発明に基づく方法を実施するのに、示されたすべてのブロックが必要となるわけではない。

本発明は、１つまたは複数のコンポーネントによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で記述することができる。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、データ構造などを含む。一般に、プログラムモジュールの機能は、様々な実施形態において希望に応じて組み合わせまたは分散させることができる。

図８を参照すると、装置を関連づける本発明の一態様に基づく方法８００が示されている。８１０で、信用媒体（例えばＵＳＢ）を介して（例えば装置の）接続が確立される。８２０で、例えば装置および／または関連づけられたドライバによってアソシエーション要求が発行される。８３０で、アソシエーション応答に関連づけられた情報が（例えばドライバから）受け取られる。この情報は例えば、アソシエーションマネージャから受け取られたアソシエーション応答を含むことができる。この情報はあるいは、アソシエーションマネージャから受け取られたアソシエーション応答の一部を含むことができる。

８４０で、アソシエーションが成功だったかどうかに関する判定が実施される。８４０での判定がＮＯの場合、それ以上の処理は実施されない。８４０での判定がＹＥＳの場合には、８５０で、このアソシエーション応答に関連づけられた情報が使用されて、非信用媒体（例えば無線接続）を介して（例えば装置を）接続する。

次に図９を参照すると、装置のアソシエーションを容易にする本発明の一態様に基づく方法９００が示されている。９１０で、アソシエーション要求に関連づけられた情報が受け取られる。９２０で、アソシエーション要求が受け取られたかどうかに関する判定が実施される。９２０での判定がＮＯの場合には、９３０で、アソシエーション要求が生成され、処理は９４０に続く。９２０での判定がＹＥＳの場合には、９４０で、受け取られたアソシエーション要求が例えばアソシエーションマネージャへ送られる。

９５０で、例えばアソシエーションマネージャからアソシエーション応答が受け取られる。９６０で、アソシエーション応答に関連づけられた情報が要求装置に提供される。例えば、この情報は、アソシエーション応答の全体および／またはアソシエーション応答の部分を含むことができる。その後、これ以上の処理は実施されない。

次に図１０〜１２を参照すると、ＵＳＢ接続１０００を介して装置を関連づける本発明の一態様に基づく方法が示されている。１００４で、装置が列挙され、かつ／または新しいアソシエーション要求事象が発行される。１００８で、ＧＥＴ＿ＡＳＳＯＣＩＡＴＩＯＮ＿ＩＮＦＯＲＭＡＴＩＯＮ要求が例えばドライバによって装置に送られる。１０１２で、アソシエーション情報全体のサイズが例えばドライバによって決定される（例えばサイズ＝３＋ｓｉｚｅｏｆ（ＲＥＱＵＥＳＴ＿ＩＮＦＯ）×ＰｅｎｄｉｎｇＲｅｑｕｅｓｔＣｏｕｎｔ）。

１０１６で、実質的にすべてのアソシエーション情報が例えばドライバによって受け取られたかどうかに関する判定が実施される。１０１６での判定がＮＯの場合、処理は１００８に続く。１０１６での判定がＹＥＳの場合には、１０２０で、ＰｅｎｄｉｎｇＲｅｑｕｅｓｔＣｏｕｎｔが０よりも大きいかどうかに関する決定が実施される。１０２０での判定がＮＯの場合、それ以上の処理は実施されない。

１０２０での判定がＹＥＳの場合には、１０２４で、（例えばドライバによって）処理する要求が識別される。１０２８で、転送（例えばアソシエーション要求）のサイズが決定される。１０３２で、ＧＥＴ＿ＡＳＳＯＣＩＡＴＩＯＮ＿ＲＥＱＵＥＳＴが送られる。１０３６で、他に要求データがあるかどうかに関する判定が実施される。１０３６での判定がＹＥＳの場合、処理は１０２８に続く。１０３６での判定がＮＯの場合には、１０４０で、要求されたアソシエーションが処理され、（例えばアソシエーションマネージャおよび／またはハンドラによって）アソシエーション応答が生成される。

１０４０で、アソシエーション応答転送のサイズが決定される。１０４８で、ＳＥＴ＿ＡＳＳＯＣＩＡＴＩＯＮ＿ＲＥＳＰＯＮＳＥが送られる。１０５２で、他に応答データがあるかどうかに関する判定が実施される。１０５２での判定がＹＥＳの場合、処理は１０４４に続く。１０５２での判定がＮＯの場合には、１０５６で、他に要求があるかどうかに関する決定が実施される。

１０５６での判定がＹＥＳの場合、処理は１０２４に続く。１０５６での判定がＮＯの場合には、１０６０で、追加の要求フラグがアソシエーション情報の中に送られているかどうかに関する決定が実施される。１０６０での判定がＹＥＳの場合、処理は１００８に続く。１０６０での判定がＮＯの場合、それ以上の処理は実施されない。

次に図１３を参照すると、本発明の一態様に基づくアソシエーション管理方法１３００が示されている。１３１０で、アソシエーション要求が例えばドライバから受け取られる。１３２０で、そのアソシエーション要求に対するハンドラが識別される。１３４０で、そのアソシエーション要求に対するハンドラが存在するかどうかに関する判定が実施される。１３４０での判定がＮＯの場合には、１３５０で、アソシエーション応答の失敗が生成され、処理は１３６０に続く。

１３４０での判定がＹＥＳの場合には、１３７０で、アソシエーション要求に関連づけられた情報がハンドラに送られる。例えば、この情報は、アソシエーション要求および／またはアソシエーション要求の一部（例えば属性リスト）を含むことができる。

１３８０で、アソシエーション応答に関連づけられた情報がハンドラから受け取られる。１３６０で、アソシエーション応答が要求ドライバに提供される。

図１４〜１６を参照すると、本発明の一態様に基づくアソシエーション管理方法１４００が示されている。１４０４で、アソシエーション要求が例えばドライバから受け取られる。１４０８で、このアソシエーション要求の妥当性が検査される。１４１２で、アソシエーション要求が適格かどうかに関する判定が実施される。１４１２での判定がＮＯの場合には、１４１６で、不適格なアソシエーション要求を指示するアソシエーション応答が生成され、処理は１４２０に続く。

１４１２での判定がＹＥＳの場合には、１４２４で、アソシエーション要求に対するハンドラが見つけられる。１４２８で、ハンドラが見つかったかどうかに関する判定が実施される。１４２８での判定がＮＯの場合には、１４３２で、サポートされていないアソシエーションタイプを指示するアソシエーション応答が生成され、処理は１４２０に続く。

１４２８での判定がＹＥＳの場合には、１４３６で、アソシエーション要求が構文解析され、属性のリストが構築される。１４４０で、識別されたハンドラにこの属性リストが送られる。１４４４で、応答情報がハンドラから受け取られる。１４４８で、アソシエーションが成功だったかどうかに関する判定が実施される。１４４８での判定がＮＯの場合には、１４５２で、適当なエラーステータスを指示するアソシエーション応答が生成され、処理は１４２０に続く。

１４４８での判定がＹＥＳの場合には、１４５６で、応答フォーマットの妥当性が検査される。１４６０で、応答が適格かどうかに関する判定が実施される。１４６０での判定がＮＯの場合には、１４６４で、適当なエラーステータスを指示するアソシエーション応答が生成され、処理は１４２０に続く。

１４６０での判定がＹＥＳの場合には、１４６８で、ハンドラからの応答に基づいてアソシエーション応答が生成される。１４２０で、このアソシエーション応答が要求ドライバに提供され、それ以上の処理は実施されない。

図１７を参照すると、本発明の一態様に基づくアソシエーションハンドラ方法１７００が示されている。１７１０で、アソシエーション要求に関連づけられた情報（例えば属性リスト）が例えばアソシエーションマネージャから受け取られる。１７２０で、アソシエーション要求が処理される。１７３０で、アソシエーションマネージャに応答情報が提供される。

本発明の様々な態様に追加の文脈を提供するため、図１８および以下の議論は、本発明の様々な態様を実現することができる適当な動作環境１８１０の簡単な概説を提供することを意図したものである。本発明は、１つまたは複数のコンピュータまたは他の装置によって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で記述されるが、本発明は、他のプログラムモジュールと組み合わせて、かつ／またはハードウェアとソフトウェアの組合せとして、実現することもできることを当業者は理解されたい。しかし一般に、プログラムモジュールは、特定のタスクを実行し、または特定のデータ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。動作環境１８１０は、適当な動作環境の一例にすぎず、本発明の使用範囲または本発明の機能の範囲に関する制限を示唆することを意図したものではない。本発明とともに使用するのに適している可能性がある他の周知のコンピュータシステム、環境および／または構成には、パーソナルコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースシステム、プログラマブル家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置を含む分散コンピューティング環境などが含まれる。ただしこれらに限定されるわけではない。

図１８を参照すると、本発明の様々な態様を実現するための例示的な環境１８１０はコンピュータ１８１２を含む。コンピュータ１８１２は、処理ユニット１８１４、システムメモリ１８１６およびシステムバス１８１８を含む。システムバス１８１８は、システムメモリ１８１６を含むシステムコンポーネントを処理ユニット１８１４に結合する。処理ユニット１８１４は、使用可能な様々なプロセッサのうちの任意のプロセッサとすることができる。デュアルマイクロプロセッサおよび他のマルチプロセッサーアーキテクチャを処理ユニット１８１４として使用することもできる。

システムバス１８１８は、例えば８ビットバス、ＩＳＡ（Ｉｎｄｕｓｔｒｉａｌ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＭＳＡ（Ｍｉｃｒｏ−Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＥＩＳＡ（Ｅｘｔｅｎｄｅｄ ＩＳＡ）、ＩＤＥ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｄｒｉｖｅ Ｅｌｅｃｔｒｏｎｉｃｓ）、ＶＬＢ（ＶＥＳＡ Ｌｏｃａｌ Ｂｕｓ）、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｅａｌ Ｂｕｓ）、ＡＧＰ（Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）、ＰＣＭＣＩＡ（Personal Computer Memory Card International Association bus）およびＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ）を含む使用可能な様々なバスアーキテクチャを使用した、メモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／あるいはローカルバスを含む、いくつかのバス構造タイプのうちの任意のバス構造とすることができる。

システムメモリ１８１６は、揮発性メモリ１８２０および不揮発性メモリ１８２２を含む。不揮発性メモリ１８２２には、例えば起動中にコンピュータ１８１２内の要素間で情報を転送するための基本ルーチンを含む基本入出力システム（ＢＩＯＳ）が記憶されている。不揮発性メモリ１８２２は例えば、リードオンリーメモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、電気的にプログラム可能なＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能なＲＯＭ（ＥＥＰＲＯＭ）、またはフラッシュメモリを含む。ただしこれらに限定されるわけではない。揮発性メモリ１８２０は、外部キャッシュメモリの働きをするランダムアクセスメモリ（ＲＡＭ）を含む。ＲＡＭは例えば、ＳＲＡＭ（ｓｙｎｃｈｒｏｎｏｕｓ ＲＡＭ）、ＤＲＡＭ（ｄｙｎａｍｉｃ ＲＡＭ）、ＳＤＲＡＭ（ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ）、ＤＤＲ ＳＤＲＡＭ（ｄｏｕｂｌｅ ｄａｔａ ｒａｔｅ ＳＤＲＡＭ）、ＥＳＤＲＡＭ（ｅｎｈａｎｃｅｄ ＳＤＲＡＭ）、ＳＬＤＲＡＭ（Ｓｙｎｃｈｌｉｎｋ ＤＲＡＭ）、ＤＲＲＡＭ（ｄｉｒｅｃｔ Ｒａｍｂｕｓ ＲＡＭ）などの多くの形態で使用可能である。ただしこれらに限定されるわけではない。

コンピュータ１８１２はさらに、取り外し可能／取り外し不能な揮発性／不揮発性コンピュータ記憶媒体を含む。図１８には例えばディスク記憶装置１８２４が示されている。ディスク記憶装置１８２４は、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、メモリスティックのような装置を含む。ただしこれらに限定されるわけではない。ディスク記憶装置１８２４はさらに、ＣＤ−ＲＯＭ（ｃｏｍｐａｃｔ ｄｉｓｋ ＲＯＭ ｄｅｖｉｃｅ）、ＣＤ−Ｒドライブ（ＣＤ ｒｅｃｏｒｄａｂｌｅ ｄｒｉｖｅ）、ＣＤ−ＲＷドライブ（ＣＤ ｒｅｗｒｉｔａｂｌｅ ｄｒｉｖｅ）、ＤＶＤ−ＲＯＭ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ ＲＯＭ ｄｒｉｖｅ）などの光ディスクドライブを含む記憶媒体を、他の記憶媒体とは別にまたは他の記憶媒体と組み合わせて含むことができる。ただし光ディスクドライブはこれらに限定されるわけではない。ディスク記憶装置１８２４とシステムバス１８１８の接続を容易にするため、インターフェース１８２６などの取外し可能なまたは取外し不能のインターフェースが一般に使用される。

図１８には、ユーザと適当な動作環境１８１０の中に記載された基本的なコンピュータリソースとの間の仲介手段の働きをするソフトウェアが記載されていることを理解されたい。このようなソフトウェアにはオペレーティングシステム１８２８が含まれる。オペレーティングシステム１８２８は、ディスク記憶装置１８２４上に記憶することができ、コンピュータシステム１８１２のリソースを制御し割り当てる役目を果たす。システムアプリケーション１８３０は、システムメモリ１８１６またはディスク記憶装置１８２４に記憶されたプログラムモジュール１８３２およびプログラムデータ１８３４を通して、オペレーティングシステム１８２８によるリソースの管理を利用する。本発明は、様々なオペレーティングシステムまたはオペレーティングシステムの組合せを用いて実現することができることを理解されたい。

ユーザは、入力装置１８３６によってコンピュータ１８１２にコマンドまたは情報を入力する。入力装置１８３６には、マウスなどのポインティングデバイス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロホン、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラなどが含まれる。これらの入力装置および他の入力装置は、インターフェースポート１８３８を介してシステムバス１８１８を通して処理ユニット１８１４に接続する。インターフェースポート１８３８には例えば、シリアルポート、パラレルポート、ゲームポートおよびユニバーサルシリアルバス（ＵＳＢ）が含まれる。出力装置１８４０は、入力装置１８３６と同じタイプのいくつかのポートを使用する。したがって例えば、ＵＳＢポートを使用して、コンピュータ１８１２に入力を提供し、コンピュータ１８１２から出力装置１８４０に情報を出力することができる。出力アダプタ１８４２は、モニタ、スピーカ、プリンタなど、専用のアダプタを必要とするいくつかの出力装置１８４０があることを示すために提供されている。出力アダプタ１８４２には例えば、出力装置１８４０とシステムバス１８１８の間の接続手段を提供するビデオカードおよびサウンドカードが含まれる。ただしこれらに限定されるわけではない。リモートコンピュータ１８４４などの他の装置および／または装置のシステムは、入力機能と出力機能の両方を提供することに留意されたい。

コンピュータ１８１２は、リモートコンピュータ１８４４などの１つまたは複数のリモートコンピュータへの論理接続を使用するネットワーク環境で動作することができる。リモートコンピュータ１８４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの電気器具、ピア（ｐｅｅｒ）装置または他の一般的なネットワークノードなどであることができ、リモートコンピュータ１８４４は一般に、コンピュータ１８１２に関して説明した要素の多くまたは全部を含む。簡潔にするため、リモートコンピュータ１８４４には記憶装置１８４６しか示されていない。リモートコンピュータ１８４４は、ネットワークインターフェース１８４８を介してコンピュータ１８１２に論理的に接続され、次いで通信接続１８５０を介して物理的に接続される。ネットワークインターフェース１８４８は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）などの通信ネットワークを包含する。ＬＡＮ技術には、ＦＤＤＩ（Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）、ＣＤＤＩ（Ｃｏｐｐｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）、Ｅｔｈｅｒｎｅｔ（登録商標）／ＩＥＥＥ８０２．３、Ｔｏｋｅｎ Ｒｉｎｇ／ＩＥＥＥ８０２．５などが含まれる。ＷＡＮ技術には、２地点間リンク、統合サービスデジタル通信網（ＩＳＤＮ）およびそのバリエーションのような回線交換網、パケット交換網、デジタル加入者線（ＤＳＬ）などが含まれる。ただしこれらに限定されるわけではない。

通信接続１８５０は、ネットワークインターフェース１８４８をバス１８１８に接続するために使用されるハードウェア／ソフトウェアを指す。図を分かりやすくするために、通信接続１８５０はコンピュータ１８１２の内部に示されているが、通信接続１８５０はコンピュータ１８１２の外部にあってもよい。ネットワークインターフェース１８４８に接続するために必要なハードウェア／ソフトウェアには例えば、通常の電話グレードのモデム、ケーブルモデムおよびＤＳＬモデムを含むモデム、ＩＳＤＮアダプタ、Ｅｔｈｅｒｎｅｔ（登録商標）カードなどの内部および外部技術が含まれる。

以上の説明は本発明の例を含む。もちろん、本発明を説明するために、コンポーネントまたは方法の考えられるすべての組合せを記載することは不可能だが、本発明の他の多くの組合せおよび置換が可能であることを当業者は理解されたい。したがって、本発明は、添付の請求項の趣旨および範囲に含まれるこのようなすべての変更、修正および変形を包含する。さらに、詳細な説明または請求項で用語「含む（ｉｎｃｌｕｄｅ）」が使用される範囲において、この用語は、請求項で移行語（ｔｒａｎｓｉｔｉｏｎａｌ ｗｏｒｄ）として使用されるときの用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」の解釈と同様に包括的（ｉｎｃｌｕｓｉｖｅ）である。

本発明の一態様に基づくアソシエーションアーキテクチャのブロック図である。 本発明の一態様に基づくアソシエーション要求を示す図である。 本発明の一態様に基づくアソシエーション応答を示す図である。 本発明の一態様に基づくアソシエーション管理システムのブロック図である。 本発明の一態様に基づくアソシエーション管理システムのブロック図である。 本発明の一態様に基づくアソシエーションハンドラシステムのブロック図である。 本発明の一態様に基づくアソシエーションドライバシステムのブロック図である。 装置を関連づける本発明の一態様に基づく方法の流れ図である。 装置のアソシエーションを容易にする本発明の一態様に基づく方法の流れ図である。 ＵＳＢ接続によって装置を結びつける本発明の一態様に基づく方法の流れ図である。 図１０の方法の続きを示す流れ図である。 図１０および１１の方法の続きを示す流れ図である。 本発明の一態様に基づくアソシエーション管理方法の流れ図である。 本発明の一態様に基づくアソシエーション管理方法の流れ図である。 図１４の方法の続きを示す流れ図である。 図１４および１５の方法の続きを示す流れ図である。 本発明の一態様に基づくアソシエーションハンドラ方法の流れ図である。 本発明が機能することができる動作環境の一例である。

符号の説明

１１０ 装置
１２０ アソシエーションマネージャ
１３０ ハンドラ
１４０ ドライバ
１５０ ハンドラレジストリ
１６０ ドライバレジストリ
２１０ アソシエーション要求ヘッダ
３１０ アソシエーション応答ヘッダ
４１０ アソシエーションマネージャ
４２０ マネージャ通信コンポーネント
４３０ ハンドラ識別コンポーネント
５１０ アソシエーションマネージャ
５２０ 初期化コンポーネント
６１０ ハンドラ
６２０ 要求コンポーネント
６３０ 応答コンポーネント
６４０ アソシエーションプロセッサ
６５０ サービス
７１０ ドライバ
７２０ 信用媒体通信コンポーネント
７３０ ドライバ通信コンポーネント
７４０ 装置
１８１４ 処理ユニット
１８１６ システムメモリ
１８１８ バス
１８２０ 揮発
１８２２ 不揮発
１８２４ ディスク記憶装置
１８２６ インターフェース
１８２８ オペレーティングシステム
１８３０ アプリケーション
１８３２ モジュール
１８３４ データ
１８３６ 入力装置
１８３８ 入力ポート
１８４０ 出力装置
１８４２ 出力アダプタ
１８４４ リモートコンピュータ
１８４６ 記憶装置
１８４８ ネットワークインターフェース
１８５０ 通信接続

Claims (20)

1. １つまたは複数のハンドラに関連づけられた識別情報を記憶するハンドラレジストリと、
   特定のハンドラにアソシエーション要求を、前記アソシエーション要求の中の経路指定情報および前記ハンドラレジストリの中に記憶された前記識別情報に少なくとも部分的に基づいて提供するアソシエーションマネージャと
   を備えることを特徴とするアソシエーション管理システム。
2. ハンドラに関連づけられた前記識別情報は大域的に固有の識別子を含むことを特徴とする請求項１に記載のシステム。
3. システム初期化中にインスタンスが生成される少なくとも１つのドライバおよび少なくとも１つのハンドラを識別する初期化コンポーネントをさらに備え、前記初期化コンポーネントはさらに、前記少なくとも１つのドライバおよび少なくとも１つのハンドラのインスタンス生成を開始することを特徴とする請求項１に記載のシステム。
4. インスタンスが生成される前記少なくとも１つのドライバに関連づけられた情報を記憶したドライバレジストリをさらに備えることを特徴とする請求項３に記載のシステム。
5. 前記アソシエーション要求は少なくとも１つのアソシエーション要求属性を含むことを特徴とする請求項１に記載のシステム。
6. 前記アソシエーション要求属性は属性タイプ、属性データ長およびデータを含むことを特徴とする請求項５に記載のシステム。
7. 前記アソシエーションマネージャは、前記ハンドラによって提供される情報に少なくとも部分的に基づいてアソシエーション応答を生成することを特徴とする請求項１に記載のシステム。
8. 前記アソシエーション応答はアソシエーション応答属性を含むことを特徴とする請求項７に記載のシステム。
9. 前記アソシエーション応答属性は属性タイプ、属性長さおよびデータを含むことを特徴とする請求項８に記載のシステム。
10. 前記アソシエーション応答は、非信用媒体を介して装置がコンピュータシステムと通信するための情報を含むことを特徴とする請求項７に記載のシステム。
11. 前記非信用媒体は無線通信接続を含むことを特徴とする請求項１０に記載のシステム。
12. 前記アソシエーション要求はドライバによって生成され、前記ドライバはさらに前記アソシエーション応答を受け取ることを特徴とする請求項１０に記載のシステム。
13. アソシエーション要求に少なくとも部分的に基づいてハンドラを識別するステップと、
    前記アソシエーション要求に関連づけられた情報を前記識別されたハンドラに送るステップと、
    前記ハンドラから応答を受け取るステップと、
    前記応答に少なくとも部分的に基づいてアソシエーション応答を生成するステップと、
    前記アソシエーション応答を要求ドライバに提供するステップと
    を含むことを特徴とするアソシエーション管理方法。
14. 前記アソシエーション要求の妥当性を検査するステップ、
    前記アソシエーション要求が適格かどうかを判定するステップ、および
    前記アソシエーション要求が適格でない場合に、不適格なアソシエーション要求を指示するアソシエーション応答を生成するステップ
    のうちの少なくとも１つのステップをさらに含むことを特徴とする請求項１３に記載の方法。
15. ハンドラが見つかったかどうかを判定するステップ、
    前記ハンドラが見つからなかった場合に、サポートされていないアソシエーションタイプを指示するアソシエーション応答を生成するステップ、および
    前記アソシエーション要求を構文解析して属性のリストを構築するステップ
    のうちの少なくとも１つのステップをさらに含むことを特徴とする請求項１３に記載の方法。
16. 前記応答フォーマットの妥当性を検査するステップ、
    アソシエーションが成功したかどうかを判定するステップ、
    前記アソシエーションが成功しなかった場合に、エラーステータスを指示するアソシエーション応答を生成するステップ、
    前記応答が適格かどうかを判定するステップ、および
    前記応答が適格でない場合に、エラーステータスを指示するアソシエーション応答を生成するステップ
    のうちの少なくとも１つのステップをさらに含むことを特徴とする請求項１３に記載の方法。
17. 請求項１３に記載の方法を実行するためのコンピュータ実行可能命令が記憶されていることを特徴とするコンピュータ可読媒体。
18. ２つ以上のコンピュータコンポーネント間で伝送され、装置アソシエーションを容易にするデータパケットであって、
    アソシエーション応答ヘッダおよびアソシエーション応答属性を含み、非信用媒体を介して装置がコンピュータシステムと通信するための情報を提供するアソシエーション応答
    を含むことを特徴とするデータパケット。
19. 前記アソシエーション応答属性は属性タイプ、属性長さおよびデータを含むことを特徴とする請求項１８に記載のデータパケット。
20. 前記非信用媒体は無線通信接続を含むことを特徴とする請求項１８に記載のシステム。
    

Images