111111111111111111111111111111111111111111111111111111111111111111111111111US009122623Bl

(12) United States PatentWieland

(10) Patent No.:(45) Date of Patent:

US 9,122,623 Bl*Sep.l,2015

(54) METHOD FOR CREATION OF DEVICEDRIVERS AND DEVICE OBJECTS FORPERIPHERAL DEVICES

(58) Field of Classification SearchNoneSee application file for complete search history.

(71) Applicant: Open Invention Network LLC,Durham, NC (US)

(56) References Cited

U.S. PATENT DOCUMENTS

(72) Inventor: Martin Wieland, Munich (DE)

(21) Appl. No.: 14/471,223

(73) Assignee: Open Invention Network, LLC,Durham, NC (US)

( *) Notice:

8/1994 Crick 713/16/2000 Garney 710/157/2001 Chrabaszcz 710/3024/2003 Boyle et aI 713/25/2003 Tabares et al. 709/321

12/2003 Paul 709/32111/2004 Goodman 710/811/2005 Belvin et al. 719/32810/2006 Yoshimura et al. 713/12/2008 Suzuki et al. 710/302

5,339,432 A *6,081,850 A *6,263,387 Bl *

2003/0070063 Al *2003/0088711 Al *2003/0225928 Al *2004/0230710 Al *2005/0257226 Al *2006/0230261 Al *2008/0040526 Al *

* cited by examiner

Primary Examiner - Elias Mamo(74) Attorney, Agent, or Firm - Haynes and Boone, LLP

(57) ABSTRACT

All steps required to create and operate a peripheral device ofan electronic device can be performed without the need toplug in the peripheral device to the electronic device. Setupinformation for a peripheral device is extracted, modified andstored to fit to a physical existent peripheral device. Themodified setup information is used to create a data structurethat is passed to the peripheral bus driver. As the data structurecontains a hot plug notification the reception causes theperipheral bus driver to initiate the setup process for theperipheral device. As the data structure is built from setupinformation that is available at the electronic device no addi­tional user action is required. The invention also allows thecreation of a device object for existing signed driver packetsthat may not be altered.

20 Claims, 6 Drawing Sheets

(2006.01)(2006.01)(2006.01)

Subject to any disclaimer, the term of thispatent is extended or adjusted under 35U.S.c. 154(b) by 0 days.

This patent is subject to a terminal dis­claimer.

Filed: Aug. 28, 2014

Int. Cl.G06F 3/00G06F 13/10G06F 13/36U.S. Cl.CPC G06F 13/102 (2013.01); G06F 13/36

(2013.01)

Related U.S. Application Data

Continuation of application No. 14/044,086, filed onOct. 2, 2013, now Pat. No. 8,825,911, which is acontinuation of application No. 121711,462, filed onFeb. 24, 2010, now Pat. No. 8,554,957.

(52)

(51)

(22)

(63)

300

/LOAD DEVICE IDENTIFICATION

r-------~------...,__ 301QUERY SETUP INFORMATION

REPLACE DEVICE IDENTIFICATION

EXTRACT SECTIONS

__ 302

303./

304/"

STORE SETUPINFORMATION

CREATE DATA STRUCTURE__ 305

PASS DATA STRUCTURE TOPERIPHERAL BUS DRIVER

__ 306

rFJ

=­('D('D.........o....0\

~7J).•~~~

~=~

No....Ul

....~

drJl

,,'C

"""'"NN0-.,NW

="""'"

rFJ('D

'?IDEVICE I

109

110I

DEVICE

107/'

PERIPHERAL BUSINTERFACE

PERIPHERAL DEVICEINTERFACE,

111

NON VOLATILEMEMORY

SYSTEM BUS - 105

100/

1061- 101 /' iVOLATILE MEMORY i PROCESSING

UNITOPERATING -102SYSTEM -APPLICATION

-PROGRAMS - 103

PROGRAMI

DATA -104

FIG.1

210203

I204

I205

I

~7J).•~~~

~=~

No....Ul

rFJ

=­('D('D.....No....0\

....~

drJl

,,'C

"""'"NN0-.,NW

="""'"

rFJ('D

'?

INF FILESCATALOG FILES I"208

.. ...,/ KERNEL MODE

~

USER MODE.,

NEW DEVICEPnPMANAGER

...PnP MANAGER DLL...

JJf'

J

207/

CFGMGRAPI ......a...,

SETUP API ......

"209

/206

.. CO-INSTALLERS.,CLASS INSTALLERS

I IBUS /201

FIG.2

300

/

~7J).•~~~

~=~LOAD DEVICE IDENTIFICATION

, T • 301

QUERY SETUP INFORMATION

______ 302

EXTRACT SECTIONS I 303 /' 304

/'· I+- STORE SETUPI REPLACE DEVICE IDENTIFICATION INFORMATION

+CREATE DATA STRUCTURE .------ 305

rFJ('D

'?....~

No....Ul

rFJ

=­('D('D.....(.H

o....0\

FIG.3

PASS DATA STRUCTURE TOPERIPHERAL BUS DRIVER

______ 306

drJl

,,'C

"""'"NN0-.,NW

="""'"

SEND 1/0 REQUEST PACKET

401

"'"

408...............

FIG_4

• T • 400

RESPONDTO110 REOUEST

402---HARDVVARE IDsCOMPATIBLE IDs

405,...-407,...-

FILE

RANKED DRIVER LIST

~7J).•~~~

~=~

rFJ('D

'?....~

No....Ul

rFJ

=­('D('D.....,j;o,.

o....0\

drJl

,,'C

"""'"NN0-.,NW

="""'"

u.s. Patent Sep.l,2015 Sheet 5 of 6 US 9,122,623 Bl

Lt).(!)u:

a:wC)«z<{

2 ,-...0..Z C0.. f+ zw wC0.:?! ~

a:wen:::::>

a:wC)«z«20..Z

..... 0..WCo2...JWZa:w~

wa:::>r-u::>a:r-en>-a:«a:00..2w Lt)r-

""'"0 0Lt) Lt)

8_ 4~

\Lt)

w ......J r"-U.

Z (II")

,-.,., 0 0a: Lt)

~ w\z >- :2: 0::C)~ a: Cw 0CO u. en

z ::>~ - Z CO

0.. C)Q::>r- 3~ -+w ...(/) 0..(.)r-iI \ I0-:I:b

~ C\IZ 0 0LO Lt)

No....Ul

....~

~7J).•~~~

~=~

rFJ

=­('D('D.....0\o....0\

rFJ('D

'?

605/'

604

BUS DEVICES IDBUS INSTANCE ID

BUS CONTAINER ID

,..".603

606/'

1

DEVICE OBJECT,, .1.. _ .............. _ ........

-- /'r-------t----------.••

... PHYSICAL DEVICE I ,..".600 .."".-60...

NON VOLATILE MEMORY IlII602

" • .LHOT PLUG HARDWARE ID

NOTIFICATION COMPATIBLE ID

• +BUS

DRIVER

FIG.6 606-HARDWARE ID

COMPATIBLE ID

drJl

,,'C

"""'"NN0-.,NW

="""'"

US 9,122,623 Bl1

METHOD FOR CREATION OF DEVICEDRIVERS AND DEVICE OBJECTS FOR

PERIPHERAL DEVICES

CROSS-REFERENCE TO RELATEDAPPLICATIONS

This application is a continuation of application Ser. No.14/044,086, entitled "METHOD FOR CREATION OFDEVICE DRIVERS AND DEVICE OBJECTS FORPERIPHERAL DEVICES", filed on Oct. 2, 2013, now issuedU.S. Pat. No. 8,825,911, issued on Sep. 2, 2014, which is acontinuation of application Ser. No. 121711,462, entitled"METHOD FOR CREATION OF DEVICE DRIVERS ANDDEVICE OBJECTS FOR PERIPHERAL DEVICES", filedon Feb. 24, 2010, now issued U.S. Pat. No. 8,554,957, issuedon Oct. 8, 2013, the entire contents of each are hereby incor­porated by reference in their entirety.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to a method for connecting anelectronic device to a peripheral device generally and, moreparticularly, to a method for creation and setup of a devicedriver for peripheral devices that do not have a driver thatmatches the device identifier of the peripheral device.

BACKGROUND OF THE INVENTION

A hardware abstraction layer (HAL), in modern operatingsystems, is interposed between physical hardware and oper­ating system (OS). The hardware abstraction layer (HAL) isan abstraction layer, implemented in software, between thephysical hardware ofa computer and the software that runs onthat computer. Its function is to hide differences in hardwarefrom most ofthe operating system kernel, so that most of thekernel-mode code does not need to be changed to run onsystems with different hardware. On a electronic device suchas a computer, HAL can basically be considered to be thedriver for the motherboard and allows instructions fromhigher level computer languages to communicate with lowerlevel components, such as directly with hardware. Opensource operating systems, and some other portable operatingsystems also have a HAL, even ifit' s not explicitly designatedas such. Some operating systems, such as Linux, have theability to insert one while running. Popular expansion buseswhich are used on more than one architecture are alsoabstracted, such as ISA, EISA, PCI, PCI-E allowing, from theOS manufacturers point of view, drivers to also be highlyportable with a minimum of code modification. As the HALwas introduced and is supplied by the manufacturer ofthe OSthe OS, thus its manufacturer gains extensive control of thehardware. The OS is only capable to identifY physical existenthardware by specific information held ready and passed bythe hardware. A technique that allows to actively build allrequired information for a peripheral device before it is con­nected to the electronic device and even is able to morph thephysical existent peripheral device into a device desired bythe OS is not currently known in the art. However, suchtechnique would offer significant advantages over the priorart.

A device driver, in electronic data processing, is a com­puterprogram that allows a higher-level computer program tointeract with a hardware device. A device driver typicallycommunicates with the device through the system bus or acommunications subsystem to which the hardware is con­nected. When a calling program invokes a routine in the

2driver, the driver issues commands to the device. Once thedevice sends data back to the driver, the driver may invokeroutines in the original calling program. Seen from the OSmanufacturers point of view, a device driver simplifies pro­gramming by acting as an abstraction layer between a hard­ware device and the application and OS that uses it. Thehigher-level application code can be written independently ofwhatever specific hardware device it will ultimately control,as it can interface with it in a standard way, regardless of the

10 underlying hardware. Every version of a device requires itsown hardware-specific specialized commands.

In contrast, most applications utilize devices by means ofsimplified high-level device-generic commands. The device­driver accepts these commands and breaks them into a series

15 of low-level device-specific commands as required by thedevice 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

20 enabling the OS to dialog with physical existent hardware, avirtual device driver takes the opposite role and emulates apiece ofhardware, so that the OS and its application programshave the illusion ofaccessing real hardware. Attempts by theOS or an application program to access the virtual hardware

25 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 operatingsystem. This technique introduces a device driver for a com­puter system that includes an open source operating system,

30 including an open source kernel. The device driver is con­structed from an open source service layer and a set of pre­compiled driver modules that can be compiled against thekernel of the operating system. A service layer provides aninterface between the kernel ofthe operating system and a set

35 of applicable driver modules. Although this method allowsthe usage of one OS service layer for multiple hardwaredevices hardware specific device drivers for each peripheraldevice are still needed. A solution for physical existentdevices that do not have a driver that matches the device

40 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 aperipheral device comprising a computer readable media andan interface circuit. The computer readable media may be

45 configured to store instructions for operating the peripheraldevice. The interface circuit may be configured to communi­cate the instructions to an operating system of a computer inresponse to connection of the peripheral device to the com­puter. Although this invention eliminates the need to install a

50 hardware specific device driver from separate media itrequires a computer readable media in the device itself there­fore making it impossible to use the invention on devices thatdo not provide such a capability. As the invention still requiresa hardware-specific device driver it does not give an accept-

55 able answer to the question how devices that have no suchdriver can communicate with the computer.

In U.S. Pat. No. 5,794,032 a system for the identificationand configuration ofcomputer hardware peripherals is shownthat allows the automatic identification and configuration ofa

60 computer peripheral. The system uses an initialization pro­gram to send one or more query instructions to a peripheraldevice. In response to the query instructions, the peripheraldrive replies with data that can be used to uniquely identifYthe model number or type of the device. The system then

65 selects the appropriate software driver for the identifiedperipheral device and loads the selected driver. This approachalso requires appropriate hardware specific drivers to be

US 9,122,623 Bl

SUMMARY OF THE INVENTION

BRIEF DESCRIPTION OF THE FIGURES

DETAILED DESCRIPTION OF THE INVENTION

4already installed compatible device and a hardware-specificdevice driver for the new device. In addition a restart of thecomputer is mandatory. The required deletion of existingregistry entries most likely will be prohibited by the os or mylead to serious corruption of the computers registry.

FIG. 1 is a block diagram of an exemplary operating envi­ronment.

FIG. 2 is a block diagram showing involved componentswhen using the invention with Microsoft Windows OperatingSystems.

FIG. 3 is a flow chart illustrating a method of creating adevice driver and initializing the setup process in accordancewith the present invention.

FIG. 4 is a flow chart illustrating a method of ranking adevice driver by the Operating System during the setup pro­cedure in a trusted system context without user interaction.

FIG. 5 is a flow chart illustrating a method of extractingsetup infonnations from a signed device driver and initializ­ing the setup process for creation ofa device object in accor­dance with the present invention.

FIG. 6 is a flow chart illustrating a method of binding aphysical device to a previously generated device object for asigned driver in accordance with the present invention.

In order to avoid confusion often present in the world of65 electronic devices jargon, for purposes of the present inven­

tion, the following term shall have the meaning set forthbelow: "BUS" shall mean any device to which other physical,

The present invention provides a way to perform all stepsrequired to build setup infonnation's, install and initialize aperipheral device of an electronic device without the need toplug in the peripheral device to the electronic device. Setupinformation of a unsigned driver for a peripheral device isextracted, modified and stored to fit to a physical existentperipheral device. The modified setup information is used tocreate a data structure that is passed to the peripheral busdriver. As signed device drivers must not be altered to keeptheir functionality the invention also allows the creation of adevice object that in further steps is bound to the physicalexistent peripheral device by changing its relations to theperipheral bus. As the data structure contains a hot plug noti-fication the reception causes the peripheral bus driver to ini­tiate the setup process for the peripheral device. As the datastructure or the device object is built from setup infonnationthat is available at the electronic device no additional useraction is required. Ifused with a physical existent peripheraldevice that has multiple functional capabilities the presentinvention allows to transfer the features of other devices tothis device. Some major advantages of the invention are:

30 Devices that do not contain required electronic parts for suc­cessful initialization of a setup process may be installed.Compatible devices that do not have an own set of devicedrivers may use setup data from existent devices. Devices thatare compatible but do not have signed drivers may be used inan environment that obligatory requires signed drivers. Adevice with multiple functional capabilities can lend deviceinformation's from already installed devices. Non PUPdevices can behave like PnP devices as the initial creationdoes not require the hardware to be connected.

3installed on the computer before the peripheral device isplugged in. As the HAL ofmodern operating systems permitsdirect hardware access this technique is only applicable foroperating systems that do not have such intennediate layer.

u.s. Pat. No. 7,574,713 discloses methods, systems, andcomputer program products for instantiating a device driverfor communication with a device by dynamically associatingthe device driver at run-time with a device-specific and/orservice-specific software component. This may be done byinstantiating a device driver for communication with a device 10

by dynamically associating the device driver at run-time witha device-specific software component. The software compo­nent contains infonnation that facilitates communicationwith devices of a specific type. In other embodiments, adevice driver is instantiated by defining a plurality of device 15

parameters and associating one or more of the plurality ofdevice parameters with a service. The device parameters thatare associated with the service are then dynamically commu­nicated to the device driver at run-time. Thus, a generic devicedriver may be dynamically configured at run-time to commu- 20

nicate with devices of a particular device type and/or deviceparameters may be associated with a service and communi­cated to the device driver. These device parameters that areassociated with a particular service and then passed to thedevice driver may allow the device driver to collect data from 25

a particular device that is relevant to a particular serviceoffering. Although this invention allows ultra flexible accessto and configuration of devices it requires the lower levelcomponents to be recognized and accessible by the HALbefore the methods can come into operation.

u.s. Pat. No. 7,275,118 shows an input/output (I/O) devicedriver loading method for a data processing system thatinvolves communication ofa secondary I/O device driver to adata processing system using a primary I/O device driver. Aninitial (first) device identification infonnation is passed from 35

the peripheral device to the data processing system. This firstdevice identification information corresponds to a first I/Odevice driver in the data processing system. By utilizing theinvention the device then transmits a second I/O device driverfrom the peripheral device to the data processing system 40

using the first I/O device driver in the data processing system.A second device identification infonnation is then passedfrom the peripheral device to the data processing system.Although this method allows the use of simplified genericdevice class drivers to establish an initial communication 45

with the data processing system to transmit additional devicedrivers and device identification infonnation to the data pro­cessing system it requires the device to be plugged into thedata processing system and a hardware specific device driverto be available for the peripheral device. Also this method 50

does not give an acceptable answer to the question on howdevices can be installed and used that do not have a hardwarespecific driver for any ofthe transmitted device identificationinformation.

u.s. Pat. No. 6,345,319 discloses a setting method for 55

installation of a plug and play device by utilizing the set-upfile (INF) of a hardware driver. The method reads the deviceID ofa new device and copies the driver file ofthe new deviceto the corresponding directory. The device ID and all relateddevice class ofan already installed (original) device is deleted 60

from the computer's registry. After a restart of the computerthe os displays that a new device is found and automaticallyestablishes the relationship between the new device and thepreviously installed driver through the new device ID andclass in order to let the new device be operated normally.

Although the invention describes a method to makechanges to an existing system configuration it requires an

US 9,122,623 Bl5 6

The request can be built and sent by either an application uponuser request or a generic multi purpose device driver or ser­vice that automatically starts when the creation ofthe tempo­rary data structure is finished. The data structure sent to thebus driver contains at least the request to add a new device, theclass and the device id both taken from the temporary datastructure. The class and the device id allow the proper selec­tion ofthe setup information file built in the prior step. Recep­tion of this data structure at the peripheral bus driver causes

10 the function driver for the bus device to determine that a newdevice is on its bus. FIG. 2 is a block diagram showinginvolved components when using the invention withMicrosoft Windows Operating Systems. Passing the datastructure to the peripheral bus driver 202 causes actions that

15 are similar to plug a peripheral device 200 into the peripheralbus 20l.

If the data structure passed to the peripheral bus drivercontains a notification flag and the bus supports hot-plugnotification, the method may be applied while the system is

20 running Now the peripheral device is enumerated. The busdriver 202, targeted by the data structure, receives the hot­plug notification flag of the new device. The bus driver noti­fies the kernel-mode PnP manager 203 that the list ofdeviceson the bus has changed. In this case, the change is a new

25 device on the bus. The kernel-mode PnP manager queries thebus driver for a list ofdevices present on the bus by sending aquery for Bus Relations. The bus driver responds to the querywith a current list ofdevices on the bus. The kernel-mode PUPmanager compares the new list against the previous list and,

30 in this case, determines that there is one new device on thebus.

The kernel-mode PnP manager sends queries to the busdriver to gather information about the new device, such as thedevice's hardware IDs, compatible IDs, and device capabili-

35 ties. The kernel-mode PnP manager notifies the user-modePUP manager 204 that there is a device to be installed. Theuser-mode PnP manager tries to perform a trusted installa­tion. As the data structure passed to the peripheral bus driverwas generated from the setup information file and the setup

40 information file is stored at a location were the electronicdevice expects the information a server side installation canbe performed. The user-mode PnP manager creates a newprocess using rund1l32.exe and launches newdev.dll 205 toinstall the device.

The new device DLL calls setup API 206 device installa-tion functions and CfgMgr API 207 PnP configuration man­ager functions to carry out its installation tasks. The newdevice DLL queries the system to build a list of possibledrivers for the device. As the setup information file stored in

50 the previous steps is available on the system and matches thenew device, the returned driver list contains the requireddriver.

Setup uses the Class and ClassGUID entries in the device'sINF Version section to determine the device setup class. The

55 setup class determines the class installer and the class co­installers for the device, if any. Device-specific co-installersare listed in the appropriate INF section. Setup transfers con­trol to kernel mode to load drivers and start the device.

Once Setup has selected the driver for the device, copied60 the appropriate driver files, registered any device-specific

co-installers, and registered any device interfaces, it transferscontrol to kernel mode to load the drivers and try to start thedevice. The appropriate CfgMgr function sends a request tothe user-mode PnP manager, which passes it to the kernel-

65 mode PnP manager. The PnP manager loads the appropriatefunction driver 210 and any optional filter driver 211 for thedevice.

logical, or virtual devices are attached; a bus includes tradi­tional buses such as SCSI and PCI, as well as parallel ports,serial ports, and i8042 ports.

The invention may be more vividly described with refer­ence to FIGS. 1-3. FIG. 1 is a schematic diagram of a con­ventional digital electronic device that can be used to imple­ment various aspects ofthe invention. When a new peripheraldevice 109 is connected to a peripheral device interface 110 ora peripheral bus 108 that is connected to the system bus 105by a peripheral bus interface 107, the electronic device 100detects the presence ofthe connected peripheral device and aconfiguration process (e.g., enumeration) begins. An enu­meration process assigns a unique address to the connectedperipheral device, queries the connected peripheral deviceabout requirements and capabilities, writes data about theconnected peripheral device to the as 102 of the electronicdevice and loads the appropriate software device driver froma non volatile memory into the as.

The device driver is a program that allows the as andapplication programs 103 to communicate correctly with theperipheral device, provides information to the electronicdevices operating system about the peripheral device andallows transfer of program data 104 to the peripheral device.

FIG. 3 is a flow chart illustrating a method of creating adevice driver and initializing the setup process in accordancewith the present invention. Initially the present inventioncollects information's 301 about a desired device and createsan appropriate setup information file 304 for the device. Thismay either be done by extracting installation informationfrom an existing device or by utilizing a prebuilt setup infor­mation file. Setup information is stored in a plain text file. Theplain text file is divided into sections that contain informa­tion's about the peripheral device's capabilities, dependen­cies and requirements. During the setup process the as loadsthe setup information file into volatile memory, identifies thesections, reads the content of each section and writes entriesto the registry, the configuration database of the electronicdevice. Instead ofmaking changes to the configuration data­base ofthe electronic device the invention uses this method tobuild a temporary data structure that is required to perform thefollowing steps. The temporary data structure may be held involatile memory such as a random access memory or bestored to non volatile memory such as a physical storagedevice. As the as searches and selects the appropriate setupinformation file for a peripheral device by comparing the 45

class and the device id ofthe peripheral device with the classand the device id stored in the setup information file changesof the contents of the data structure are necessary to create asetup information file that fits to the peripheral device. Thedevice id of the extracted or prebuilt setup information filestored in the temporary data structure is exchanged with thedevice id 300 of the physical peripheral device that shouldfinally be plugged into the peripheral bus. This may either bedone by user input or by reading a plain text file which issupplied with the peripheral device and just contains thedevice id. The content ofthe modified data structure is used tobuild the setup information file 304 for the new device. Thissetup information file is stored to a location were the elec­tronic device expects to find such information.

In the next step, the temporary data structure is used tocreate a data structure 305 that is needed to initialize the setupprocess for the new device without the need for the physicaldevice to be plugged into the peripheral bus or interface oftheelectronic device. As the bus driver of a peripheral bus isaccessible and accepts configuration requests from either theperipheral bus or the system bus the configuration request canbe formed from the content of the temporary data structure.

US 9,122,623 Bl7 8

and data input from the Operating System or an applicationprogram and there is no physical device attached to the bus atthis point the Plug and Play managers IRP's are answered bysending 504 the previously collected data from the signeddevice driver in form of strings to the Plug and Play managervia the bus driver that adds, due to the reception ofthe hot plugnotification, some of the required informations like the busdevices ID, bus instance ID or bus container ID. Hardwarespecific information like the devices hardware ID or its com-

10 patible ID are taken from the setup information file. TheKernel Mode Plug and Play manager then notifies 505 theUser Mode Plug and Play manager that there is a new deviceto be installed.

Next a routine to add a device object is started. To build the15 required parameters this routine uses the information col­

lected in the previous step. The routine is responsible forcreating the functional device object 210 or filter deviceobject 211 for the device. The routine contains a pointer to thedriver object structure which is the devices signed driver

20 object and a pointer to the physical device object created bythe lower level driver.

As simple reading from a file in the driver package does notalter the package the required information to create the appro­priate pointers for the routine to add the device 0 bject for the

25 expected device is read from the signed driver before theroutine is started. The routine contains a pointer to the signeddriver and a pointer to the newly arrived physical deviceobject created in the previous steps by the Plug and Playmanager.

This routine to add the device calls two other routines thatcreate the device object for use ofthe signed driver and attachthe device to the highest device object in the chain and returna pointer to the previously highest device object. In additionto a pointer to the driver object the first routine contains the

35 driver-determined number of bytes to be allocated for thedevice extension of the device object, the device type, it'scharacteristics, information about the devices exclusiveaccess properties and a pointer to a variable that receives apointer to the newly created device object structure. As all

40 information needed by this routine is taken from the signeddevice driver installation package various device types can beeasily installed, including but not limited to:

Battery devices and UPS devices, biometric-based per­sonal identification devices and Bluetooth devices. CD-ROM

45 drives, including SCSI CD-ROM drives. In this case, theOperating System's CD-ROM class installer also installs asystem-supplied CD audio driver and CD-ROM changerdriver, a Plug and Play filter driver. Disk Drives includinghard disk drives, display adapters, video adapters, display

50 drivers and video miniport drivers. Floppy disk Controllersand floppy disk drive controllers.

Hard disk controllers, including ATAIATAPI controllers.Human Interface Devices (HID) including interactive inputdevices that are operated by the system-supplied HID class

55 driver, which includes USB devices that comply with theUSB HID Standard and non-USB devices that use a HIDminidriver. IEEE 1284.4 devices that control the operation ofmultifunction IEEE 1284.4 peripheral devices. IEEE 1284.4print functions on a Dot4 device that has a single child device,

60 which is a member of the printer device setup class. IEEE1394 devices that support the 61883 protocol including the61883.sys protocol driver that transmits various audio andvideo data streams over the 1394 bus, including quality DY,MPEG2, DSS, andAudio. IEEE 1394 devices that support the

65 AVC protocol device class. IEEE 1394 devices that supportthe SBP2 protocol device class. IEEE 1394 host controllersconnected on a PCI bus. Imaging devices including still-

The PnP manager calls the Driver Entry routine for anyrequired driver that is not yet loaded. The PnP manager thencalls the AddDevice routine for each driver, starting withlowerfilter drivers, then the function driver, and, lastly, anyupper filter drivers. The PUP manager assigns resources to thedevice, if required, and sends a start request to the device'sdrivers.

After finishing these steps the physical existent peripheraldevice may be plugged into the peripheral bus. As this devicesends a hot-plug notification and its device class and device idfits to the driver installed by the data structure the electronicdevice assumes that the peripheral device is plugged in andstarts it.

As the previously described steps of the present inventionalter parts ofthe initial existent driver package for installationof signed drivers a different approach is needed. If the Oper­ating system detects that at least one file in the signed driverpackage has been altered since the package was signed itcategorizes the drivers as altered. This makes it impossible toperform the desired device installation that can be handledentirely by the Operating System's user-mode and kernel­mode PnP manager components. In such case, for non-ad­ministrative and standard users, the Operating System doesnot prompt the user. It would only automatically install adriver signed by a signing authority but silently refuses toinstall the altered driver. In some operating systems, in orderfor a user to access specific content such as HD DVD andother licensed formats, all kernel-mode components on hissystem must be signed. That means that, if the user tries toinstall the altered driver, the system is not allowed to play the 30

licensed content.FIG. 4 is a flow chart illustrating a method of ranking a

device driver by the Operating System during the setup pro­cedure in a trusted system context without user interaction.Initially, the Kernel Mode Plug and Play Manager sends anI/O Request Packet 400 to the Bus Driver. The Bus driverresponds 401 to the request by sending in the Hardware andCompatible IDs 402. Based on this information the setupprocess queries 403 the Operating Systems driver store or alocation where the Operating System expects drivers, such asan INF directory, for matching drivers. If Matching driversare found 404 they are added to a driver list 405. If the setupprocess cannot find a matching driver it exits unattendedsetup mode 406. If drivers are found the setup process com­pares the content of the setup information files 407 to thedevice identification strings received in step 404 and builds adriver list with rank indicators 408.

As described in the previous steps the Operating Systemdoes not directly interact with hardware. Instead, every pieceofhardware is represented by a device object that receives allIn- and Output from the Operating System. To successfullyuse the invention with signed drivers a device object for thedevice expected by the unmodified signed driver in the Oper­ating System has to be created and, in later steps, bound to thephysical existent device that is not attached to the electronicdevice when the required device object is created.

To successfully collect all necessary data for creating thenew device object the setup information file sections of thesigned driver and its content are read 500 into a temporarydata structure. As already described the creation ofthe deviceobject is initialized by sending 501 a hot plug notification tothe bus driver. The reception ofthe notification causes the busdriver to notify 502 the Kernel Plug and Play Manager that thelist of devices on the bus has changed.

The Kernel Plug and Play Manager sends 503 I/O RequestPackets (IRP) to the bus driver to gather informations aboutthe new device. As the bus driver is able to receive commands

US 9,122,623 Bl9 10

55

allow access and configuration, initially the non volatilememory of the device is programmed to send out a hot plugnotification 602 and identification infonnations 603 for asimple generic device. Non signed drivers for such devicesare available and may be silently installed on most commonelectronic devices. To bind this physical device to the existingbut inactive Operating Systems device object 604 for thesigned driver package the bus specific informations busdevices ID, bus instance ID and bus container ID 605 for the

10 device object are queried by sending I/O Request Packets tothe bus driver 606. Due to the fact that the Operating Systemsdevice object is already installed but not active the Bus rela­tions for this device are known and its Hardware and Com­patible ID 606 can be queried, transmitted to and stored in the

15 physical devices non volatile memory. The next time theperipheral device is plugged into the peripheral bus thedevices notifications fit to the previously installed OperationSystem's device object. As the device is already installed itcan be used without any further installation steps or user

20 interaction, it just appears as switched ON. The OperatingSystem perfonns all I/O requests to the Operation Systemsdevice object which is now bound to the physical device.

Although the invention has been described in relation topreferred embodiments, many variations, equivalents, modi-

25 fications and other uses will become apparent to those skilledin the art. The scope of the present invention should not belimited to the specific disclosure but detennined only by theappended claims.

What is claimed is:1. A method, comprising:replacing a device identification (ID) in a data structure

with a device ID of a peripheral device;passing a request to a device driver of an interface of the

peripheral device and a bus that initiates the installationofthe peripheral device, wherein the peripheral device isnot connected to the electronic device, wherein therequest comprises a request to add the peripheral device,a class identifier of the peripheral device and the deviceID of the peripheral device which cause a bus driver ofthe bus to receive the request and detennine a new deviceis operating on the bus as a Plug and Play device; and

adding entries to provide Plug and Play functionality to thedata structure generated from an existent setup infonna­tion file that does not provide such functionality.

2. The method of claim 1, wherein a previously existentsetup infonnation is stored in a file.

3. The method ofclaim 1, wherein existent setup infonna­tion is stored in a configuration memory of the electronicdevice.

4. The method of claim 1, further comprising storing thedevice ID of the peripheral device.

5. The method of claim 1, further comprising passing aninstance ID to the driver of the peripheral interface or bus toidentify an instance of the peripheral device.

6. The method according to claim 1, wherein the bus is anexpansion bus.

7. The method according to claim 1, wherein the bus is aperipheral bus.

8. The method of claim 1, wherein the peripheral device60 supports the functionality of multiple devices and the opera­

tions of creation of setup infonnation, initialization and per­formance ofan installation are perfonned for each supportedfunctionality of the multiple devices.

9. An apparatus, comprising:a memory; anda processor communicably coupled to the memory, the

processor configured to:

image capture devices, digital cameras, and scanners. IrDAdevices including serial-IR and fast-IR NDIS miniports. Key­boards also specified in the (secondary) INF for an enumer­ated child HID keyboard device. Media changers includingSCSI media changer devices. Memory technology driversincluding memory devices, such as flash memory cards.Modems and display monitors. An setup information file fora device of this class installs no device driver, but ratherspecifies the features ofa particular monitor to be stored in theregistry for use by drivers of video adapters. Mouse devicesand other kinds of pointing devices, such as trackballs alsospecified in the (secondary) INF for an enumerated child HIDmouse device. Multifunction Devices including combo cards,such as a PCMCIA modem and netcard adapter. The driverfor such a Plug and Play multifunction device is installedunder this class and enumerates the modem and netcard sepa­rately as its child devices. Multimedia devices includingAudio and DVD multimedia devices, joystick ports, and full­motion video capture devices. Multiport serial adaptersincluding intelligent multiport serial cards. Network adaptersincluding NDIS NIC miniport drivers. Network clientsincluding network and/or print providers. Network servicessuch as redirectors and servers. Network transports includingNDIS protocols, CoNDIS stand-alone call managers, andCoNDIS clients, as well as higher level drivers in transportstacks. PCI SSL accelerator devices that accelerate securesocket layer (SSL) cryptographic processing. PCMCIAadapters including CardBus host controllers. Ports (COM &LPT ports) including serial and parallel port devices. Printersand bus-specific class drivers including SCSI/1394-enumer- 30

ated printers. Processors, SCSI and RAID controllers includ­ing SCSI HBAs (Host Bus Adapters) and disk-array control­lers. Smart Card readers and storage volumes includingstorage volumes as defined by the system-supplied logicalvolume manager and class drivers that create device objects to 35

represent storage volumes, such as the system disk classdriver. System Devices, including HALs, system buses, sys­tem bridges, the system ACPI driver, and the system volumemanager driver. Tape drives, including all tape miniclass driv­ers. USB host controllers and USB hubs. Windows CE USB 40

ActiveSync devices that support communication between apersonal computer and a device that is compatible with theWindows CE ActiveSync driver (generally, PocketPCdevices) over USB.

The second routine attaches the device to the highest 45

device object in the chain (if any) and returns a pointer to thepreviously highest device object. the routine contains apointer to the previously created device object and a pointer toanother driver's device object, such as a pointer returned by apreceding call to a routine that returns a pointer to the top 50

object in the named device object's stack.Due to the fact, that the physical device identification

expected by the signed driver is read from the driver and sentto the User Mode Plug and Play Manager a trusted ("serverside") silent installation can be perfonned.

Initially the device object is installed but due to the fact thatthere is no device plugged into the bus, not started. As thephysical existent peripheral device that was used withunsigned drivers, when plugged into the bus, does not send ahotplug notification or other notifications that would initializean enumeration process additional steps are required to bindthe physical device to the device 0 bject created in the previoussteps in case a signed driver should or has to be used.

To allow binding of a physical device that has no signeddrivers but should be used with such drivers the hardware 65

device 600 has to have non volatile memory 601 that providesread- and writeable access to an application program. To

US 9,122,623 Bl11

replace a device identification (ID) in a data structurewith a device ID of a peripheral device;

pass a request to a device driver of an interface of theperipheral device and a bus that initiates the installa­tiOl1. of .the peripheral device, wherein the peripheraldevIce IS not connected to the apparatus, wherein therequest comprises a request to add the peripheraldevice, a class identifier of the peripheral device andthe device ID of the peripheral device which cause abus driver of the bus to receive the request and deter- 10mine a new device is operating on the bus as a Plugand Play device; and

add entries to provide Plug and Play fnnctionality to thedata structure generated from an existent setup infor­mation file that does not provide such functionality. 15

10. The apparatus ofclaim 9, wherein a previously existentsetup information is stored in a file.

11. The apparatus ofclaim 9, wherein existent setup infor­mation is stored in a configuration memory of the apparatus.

12. The apparatus of claim 9, wherein the processor isf

wurther configured to pass an instance ID to the driver of the

peripheral interface to identify an instance of the peripheraldevice.

13. The apparatus of claim 9, wherein the processor isfurther configured to pass an instance ID to the driver of theb

~

us to identify an instance of the peripheral device.14. The apparatus of claim 9, wherein the bus is an expan­

sion bus.15. The apparatus of claim 9, wherein the bus is a periph­

eral bus. 3016. The apparatus ofclaim 9, where in the peripheral device

s.upports the ~nctionality ofmultiple devices and the opera­tions of creatIOn of setup information, initialization and per­formance ofan installation are performed for each supportedfnnctionality of the multiple devices.

1217. A non-transitory computer readable medium compris­

ing a computer program that when executed causes a proces­sor to perform:

replacing a device identification (ID) in a data structurewith a device ID of a peripheral device;

passing a request to at least one of a device driver of aninterface ofthe peripheral device and a bus that initiatesthe installation of the peripheral device, wherein theperipheral device is not connected to the electronicdevice, wherein the request comprises a request to addthe peripheral device, a class identifier ofthe peripheraldevice and the device ID of the peripheral device whichcause a bus driver of the bus to receive the request anddetermine a new device is operating on the bus as a Plugand Play device; and

adding entries to provide Plug and Play functionality to thedata structure generated from an existent setup informa­tion file that does not provide such fnnctionality.

1~. Th~ method of claim 1, further comprising creating adevIce object of the electronic device and binding the deviceobject to the peripheral device to provide a signed driver thatis used during the installation of the peripheral device.

19. The apparatus of claim 9, wherein the processor isfurther configured to create a device object of the apparatusand bind the device object to the peripheral device to providea signed driver that is used during the installation of theperipheral device.

20. The non-transitory computer readable medium ofclaim17, wherein the processor is further configured to performcreating a device object of the electronic device and bindingthe device object to the peripheral device to provide a signeddriver that is used during the installation of the peripheraldevice.

* * * * *