A hardware abstraction layer (HAL), in modern operating systems, is interposed between physical hardware and operating system (OS). The hardware abstraction layer (HAL) is an abstraction layer, implemented in software, between the physical hardware of a computer and the software that runs on that computer. Its function is to hide differences in hardware from most of the operating system kernel, so that most of the kernel-mode code does not need to be changed to run on systems with different hardware. On a electronic device such as a computer, HAL can basically be considered to be the driver for the motherboard and allows instructions from higher level computer languages to communicate with lower level components, such as directly with hardware. Open source operating systems, and some other portable operating systems also have a HAL, even if it's not explicitly designated as such. Some operating systems, such as Linux, have the ability to insert one while running Popular expansion buses which are used on more than one architecture are also abstracted, such as ISA, EISA, PCI, PCI-E allowing, from the OS manufacturers point of view, drivers to also be highly portable with a minimum of code modification. As the HAL was introduced and is supplied by the manufacturer of the OS the OS, thus its manufacturer gains extensive control of the hardware. The OS is only capable to identify physical existent hardware by specific information held ready and passed by the hardware. A technique that allows to actively build all required information for a peripheral device before it is connected to the electronic device and even is able to morph the physical existent peripheral device into a device desired by the OS is not currently known in the art. However, such technique would offer significant advantages over the prior art.
A device driver, in electronic data processing, is a computer program that allows a higher-level computer program to interact with a hardware device. A device driver typically communicates with the device through the system bus or a communications subsystem to which the hardware is connected. When a calling program invokes a routine in the driver, the driver issues commands to the device. Once the device sends data back to the driver, the driver may invoke routines in the original calling program. Seen from the OS manufacturers point of view, a device driver simplifies programming by acting as an abstraction layer between a hardware device and the application and OS that uses it. The higher-level application code can be written independently of whatever specific hardware device it will ultimately control, as it can interface with it in a standard way, regardless of the underlying hardware. Every version of a device requires its own hardware-specific specialized commands.
In contrast, most applications utilize devices by means of simplified high-level device-generic commands. The device-driver accepts these commands and breaks them into a series of low-level device-specific commands as required by the device being driven. By design device drivers are hardware-dependent and operating-system-specific.
A virtual device driver as disclosed in U.S. Pat. No. 6,968,307 is a particular variant of device drivers. Instead of enabling the OS to dialog with physical existent hardware, a virtual device driver takes the opposite role and emulates a piece of hardware, so that the OS and its application programs have the illusion of accessing real hardware. Attempts by the OS or an application program to access the virtual hardware may also be routed to physical existent hardware.
U.S. Pat. No. 7,571,445 describes a system and method for dynamic device driver support in an open source operating system. This technique introduces a device driver for a computer system that includes an open source operating system, including an open source kernel. The device driver is constructed from an open source service layer and a set of precompiled driver modules that can be compiled against the kernel of the operating system. A service layer provides an interface between the kernel of the operating system and a set of applicable driver modules. Although this method allows the usage of one OS service layer for multiple hardware devices hardware specific device drivers for each peripheral device are still needed. A solution for physical existent devices that do not have a driver that matches the device identifier of the device is not included.
U.S. Pat. No. 6,754,725 discloses an USB peripheral that contains its own device driver. The invention concerns a peripheral device comprising a computer readable media and an interface circuit. The computer readable media may be configured to store instructions for operating the peripheral device. The interface circuit may be configured to communicate the instructions to an operating system of a computer in response to connection of the peripheral device to the computer. Although this invention eliminates the need to install a hardware specific device driver from separate media it requires a computer readable media in the device itself therefore making it impossible to use the invention on devices that do not provide such a capability. As the invention still requires a hardware-specific device driver it does not give an acceptable answer to the question how devices that have no such driver can communicate with the computer.
In U.S. Pat. No. 5,794,032 a system for the identification and configuration of computer hardware peripherals is shown that allows the automatic identification and configuration of a computer peripheral. The system uses an initialization program to send one or more query instructions to a peripheral device. In response to the query instructions, the peripheral drive replies with data that can be used to uniquely identify the model number or type of the device. The system then selects the appropriate software driver for the identified peripheral device and loads the selected driver. This approach also requires appropriate hardware specific drivers to be installed on the computer before the peripheral device is plugged in. As the HAL of modern operating systems permits direct hardware access this technique is only applicable for operating systems that do not have such intermediate layer.
U.S. Pat. No. 7,574,713 discloses methods, systems, and computer program products for instantiating a device driver for communication with a device by dynamically associating the device driver at run-time with a device-specific and/or service-specific software component. This may be done by instantiating a device driver for communication with a device by dynamically associating the device driver at run-time with a device-specific software component. The software component contains information that facilitates communication with devices of a specific type. In other embodiments, a device driver is instantiated by defining a plurality of device parameters and associating one or more of the plurality of device parameters with a service. The device parameters that are associated with the service are then dynamically communicated to the device driver at run-time. Thus, a generic device driver may be dynamically configured at run-time to communicate with devices of a particular device type and/or device parameters may be associated with a service and communicated to the device driver. These device parameters that are associated with a particular service and then passed to the device driver may allow the device driver to collect data from a particular device that is relevant to a particular service offering. Although this invention allows ultra flexible access to and configuration of devices it requires the lower level components to be recognized and accessible by the HAL before the methods can come into operation.
U.S. Pat. No. 7,275,118 shows an input/output (I/O) device driver loading method for a data processing system that involves communication of a secondary I/O device driver to a data processing system using a primary I/O device driver. An initial (first) device identification information is passed from the peripheral device to the data processing system. This first device identification information corresponds to a first I/O device driver in the data processing system. By utilizing the invention the device then transmits a second I/O device driver from the peripheral device to the data processing system using the first I/O device driver in the data processing system. A second device identification information is then passed from the peripheral device to the data processing system. Although this method allows the use of simplified generic device class drivers to establish an initial communication with the data processing system to transmit additional device drivers and device identification information to the data processing system it requires the device to be plugged into the data processing system and a hardware specific device driver to be available for the peripheral device. Also this method does not give an acceptable answer to the question on how devices can be installed and used that do not have a hardware specific driver for any of the transmitted device identification information.
U.S. Pat. No. 6,345,319 discloses a setting method for installation of a plug and play device by utilizing the set-up file (INF) of a hardware driver. The method reads the device ID of a new device and copies the driver file of the new device to the corresponding directory. The device ID and all related device class of an already installed (original) device is deleted from the computer's registry. After a restart of the computer the OS displays that a new device is found and automatically establishes the relationship between the new device and the previously installed driver through the new device ID and class in order to let the new device be operated normally.
Although the invention describes a method to make changes to an existing system configuration it requires an already installed compatible device and a hardware-specific device driver for the new device. In addition a restart of the computer is mandatory. The required deletion of existing registry entries most likely will be prohibited by the OS or my lead to serious corruption of the computers registry.
USPTO Backgrounds
USPTO Backgrounds