Electrical computers and digital data processing systems: input/ – Input/output data processing – Input/output access regulation
Reexamination Certificate
2000-12-21
2004-12-14
Gaffin, Jeffrey (Department: 2182)
Electrical computers and digital data processing systems: input/
Input/output data processing
Input/output access regulation
C710S008000, C710S010000, C710S016000, C710S033000, C710S062000, C710S065000, C710S038000
Reexamination Certificate
active
06832273
ABSTRACT:
TECHNICAL FIELD
The following description relates generally to the use of peripheral devices with software applications. More specifically, the following description relates to the use of device specific information and resources with such software
1
applications.
BACKGROUND OF THE INVENTION
The Universal Serial Bus (USB) is a cable bus that supports data exchange between a host computer and a wide range of simultaneously accessible peripheral devices. The attached peripheral devices share USB bandwidth through a host-scheduled, token-based protocol. The bus allows peripherals to be attached, configured, used, and detached while the host and other peripherals are in operation.
The USB is defined by a specification that is approved by a committee of industry representatives. The specification covers all aspects of USB operation, including electrical, mechanical, and communications characteristics. To be called a USB device, a peripheral must conform to this very exacting specification.
USB device information is typically stored in so-called “descriptors” or request codes—data structures formatted as specified by the USB specification. Descriptors are used in a USB system to define “device requests” from a host to a peripheral device. A device request is a data structure that is conveyed in a “control transfer” from the host to the peripheral device. A control transfer contains the following fields:
bmRequestType—a mask field indicating (a) the direction of data transfer in a subsequent phase of the control transfer; (b) a request type (standard, class, vendor, or reserved); and (c) a recipient (device, interface, endpoint, or other). The primary types of requests specified in the “request type” field are the “standard” and “vendor” types, which will be discussed below.
bRequest—a request code indicating one of a plurality of different commands to which the device is responsive.
wValue—a field that varies according to the request specified by bRequest.
wIndex—a field that varies according to request; typically used to pass an index or offset as part of the specified request.
wLength—number of bytes to transfer if there is a subsequent data stage.
All USB devices are supposed to support and respond to “standard” requests—referred to herein as “USB-specific” requests. In USB-specific requests, the request type portion of the bmRequestType field contains a predefined value indicative of the “standard” request type.
Each different USB-specific request has a pre-assigned USB-specific request code, defined in the USB specification. This is the value used in the bRequest field of the device request, to differentiate between different USB-specific requests. For each USB-specific request code, the USB specification sets forth the meanings of wValue and wIndex, as well as the format of any returned data.
USB devices can optionally support “vendor” requests—referred to herein as “device-specific” requests. In a device-specific request, the request type portion of the bmRequestType field contains a predefined value to indicate a “vendor” request type. In the case of device-specific requests, the USB specification does not assign request codes, define the meanings of wValue and wIndex, or define the format of returned data. Rather, each device has nearly complete control over the meaning, functionality, and data format of device-specific requests. Specifically, the device can define its own requests and assign device-specified request codes to them. This allows devices to implement their own device requests for use by host computers, and provides tremendous flexibility for manufacturers of peripherals.
The inventors have discovered a need for a similar feature that would benefit various hosts, application programs, host operating systems hardware manufacturers (OEMs), and Independent Hardware Vendors (IHVs). Specifically, designers of application programs and operating systems would value the opportunity to define their own device requests (and the associated responses), and to have such requests supported in a uniform way by compatible peripherals. Moreover, OEMs and IHVs would value the ability to supply additional USB device specific information to the hosts, application programs and host operating systems in response to such device requests. However, the different request types supported in the bmRequestType field of a USB device request do not include a “host” type of request.
As an example of this need for a host type of request, consider that the USB Device Working Group (DWG) has defined a set of standards that describe different types of USB devices. For each of these standards, the DWG has created a respective class specification that specifies static predetermined class and subclass numbers that correspond to the class specification. These specifications are designed such that to be in compliance with a particular class specification, an operating system must include only a single default, or “generic” device driver to control a USB device that is configured according to the particular class specification.
When a USB device is installed onto a system, the device indicates that it was created according to a particular DWG class specification by listing predefined class and subclass codes that correspond to the DWG specification. These predefined codes can be used by an operating system to load a single generic device driver to control the device.
However, it is often the case that a vendor of a USB device would prefer that a different, or “more specific” device driver be used to control the device, rather than the generic device driver supplied by the operating system. For example, a more specific device driver may be preferred to work around known bugs in the device's software, provide product identification, use value added features, and the like. Such more specific device drivers are typically supplied by OEM/IHV supplied installation media that are distributed with a device. Such installation media include installation disks (e.g., floppy diskettes) or setup computer program applications.
To provide for more specific device driver matches with respect to a USB device, USB device descriptors include markings that describe the manufacturer, product, and revision. An operating system (OS) can use such markings to determine whether a more specific, and therefore a more customized device driver match is available from the installation media. If for some reason a specific match is not found, the concepts of class and subclass codes, as described above, facilitate the loading of a generic device driver to control the device.
Unfortunately, unless the USB DWG has already allocated certain class and subclass codes for a particular USB device, that particular device cannot have a match based on class and subclass codes to identify a generic device driver to control the device. If the device's corresponding class and subclass codes are not supported by the DWG, an OEM/IHV distributing the device must at least provide installation media with the device to specify a given match that corresponds to a generic driver that is already present on the system. Otherwise, the OEM/IHV must supply a special device driver with the corresponding installation media.
In light of the above, a user of a device that specifies non-standard DWG class codes is required to use such installation media to load a device driver to control the device. It would be beneficial both in terms of simplifying matters for OEMs/IHVs and simplifying customer ease of use if an operating system could specify a default device driver that is already present on the system in response to installing a device that does not specify a standard USB DWG class and/or subclass code.
Ideally, an operating system vendor could develop a new standard USB device class—one not supported by DWG,and distribute a device driver to control devices built to that new standard with the operating system. In this manner, an OEM/IHV could not only distribute devices built to that standard before the USB DWG has adopted a corresponding class and
Bhesania Firdosh K.
Dunn John C.
Ray Kenneth D.
Casiano Angel L.
Gaffin Jeffrey
Lee & Hayes PLLC
Microsoft Corporation
LandOfFree
System and method to specify extended configuration... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method to specify extended configuration..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method to specify extended configuration... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3278183