Peer To Patent

Pre-Grant Publication Number: 20070162625

Method and apparatus for delivering device drivers

Collaborate on the process of community review for this application. Posting will not be forwarded to the USPTO. Flagging a post as an ACTION ITEM signals further research. Flagging SPAM and ABUSE helps to manage discussion. Placing double brackets around a reference to a claim or prior art will create a hyperlink to the original ex. [[claim 1]] and [[prior art 2]].

Please review the Community Code of Conduct prior to posting

Discussion (16)

View: Date|Claims|Prior Art|Action Item|

Facilitator's Comment

Action Item

Show without Noise

Rakesh Parimi (almost 6 years ago)

Regarding Claim 00001
I was recently trying to install an old web cam onto Windows XP - and it turned out that the device driver on the installation CD was only supported for XP SP2. I think this suggested new method of delivering device drivers will come in handy in such cases - if the suggested technique can really work. There are obvious dependencies on the Operating System, XP SP2 in this case, being able to use advanced device driver find (e.g. on network) and then download it (what about security, network firewall). Do I want it to be installed automatically? It that a reliable piece of software? What about security loopholes? Is it hack proof? The idea maybe a nice to have one, but the disclosure is not illustrating the exact technique to be used. In a way it is incomplete.

Alex Young (almost 6 years ago)

I refer you to the [[description]]:

"In this embodiment, the computer system includes a service processor, which may be separate from a primary processor or CPU. The service processor includes storage, such as a flash ROM or PROM, in which the device driver is stored. Drivers for all devices that are installed and/or that could be installed in the system may be stored in the service processor storage."

It's assumed that physically acquiring the device drivers has already happened. In your case, the web cam driver would already be stored in the service processor before XP booted, so there's no need for any network access. One can make the assumption that the drivers would be tested before being stored in the service processor, so concerns as to the quality of the driver are tangential, really. I would consider this patent complete enough to be able to implement it.

Richard Robinson (almost 6 years ago)

I am not certain how a device driver is being defined here, but if a cryptographic key can be considered a device driver, then Blu-Ray, DVD, and other media disk readers always download a key (device driver) each time a new disk ("device") is placed into an old reader (e.g. DVD player).

Alex Young (almost 6 years ago)

Interesting background - not sure if it's prior art, though: http://l4ka.org/publications/paper.php?docid=1208

Teddi Maranzano (almost 6 years ago)

If a system administrator has installed a 3rd party adapter on his hardware, he gets the vendor's driver as part of the product. The driver is part of the overall install process. Whether he installs the driver into the OS directly or into the service processor ( would that be a firmware layer?), he still is aware of the need to do it. So I don't know he saved himself any work. Also, a lot of customers have security requirements for hardened OS images or other strict controls that would preclude just having the OS go and download a driver. I suppose a central software repository server could be set up to push out required drivers on demand. But don't the major UNIX OS's already have that capability?

Alex Young (almost 6 years ago)

It doesn't matter. The point of this invention (as I read it - I stand to be corrected) is to allow you to run an old OS on top of a hypervisor on special hardware, so that the hypervisor asks a coprocessor for the right driver for that OS / hardware combination. The hypervisor basically acts as a multiplexer for the device drivers, and lets you transparently run more than one old OS side-by-side with the service processor (claimed as a solid-state storage area of at least 32MB in Claim 6, so I'm sure they've got flash in mind) providing the correct device driver on boot of that guest OS. The best place I can think of for prior art as far as driver loading is concerned would be the Xen source code, but I'm pretty sure there's no capability there for storing drivers to flash. I'll take a look, anyway, something might show up.

Alex Young (almost 6 years ago)

Also worth checking out is the OpenFirmware spec - it's got a lot of similarities to what's being claimed here. There are enough differences between the spec itself and this application that I don't think OF would be prior art, but the similarities are great enough that there may be relevant journal articles that connect the dots. More food for thought...

Teddi Maranzano (almost 6 years ago)

I read it that they are talking about vmware containers that can be moved from one h/w platform to another, so that's running an old OS on a newer platform. They're also talking about needing a new driver for a newly installed bit of h/w, and also about updating an existing driver to a newer version. It has to be Non-volatile RAM or other solid state so that the drivers are available prior to OS initialization. This may be beyond the scope of the application, but how would you update the service processor? Through firmware updates to the h/w platform?

Alex Young (almost 6 years ago)

That's out of scope, because they aren't claiming anything related to updating the service processor. That being said, I'd handle it with a privileged management OS that downloaded updates over the network and handed them off to the hypervisor for storage via a virtual device driver.

"It has to be Non-volatile RAM or other solid state so that the drivers are available prior to OS initialization."

Not sure I agree with this. All that's necessary is that the hypervisor has access to the drivers during the guest OS boot sequence. If the drivers were stored on disk, that could be arranged via a disk device driver in the hypervisor itself. That would complicate the hypervisor code, though, so it may be that they've gone with firmware storage for simplicity.

Alex Young (almost 6 years ago)

That raises another point. If a hypervisor with that design existed, would it invalidate this application? It would invalidate claims 1-5, 7, 8-11 (I think - it depends if the "service processor" in claim 9 can be interpreted as being software in the hypervisor itself) and 13 at least, and put the remaining claims under a non-obviousness test. In that case, I'd argue that moving storage from hard disk to flash was obvious, so claim 6 would fall as well, and the patent would have to stand on claim 14 and its dependents.

Todd Gatts (almost 6 years ago)

For me, Claim 1 seems to hinge on whether operating systems and device drivers are somehow different enough to make a relatively common interaction into a novel one. The process of detecting a missing piece of software or a down-level pieces of software, downloading the needed software, and restarting or continuing happens daily. Firefox, Windows updates, Java, Flash -- each of these detect, download, and install. In addition, many of these installations will occur without user interaction, if the user wishes. Why is an OS at boot time something different than a browser? Why is a device driver different than a Flash plug-in or a Java Virtual Machine?

Wayne Delia (almost 6 years ago)

I generally agree. If I were to play a weak "devil's advocate" here, the difference would be that the application software product (i.e. a browser) has all the background services of the operating system available during an inspection/detection/downloading/restarting in an upgrade of the application software product, while an OS itself may not have those background services available (yet) when a device driver software piece is inspected for possible upgrade during boot-up. It's a weak defense, but might be the difference needed.

Dharmesh Bhakta (almost 6 years ago)

I think Todd has pretty strong case. Wayne, I think even the service processor would require background services just as the application software product. One can ask the same question, How will the operating system update the driver without background services (the processor)? I don't think the core idea is a novel one.

Bryan Aupperle (almost 6 years ago)

Software to look for new or updated drivers already exists, for example Lenovo Software Installer. The only novelty would therefore be doing the install/update with out user action. However, as Todd points out, this is already done for various applications, so adding this function to driver update software would be obvious.

Alex Young (almost 6 years ago)

Am I reading the claims wrong, then? I read Claim 1 and the background to say that the drivers are being supplied by hardware (a "support processor"), not software. If that's the case, then we need to look for a device with a USB port that can handle different types of interface device by loading firmware on demand from a chip external to the main device CPU. That's the closest analogy I can think of.

Sreekanth Kannepalli (almost 6 years ago)

I agree with Todd. In fact there is no thin line between differentiating a Device Driver to a Software Piece

0 days left