Electrical computers and digital data processing systems: input/ – Input/output data processing – Input/output access regulation
Reexamination Certificate
2000-02-04
2002-11-19
Shin, Christopher B. (Department: 2182)
Electrical computers and digital data processing systems: input/
Input/output data processing
Input/output access regulation
C710S011000, C710S313000
Reexamination Certificate
active
06484219
ABSTRACT:
TECHNICAL FIELD
The following relates to device requests made to USB devices and to methods of implementing device requests that are defined by a host system rather than by the USB standard or by the device itself.
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.
One significant feature of USB is that it allows peripheral devices to store information about themselves, and to provide such information upon request to host computers. This avoids the need for the computer, operating system, or application programs to maintain this information for many different devices. Instead, the device stores and provides its own information.
The USB device information is typically stored in so-called “descriptors”—data structures formatted as specified by the USB specification. These descriptors contain information that is primarily related to device controls joysticks, buttons, wheels, sliders, etc.). They describe the type of each control, the format of data generated by the control, the range of values generated by the control, and many other characteristics.
In defining the USB communications protocol, the USB committee attempted to foresee future needs, and to provide ways to accommodate such needs within the existing protocol. In addition, the USB specification is updated from time to time, thereby providing a mechanism for adding further functionality while still retaining backward compatibility.
It was recognized from an early date that certain peripherals might need to define their own descriptors or request codes, relating to new features or technology not encompassed by the USB-defined descriptors. This capability was provided by reserving certain request codes for definition and use by individual peripheral manufacturers.
Request codes 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 a USB-specific request, 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, and host operating systems. 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.
As an example of this need, a co-pending US Patent Application (“System and Method for Mapping Input Device Controls to Software Actions,” Ser. No. 09/483,113, filed Jan. 10, 2000), describes a technique in which different controls of a device are arranged in different combinations for use with application programs of different “genres.” For each genre, the controls of the device are enumerated along with standard “actions” that are to be initiated in response to the respective controls.
Although such information can be maintained at the host for various different controllers, it would be desirable for each controller to store its own genre information, and to make it available through a predefined USB device request. However, such a device request is not defined by the USB specification.
Ideally, a device request such as this would be defined by the host or by the manufacturer of an operating system that executes on the host, and supported uniformly by peripheral devices. Because of this, the device request might be referred to as a “host-specific” device request—in contrast to “USB-specified” requests and “device specific” requests.
However, the different request types supported in the bmRequestType field of a USB device request do not include a “host” type of request.
One possible solution to this problem would be to simply usurp a vendor-specific request code, and attempt to persuade all device manufacturers to use this request code to initiate an agreed-upon host-specific device request. However, this would not provide backward compatibility in the case that the chosen request code was used in previously manufactured devices for different, vendor-specific requests.
Another possibility might be to work with the USB committee to define a new type of request—possibly including a range of request codes for use by host computers. However, this would be a very long term project, and would not produce results quickly enough to be useful in current host program versions.
Accordingly, the inventors have devised a technique that allows a host system to define and issue host-specific device requests while remaining within the current USB specification and maintaining backward compatibility with previous generations of USB peripheral devices.
SUMMARY
Described below is a technique for implementing a host-specific device request in a USB system. The system includes a USB device that responds to device requests from a host. The device requests include USB-specific device requests with corresponding USB-specified request codes and device-specific device requests with corresponding device-specific request codes. The USB-specific requests include a GET_DESCRIPTOR device request that is initiated with a corresponding GET_DESCRIPTOR request code.
The described tech
Bhesania Firdosh K.
Dunn John C.
Ray Kenneth D.
Lee & Hayes PLLC
Microsoft Corporation
Shin Christopher B.
LandOfFree
Host-specified USB device requests does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Host-specified USB device requests, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Host-specified USB device requests will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2958707