I 1111111111111111 11111 lllll 111111111111111 1111111111 111111111111111 IIII IIII
`US007673303B2
`
`c12) United States Patent
`Sadovsky et al.
`
`(IO) Patent No.:
`(45) Date of Patent:
`
`US 7,673,303 B2
`*Mar. 2, 2010
`
`(54) SIMPLIFIED DEVICE DRIVERS FOR
`HARDWARE DEVICES OF A COMPUTER
`SYSTEM
`
`(75)
`
`Inventors: Vladimir Sadovsky, Bellevue, WA
`(US); Franc J. Camara, Redmond, WA
`(US); Keisuke Tsuchida, Redmond, WA
`(US); Lyman Cooper Partin, Bellevue,
`WA (US)
`
`(73) Assignee: Microsoft Corporation, Redmond, WA
`(US)
`
`( *) Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 631 days.
`
`This patent is subject to a terminal dis(cid:173)
`claimer.
`
`(21) Appl. No.: 11/276,482
`
`(22)
`
`Filed:
`
`Mar. 1, 2006
`
`(65)
`
`Prior Publication Data
`
`US 2006/0147234 Al
`
`Jul. 6, 2006
`
`(63)
`
`(60)
`
`(51)
`
`Related U.S. Application Data
`
`Continuation of application No. 09/809,237, filed on
`Mar. 15, 2001, now Pat. No. 7,047,534.
`
`Provisional application No. 60/190,457, filed on Mar.
`17, 2000.
`
`Int. Cl.
`G06F 9/46
`G06F 9/44
`
`(2006.01)
`(2006.01)
`
`(52) U.S. Cl. ....................... 718/101; 719/322; 719/326;
`719/327
`(58) Field of Classification Search ................. 719/322,
`719/326-327; 718/101
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,265,252 A
`1111993 Rawson, III et al.
`5,307,491 A *
`4/1994 Feriozi et al. ............... 719/326
`5,727,212 A *
`3/1998 Dinallo ....................... 719/321
`6,868,545 Bl *
`3/2005 Devins et al.
`............... 719/327
`7,093,265 Bl*
`8/2006 Jantz et al. .................. 719/321
`7,167,254 Bl*
`1/2007 Abe .......................... 358/1.15
`* cited by examiner
`
`Primary Examiner-Meng-Ai An
`Assistant Examiner----Camquy Truong
`(74) Attorney, Agent, or Firm-Lee & Hayes, PLLC
`
`(57)
`
`ABSTRACT
`
`A computer system uses simplified device drivers for operat(cid:173)
`ing hardware devices. A simplified device driver for a hard(cid:173)
`ware device of a given device type, such as a flatbed scanner,
`works with a system-supplied common driver for that given
`device type. The common driver and the simplified driver
`together function like a regular device driver. The simplified
`device driver implements a small number of entry point func(cid:173)
`tions corresponding to a pre-selected set of operation com(cid:173)
`mands "generic" to hardware devices of that given device
`type. When an application makes a request for an operation by
`the device, the request is passed through a device driver
`interface (DDI) to the common driver. The common driver
`then calls the entry point functions in the simplified device
`driver to carry out the requested operation.
`
`18 Claims, 3 Drawing Sheets
`
`Device Driver Interface -
`(DOI)
`
`Application
`
`Intermediate Operating
`System Component(s)
`
`-
`
`-
`
`-
`
`-
`
`-
`
`Conn11on Driver
`(for a given device type)
`
`Simplified Device Driver
`
`Lower-level
`Drivers
`
`_{_ 68
`
`66
`
`62
`
`Hardware Device
`(of the given type)
`
`64
`
`70
`
`Petitioners Microsoft Corporation and HP Inc. - Ex. 1026, p. 1
`
`

`

`U.S. Patent
`
`Mar.2,2010
`
`Sheet 1 of 3
`
`US 7,673,303 B2
`
`20
`
`SYSTEM
`MEMORY
`(ROivi)
`
`PERSONAL COMPUTER
`
`22
`
`24
`
`21
`
`48
`
`Monitor
`
`47
`
`BIOS
`L..._ _ _ _ ...J--i--26
`
`OPERATING
`SYSTEM
`
`APPLICATION
`PROGRAM
`
`OTHER
`PROGRAM
`MODULES
`
`PROGRAM
`DATA
`
`PRO(cid:173)
`CESSING
`UNIT
`
`VIDEO
`ADAPTER
`
`23
`
`53
`
`25
`
`35
`
`36 32
`
`33
`
`37
`
`SERIAL
`HARD DISK MAG DISK OPTICAL
`PORT
`DRIVE
`DRIVE DISKDRJVE
`INTERFACE INTERFACE INTERFACE INTERFACE
`
`46
`
`51
`
`hard disk
`drive
`'--------.-----'
`
`38
`
`27
`
`Magnetic Optical driv
`I
`disk drive
`I
`28
`30
`
`2':1---... .. 3
`
`I
`
`I
`
`I
`
`OPERATING
`SYSTEM
`
`APPLI-
`CATION
`PROGRAMS
`
`I
`
`35
`
`I
`36
`
`OTHER
`PROGRAM PROGRAM
`MODULES DATA
`I
`I
`37
`38
`
`ouse
`42
`
`Keyboard
`I
`40 52-
`
`49
`
`REMOTE
`COMPUTER
`
`5
`
`36
`
`APPLICATION
`PROGRAMS
`
`Fig. 1
`
`Petitioners Microsoft Corporation and HP Inc. - Ex. 1026, p. 2
`
`

`

`U.S. Patent
`
`Mar.2,2010
`
`Sheet 2 of 3
`
`US 7,673,303 B2
`
`Device Driver Interface -
`(DDI)
`
`Application
`
`r-------·-····••u••· .. ····--·--· ---····················· ......... ,
`1
`:
`i
`
`i Intermediate Operating
`:
`System Component(s)
`i
`
`: •••••••••••••••••••••••••••••••• •••u•••••••••••••••••••••••••••:
`
`-
`
`-
`
`-
`
`-
`
`Common Driver
`(for a given device type)
`
`Simplified Device Driver
`
`_
`
`f
`
`68
`
`66
`
`62
`
`• • • • • • • • • • • • • • • • • • • • •H (cid:127)
`
`(cid:127)
`
`'
`'
`
`• • • • • • • • • • • • • • • • • • • • • • • • •
`'
`'
`!
`
`l Lo;;i~::svel
`
`• ....................... ......................... .J
`
`Hardware Device
`( of the given type)
`
`64
`
`70
`
`Fig. 2
`
`Petitioners Microsoft Corporation and HP Inc. - Ex. 1026, p. 3
`
`

`

`U.S. Patent
`
`Mar.2,2010
`
`Sheet 3 of 3
`
`US 7,673,303 B2
`
`86
`
`(cid:143)-
`
`'--
`
`84
`
`Image-Processing
`Application
`
`80
`
`Image Acquisition API -
`
`-
`
`100
`
`~ - -~ - - -~
`
`Image Acquisition
`Service
`
`Image Acquisition DDI- -
`
`L SCANINFO
`
`92_)
`
`72
`
`Flatbed Driver
`
`Device Driver
`(regular)
`
`76
`
`Simplified Flatbed
`Scanner Driver
`
`12
`_ _ _ UserMode_)
`
`102
`
`Kernel Mode
`
`Kernel 1/0 Drivers
`
`88
`
`Captured
`Image
`Data
`
`~4
`
`Image-(cid:173)
`Capturing
`Device
`
`78
`
`Fig. 3
`
`Petitioners Microsoft Corporation and HP Inc. - Ex. 1026, p. 4
`
`

`

`US 7,673,303 B2
`
`2
`SUMMARY OF THE INVENTION
`
`1
`SIMPLIFIED DEVICE DRIVERS FOR
`HARDWARE DEVICES OF A COMPUTER
`SYSTEM
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`This application is a continuation of and priority is claimed
`to application Ser. No. 09/809,237, filed Mar. 15, 2001, now
`U.S. Pat. No. 7,047,534 titled "SIMPLIFIED DEVICE
`DRIVERS FOR HARDWARE DEVICES OF A COM(cid:173)
`PUTER SYSTEM" and issued to Sadovsky, which claims
`priority from U.S. Provisional Patent Application Ser. No.
`60/190,457, filed Mar. 17, 2000. This United States patent is
`commonly assigned herewith and is hereby incorporated
`herein by reference for all that it discloses.
`
`TECHNICAL FIELD OF THE INVENTION
`
`This invention relates generally to computer operating sys(cid:173)
`tems, and more particularly to software components for com(cid:173)
`municating with and controlling the operation of a computer
`hardware device, such as a scanner.
`
`BACKGROUND OF THE INVENTION
`
`A computer system employs hardware devices for various
`functions, such as data input and output, printing, display, etc.
`Each hardware device in the computer system is typically
`operated through its associated device driver, which is typi- 30
`cally provided by the vendor of the hardware device and
`loaded as part of the operating system. The device driver
`allows the operating system of the computer and applications
`rumiing on the computer to communicate with the device and
`control its operations. The device driver is device-specific in 35
`that it is written to handle the specific behavior of the device.
`On the other hand, the device driver also has to be written
`according to specifications and requirements of the operating
`system with which the driver is to be used.
`Although the quality of the device driver for a hardware 40
`device is critical to the proper operation of the device, many
`hardware vendors find it difficult to put in the significant time
`and resources needed to adequately develop a device driver.
`As a result, device drivers provided by hardware vendors are
`often of unsatisfactory quality and require extensive fixing 45
`before they can be used with the operating system. This
`problem is especially significant for models with low profit
`margins. For example, flatbed color scanners are commonly
`used for capturing color images for incorporation in presen(cid:173)
`tations and communications. Some low-end models of flatbed 50
`scanners have rather low retail prices, which limit the
`resources their vendors could reasonably spend on writing
`device drivers for them.
`The difficulty in obtaining well-developed device drivers is
`exacerbated by the need to include many device drivers with
`an operating system. One of the goals of modern operating
`systems is to provide an "out-of-the-box" experience, where
`an end user can simply connect a device to her computer and
`the device will work without the need to install any extra
`software. To provide such an experience, an operating system
`typically includes many device drivers from different hard(cid:173)
`ware vendors. Due to the large number of device drivers
`involved, the time and resources required to test and fix the
`drivers to ensure their proper operations can become unac(cid:173)
`ceptably high. Accordingly, there is a need for a new approach
`in developing device drivers that makes it significantly easier
`for hardware vendors to develop high-quality device drivers.
`
`In view of the foregoing, the present invention provides a
`computer system that allows the use of simplified device
`5 drivers for operating hardware devices. A simplified device
`driver for a hardware device of a given type, such as a flatbed
`scanner, works with a common driver provided for that given
`type, and together they function like a regular device driver.
`The simplified device driver implements entry point func-
`10 tions for a small set of pre-selected operation commands
`"generic" to different device models and brands of that given
`device type. When an application makes a request for an
`operation by the device, the request is passed through a device
`driver interface (DDI) to the common driver. The common
`15 driver then calls the entry point functions in the simplified
`device driver to control the device to carry out the requested
`operation. Because a simplified device driver only has to
`implement a small number of entry point functions for
`generic device operation commands, it is significantly less
`20 complicated than a regular device driver that has to handle
`various driver interface functions required by the operating
`system. As a result, it is much easier for a hardware vendor to
`develop a high-quality simplified device driver.
`Additional features and advantages of the invention will be
`25 made apparent from the following detailed description of
`illustrative embodiments, which proceeds with reference to
`the accompanying figures.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`While the appended claims set forth the features of the
`present invention with particularity, the invention, together
`with its objects and advantages, may be best understood from
`the following detailed description taken in conjunction with
`the accompanying drawings of which:
`FIG. 1 is a block diagram generally illustrating an exem(cid:173)
`plary computer system on which the present invention may be
`performed;
`FIG. 2 is a schematic diagram showing a general view of a
`system that employs a simplified device driver in accordance
`with the invention; and
`FIG. 3 is an embodiment of an image acquisition system
`that has a simplified device driver for a flatbed scanner.
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`Turning to the drawings, wherein like reference numerals
`refer to like elements, the invention is illustrated as being
`implemented in a suitable computing environment. Although
`not required, the invention will be described in the general
`context of computer-executable instructions, such as program
`modules, being executed by a personal computer. Generally,
`program modules include routines, programs, objects, com-
`55 ponents, data structures, etc. that perform particular tasks or
`implement particular abstract data types. Moreover, those
`skilled in the art will appreciate that the invention may be
`practiced with other computer system configurations, includ(cid:173)
`ing hand-held devices, multi-processor systems, micropro-
`60 cessor based or programmable consumer electronics, net(cid:173)
`work PCs, minicomputers, mainframe computers, and the
`like. The invention may also be practiced in distributed com(cid:173)
`puting environments where tasks are performed by remote
`processing devices that are linked through a communications
`65 network. In a distributed computing environment, program
`modules may be located in both local and remote memory
`storage devices.
`
`Petitioners Microsoft Corporation and HP Inc. - Ex. 1026, p. 5
`
`

`

`US 7,673,303 B2
`
`3
`With reference to FIG. 1, an exemplary system for imple(cid:173)
`menting the invention includes a general-purpose computing
`device in the form of a conventional personal computer 20,
`including a processing unit 21, a system memory 22, and a
`system bus 23 that couples various system components 5
`including the system memory to the processing unit 21. The
`system bus 23 may be any of several types of bus structures
`including a memory bus or memory controller, a peripheral
`bus, and a local bus using any of a variety ofbus architectures.
`The system memory includes read only memory (ROM) 24 10
`and random access memory (RAM) 25. A basic input/output
`system (BIOS) 26, containing the basic routines that help to
`transfer information between elements within the personal
`computer 20, such as during start-up, is stored in ROM 24.
`The personal computer 20 further includes a hard disk drive 15
`27 for reading from and writing to a hard disk 60, a magnetic
`disk drive 28 for reading from or writing to a removable
`magnetic disk 29, and an optical disk drive 30 for reading
`from or writing to a removable optical disk 31 such as a CD
`ROM or other optical media.
`The hard disk drive 27, magnetic disk drive 28, and optical
`disk drive 3 0 are connected to the system bus 23 by a hard disk
`drive interface 32, a magnetic disk drive interface 33, and an
`optical disk drive interface 34, respectively. The drives and
`their associated computer-readable media provide nonvola- 25
`tile storage of computer readable instructions, data structures,
`program modules and other data for the personal computer
`20. Although the exemplary environment described herein
`employs a hard disk 60, a removable magnetic disk 29, and a
`removable optical disk 31, it will be appreciated by those 30
`skilled in the art that other types of computer readable media
`which can store data that is accessible by a computer, such as
`magnetic cassettes, flash memory cards, digital video disks,
`Bernoulli cartridges, random access memories, read only
`memories, and the like may also be used in the exemplary 35
`operating environment.
`A number of program modules may be stored on the hard
`disk 60, magnetic disk 29, optical disk 31, ROM 24 or RAM
`25, including an operating system 35, one or more applica(cid:173)
`tions programs 36, other program modules 37, and program
`data 38. A user may enter commands and information into the
`personal computer 20 through input devices such as a key(cid:173)
`board 40 and a pointing device 42. Other input devices may
`include a microphone, joystick, game pad, or the like. The
`input devices may further include image-capturing devices,
`such as scanners and digital cameras, as sources of color
`image data. These and other input devices are often connected
`to the processing unit 21 through a serial port interface 46 that
`is coupled to the system bus, but may be connected by other
`interfaces, such as a parallel port, game port or a universal
`serial bus (USB). A monitor 4 7 orother type of display device
`is also connected to the system bus 23 via an interface, such as
`a video adapter 48. In addition to the monitor, personal com(cid:173)
`puters typically include other peripheral output devices, not
`shown, such as speakers and printers.
`The personal computer 20 may operate in a networked
`environment using logical connections to one or more remote
`computers, such as a remote computer 49. The remote com(cid:173)
`puter 49 may be another personal computer, a server, a router,
`a network PC, a peer device or other common network node,
`and typically includes many or all of the elements described
`above relative to the personal computer 20, although only a
`memory storage device 50 has been illustrated in FIG. 1. The
`logical connections depicted in FIG. 1 include a local area
`network (LAN) 51 and a wide area network (WAN) 52. Such
`networking environments are commonplace in offices, enter(cid:173)
`prise-wide computer networks, intranets and the Internet.
`
`4
`When used in a LAN networking environment, the per(cid:173)
`sonal computer 20 is connected to the local network 51
`through a network interface or adapter 53. When used in a
`WAN networking environment, the person computer 20 typi(cid:173)
`cally includes a modem 54 or other means for establishing
`communications over the WAN 52. The modem 54, which
`may be internal or external, is connected to the system bus 23
`via the serial port interface 46. In a networked environment,
`program modules depicted relative to the personal computer
`20, or portions thereof, may be stored in the remote memory
`storage device. It will be appreciated that the network con-
`nections shown are exemplary and other means of establish(cid:173)
`ing a communications link between the computers may be
`used.
`In the description that follows, the invention will be
`described with reference to acts and symbolic representations
`of operations that are performed by one or more computers,
`unless indicated otherwise. As such, it will be understood that
`such acts and operations, which are at times referred to as
`20 being computer-executed, include the manipulation by the
`processing unit of the computer of electrical signals repre(cid:173)
`senting data in a structured form. This manipulation trans(cid:173)
`forms the data or maintains it at locations in the memory
`system of the computer, which reconfigures or otherwise
`alters the operation of the computer in a manner well under(cid:173)
`stood by those skilled in the art. The data structures where
`data is maintained are physical locations of the memory that
`have particular properties defined by the format of the data.
`However, while the invention is being described in the fore(cid:173)
`going context, it is not meant to be limiting as those of skill in
`the art will appreciate that various of the acts and operation
`described hereinafter may also be implemented in hardware.
`Referring now to FIG. 2, the present invention is directed to
`a system architecture that enables the use of a "simplified"
`device driver 62 for controlling the operation of a hardware
`device 64. The simplified device driver is significantly easier
`to develop and to debug than regular device drivers. As a
`result, hardware vendors are likely to be able to develop
`high-quality simplified device drivers that do not require
`40 extensive fixing. As will be described in greater detail below,
`the simplification of the device drivers in accordance with the
`invention is achieved by using a "common" driver 66 for a
`given type of hardware devices, such as flatbed scanners, that
`works together with "simplified" device drivers for different
`45 devices of that given type. The common behavior between the
`different models of devices 64 of the given type is abstracted
`into the common driver 66, which preferably is system-sup(cid:173)
`plied. Specifically, the simplified device drivers are required
`to implement functions responsive to a small set of pre-se-
`50 lected simple operation commands from the common driver
`that are "generic" to the given type of devices. Using the
`pre-selected set of commands, the common driver can operate
`devices of that type through their respective simplified drivers
`to provide their functionality. For example, the set of com-
`55 mands may include simple input/output (I/O) operations such
`as "SET" and "GET' operations that are generic in use, but
`the specific operations performed by the simplified driver to
`carry out the commands depend on the target device. The
`common driver is not required to have knowledge of the
`60 specifics of the simplified driver.
`In contrast to the common driver, the simplified device
`driver 62 for a particular device 64 implements any needed
`device behavior specific to the device and is expected to be
`provided by the vendor of that device. As described above, the
`65 common driver can send a finite set of commands to the
`simplified device driverof a target device to accomplish tasks.
`The simplified driver can implement any method to translate
`
`Petitioners Microsoft Corporation and HP Inc. - Ex. 1026, p. 6
`
`

`

`US 7,673,303 B2
`
`5
`the generic connnands from the connnon driver into device
`specific operations. The connnon driver is not concerned with
`the details of such device specific operations and preferably
`only has to be informed of the success/failure status of these
`commands.
`By way of example, in an embodiment where the devices
`are scanners, the connnon driver may send a connnand to set
`the X resolution (e.g., "CMD_SET_X_RESOLUTION") to
`the simplified driver of a scanner with the intended value of
`the X resolution. The simplified driver interprets the com(cid:173)
`mand as an intention to set the X resolution, and issues the
`correct sequence of connnands to the associated scanner with
`the specified x resolution value. The simplified driver then
`returns a response to the connnon driver indicating whether
`the setting operation is successful.
`In the following description, the invention will be
`described in the context of an embodiment based on the
`Windows Image Acquisition (WIA) architecture, which is
`part of the Windows operating system of Microsoft Corpora(cid:173)
`tion. Moreover, the invention will be described using flatbed
`scanners as one example of the different types of hardware
`devices for which simplified device drivers can be advanta(cid:173)
`geously used. It will be appreciated, however, that the
`approach of employing simplified device-specific drivers in
`accordance with the invention can be effectively used in other
`types of operating systems. Moreover, the invention is not
`limited only to flatbed scanners but can be advantageously
`applied to other types of computer peripheral devices, where
`a connnon set of generic operations can be defined for differ(cid:173)
`ent models of the devices.
`Referring now to FIG. 3, the operating system of the shown
`embodiment employs an image acquisition architecture that
`is designed to enable an image-processing application 80 to
`effectively connnunicate with and control the operations of
`various image-capturing devices, such as scanners and digital
`cameras. To illustrate the concept of using simplified device
`drivers in accordance with the invention, a simplified device
`driver 72 for a flatbed scanner 7 4 is juxtaposed with a regular
`device driver 76 for another image-capturing device 78, and
`the image acquisition architecture is described in connection 40
`with the regular device driver to allow an appreciation of the
`advantages of using the simplified device driver.
`In the embodiment of FIG. 3, the image-capturing device
`78 functions as a source of color image data, which can be
`transmitted to an image-processing application 80 for various
`types of processing and editing operations. The processed or
`edited color image may then be displayed on a color display
`device (such as a computer monitor 84) for viewing, printed
`on a printer 86, or included in a document for presentation or
`communication purposes.
`The image acquisition architecture of the operating system
`88 includes a system-supplied image acquisition service 100,
`which servers as an intermediate between the application 80
`and the device drivers for various image-capturing devices,
`such as the image-capturing device 78 (which may be a scan(cid:173)
`ner, a digital camera, etc.) and the flatbed scanner 74. The
`image-processing application 80 connnunicates with the
`image acquisition service 100 through an image acquisition
`Application Progrannning Interface (API) 110 provided by
`the operating system 88. When the application 80 makes a
`request to use one of the image capturing devices, the image
`acquisition service 100 directs the request to the device driver
`for that image-capturing device. Connnunicating with the
`device driver 76 through the image acquisition service 100,
`the image processing application 80 can monitor, connnuni(cid:173)
`cate with, and receive captured color image data from the
`image-capturing device 78.
`
`6
`The device driver 76 is typically supplied by the vendor of
`the associated image-capturing device 78. In the illustrated
`embodiment, the device driver 80 is a user-mode component
`that directs image acquisition property changes and com-
`5 mands to its associated image-capturing device 70. It com(cid:173)
`municates through a device-specific user-mode interface 112
`with system-supplied or vendor-supplied kernel-mode I/0
`device drivers 102, which drives the image-capturing device
`78 through a driver such as a USB driver. The kernel-mode
`10 image drivers 102, which are bus-specific, package data for
`delivery to the image-capturing device 78 and transfer data
`from the image-capturing device to the device driver 80. The
`connnunications between the kernel-mode image driver 102
`and the image-capturing device 78 may be based on one of
`15 different types of buses. For instance, in one implementation,
`kernel-mode image drivers for the USB, SCSI, and IEEE
`1394 buses are provided with the operating system 88.
`In the opposite direction of the connnand/data flow, the
`device driver 76 connnunicates with the image acquisition
`20 service 100 through a Device Driverlnterface (DDI) 106. The
`image acquisition DDI 106 allows the image acquisition ser(cid:173)
`vice 100 to connnunicate with and control the device driver
`76. Requests made by the application 80 concerning the
`image-capturing device 78 are directed to the image acquisi-
`25 tion service 100, which in turn directs the requests to the
`appropriate device driver 76 through the image acquisition
`Device Driver Interface (DDI) 106. To work with the image
`acquisition DDI 106, the device driver 76 is required to imple(cid:173)
`ment various pre-defined interface methods for communica-
`30 tions with the Image Acquisition Service 100. The interface
`methods perform device-related tasks such as: creating a tree(cid:173)
`like data structure ( called a "device tree") with items repre(cid:173)
`senting the device and its images and folders; reading and
`writing properties of the items in the device tree; transferring
`35 captured image data from the image-capturing device; enu(cid:173)
`merating device image formats supported by the device;
`deleting an item in the device tree; sending operation com(cid:173)
`mands to the device; enumerating device capabilities; and
`obtaining device error message strings.
`It can be seen from this example that to implement the
`required DDI interface methods in a regular device driver for
`an image-capturing device, a hardware vendor has to have a
`good understanding of the image-acquisition architecture of
`the operation system and to follow carefully the specifications
`45 of the methods and their parameters. Due to the relatively
`large number and complexity of the required interface meth(cid:173)
`ods, the proper development of a regular device driver 76 for
`an image-capturing device can require significant time and
`resources. The hardware vendor of the device 78 may find it
`50 difficult to allocate the needed resources for driver develop(cid:173)
`ment, especially when the device is a low-end model. This
`problem, of course, is not peculiar to image-capturing devices
`but is a general one for vendor-provided device drivers.
`The use of simplified device drivers in accordance with the
`55 invention effectively solves this problem. Specifically, rather
`than implementing all the device driver interface methods
`required of a regular device driver (e.g., the driver 76), a
`simplified device driver for a device of a given type only has
`to implement entry point functions pertaining to a very small
`60 set of operation connnands generic to devices of the given
`type. Those entry point functions allow the simplified device
`driver to be accessed by a connnon driver for the given device
`type. The connnon driver, preferably system-supplied,
`handles the device driver interface methods as required by the
`65 system architecture, and connnunicates with the simplified
`device driver through the entry point functions implemented
`therein. In this way, the system-supplied connnon driver and
`
`Petitioners Microsoft Corporation and HP Inc. - Ex. 1026, p. 7
`
`

`

`US 7,673,303 B2
`
`8
`I. Required Entry Point Functions
`A. The MicroEntry Function
`The MicroEntry function is defined as:
`
`HRESULT MicroEntry(
`LONG !Command
`PVALpValue
`
`);
`
`This function is used by the Flatbed Driver to dispatch com(cid:173)
`mands to the simplified driver. As to the parameters, !Com(cid:173)
`mand represents a command issued to the simplified scanner
`driver by the Flatbed Driver. The parameter p Value is a
`pointer to a VAL structure that specifies data related to the
`corresponding !Command. The valid p Val data members are
`described in a Command Reference Section below. If the
`function succeeds, the VAL structure pointed to by pValue
`should contain valid data related to the corresponding !com(cid:173)
`mand issued. If the function fails, error information can be set
`in the !Val member of the VAL structure. For any command
`not
`supported by
`the
`simplified driver,
`a value
`"E_NOTIMPL" will be returned. The list of required com(cid:173)
`mands to be supported by the simplified driver is provided in
`the Required Command section below. Most of the com(cid:173)
`mands sent to MicroEntry are used to set parameters of a scan
`operation by the flatbed scanner. The simplified scanner
`driver sends the settings down to the flatbed scanner.
`B. The GetScaninfo Function
`The GetScaninfo function is defined as
`
`HRESULT GetScanlnfo(
`PSCANINFO pScanlnfo
`
`);
`
`40 This function returns the valid and current values for all of the
`scanner's properties. The parameter pScaninfo is a pointer to
`a SCANINFO structure that contains information about the
`simplified scanner driver's current and valid settings.
`C. The SetPixe!Window Function
`The SetPixe!Window function is defined as:
`
`7
`the vendor-supplied simplified device driver together func(cid:173)
`tion like a regular device driver ( such as the device driver 76).
`Since the simplified device driver does not have to implement
`the complicated system interface methods, it is significantly
`easier for the hardware vendor to develop. The hardware 5
`vendor only has to focus on device-specific behavior, which it
`knows best, in writing the simplified device driver to perform
`operations for carrying out the small set of commands from
`the common driver.
`For instance, in the illustrated embodiment, the image 10
`acquisition architecture requires a regular device driver 76 to
`handle the management and validation of the settings of
`image acquisition properties according to rules defined as
`part of the architecture. With the combination of a common
`driver and one or more simplified drivers, the common driver 15
`controls the various aspects of the property management and
`validation. Thus, a simplified driver does not have to deal with
`property management and validation, and only has to handle
`property setting negotiations and data acquisition operations.
`In one embodiment, the installation of a simplified device 20
`driver requires additional entries in the installation file ( .INF).
`First, an entry is included in the device data section of the .INF
`file to indicate that the device driver is a "simplified" one
`rather than a regular driver. The value of this entry is set to be
`the name of the file (in this embodiment a .DLL file) that 25
`implements the simplified device driver. Moreover, in an
`"Add to Register" section where a regular device driver would
`normally be referenced, the file that implements the common
`driver is listed as the driver for the device.
`In the embodiment of the image-acquisition system shown 30
`in FIG. 3, the common driver for flatbed scanners is referred
`to as the "Flatbed Driver" 90. The Flatbed Driver 90 may be
`used together with a plurality of simplified device drivers,
`referred to as "simplified scanner drivers," for flatbed scan(cid:173)
`ners that may be of different models from different hardware 35
`vendors. Each of the simplified scanner drivers is required to
`implement entry point functions for corresponding operation
`commands generic to those flatbed scanners. Specifically,
`there are only four entry point functions that the simplified
`sc