http://www.peertopatent.org/patent/20070162625/activity A method and apparatus for delivering a device driver to an operating system without user intervention. One or more operating systems (e.g., different operating system programs, different versions of one operating system) execute on a computer platform. During booting of an operating system a device is identified for which a driver is needed. The driver is requested from a service processor of the platform, which includes memory or storage for storing multiple device drivers (or multiple versions of one driver, for different operating systems). The driver is retrieved from the service processor's storage and delivered to the operating system. en-us Method and apparatus for delivering device drivers 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. Thu, 16 Aug 2007 08:43:48 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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. Thu, 16 Aug 2007 09:10:55 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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). Wed, 01 Aug 2007 18:21:00 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers Interesting background - not sure if it's prior art, though: http://l4ka.org/publications/paper.php?docid=1208 Tue, 31 Jul 2007 10:25:31 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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? Mon, 30 Jul 2007 17:34:06 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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. Tue, 31 Jul 2007 09:51:26 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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... Tue, 31 Jul 2007 11:07:54 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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? Tue, 31 Jul 2007 21:55:47 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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. Wed, 01 Aug 2007 01:01:18 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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. Wed, 01 Aug 2007 01:12:40 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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? Mon, 30 Jul 2007 08:40:56 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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. Mon, 30 Jul 2007 10:19:39 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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. Mon, 30 Jul 2007 13:59:45 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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. Tue, 31 Jul 2007 08:53:45 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers 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. Tue, 31 Jul 2007 09:35:24 -0700 http://www.peertopatent.org/patent/20070162625/discussion Method and apparatus for delivering device drivers I agree with Todd. In fact there is no thin line between differentiating a Device Driver to a Software Piece Tue, 07 Aug 2007 02:13:07 -0700 http://www.peertopatent.org/patent/20070162625/discussion