JP4856700B2 - Establishing a wireless universal serial bus (WUSB) connection via a trusted medium - Google Patents

Description

  The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. This summary is not intended to identify key / critical elements of the invention, nor is it intended to delimit the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

  In the following, an extensible architecture of untrusted media (eg, wireless) device configuration via trusted media is described. This architecture can be used to associate devices that utilize untrusted media (eg, wireless connections). The association is accomplished using a trusted medium such as a wired connection.

  This architecture includes systems and methods for establishing a wireless universal serial bus (WUSB) connection between a connected device and a host device using a trusted medium, such as a wired connection. In one embodiment, the connecting device sends an association request to the host device through the trusted medium. The association request includes device attributes associated with the connected device's WESM component. In response to this, the host device analyzes the association request to confirm its validity, and determines a connection attribute for connection using WUSB. The host device sends a response having a connection attribute to the connection device through the trusted medium. The connection device uses the connection attribute to configure the WUSB component and establish a WUSB connection with the host device.

  Next, the present invention will be described with reference to the drawings. In the drawings, the same reference numerals are used throughout the drawings to refer to the same elements. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it may be apparent that the invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the present invention.

  As used in this application, the terms “component”, “handler”, “model”, “system”, etc. refer to either hardware, a combination of hardware and software, software, or running software. Intended to refer to computer-related entities. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can exist in one process and / or thread of execution, one component can be localized on one computer, and / or two or It can be distributed among more than two computers. These components can also execute from various computer readable media having various data structures stored thereon. A component may include one or more data packets (eg, data from one component that interacts with another component in a local system, distributed system, and / or other via signals across a network such as the Internet. Can communicate via a local process and / or a remote process according to a signal or the like having data from a component interacting with the system. The computer component can be stored, for example, on a computer readable medium according to the present invention. This computer-readable medium includes ASIC (Application Specific Integrated Circuit), CD (Compact Disc), DVD (Digital Video Disc), ROM (Read Only Memory), Floppy (Registered Trademark) Disc, Hard Disk, EEPROM (Electrical Erase) Possible programmable read-only memory), and memory sticks.

  Further, “trusted media” refers to trusted connections that can transfer related information to associate untrusted media. Examples of trusted media include, but are not limited to, serial connections, parallel connections, and / or universal serial bus (USB) connections. “Untrusted media” refers to media that are associated to establish trust. Wireless connection (s) such as Bluetooth and / or IEEE 802.11 are examples of untrusted media.

  With reference to FIG. 1, an association architecture 100 in accordance with an aspect of the present invention is illustrated. The architecture 100 can be used to associate a device 110 that utilizes an untrusted medium (eg, a wireless connection). The association is accomplished using a trusted medium such as a wired connection.

  An “association request” refers to a data block sent from the device 110 to the driver 120 to initiate the association. The association request can then be forwarded to the association manager 130. The association manager 130 forwards the association request to the appropriate handler 140. An “association response” refers to a data block sent from the driver 120 to the device 110 to complete the association (eg, successful and / or unsuccessful).

  The architecture 100 can facilitate the configuration of the device 110 to communicate (eg, securely) via an untrusted medium (eg, a wireless connection). The configuration of device 110 may be based at least in part on information exchanged via a trusted medium (eg, a wired connection). In one example, the device 110 sends an association request to the driver 120 and receives an association response from the driver 120. If the association is successful, the association response can include, for example, configuration information (eg, an encryption key) that allows the device 110 to communicate (eg, securely) over the untrusted medium. If the association is unsuccessful, the association response can include error information, for example.

  In one example, device 110 is a wireless enabled digital camera that also includes a USB connection. USB connections (trusted media) can be used to configure wireless connections (untrusted media) for digital cameras. For example, a “found new hardware” wizard may be used to select and / or create a wireless profile for transfer to the digital camera via architecture 100. When this profile information is transferred to the digital camera via the USB connection, the USB connection can be disconnected and the digital camera can communicate via the wireless connection.

  For example, the driver 120 can channel an association request received via the trusted medium to the association manager 130. Driver 120 can further provide the association response received from association manager 130 to device 110 via the trusted medium. In another example, driver 120 generates an association request and provides it to association manager 130. Optionally, the driver 120 can also determine an appropriate time for issuing the association request.

  In yet another example, a particular driver 120 can be used to configure multiple untrusted media. For example, the driver 120 can be used to communicate via a USB connection to a plurality of devices 110 that communicate via a plurality of untrusted media.

  Association manager 130 provides association data to the appropriate computer. The association manager 130 can receive an association request from the driver 120. Based at least in part on the routing information of the association request, association manager 130 may provide information associated with the association request to a particular handler 140 for processing. Once this particular handler 140 has completed processing the association request, this handler 140 can provide an association response to the association manager 130. Based at least in part on the routing information in the association response, the association manager 130 can provide the association response to the requesting driver 120.

  The handler 140 interfaces with a service (not shown) that performs device installation. In one example, handler 140 is the only component of architecture 100 that has explicit knowledge of association requests. The handler 140 operates based at least in part on the contents of the association request, as will be described in more detail below. For example, this operation (s) may depend on the connection type that is to be established by the association request. When a particular handler 140 completes processing the association request, this handler 140 can provide an association response to the association manager 130.

  The architecture 100 can include a handler registry 150 that stores identification information associated with one or more handlers 140. The association manager 130 can use the identification information stored in the handler registry 150 to determine to which of the plurality of handlers 140 a particular association request is to be provided.

  Further, the architecture 100 can optionally include a driver registry 160 that stores identification information associated with one or more drivers 120. The association manager 130 uses the identification information stored in the driver registry 160 (as described below) to create any instance of one or more drivers 120, for example during initialization. Can be determined.

  Although device 110 is shown as a single entity, it can include objects that send and / or receive association requests and ultimately objects associated with the host (eg, target device).

  In one example, the architecture 100 supports only one association request and one associated association response. In this example, the information required from device 110 to facilitate association is embedded in the association request. Similarly, information needed for device 110 to facilitate association is also embedded in the association response.

  With reference to FIG. 2, an association request 200 in accordance with an aspect of the present invention is illustrated. Association request 200 includes an association request header 210 and one or more association request attribute (s) 220 (eg, attribute type, length, and data). An attribute is a single item in an association request and / or in an association response. For example, association request header 210 may include a set of globally defined request attribute (s) in a format similar to the attributes described below for association request attribute (s) 220.

  In one example, association request (s) and / or association response (s) are organized in a parsable stream. This stream comprises a series of attribute (s), each attribute having a defined type and associated data. This promotes architectural flexibility and extensibility. One exemplary attribute structure is specified in Table 1.

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

This exemplary attribute structure can be defined, for example, as follows.

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

In one example, there are several predefined attribute types that are intended to be used by the system itself (eg, common to many association types) and are not specific to any particular association type. is there.

例示的なアソシエーションステータス値は以下の通りである。

Exemplary association status values are as follows:

アソシエーション要求
この例では、アソシエーション要求は、一連の属性である。第１の属性は、AssociationType（アソシエーションタイプ）である。これは、どのハンドラに要求を送信するのかを識別するのに使用される。この例では、この値は、ハンドラ（又はハンドラに関連付けられた或る仕様）によって定義されたＧＵＩＤである。たとえば、Ｂｌｕｅｔｏｏｔｈデバイスを関連付けるために、Ｂｌｕｅｔｏｏｔｈ特有のＧＵＩＤ、及び、その特定のＧＵＩＤをハンドリングすることを指定したハンドラが存在し得る。

Association Request In this example, an association request is a set of attributes. The first attribute is AssociationType (association type). This is used to identify which handler to send the request to. In this example, this value is a GUID defined by the handler (or some specification associated with the handler). For example, to associate a Bluetooth device, there may be a Bluetooth specific GUID and a handler that specifies to handle that particular GUID.

  The second attribute of the association request is length. This is the total length of all the attributes of this request, including the AssociationType field and the Length field itself. This is used to aid in parsing, so that if a component is not related to a particular AssociationType, that component must parse each attribute in the request, as opposed to The entire request can be skipped.

  In this example, immediately following length to facilitate a simple device that can perform basic association with minimal processing (eg, device (s) with a silicon-only solution without firmware) The attribute (s) are carefully defined. To achieve this, it can be helpful to be able to simply jump to a predefined offset in the structure to extract the desired data. Thus, in this example, the attribute immediately following Length contains the minimum amount of data needed to perform a basic association. Furthermore, the attributes can be arranged in a predefined order and can always be present. In one example, almost all of this required data is contained within a single attribute. In this example, any variable length field is placed at the end of these basic attributes so as not to affect the offset in the association request.

In another example, several attributes are used, each containing a small amount of data. Thus, it should be understood that any number of attributes can be followed, for example, when attributes to provide extended functionality follow.
Association Response Referring to FIG. 3, an association response 300 in accordance with an aspect of the present invention is illustrated. The association response 300 includes an association response header 310 and zero, one, or more association response attribute (s) 320. For example, association response header 310 may include a set of globally defined request attribute (s) in a format similar to the attributes described below for association response attribute (s) 320.

  The association response attribute 320 is a piece of data including an attribute type, length, and data. Similar to the association request described above, in one example, the association response is a series of attributes. In this example, the first attribute is AssocitaionType. This is used to echo the AssociationType of the association request that resulted in this response.

  The second attribute of the association response is length. This is the total length of all attributes of this request, including the AssociationType field and the length field itself. This is used to aid in parsing, so that if a component is not related to a particular AssociationType, that component must parse each attribute in the request, as opposed to The request can be skipped.

  The third attribute of the association response is AssociationStatus (association status). This is to notify the device about the result of the association request. In this example, if the association process is successful, this value will be 0x0000, meaning that the device can continue to read the association response attributes. If the value is 0xc0001, the host could not find a handler that can handle the specified AssociationType. In this case, the device should not make any assumptions about further attributes of the association response.

  In order to allow simple devices to perform basic associations with minimal processing, the attribute (s) immediately following AssociationStatus can be carefully defined as described above. In this example, to achieve this, it is necessary to be able to simply jump to a predefined offset in the structure to extract the desired data. As such, these attributes contain the minimum amount of data necessary to perform a basic association. In addition, in this example, these attributes are arranged in a predefined order and always exist. Any variable length field is placed at the end of these basic attributes so as not to affect the offset in the association request. Any number of attributes can follow, followed by attributes to provide extended functionality.

  With reference to FIG. 4, illustrated is an association management system 400 in accordance with an aspect of the present invention. Association management system 400 includes an association manager 410 having a manager communication component 420 and a handler identification component 430. The system 400 further includes a handler registry 150 and optionally a driver registry 160.

  Association manager 410 is responsible for providing association data (eg, association request (s) and / or association response (s)) to the appropriate components (eg, handlers and / or drivers). Manager communication component 420 can receive association request (s) from driver (s) (not shown). The manager communication component 420 can provide at least a portion of an association request (eg, an association request header) to the handler identification component 430.

  Based on the information provided by the manager communication component 420 and the identification information stored in the handler registry 150, the handler identification component 430 identifies a particular handler (not shown) for which an association request is provided. In one example, association manager 410 loads the handler identified by handler identification component 430. In another example, the handler (s) are loaded at initialization (as described in more detail below). Thereafter, the manager communication component 420 provides information associated with the association request to the handler identified by the handler identification component 430.

  When the handler processes the association request, it provides an association response to the manager communication component 420. The manager communication component 420 then provides this association response to the request driver.

  In one example, the association manager 410 verifies the validity of the association request. For example, the association manager 410 can determine whether it is well-formed. If the request is not in conformance, the association manager 410 indicates an association response indicating that this association request is malformed (for example, a status attribute set in the ERROR_MALFORMED_ASSOCIATION_REQUEST (association request error in inconsistent form)) And this association response can be provided to the requesting driver. In this example, the association manager 410 uses the following criteria to determine whether the association request is in a consistent format.

  a. The request length is large enough (eg, 36 bytes) to hold at least the AssociationType and Length attributes.

  b. The first attribute is AssociationType and its length has an appropriate size (eg, based on a globally unique identifier (GUID) associated with a particular handler).

  c. The second attribute is Length and has an appropriate size (eg, ULONG).

  d. The value of the Length attribute is greater than the AssociationType attribute and the Length attribute (eg, 36 bytes) and is less than or equal to the length of the request.

  e. Each subsequent attribute has a length that is not greater than the value of the Length attribute when that attribute is added to the current position of the attribute in the request.

  f. There is exactly one AssociationType attribute and exactly one Length attribute in the request.

  Next, association manager 410 determines whether there is a registered handler for a specified association type (eg, GUID stored in handler registry 150) included in the association request. If the handler is not found, the association manager 410 can generate an association response indicating that the requested association type is not supported and provide this association response to the requesting driver.

  If a handler is found, in this example, association manager 410 can parse the association request and extract a list of attribute (s). The association manager 410 can then provide the list of extracted attribute (s) to that particular handler.

  If association manager 410 fails to provide a list of extracted attribute (s) to a particular handler, association manager 410 generates an association response indicating that the particular handler did not respond. This association response can be provided to the requesting driver.

If the association manager 410 successfully provides a list of extracted attribute (s) to a particular handler, upon completion of processing by the handler, the association manager 410, in this example, associates the association response attribute list with the handler. Receive from. The association manager 410 can determine whether the association response attribute list is in a consistent format. For example,
a. There is exactly one status attribute.

  b. There are no Length and AssociationType attributes (eg, added by association manager 410).

  c. If the association request includes a MaximumResponseLength attribute, the overall size of these attributes must be less than that value.

  If the response is in a consistent format, association manager 410 generates an association response (eg, a byte array) based at least in part on the association response attribute list. For example, the association manager 410 can do the following:

  a. Sum the overall size of all attributes in the response attribute list.

  b. Add necessary size to AssociationType attribute and Length attribute.

  c. Allocate a buffer large enough to hold the response.

  d. Set the buffer's first attribute to the AssociationType from the association request.

  e. Add a Length attribute to the buffer using the calculated response length.

  f. Add AssociationStatus attribute.

  g. Each additional attribute is added in the order in which they were in the attribute list.

  The association manager 410 can then provide an association response to the requesting driver.

  In one example, the association manager implements the following interface:

SendAssociationRequest()（アソシエーション要求送信）は、アソシエーションプロセスを開始するためにドライバ（複数可）によってコールされる。アソシエーション応答は、デバイスに容易に返信できるバイトアレイとして返される。一例では、AssociationResponse（アソシエーション応答）を解放することがドライバの責務である。

SendAssociationRequest () (association request transmission) is called by the driver (s) to initiate the association process. The association response is returned as a byte array that can be easily returned to the device. In one example, it is the driver's responsibility to release the AssociationResponse.

  With reference to FIG. 5, an association management system 500 in accordance with an aspect of the present invention is illustrated. The system 500 includes an association manager 510, a handler registry 150, a driver registry 160, and an initialization component 520.

  As described above, association manager 510 is responsible for providing association data (eg, association request (s) and / or association response (s)) to the appropriate component (eg, handler and / or driver). To do. On the other hand, in this example, initialization component 520 uses information stored in driver registry 160 to identify one or more drivers (not shown) during system 500 initialization, for example. Decide which driver instance to create. For example, the driver (s) can be registered (eg, manually and / or automatically) during configuration of the computer system (not shown).

  In one example, during system initialization, initialization component 520 identifies driver (s) and handler (s) based at least in part on information stored in driver registry 160 and handler registry 150, respectively. The initialization component 520 then creates an instance of the identified handler (s) and identified driver (s).

  In this example, for each handler, association manager 510 may retrieve the association type count and allocate an associated storage buffer (eg, association type count × sizeof (GUID)). This buffer can be used to retrieve the association type from the handler. In another example, the handler allocates storage space and provides the storage space to the association manager.

  The association type can be an array of GUIDs that represent the specific association types that the handler supports. For each retrieved GUID, an entry can be added to the GUID-to-handler mapping (Handler mappings) stored in the handler registry. For example,

次に、このマッピングリストは、アソシエーションマネージャ５１０が、適切なハンドラへのアソシエーション要求のルーティングを決定するのに用いることができる。

This mapping list can then be used by the association manager 510 to determine the routing of the association request to the appropriate handler.

  In this example, the initialization component 520 activates the driver once the handlers are created and their association types are discovered. Activation is performed after the handler is loaded and initialized to ensure that the association request (s) are not received until the handler is discovered and loaded. For example, a “Start ()” method can be invoked to activate a driver.

  With reference now to FIG. 6, an association handler system 600 in accordance with an aspect of the present invention is illustrated. The system 600 includes a handler 610 that includes a request component 620, a response component 630, and an association processor.

  The handler 610 consumes the association request (possibly along with other component (s) (not shown)) and generates information associated with the association response.

  For example, the request component 620 can receive information (eg, an association request and / or a parsed attribute list) associated with the association request from an association manager (not shown). The request component 620 can analyze the content of the information associated with the association request to determine what action (s) to perform. Association processor 640 facilitates operation (s) via service 650. This action (s) can depend, for example, on the connection type to be established. Upon completion of the operation (s), the association processor 640 can provide information regarding this association to the response component 630. The response component 630 can then generate information (eg, association response and / or attribute list) associated with the association response. This information can be provided to the association manager.

  In one example, multiple handlers 610 implement the following COM interface.

この例では、「manager」（マネージャ）は、アソシエーションマネージャへのインターフェースポインタである。さらに、「AssociationTypes」は、ＰＯＮＧハンドラがハンドリングできるAssociationType GUIDのアレイを返す。同様に、「AssociationTypeCount」（アソシエーションタイプカウント）は、ＰＯＮＧハンドラがハンドリングできるAssociationTypeの個数である。「HandleAssociationRequest()」は、ハンドラ６１０がサポートしたことを報告したアソシエーション要求をアソシエーションマネージャが受信した時に、そのアソシエーションマネージャによってコールされる。「RequestAttributes」は、属性構造のリストである。ハンドラ６１０は、デバイス（図示せず）に返される属性である属性構造体のリストであるResponseAttributesを返すのに必要なメモリを割り当てることが期待されている。

In this example, “manager” is an interface pointer to the association manager. Furthermore, “AssociationTypes” returns an array of AssociationType GUIDs that can be handled by the PONG handler. Similarly, “AssociationTypeCount” (association type count) is the number of AssociationTypes that can be handled by the PONG handler. “HandleAssociationRequest ()” is called by the association manager when the association manager receives an association request reporting that the handler 610 has supported it. “RequestAttributes” is a list of attribute structures. The handler 610 is expected to allocate memory required to return ResponseAttributes, which is a list of attribute structures that are attributes returned to the device (not shown).

  In another example, the handler 610 stores information about the device, for example in a database, for future installation when the device is discovered on the target media. For example, a particular handler 610 can be associated with a Wi-Fi target medium. In this example, the device (s) desiring to use the Wi-Fi target medium send an association request (s) and receive an association response (s) in the form of an attribute list. The attribute list can be provided by the handler 610 to the association manager, which can then form an association response.

In the following Table 9, Table 10, and Table 11, “attribute” refers to a friendly name associated with the attribute element. “Attribute ID” is an identifier (for example, a number) used to identify an attribute element of the attribute list. “Length” indicates the length of data of the attribute element. The length of the attribute can be variable and / or fixed length, in this example expressed in bytes. The length value can also specify the maximum length. In an association response, in one example, a fixed length can be used to ensure that there is an offset to this value, which aids the device's ability to analyze the response. The actual value of the attribute may not use up the entire length allocated for the data. In these cases, the additional field can specify the actual length of the attribute data. “Tolerance” refers to an tolerance field that describes the value supported by the device. If an acceptable value is required, this means that the device must support that value when that value is included in the attribute list. Unless otherwise specified in Table 9, Table 10, and / or Table 11, values should be considered necessary. If the tolerance value is optional, the device need not support that value, but should be prepared to accommodate that value being included in the attribute list. Optional values may be required in future versions of this specification.
Wireless Protocol The IEEE 802.11 standard set defines two network types: encrypted networks (eg, WEP networks) and unencrypted networks. Due to the known weaknesses of the WEP protocol, the wireless industry has implemented support for the IEEE 802.1x standard as a mechanism to address the major deficiencies of the WEP protocol. These major deficiencies are user authentication, encryption key management, and encryption key distribution. In a WEP encrypted network, the user needs to provide an encryption key, and in an 802.1x-enabled network, if the user has valid credentials (eg, a digital certificate or username and password). The encryption key is provided automatically. In an encrypted 802.11 network, this presents usability issues. The reason is to determine a priori whether the user needs to enter a WEP key or if the network supports 802.1x and the user does not need to enter the WEP key. However, it is not possible at present.

The WEP algorithm has been shown to be cryptographically weak, but is called Wi-Fi Protected Access (WPA) to address this fundamental weakness of the WEP algorithm. Security enhancements to the 802.11 standard set were introduced. WPA also addresses some of the original 802.11 standard usability issues by specifying the information elements that a WPA-enabled access point includes in its beacon frame. This information element, among other things, requires the network to ask the user to enter an encryption key (called WPA pre-shared key mode (WPA-PSK)), or the key is automatically set by the user's credentials. Is provided (called "WPA mode").
Wired Equivalent Privacy WEP is defined by the IEEE 802.11 standard and aims to provide a level of data confidentiality comparable to wired networks. Due to the nature of wireless LAN networks, it can be difficult to implement a security infrastructure that monitors physical access to this network. Unlike wired networks, where physical connections are required, anyone within range of a wireless access point (AP) can probably send and receive frames and listen to other frames in transit. Can be clarified. This greatly facilitates wiretapping and remote sniffing of wireless LAN frames.

  WEP provides a data confidentiality service by encrypting data transmitted between wireless nodes. 802.11 frame WEP encryption is indicated by setting the WEP flag in the 802.11 frame MAC header. WEP provides data integrity against probability errors by including an integrity check value (ICV) in the encrypted portion of the radio frame.

  The following table shows the two shared keys defined by WEP.

ＷＥＰ暗号化は、４０ビット及び１０４ビットの暗号化鍵を用いたＲＣ４対称ストリーム暗号を使用する。
Ｗｉ−Ｆｉ保護アクセス
ＷＰＡは、ＷＥＰのセキュリティ機能を改良するように設計されたとえばＷｉ−Ｆｉ標準規格である。ＷＥＰとは異なり、ＷＰＡでは、８０２．１ｘ認証が必要とされる。ＷＰＡでは、ユニキャスト暗号化鍵及びグローバル暗号化鍵の双方のリキー（rekeying）が必要とされる。ユニキャスト暗号化鍵では、一時的鍵完全性プロトコル（Temporal Key Integrity Protocol）（ＴＫＩＰ）が、フレームごとに鍵を変更し、この変更は、無線クライアントと無線アクセスポイント（ＡＰ）との間で同期される。グローバル暗号化鍵では、ＷＰＡが、無線ＡＰが変更された鍵を接続された無線クライアントに広告するための機構を含む。

WEP encryption uses RC4 symmetric stream ciphers with 40-bit and 104-bit encryption keys.
Wi-Fi Protected Access WPA is designed to improve the security features of WEP, for example the Wi-Fi standard. Unlike WEP, WPA requires 802.1x authentication. In WPA, rekeying of both a unicast encryption key and a global encryption key is required. For unicast encryption keys, the Temporal Key Integrity Protocol (TKIP) changes the key every frame and this change is synchronized between the wireless client and the wireless access point (AP). Is done. For global encryption keys, the WPA includes a mechanism for advertising the changed key to the connected wireless client.

  TKIP replaces WEP with a stronger encryption algorithm than the WEP algorithm. TKIP also verifies the security configuration after the encryption key has been determined, synchronized changes of the unicast encryption key for each frame, and unique starting unicast encryption key for each pre-shared key authentication. It also provides a decision.

  WPA also uses a method known as “Michael” that estimates an algorithm that calculates an 8-byte message integrity code (MIC). The MIC is placed between the data portion of the IEEE 802.11 frame and a 4-byte integrity check value (ICV). The MIC field is encrypted along with the frame data and ICV.

WPA is a tentative standard that is replaced by the IEEE 802.11i standard when the IEEE 802.11i standard is completed.
The Wi-Fi handler association type is an attribute included in the header section of the association request and association response, and is separated from the data attribute. This attribute is used by the association manager to forward the association request (s) to the correct handler. In this example, the Wi-Fi handler 410 has the following required association types:

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

The data section of the association request contains attributes that are specific to that attribute type. The following table identifies exemplary attributes that the association manager can transfer to the Wi-Fi handler 610.

ＭＡＣアドレス
ＭＡＣアドレスは、４８ビット値のＭＡＣアドレスを含む６バイト値である。たとえば、０ｘ００ ０ｘ０７ ０ｘＥ９ ０ｘ４Ｃ ０ｘＡ８ ０ｘ１Ｃである。
ネットワーク認証タイプフラグ
このフラグセットは、どの「ネットワーク認証タイプ」のタイプがサポートされているのかを信号で伝えることをデバイスに可能にする。この情報は、診断目的に使用することができる。デバイスが、必要とされる属性をサポートしていない場合、ユーザに対して、このことを通知することができ、この問題を是正するための実行可能な指令を与えることができる。この例では、このフィールドの値は、以下の値のうちの１つ又は２つ以上のビットごとのＯＲである。

MAC address The MAC address is a 6-byte value containing a 48-bit MAC address. For example, 0x00 0x07 0xE9 0x4C 0xA8 0x1C.
Network Authentication Type Flag This flag set allows the device to signal which “network authentication type” types are supported. This information can be used for diagnostic purposes. If the device does not support the required attributes, the user can be notified of this and can be provided with executable instructions to correct this problem. In this example, the value of this field is a bitwise OR of one or more of the following values:

0x0001 = Open (open)
0x0002 = WPAPSK
0x0004 = Shared
0x0008 = WPA
0x0010 = WPA-NONE
0x0020 = WPA2
In this example, the other values are reserved and are set to zero.
Data Encryption Type Flag This flag set allows the device to signal which “data encryption type” types are supported. This information can be used for diagnostic purposes. If the device does not support the required attributes, the user can be notified of this and can be provided with executable instructions to correct this problem. In this example, the value of this field is a bitwise OR of one or more of the following values:

0x0001 = WEP
0x0002 = TKIP
0x0004 = AES
Again, in this example, the other values are reserved and are set to zero.
Connection Type Flag This flag set allows the device to signal which “connection type” types are supported. This information can be used for diagnostic purposes. If the device does not support the required attributes, the user can be notified of this and the user can be provided with actionable instructions to correct this problem. In this example, the value of this field is a bitwise OR of one or more of the following values:

0x01 = ESS (Extended Service Set)
0x02 = IBSS (Independent Basic Service Set)
In this example, the other values are reserved and are set to zero.

  Based at least in part on the interaction of handler 610 with service 650, response component 630 generates information associated with the association response. Continuing with the Wi-Fi handler example, Table 11 identifies exemplary association response attributes. The length of the attribute in the attribute list of this example is fixed. Thus, the device product can easily jump to the appropriate offset and read the value of any given attribute in the response. The offset refers to the beginning of the attribute.

ＳＳＩＤ
ＳＳＩＤは、前述したように、ブロードキャスト無線ネットワークで使用される文字列である。
ネットワーク鍵
ネットワーク鍵は、ネットワークを安全にするのに使用される文字列である。この例では、以下の属性が、ネットワーク鍵の許容値に対する制約条件として置かれる。デバイスは、以下の構成を受け入れるか又は拒否する準備がされていなければならない。

SSID
As described above, the SSID is a character string used in the broadcast wireless network.
Network key The network key is a string used to secure the network. In this example, the following attributes are placed as constraints on the allowable value of the network key. The device must be prepared to accept or reject the following configuration:

ＷＥＰ鍵
データ認証タイプがＷＥＰであるとき、ネットワーク鍵は、４０ビット又は１０４ビットのＷＥＰ鍵のＡＳＣＩＩ表現又はＨＥＸ表現である。このタイプは、文字列の長さによって決定することができる。
ＷＰＡＰＳＫパスフレーズ
ネットワーク鍵属性が０文字〜６３文字のＡＳＣＩＩ文字列であり、且つ、「ネットワーク認証タイプ」属性がＷＰＡである場合、ネットワーク鍵属性は、ＷＰＡバイナリ鍵を導出するパスフレーズとして使用される。
自動提供鍵（Key Provided Automatically）（８０２．１ｘ）
「自動提供鍵（８０２．１ｘ）」属性は、ネットワーク鍵が８０１．ｘを介して提供されるか否かを指示する。ＷＰＡ−ＰＳＫ又はＷＥＰが、無線ネットワークを安全にするのに使用される場合、これは、通常は０に設定される。
ネットワーク認証タイプ
ネットワーク認証タイプは、どのタイプのセキュリティメカニズムが、特定のネットワークに参加するのに必要とされるのかを示す。このフラグセットは、以下のメカニズムのうちのいずれが使用されるのかを指定する。

WEP Key When the data authentication type is WEP, the network key is an ASCII or HEX representation of a 40-bit or 104-bit WEP key. This type can be determined by the length of the string.
WPAPSK passphrase When the network key attribute is an ASCII character string of 0 to 63 characters and the “network authentication type” attribute is WPA, the network key attribute is used as a passphrase for deriving the WPA binary key. .
Key Provided Automatically (802.1x)
The “automatically provided key (802.1x)” attribute indicates that the network key is 801. Indicates whether to be provided via x. If WPA-PSK or WEP is used to secure the wireless network, this is usually set to zero.
Network Authentication Type The network authentication type indicates what type of security mechanism is required to join a particular network. This flag set specifies which of the following mechanisms is used:

0x0001 = Open
0x0002 = WPAPSK
0x0004 = Shared
0x0008 = WPA
0x0010 = WPA-NONE
0x0020 = WPA2
In this example, the other values are reserved and are set to zero. Importantly, unlike association requests, these flags are mutually exclusive and only one flag can be set at a time.
Data encryption type This value specifies the encryption mechanism deployed by the wireless network. This flag set specifies which of the following mechanisms is used:

0x0001 = WEP
0x0002 = TKIP
0x0004 = AES
All other values are reserved and are set to zero. Importantly, unlike association requests, these flags are mutually exclusive and only one flag can be set at a time.
Connection type The connection type defines the type of wireless network. This flag set specifies which of the following mechanisms is used:

0x01 = ESS
0x02 = IBSS
All other values are reserved and are set to zero. These flags are mutually exclusive.

  With reference now to FIG. 7, an association driver system 700 in accordance with an aspect of the present invention is illustrated. System 700 includes a driver 710 with a trusted media communication component 720 and a driver communication component 730.

  Trusted media communication component 720 interfaces with device 740 via a trusted media (eg, USB connection). In one example, the trusted media communication component 720 receives an association request (eg, an association request initiated time independent of device enumeration) from the device 740. In another example, the trusted media communication component 720 receives a notification of a request to issue an association request. Thereafter, the driver 710 generates an association request that is sent to an association manager (not shown) via the driver communication component 730.

  In one example, driver (s) 710 implements the following interface:

「Manager」は、アソシエーションマネージャへのインターフェースポインタであり、それによって、ドライバは、SendAssociationRequest（アソシエーション要求送信）をコールすることができるようになっている。Start()は、新しいアソシエーション要求の検出及び発行をドライバに開始してほしいときにアソシエーションマネージャによってコールされる。Stop()は、新しいアソシエーション要求の発行をドライバに停止してほしいとき（たとえば、ユーザが特定のトラステッド媒体上で関連付けを無効にしたいとき）に、アソシエーションマネージャによってコールされる。

“Manager” is an interface pointer to the association manager, so that the driver can call SendAssociationRequest (send association request). Start () is called by the association manager when the driver wants the driver to start detecting and issuing a new association request. Stop () is called by the association manager when the driver wants the driver to stop issuing new association requests (eg, when the user wants to invalidate the association on a particular trusted medium).

  In one example, a particular driver 710 can be associated with a USB trusted medium. In this example, the device (s) that want to use the untrusted medium securely send an association request (s) through the driver 710 and receive an association response (s).

  In the device (s) that implements the dynamic association function, the association request can be generated independently of the device enumeration, but in this case, there is an optional interrupt IN endpoint in one example. This endpoint facilitates notification of new association requests. A standard endpoint descriptor for this optional endpoint can be found in Table 14.

デバイスのインターフェースが、オプションのエンドポイントを含まない場合、関連付けは、列挙時にのみ行われる。このようなデバイスがアソシエーションプロセスを開始したい場合、デバイスは、デバイスが開始するＵＳＢリセットを行わなければならない。これによって、デバイスは、ホストにより再列挙され、その時点で、ホストは、デバイスからアソシエーション要求（複数可）を取り出す。別の例では、デバイスは、ＨＵＢ機能も実施して、そのデバイスの希望に応じてアソシエーション機能を往来させる（come and go）ことができる。

If the device interface does not include an optional endpoint, the association is only done at enumeration. If such a device wishes to initiate the association process, the device must perform a USB reset initiated by the device. This causes the device to be re-enumerated by the host, at which point the host retrieves association request (s) from the device. In another example, a device can also perform a HUB function to come and go an association function as desired by the device.

  Since this control endpoint is the only required endpoint for devices that support the association interface, the necessary data transfer takes place on that endpoint. In this example, these transfers are in the form of association class requests.

  Table 15 shows, in one example, a list of association class requests that the device must support.

GET_ASSOCIATION_INFORMATION（アソシエーション情報取得）
この要求は、デバイスからアソシエーション情報構造体を取り出す。このアソシエーション情報は、REQUEST_INFO（要求情報）ブロックのリストを含む。各REQUEST_INFOブロックは、デバイスが発行したい単一のアソシエーション要求に関するものである。

GET_ASSOCIATION_INFORMATION (get association information)
This request retrieves the association information structure from the device. This association information includes a list of REQUEST_INFO (request information) blocks. Each REQUEST_INFO block is for a single association request that the device wishes to issue.

表１７は、例示的なASSOCIATION_INFORMATION構造体を示している。

Table 17 shows an exemplary ASSOCIATION_INFORMATION structure.

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

Table 18 provides exemplary association information flag information.

表１９は、例示的なREQUEST_INFO（要求情報）構造体を示している。

Table 19 shows an exemplary REQUEST_INFO (request information) structure.

GET_ASSOCIATION_REQUEST（アソシエーション要求取得）
この要求は、デバイスから特定のアソシエーションを取り出す。この要求は、wValue（ｗ値）フィールド内のRequestID（要求ＩＤ）値によって識別される。

GET_ASSOCIATION_REQUEST (get association request)
This request retrieves a specific association from the device. This request is identified by the RequestID value in the wValue field.

この例では、要求ブロックは、４ＫＢのデータブロックである。制御転送の最大転送サイズは６４ＫＢであり、その結果、理論的には、各GET_ASSOCIATION_REQUESTにおいて１６個の要求ブロックを転送することができる。転送される実際のデータ量は、wLength（ｗ長さ）フィールドによって指定される。wValueフィールドで指定されたBlockNumber（ブロック番号）は、この制御転送の開始ブロック番号を識別する。その結果、この例では、デバイス５４０は、RequestIDによって指定される要求のアソシエーション要求データを、オフセットBlockNumber×４ＫＢから開始して、wLengthバイトを転送して返すはずである。
SET_ASSOCIATION_RESPONSE（アソシエーション応答設定）
この要求は、wValueフィールドのRequestID値によって識別される特定のアソシエーション要求に対する応答を送信する。

In this example, the request block is a 4 KB data block. The maximum transfer size of the control transfer is 64 KB. As a result, theoretically, 16 request blocks can be transferred in each GET_ASSOCIATION_REQUEST. The actual amount of data transferred is specified by the wLength field. The BlockNumber (block number) specified in the wValue field identifies the start block number of this control transfer. As a result, in this example, the device 540 should return association request data for the request specified by the RequestID, starting with the offset BlockNumber × 4 KB and transferring wLength bytes.
SET_ASSOCIATION_RESPONSE (association response setting)
This request sends a response to the specific association request identified by the RequestID value in the wValue field.

この例では、TrasferFlags（転送フラグ）値は、表２２に見られる値の０個以上の値のビットごとのＯＲである。

In this example, the TrasferFlags (transfer flag) value is an OR for each bit of zero or more of the values found in Table 22.

アソシエーション割り込みＩＮメッセージ（複数可）
NewAssociationRequest（新しいアソシエーション要求）
この割り込みＩＮメッセージは、デバイスが、処理する必要がある新しいアソシエーション要求（複数可）又は変更されたアソシエーション要求（複数可）を有することをホストに示す。ホストは、このメッセージを受信すると、GET_ASSOCIATION_INFORMATION要求を発行することができ、それに応じてこれらの要求を処理することができる。

Association interrupt IN message (s)
NewAssociationRequest (New Association Request)
This interrupt IN message indicates to the host that the device has new association request (s) or modified association request (s) that need to be processed. Upon receiving this message, the host can issue GET_ASSOCIATION_INFORMATION requests and can process these requests accordingly.

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

System 100, device 110, association manager 120, handler 130, driver 140, handler registry 150, driver registry 160, system 400, association manager 410, manager communication component 420, handler identification component 430, association manager 510, initialization component 520, System 600, handler 610, request component 620, response component 630, association processor 640, service 650, system 700, driver 710, trusted media communication component 720, driver communication component 730, and / or device 740 are terminology herein. Computer components as defined in the It should be appreciated that it is Rukoto.

  Referring briefly to FIGS. 8-18, methodologies that can be implemented in accordance with the present invention are illustrated. For ease of explanation, these methodologies are illustrated and described as a series of blocks, but according to the present invention, some blocks are not illustrated and described herein. It should be understood and appreciated that the present invention is not limited by the order of the blocks as they can be performed in a different order and / or can be performed simultaneously with other blocks. Should be. Moreover, not all illustrated blocks may be required to implement a methodology in accordance with the present invention.

  The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by one or more components. Generally, program modules include routines, programs, objects, data structures, etc. that perform particular tasks or implement particular abstract data types. In general, the functions of the program modules can be combined or distributed as desired in various embodiments.

  With reference to FIG. 8, illustrated is a methodology 800 for associating devices in accordance with an aspect of the present invention. At 810, a connection (eg, of the device) is established via a trusted medium (eg, USB). At 820, an association request is issued by the device and / or associated driver, for example. At 830, information associated with the association response is received (eg, from a driver). This information can include, for example, an association response received from the association manager. Alternatively, this information may include a portion of the association response received from the association manager.

  At 840, a determination is made regarding whether the association was successful. If the determination at 840 is NO (no), no further processing is performed. If the determination at 840 is YES, at 850, a connection (eg, for the device) is made via an untrusted medium (eg, a wireless connection) using information associated with the association response. .

  Now referring to FIG. 9, illustrated is a methodology 900 that facilitates device association in accordance with an aspect of the present invention. At 910, information associated with the association request is received. At 920, a determination is made regarding whether an association request has been received. If the determination at 920 is no, an association request is generated at 930 and processing continues to 940. If the determination at 920 is YES, at 940, the received association request is transmitted to, for example, an association manager.

  At 950, an association response is received from, for example, an association manager. At 960, information associated with the association response is provided to the requesting device. For example, this information can include the entire association response and / or a portion of the association response. Thereafter, no further processing is performed.

  10-12, a method 1000 for associating a device via a USB connection according to an aspect of the present invention is illustrated. At 1004, the device is enumerated and / or a new association request event is issued. At 1008, a GET_ASSOCIATION_INFORMATION request is sent to the device, for example, by the driver. At 1012, the size of the entire association information is determined, for example, by the driver (eg, size = 3 + sizeof (REQUEST_INFO) × PendingRequestCount).

  At 1016, a determination is made as to whether substantially all of the association information has been received, for example, by a driver. If the determination at 1016 is NO, processing continues at 1008. If the determination at 1016 is YES, at 1020 a determination is made regarding whether PendingRequestCount is greater than zero. If the determination at 1020 is NO, no further processing is performed.

  If the determination at 1020 is YES, at 1024, a request to handle is identified (eg, by a driver). At 1028, the size of the transfer (eg, association request) is determined. At 1032 GET_ASSOCIATION_REQUEST is transmitted. At 1036, a determination is made as to whether there is more request data. If the determination at 1036 is YES, the process continues to 1028. If the determination at 1036 is NO, at 1040, the requested association is handled and an association response is generated (eg, by an association manager and / or handler).

  At 1040, the transfer size of the association response is determined. At 1048, SET_ASSOCIATION_RESPONSE is transmitted. At 1052, a determination is made regarding whether there is more response data. If the determination at 1052 is YES, processing continues at 1044. If the determination at 1052 is NO, a determination is made at 1056 as to whether there are more requests.

  If the determination at 1056 is YES, processing continues at 1024. If the determination at 1056 is NO, a determination is made at 1060 as to whether an additional request flag has been transmitted in the association information. If the determination at 1060 is YES, processing continues at 1008. If the determination at 1060 is NO, no further processing is performed.

  Referring now to FIG. 13, illustrated is an association management method 1300 according to one aspect of the present invention. At 1310, an association request is received from, for example, a driver. At 1320, a handler for the association request is identified. At 1340, a determination is made as to whether there is a handler for the association request. If the determination at 1340 is no, an association response failure is generated at 1350 and processing continues at 1360.

  If the determination at 1340 is YES, at 1370, information associated with the association request is sent to the handler. For example, this information can include an association request and / or a portion of an association request (eg, attribute list (s)).

  At 1380, information associated with the association response is received from the handler. At 1360, an association response is provided to the requesting driver.

  With reference to FIGS. 14-16, an association management method 1400 in accordance with an aspect of the present invention is illustrated. At 1404, an association request is received from, for example, a driver. At 1408, the validity of this association request is confirmed. At 1412, a determination is made as to whether this association request is in a consistent format. If the determination at 1412 is NO, an association response is generated at 1416 indicating an inconsistent association request and processing continues at 1420.

  If the determination at 1412 is YES, at 1424 an association request handler is located. At 1428, a determination is made regarding whether a handler has been found. If the determination at 1428 is NO, an association response is generated at 1432 indicating an unsupported association type, and processing continues at 1420.

  If the determination at 1428 is YES, at 1436, the association request is analyzed and a list of attribute (s) is constructed. At 1440, this attribute list is sent to the identified handler. At 1444, response information is received from the handler. At 1448, a determination is made regarding whether the association was successful. If the determination at 1448 is NO, at 1452, an association response indicating an appropriate error status is generated, and processing continues at 1420.

  If the determination at 1448 is YES, the validity of the response format is confirmed at 1456. At 1460, a determination is made regarding whether the response is in a consistent format. If the determination at 1460 is no, at 1464, an association response indicating an appropriate error status is generated, and processing continues at 1420.

  If the determination at 1460 is yes, at 1468, an association response is generated based on the response from the handler. At 1420, this association response is provided to the requesting driver and no further processing is performed.

  With reference to FIG. 17, illustrated is an association handler method 1700 in accordance with an aspect of the present invention. At 1710, information (eg, an attribute list) associated with the association request is received, eg, from an association manager. At 1720, the association request is processed. At 1730, response information is provided to the association manager.

  In order to provide additional context for various aspects of the present invention, FIG. 18 and the following discussion provide a brief general description of a suitable operating environment 1810 in which various aspects of the present invention may be implemented. It is aimed. Although the invention will be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices, the invention may be combined with other program modules. Those skilled in the art will also recognize that this can be implemented as a combination of hardware and software. In general, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular data types. The operating environment 1810 is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Other known computer systems, environments, and / or configurations that may be suitable for use with the present invention include personal computers, handheld devices or laptop devices, multiprocessor systems, microprocessor-based systems including the systems or devices described above. , Programmable home appliances, network PCs, minicomputers, mainframe computers, distributed computing environments, and the like.

  With reference to FIG. 18, one exemplary environment 1810 for implementing various aspects of the invention includes a computer 1812. Computer 1812 includes a processing unit 1814, system memory 1816, and system bus 1818. System bus 1818 couples system components to processing unit 1814. System components include, but are not limited to, system memory 1816. The processing unit 1814 can be any of various available processors. Dual microprocessors and other microprocessor architectures may be used as the processing unit 1814.

  The system bus 1818 can be any of several types of bus structure (s) including a memory bus or memory controller, a peripheral or external bus, and / or a local bus using any available various bus architectures. It can be. Bus architecture includes 8-bit bus, industry standard architecture (ISA), microchannel architecture (MSA), extended ISA (EISA), intelligent drive electronics (IDE), VESA local bus (VLB), peripheral device interconnection (PCI) , Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association Bus (PCMCIA), and Small Computer System Interface (SCSI).

  The system memory 1816 includes volatile memory 1820 and nonvolatile memory 1822. A basic input / output system (BIOS) that includes a basic routine for transferring information between elements within the computer 1812 during startup or the like is stored in a non-volatile memory 1822. By way of example, and not limitation, non-volatile memory 1822 may include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. . Volatile memory 1820 also includes random access memory (RAM). The RAM serves as an external cache memory. By way of example and not limitation, the RAM may be synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), sync link DRAM (SLDRAM). It can be used in many forms such as direct RAM bus RAM (DRRAM).

  Computer 1812 also includes removable / non-removable volatile / nonvolatile computer storage media. FIG. 18 shows a disk storage device 1824, for example. Disk storage 1824 includes devices such as magnetic disk drives, floppy disk drives, tape drives, Jaz drives, Zip drives, LS-100 drives, flash memory cards, or memory sticks. It is not limited. In addition, the disk storage 1824 can also include storage media that is separate from other storage media or combined with other storage media. These storage media include compact disk ROM devices (CD-ROM), CD recordable drives (CD-R drives), CD rewritable drives (CD-RW drives), and digital versatile disk ROM drives (DVD-ROM). However, the present invention is not limited to these. To facilitate connection of the disk storage device 1824 to the system bus 1818, a removable or non-removable interface such as interface 1826 is typically used.

  It should be appreciated that FIG. 18 describes software that acts as an intermediary between a user and the basic computer resources described in a suitable operating environment 1810. Such software includes an operating system 1828. Operating system 1828 can be stored on disk storage device 1824 and serves to control and allocate resources of computer system 1812. System application 1830 leverages the management of resources by operating system 1828 through program modules 1832 and program data 1834 stored in either system memory 1816 or disk storage device 1824. It should be appreciated that the present invention can be implemented with various operating systems or combinations of operating systems.

  A user enters commands or information into computer 1812 through input device (s). The input device 1836 includes a pointing device such as a mouse, a trackball, a stylus, a touch pad, a keyboard, a microphone, a joystick, a game pad, a satellite antenna, a scanner, a TV tuner card, a digital camera, a digital video camera, a webcam, and the like. However, it is not limited to these. These input devices and other input devices connect to processing unit 1814 through system bus 1818 via interface port (s) 1838. Interface port (s) 1838 include, but are not limited to, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device (s) 1840 uses some of the same type of ports as input device (s) 1836. Thus, for example, a USB port can be used to provide input to computer 1812 and information can be output from computer 1812 to output device 1840. Output adapter 1842 is provided to indicate that there are several output devices 1840 such as monitors, speakers, and printers that require a dedicated adapter, among other output devices 1840. The output adapter 1842 includes, by way of example and not limitation, video cards and sound cards that provide connection means between the output device 1840 and the system bus 1818. It should be noted that other devices and / or systems of devices, such as remote computer (s) 1844, provide both input and output functions.

  Computer 1812 may operate in a network connection environment using logical connections to one or more remote computers, such as remote computer (s) 1844. The remote computer (s) 1844 can be a personal computer, server, router, network PC, workstation, microprocessor-based appliance, peer device, or other common network node, etc. Includes many or all of the elements described for 1812. For simplicity, only the memory storage device 1846 is shown with the remote computer (s) 1844. Remote computer (s) 1844 is logically connected to computer 1812 through network interface 1848 and then physically connected via communication connection 1850. The network interface 1848 includes a communication network such as a local area network (LAN) or a wide area network (WAN). LAN technologies include Fiber Wiring Data Interface (FDDI), Copper Wiring Data Interface (CDDI), Ethernet / IEEE802.3, Token Ring / IEEE802.5, etc. WAN technologies include, but are not limited to, circuit-switched networks such as point-to-point links, integrated services digital networks (ISDN) and variants thereof, packet-switched networks, and digital subscriber lines (DSL). is not.

  Communication connection (s) 1850 refers to the hardware / software used to connect network interface 1848 to bus 1818. Although communication connection 1850 is shown inside computer 1812 for clarity of illustration, communication connection 1850 can also be external to computer 1812. The hardware / software necessary to connect to the network interface 1848 includes, by way of example only, internal and external technologies such as modems, ISDN adapters, Ethernet cards, and the like. Modems include regular telephone grade modems, cable modems, and DSL modems.

  In one example embodiment, the extensible architecture may be implemented as a Plug and Go (PONG) architecture that includes wireless universal serial bus (WUSB) support. FIG. 19 shows an example of the PONG system 1900. Manager 1905 is a central component that is configured to facilitate passing data to the correct counterpart. Manager 1905 can load driver data (such as dll) into the process. For example, manager 1905 can load driver data based on driver registration. When manager 1905 receives the request block from the driver, it can see the request block header and load the appropriate handler for that request type. The handler or driver can be loaded at system startup. The request block is given to the handler for processing. When the handler is complete, a response block is returned to the driver through the manager 1905.

  Drivers 1920-1922 are responsible for interfacing with either some form of hardware or another software component. Drivers 1920-1922 are responsible for channeling requests from manager 1905 to the device over the trusted media.

  Each of the drivers 1920-1922 can detect when a new request is to be issued, and the driver retrieves or generates the request. This request is passed to the manager 1905, which later returns a response to the driver.

  Multiple handlers can use the same driver (ie, multiple target media can use the same trusted media). Drivers 1920-1922 may not require knowledge of the details of the request block or response block.

  Handlers 1910-1912 are responsible for interfacing with services that perform device installation / association. The handlers 1910-1912 can be directly related to the target medium and can be the only component that needs to have explicit knowledge about the attributes of the request block for that particular target medium. There is a global attribute that can be used by other components.

  The handlers 1910-1912 can be configured to handle any type of target medium, such as a wireless medium. As shown in FIG. 19, the handler 1912 is configured to handle WUSB media. WUSB is a wireless protocol defined by the USB Implementers Forum for connecting wireless USB peripherals to wireless USB hosts. The WUSB protocol is specified to function on the medium access control (MAC) layer of the multi-band OFDM alliance (MBOA) on the ultra-wide band (UWB). When any one of the handlers 1910 to 1912 receives a request block from the manager 1905, the handler analyzes its contents and determines an appropriate action.

  The PONG system 1900 allows a device to send requests and responses that include attributes associated with WUSB. In a request passed from the device to the handler, the attribute list may include association type, connection device ID, connection key, device setup class GUID, supported bandwidth group, integrator site URL, and the like. The association type is an attribute included in the request and response header sections and is separated from the data attribute. The association type attribute is used by the manager to forward the request to the correct handler. Table 24 shows an example of the specification of the association type attribute.

表２４及び以下の表の用語は、次のように定義される。

The terms in Table 24 and the following table are defined as follows:

  Attribute name: A friendly name associated with the attribute element.

  Attribute ID: This number is used to identify an attribute element in the attribute list.

  Length: Length of attribute element data. The length of the attribute can be variable or fixed and is expressed in bytes. The length value can also specify the maximum length. In the response, a fixed length can be used to ensure that there is an offset to this value, which aids the device's ability to analyze the response. The actual value of the attribute may not use up the entire length allocated for the data. In these cases, the additional field specifies the actual length of the attribute data.

  M / O: This field informs whether the variable is mandatory or optional. Required attribute elements are always included in the attribute list. The option value is not necessarily present. “Mandatory” is represented by M, and “Option” is represented by O.

  Tolerance: The tolerance field describes the values supported by the device. If an acceptable value is required, this means that the device supports that value when that value is included in the attribute list. Unless otherwise stated in the table, values should be considered necessary. If the tolerance value is optional, the device need not support that value, but should be prepared to accommodate that value being included in the attribute list. Optional values may be required in future versions of this specification.

  The data section of the request can include attributes specific to the attribute type. Table 25 shows an example of request attributes that can be transferred to the WUSB handler.

接続デバイスＩＤ（ＣＤＩＤ）は、無線ＵＳＢデバイスのデバイスＩＤである。デバイスＩＤが、（工場、前の関連付けの試み、ユーザ入力等からのいずれであろうと）デバイスに事前に割り当てられていた場合、デバイスは、同じＩＤを利用したい場合がある。既存のＩＤを再利用することによって、ホストは、そのデバイスに以前出会ったことがあることを知って、異なって振る舞うことができる。また、既存のＩＤを再利用することにより、ホストが異なって振る舞うことが、複数のホストに同時に関連付けることができるデバイスに対してより容易になる。たとえば、デバイスが複数のホストにわたって同じＣＤＩＤを保持したい場合又はデバイスがこのホストにすでに関連付けられていることを示したい場合に、ＣＤＩＤは、デバイスが送信することができる。ホストは、この値を上書きすることもできるし、この値を再利用することもできる。

The connection device ID (CDID) is a device ID of the wireless USB device. If a device ID has been pre-assigned to a device (whether from a factory, previous association attempt, user input, etc.), the device may wish to utilize the same ID. By reusing the existing ID, the host can behave differently, knowing that the device has previously been encountered. Also, reusing existing IDs makes it easier for devices that can be associated with multiple hosts simultaneously to behave differently. For example, a CDID can be sent by a device if the device wants to keep the same CDID across multiple hosts or if it wants to indicate that the device is already associated with this host. The host can overwrite this value or reuse this value.

  If this attribute is missing, or if its value is all zero, the host assumes that the device needs a new device ID. The host generates this unique ID and returns the ID to the device in an association response.

  The connection key (CK) is a key used to facilitate mutual authentication and generate a session encryption key, as described in the WUSB specification. The CK can be sent by the device if the device needs to have a hard-coded connection key. The device may want to include this attribute in the request if it cannot store the generated key (does not have NVRAM). However, it is not recommended that devices hard-code these keys, and conversely, the device should allow the host to generate those keys to make it more secure.

  If this attribute is missing, or if its value is all zeros, the host assumes that the device needs to generate CK and returns CK in the association response.

  The device setup class GUID is one of the supported setup class GUIDs. Providing this value in the association request may allow the display of an appropriate icon for the device, or allow implementation of certain system policies or user-defined policies. This value can be used to determine what type of device is associated. The GUID can be used to determine things such as icons and descriptions by matching with a device setup class installed on the host. This also helps to display the appropriate information on every UI, thereby helping the user to identify a particular device.

  Supported band groups can be used to determine which channel the host radio should choose from when choosing a channel. For example, a supported band group can be used by a host to determine what PHY channels it can use. Without this information from the device, the host needs to change to band group 1's channel because band group 1 is the only band group that needs to be supported by all devices. This will cause all hosts and devices to choose to use band group 1, thus flooding those channels and reducing the values of other band groups. If this information is communicated to the host at the time of association, the host will probably know the supported channels of all devices that can connect to it, so that the host will probably It becomes possible to select the channel.

  A 1 in a bit position indicates that all of the bands and channels of the associated PHY band group are supported. A 1 in bit position 0 indicates that all bands of band group 1 are supported.

  The integrator site URL can be used in the UI to provide the user with information about the device by providing a link to the device details on the USB-IF website.

  Table 26 shows examples of response attributes that can be transferred to the WUSB device. This table shows examples of offsets. Also, the header attribute can occupy the first 19 bytes of the attribute list.

ハンドラからデバイスへ渡される応答では、属性リストは、接続ホストＩＤ、接続デバイスＩＤ、接続鍵、好ましいチャネル、ホスト領域等を含むことができる。接続ホストＩＤ（ＣＨＩＤ）は、一意のホストＩＤである。デバイスは、このＩＤを使用して、ホストのビーコンを突き止めることができ、それによって、ホストを突き止めることができる。接続デバイスＩＤ（ＣＤＩＤ）は、一意のデバイスＩＤである。このＩＤは、ＣＨＩＤによって指定されたホストに対してデバイスを一意に識別する。複数のホストにわたって一意であることは保証されていない。接続鍵（ＣＫ）は、この状況を使用して再接続を確立するためのものである。ＣＫは、１２８ビットＣＣＭ鍵とすることができる。

In the response passed from the handler to the device, the attribute list can include a connection host ID, a connection device ID, a connection key, a preferred channel, a host area, and the like. The connection host ID (CHID) is a unique host ID. The device can use this ID to locate the host's beacon, thereby locating the host. The connection device ID (CDID) is a unique device ID. This ID uniquely identifies the device with respect to the host specified by the CHID. It is not guaranteed to be unique across multiple hosts. The connection key (CK) is for establishing reconnection using this situation. CK can be a 128-bit CCM key.

  Preferred channels can be specified in the host response to inform the device of the preferred channel order that the host is using. This can optimize the host search process by giving the device a hint about the relative likelihood that the host exists on any given channel. The device can search for the host in the order specified by the host, thus the possibility that the device will find the host in one of the first few channels scanned rather than scanning in a linear order. Can be higher.

  The host region can be specified in the host response to notify the device about which region the host is operating in. The device can use this information to change its radio operating characteristics to region-specific values.

  In one embodiment, the attribute length of the attribute list may be fixed. Thus, the device manufacturer can easily jump to the appropriate offset and read the value of any given attribute in the response. The offset refers to the start point of the attribute.

  Other attributes can be used for requests and responses between the device and the handler. These other attributes include hardware and compatibility ID, channel ID, band group, device manufacturer string, device description string, host string, device class GUID, manufacturer URL, device icon, association secret key, etc. Can be included. The association secret key is a PONG specific key written in the device. The device normally does not reveal the association secret key except through PONG. When the device is next attached, the association secret key is retrieved and used to authenticate the device. By using the association secret key, it is possible to perform tasks such as silently updating the association information without asking the user, thereby allowing the device to keep its own CDID etc. Can be possible. Without an association key, two devices with the same CDID (eg, obtained from another host or stolen from another device) will affect their ability to connect to the PC There is a possibility.

The following are examples of two scenarios that can be achieved using the architecture and WUSB connection mechanism described above.
Scenario 1—WUSB Portable Player with PC Todd has acquired a new wired + wireless USB portable player that synchronizes in conjunction with Windows® Media Player. When Todd opens the box, he removes the player and adds the included rechargeable battery to the player. Next, he follows instructions to install third-party software, and then attaches the player to the PC using a wired USB cable and charges the battery. During battery charging, the player is also coupled to the PC to obtain a wireless USB connection and initiates device synchronization via wired USB.

If the cable is unplugged and the device is in range, the user should not see a new dialog for wireless USB device detection, and the device should simply start working.
Scenario 2-Mobile phone with PC and storage jack have pre-associated PC and WUSB storage devices. When Jack associates his WUSB cell phone with the PC, Jack gets the option of associating other WUSB devices (which may have one free connection slot) with the cell phone. This increases the value of the PC and simplifies the end user's connection experience.

  The following include four examples of association models for associating WUSB devices for illustrative purposes.

  UI approach—Use the connect button on both systems (when the devices are in proximity) to identify the device from the UI list of devices that can be in close proximity.

  Serial number approach—This is very similar to the UI approach, but once the user identifies the device from the UI, the user must type the serial number from the device to the host to enable security. I must.

  USB cable approach—Use a generic USB cable to plug a wireless USB device into the host you want to associate. The wire can be used for normal operation or can be used to charge with an association.

  USB flash key—A general purpose USB mass storage device (eg, USB flash device) is used to store and exchange identification and security information between the device and the host.

  The PONG system 1900 shown in FIG. 19 can be specifically configured to support USB. FIG. 20 shows a USB driver stack 2000 as an example of the device manager architecture of the operating system. The driver stack 2000 can be implemented to support USB as a trusted medium in the PONG system 1900. Components 2013 to 2017 are an existing USB stack of the operating system. A component 2010 is a kernel component of the PONG USB driver. A component 2006 is a user mode PONG driver encapsulated by all PONG managers 1905.

  FIG. 21 shows an example of an operation for the WUSB device 2112 to connect to the host device 2100. The connected WUSB device 2112 can be any device that can communicate using WUSB. Typically, the connected WUSB device 2112 can also communicate using a trusted medium. As described above, trusted media may include wired connections such as wired USB, serial, parallel, firewire, Ethernet. Trusted media may also include wireless connections such as near field communication (NFC), infrared (IR), and other established wireless connections. The host device 2100 includes a manager 1905, a WUSB handler 1912, and a driver 1912 as described above with reference to FIG. As shown in FIG. 21, the host device 2100 also includes a WUSB component 2103 for connecting to an external device using WUSB and a wired component 2105 for connecting to the device using a wired component.

  In order to connect to the host device 2100, the connected WUSB device transmits a request to the driver 1921 through the wired component 2105. For example, the connected WUSB device 2112 can be connected to the wired component 2105 through a wired USB cable. This request includes information for associating the WUSB device 2112 with the host device 2100, such as the attributes described above.

  The driver 1921 transmits a request to the manager 1905. The manager 1905 analyzes the request information and confirms its validity. Specifically, the manager 1905 can determine whether the type of connection in the request and whether the request information is valid for the standard related to the connection. In this example, manager 1905 determines that the request is associated with a WUSB connection. The manager 1905 confirms the validity of the requested device attribute. If the request is valid, the manager 1905 provides WUSB connection information such as device attributes to the WUSB handler 1912.

  The WUSB handler 1912 processes the connection information and provides the host connection information to the manager 1905 in response to the request. The host connection information includes a connection attribute used for connection using WUSB. The manager 1905 provides host connection information having connection attributes to the driver 1921. The driver 1921 transmits connection information to the connected WUSB device 2112 through the wired component 2105. Next, the connected WUSB device 2112 uses the connection information for self-configuration and connection to the host device 2100. For example, the connected WUSB device 2112 can adjust the WUSB component to the configuration required by the host device 2100, such as channel, region, etc. The connected WUSB device 2112 can also transmit to the host device 2100 information having the key, host ID, and device ID identified in the received connection information.

  FIG. 22 illustrates an example process 2200 for connecting a WUSB device with a host device using the system described herein. For example, process 2200 can be implemented by manager 1902. At block 2202, an association request from a WUSB device is identified. This association request can be received through a reliable medium such as a wired medium. At block 2204, the request is parsed to verify the validity of its contents. By analyzing the request, it is possible to determine the type of association included in the request. The validity of the request is confirmed based on the standard corresponding to the type. In this example, the association type is WUSB and the validity of the request is confirmed against the WUSB standard. The validated request should include device attributes specified by the WUSB standard.

  At block 2206, WUSB device attributes are sent to the WUSB handler. At block 2208, connection attributes are received from the WUSB handler. With these connection attributes, the WUSB device can be connected to the host device. At block 2210, connection attributes are transmitted to the WUSB device over the trusted medium.

The following sections A-C are specific to the protocol used by the PONG system over USB trusted media, and the various interface descriptors required to implement PONG over USB at the PONG target device and The layout of the endpoint descriptor is shown.
A. PONG Device Interface Table 27 represents the interface descriptor and provides details of the values entered for the PONG device on USB. For most rows, a specific value or a specific set of values is provided. The vendor can be selected from a specified range, and all other values can be RESERVED for future use.

関連付け中のデバイスを識別するのに文字列を使用することができる。この文字列は、ＵＳＢ文字列記述子に局在化させることができる。良い文字列の一例は、「ＰＯＮＧ−Wireless USB Mouse」（ＰＯＮＧ−無線ＵＳＢマウス）である。一例の実施形態では、ＰＯＮＧインターフェースは、インターフェースアソシエーション記述子でグループ化されない。ＵＳＢデバイスは、１つの構成当たり２つ以上のＰＯＮＧインターフェースを有するように構成することはできない。
Ｂ．ＰＯＮＧデバイスエンドポイント
本当に安いデバイスを可能にするために、制御エンドポイントを使用することができ、割り込みエンドポイントは（拡張機能では）オプションである。制御エンドポイントを使用することによって、低速ＵＳＢデバイスも可能になる。制御エンドポイント（エンドポイント０ｘ００）は、インターフェース記述子の下では記述される必要はなく、すべてのＵＳＢデバイスに存在しなければならない。

A string can be used to identify the device being associated. This string can be localized to the USB string descriptor. An example of a good character string is “PONG-Wireless USB Mouse”. In one example embodiment, PONG interfaces are not grouped by interface association descriptor. A USB device cannot be configured to have more than one PONG interface per configuration.
B. PONG Device Endpoint A control endpoint can be used to allow a really cheap device, and an interrupt endpoint is optional (with extensions). By using a control endpoint, low speed USB devices are also possible. The control endpoint (Endpoint 0x00) does not need to be described under the interface descriptor and must be present in all USB devices.

  The smart device may choose to perform the association function after device enumeration is complete. To accomplish this, the device can implement an optional interrupt IN endpoint. This endpoint facilitates notification of new association requests. An example of a standard endpoint descriptor for this optional endpoint is shown in Table 28 as an interrupt IN endpoint descriptor.

デバイスのＰＯＮＧインターフェースが、オプションのエンドポイントを含まない場合、関連付けは、列挙時に行うことができる。このようなデバイスがアソシエーションプロセスを開始したい場合、デバイスは、デバイスが開始するＵＳＢリセットを行うことができる。これによって、デバイスをホストにより再列挙することができ、その時点で、ホストは、デバイスからアソシエーション要求を取り出すことができる。また、デバイスは、ＨＵＢ機能も実施して、そのデバイスを往来させることができる。
Ｃ．ＰＯＮＧクラス特有の要求
すべてのＰＯＮＧデータ転送は、制御エンドポイント上で行われる。これらの転送は、ＰＯＮＧクラス要求の形とすることができる。表２９は、ＰＯＮＧデバイスによってサポートされるＰＯＮＧクラス要求のリストを示している。bRequestの有効な値が示されている。

If the device's PONG interface does not include an optional endpoint, the association can be done at enumeration. If such a device wishes to initiate the association process, the device can perform a USB reset initiated by the device. This allows the device to be re-enumerated by the host, at which point the host can retrieve the association request from the device. The device can also perform a HUB function to move the device back and forth.
C. PONG Class Specific Requests All PONG data transfer is done on the control endpoint. These transfers can be in the form of PONG class requests. Table 29 shows a list of PONG class requests supported by the PONG device. Valid values for bRequest are shown.

Ｃ．１．GET_ASSOCIATION_INFORMATION
この要求は、デバイスからassociation_information（アソシエーション情報）構造体を取り出す。このassociation_informationは、REQUEST_INFOブロックのリストを含む。各REQUEST_INFOブロックは、デバイスが発行したい単一のアソシエーション要求に関するものである。表３０は、一例のGET_ASSOCIATION_INFORMATION要求を示している。

C. 1. GET_ASSOCIATION_INFORMATION
This request retrieves an association_information structure from the device. This association_information includes a list of REQUEST_INFO blocks. Each REQUEST_INFO block is for a single association request that the device wishes to issue. Table 30 shows an example GET_ASSOCIATION_INFORMATION request.

表３１は、association_informationデータ構造体の一例を示している。このデータ構造体の最初の数バイト（たとえば、３バイト）は、ヘッダセクションとすることができる。

Table 31 shows an example of the association_information data structure. The first few bytes (eg, 3 bytes) of this data structure can be a header section.

表３２は、association_informationフラグの例を示している。

Table 32 shows an example of association_information flag.

表３３は、request_info（要求情報）構造体を示している。

Table 33 shows a request_info (request information) structure.

Ｃ．２．GET_ASSOCIATION_REQUEST
この要求は、デバイスから特定のアソシエーション要求を取り出す。この要求は、wValueフィールド内のRequestID値によって識別される。表３４は、一例のGET_ASSOCIATION_REQUEST要求を示している。

C. 2. GET_ASSOCIATION_REQUEST
This request retrieves a specific association request from the device. This request is identified by the RequestID value in the wValue field. Table 34 shows an example GET_ASSOCIATION_REQUEST request.

要求ブロックは、４ＫＢのデータブロックとすることができる。制御転送の最大転送サイズは、６４ＫＢに設定することができる。したがって、理論的には、各GET_ASSOCIATION_REQUESTにおいて１６個の要求ブロックを転送することができる。転送される実際のデータ量は、wLengthフィールドによって指定される。wValueフィールドで指定されたBlockNumberは、この制御転送の開始ブロック番号を識別する。デバイスは、RequestIDによって指定される要求のアソシエーション要求データを、オフセットBlockNumber×４ＫＢから開始して、wLengthバイトを転送して返すことができる。
Ｃ．３．SET_ASSOCIATION_RESPONSE
この要求は、wValueフィールドのRequestID値によって識別される特定のアソシエーション要求に対する応答を送信する。表３5は、一例のSET_ASSOCIATION_RESPONSEを示している。

The request block may be a 4 KB data block. The maximum transfer size for control transfer can be set to 64 KB. Therefore, theoretically, 16 request blocks can be transferred in each GET_ASSOCIATION_REQUEST. The actual amount of data transferred is specified by the wLength field. The BlockNumber specified in the wValue field identifies the starting block number for this control transfer. The device can return the association request data of the request specified by the RequestID, starting from the offset BlockNumber × 4 KB and transferring the wLength bytes.
C. 3. SET_ASSOCIATION_RESPONSE
This request sends a response to the specific association request identified by the RequestID value in the wValue field. Table 35 shows an example of SET_ASSOCIATION_RESPONSE.

TransferFlags値は、値の０個以上のビットごとのＯＲである。一例のTransferFlags値が表３６に示されている。

The TransferFlags value is an OR for zero or more bits of the value. An example TransferFlags value is shown in Table 36.

ＰＯＮＧシステムは、割り込みＩＮメッセージを実施することができる。たとえば、NewAssociationRequest（新アソシエーション要求）は、デバイスが、処理する必要がある新しいアソシエーション要求又は変更されたアソシエーション要求を有することをホストに示すのに使用できる割り込みＩＮメッセージである。ホストは、このメッセージを受信すると、GET_ASSOCIATION_INFORMATION要求を発行し、それに応じてこれらの要求を処理する。表３７は、一例のNewAssociationRequestを示している。

The PONG system can implement an interrupt IN message. For example, NewAssociationRequest is an interrupt IN message that can be used to indicate to the host that the device has a new association request or a modified association request that needs to be processed. When the host receives this message, it issues a GET_ASSOCIATION_INFORMATION request and processes these requests accordingly. Table 37 shows an example NewAssociationRequest.

図２３は、本明細書で説明した特定のデータ構造体を使用してデバイスを関連付けるための一例のプロセス２３００を示している。この一例のプロセス２３００は、ＨＯＳＴがＵＳＢでデバイスを構成するためのＰＯＮＧシステム等の拡張可能アーキテクチャにおいて実施することができる。プロセス２３００は、上述した要求及び応答と共に実施することができる。

FIG. 23 illustrates an example process 2300 for associating devices using the particular data structures described herein. This example process 2300 may be implemented in an extensible architecture such as a PONG system for HOST to configure devices with USB. Process 2300 may be implemented with the requests and responses described above.

At block 2304, GET_ASSOCIATION_INFORMATION is sent. In one embodiment, the request includes at least 3 bytes of data. At block 2306, the size of the entire association information is determined. This size is
Size = 3 + sizeof (REQUEST_INFO) x PendingRequestCount
Can be obtained.

  At decision block 2308, a determination is made whether all association information has been received. If all association information has not been received, process 2300 returns to block 2304. If all association information has been received, the process 2300 moves to decision block 2310. At decision block 2310, a determination is made whether there are any pending requests. For example, this determination can be made by determining whether the PendingRequestCount data structure is greater than zero. If there are no pending requests (eg, PendingRequestCount = 0), the process 2300 ends. If there are pending requests, process 2300 proceeds to block 2312 where the process selects a request to handle.

At block 2314, the size of the transfer is determined. This size is
Size = max (remaining bytes, N × 4 KB (where 0 <N ≦ 16))
Can be obtained.

  At block 2316, GET_ASSOCIATION_REQUEST is sent for the appropriate amount of data. The RequestID should match the RequestID of the association information. BlockNumber should be the starting block number to be returned. At decision block 2318, a determination is made whether there is more request data. If there is requested data, process 2300 returns to block 2314. If there is no request data, the process proceeds to block 2320, where the association request is handled and a response is generated.

  At block 2322, the size of the response transfer is determined. At block 2324, GET_ASSOCIATION_RESPONSE is sent for the appropriate amount of data. The RequestID should match the RequestID of the request. If this transfer includes the last byte of the response, LastBlock should be set. At decision block 2326, a determination is made whether there is more data. If there is data, process 2300 returns to block 2322. If there is no more data, the process continues to decision block 2328 where a determination is made whether there are more requests. If there is a request, process 2300 returns to block 2312. If there are no more requests, the process moves to decision block 2330 where a determination is made whether an AdditionalRequests flag has been set in the association information. If the AdditionalRequests flag has been set, the process 2300 returns to block 2304. If this flag is not set, the process ends.

  It is possible that a device that supports the PONG interface may not actually be ready to send a PONG association request during device enumeration. For example, perhaps the device is actually a type of cradle for other devices that support PONG on some unique interface. USB PONG devices have already been enumerated long before the target device is inserted into its cradle. The systems and techniques described above provide a mechanism for notifying the PONG driver that the PONG driver needs to retrieve new association information.

  Also, certain devices (eg, devices with multiple target media) may need to support multiple association requests. These individual association requests may be dependent on each other or may be totally independent. Independent association is when the device wants to associate multiple target media at once without paying attention to the order in which the target media are associated. The systems and techniques described above support scenarios in which after receiving an association response from a host, the device decides to issue a new association request as a result of the response.

  What has been described above includes examples of the described invention. Of course, it is not possible to describe every possible combination of components or methodologies to illustrate the invention, but those skilled in the art will recognize that many other combinations and variations of the invention are possible. Can be recognized. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Further, in terms of the use of the term “includes” in the detailed description or in the claims, such terms are used when “comprising” is used as a transition term in the claims. Is intended to be comprehensive as well as the term “comprising”.

1 is a block diagram of an association architecture according to an aspect of the present invention. FIG. 4 is an association request diagram in accordance with an aspect of the present invention. FIG. 4 is an association response diagram according to an aspect of the present invention. 1 is a block diagram of an association management system according to an aspect of the present invention. 1 is a block diagram of an association management system according to an aspect of the present invention. 1 is a block diagram of an association handler system according to one aspect of the present invention. FIG. 1 is a block diagram of an association driver system according to an aspect of the present invention. FIG. 4 is a flowchart of a method for associating devices according to an aspect of the present invention. 6 is a flowchart of a method that facilitates device association, in accordance with an aspect of the present invention. 4 is a flowchart of a method of associating a device via a USB connection according to an aspect of the present invention. 11 is a flowchart further illustrating the method of FIG. 12 is a flowchart further illustrating the method of FIGS. 10 and 11. 3 is a flowchart of an association management method according to an aspect of the present invention. 3 is a flowchart of an association management method according to an aspect of the present invention. 15 is a flowchart further illustrating the method of FIG. 16 is a flowchart further illustrating the method of FIGS. 4 is a flowchart of an association handler method according to an aspect of the present invention. It is a figure which shows the operating environment of an example in which this invention can function. It is a figure which shows an example of a PONG system. FIG. 3 illustrates an example USB driver stack of an operating system device manager architecture. It is a figure which shows the example of operation for a WUSB device to connect with a host device. FIG. 6 illustrates an example process for connecting a WUSB device with a host device using the system described herein. FIG. 6 illustrates an example process for associating a device using a particular data structure described herein.

Claims (16)

One or more device-readable media encoded with device-executable instructions for performing the following steps, comprising:
Identifying an association request from a wireless universal serial bus (WUSB) device via a trusted medium;
Analyzing the association request, determining an association type included in the association request, and determining that the requested association type is WUSB ;
Checking the validity of the analyzed association request based on the WUSB standard;
Generating a device attribute describing the WUSB device;
Identifying the handler based on the association type;
Transmitting the device attribute to a handler of the WUSB device;
One or more device readable media comprising receiving connection attributes from the handler and transmitting the connection attributes to the WUSB device via the trusted medium. One or more device readable media according to claim 1, comprising the steps of:
A device readable medium further comprising allowing the WUSB device to connect through a wireless medium according to the connection attributes. The one or more device-readable media of claim 1, wherein
The device readable medium, wherein the trusted medium is a wired medium. The one or more device-readable media of claim 1, wherein
The trusted media includes at least one of a wired USB connection, a firewire connection, an Ethernet connection, a serial connection, a parallel connection, a wireless connection, a near field communication (NFC) connection, or an infrared (IR) connection. Medium. The one or more device-readable media of claim 1, wherein
The device readable medium, wherein the device attribute includes at least one of an association type identifier, a connection device identifier, a connection key identifier, a device setup class GUID, a supported band group, or an integrator site URL. The one or more device-readable media of claim 1, wherein
The device-readable medium, wherein the connection attribute includes at least one of a connection host identifier, a connection device identifier, a connection key identifier, a preferred channel, or a host region. A connection device comprising a wireless universal serial bus (WUSB) component, the connection device configured to send an association request to a host device over a trusted medium, wherein the association request is a device attribute associated with the connection device. And the association request further determines the association type included in the association request when analyzed by the host device, and based on the WUSB standard, the analyzed association request to confirm the validity of, include information, said connection device, said host device and WU using the connection attribute with a handler on the host device receives the connection attributes based on the association type Further configured, connected device to establish the B connection. The connection device according to claim 7 .
A connection device, wherein the trusted medium is a wired connection. The connection device according to claim 8 , comprising:
A connection device further comprising a wired component configured to communicate with the host device through the wired connection. The connection device according to claim 9 , wherein
The wired device includes at least one of a wired USB connection, a fire wire connection, an Ethernet (registered trademark) connection, a serial connection, and a parallel connection. The connection device according to claim 8 .
The connection device, wherein the device attribute includes at least one of an association type identifier, a connection device identifier, a connection key identifier, a device setup class GUID, a supported band group, or an integrator site URL. The connection device according to claim 8 .
The connection device, wherein the connection attribute includes at least one of a connection host identifier, a connection device identifier, a connection key identifier, a preferred channel, or a host region. The connection device according to claim 8 .
The connection device is further configured to deploy the WUSB component and connect to the host device using the connection attribute. A communication method between a connection device and a host device, wherein the connection device and the host device are connected to a wired medium, the method comprising:
Transmitting an association request including device attributes related to a WUSB component of the connection device from the connection device to the host device through the wired medium;
Analyzing, by the host device, the association request and determining an association type included in the association request;
Determining a connection attribute related to WUSB connection by the host device;
Checking the validity of the analyzed association request and the connection attribute based on the WUSB standard in the host device,
Transmitting a response including the connection attribute from the host device to the connection device through the wired medium; and establishing a connection with the host device using the connection attribute by the connection device;
A communication method between a connected device and a host device. The communication method between the connection device and the host device according to claim 14 ,
The communication method, wherein the device attribute includes at least one of an association type identifier, a connection device identifier, a connection key identifier, a device setup class GUID, a supported band group, or an integrator site URL. The communication method between the connection device and the host device according to claim 14 ,
The communication method, wherein the connection attribute includes at least one of a connection host identifier, a connection device identifier, a connection key identifier, a preferred channel, or a host region.

Images