1. Description

Power saving in laptop computers traditionally relied on hardware inactivity timers to determine whether a computer was idle. It would typically take several minutes before the computer could identify idle behavior and switch to a lower power consumption state. By monitoring software applications from within the operating system, BatteryMAX is able to reduce the time taken to detect idle behavior from minutes to microseconds. Moreover, it can switch power states around 18 times a second between a user's keystrokes. The technique was named Dynamic Idle Detection and includes halting, or stopping the CPU for periods of just a few microseconds until a hardware event occurs to restart it.

DR DOS 5.0 was the first Personal Computer operating system to incorporate an Idle Detection System for power management. It was invented by British engineers Roger Gross and John Constant in August 1989.^[1] A US patent describing the idle detection system was filed on 9 March 1990 and granted on 11 October 1994.^[2]

Despite taking an early lead and having the protection of a patent, BatteryMAX did not enjoy significant commercial success having been sidelined after the disarray that followed the integration of Digital Research into Novell, Inc. in 1991. It was not until 1992, some three years after the invention, that software power management under operating system control became ubiquitous following the launch of Advanced Power Management (APM) by Microsoft and Intel.

2. Functional Overview

BatteryMAX uses the technique of Dynamic Idle Detection to provide power savings by detecting what the application is doing (whether it is idle), and switching power states (entering low power mode) therefore extending the battery life of the product.

BatteryMAX employs a layered model of detection software encapsulated into an DOS character device driver called $IDLE$ that contains all the hardware-dependent code to support Dynamic Idle Detection. It can either be linked into the DR-DOS operating system BIOS or loaded dynamically using the CONFIG.SYS DEVICE directive, overloading the built-in default driver. All versions of DR-DOS since version 5.0 have contained Dynamic Idle Detection support inside the operating system kernel. When the operating system believes an application is idle, it calls the $IDLE$ BIOS/driver layer, which executes custom code written by the computer manufacturer or third parties to verify the request and switch power states. Using the device driver concept, BatteryMAX can be integrated with hardware-related power management facilities, which might be provided by the underlying hardware, including interfacing with APM or ACPI system BIOSes.

Power states are computer dependent and will vary from manufacturer to manufacturer. Power savings can be made in a number of ways including slowing/stopping the processor clock speed or shutting off power to complete sub-systems.

Before switching power states, the $IDLE$ driver uses any available hardware assistance to detect if the application has been accessing other components in the system. For example, the application may be polling a serial port, or updating a graphics screen. If this is the case, the device driver determines that the application is not in fact idle and overrides the kernel's call to switch power states by passing information back up the layers and allowing application execution to resume.

3. Detecting When an Application Is Idle

An application is idle if it is waiting for some external event to occur, for example for a keystroke or a mouse movement, or for a fixed amount of time to pass. The DR-DOS kernel monitors all DOS API calls building up a profile of the applications behavior. Certain combinations of API calls suggest that the application is idle.

The $IDLE$ driver is able to make the subtle distinction between a program that is genuinely idle, for instance one that is polling the keyboard in a tight loop, and one that is active but also polling the keyboard, to test for an abort key to be pressed. The driver makes this distinction by monitoring the time taken to go idle. If the time is within a specified period, the driver assumes that the program is idle, e.g. polling in a tight loop for a key to be pressed. If the time is outside the specified limit, the driver assumes that some processing has occurred in between polling the keyboard, and allows application execution to resume without switching power states. A local variable, IDLE_CNTDN, specifies the time against which the actual time taken to go idle is compared. The value for this variable is dynamically calculated at initialization and recalculated periodically.

4. Origins of BatteryMAX

The Idle Detection technique was first used to improve multi-tasking of single-tasking DOS applications in Digital Research's multi-tasking/multi-user Concurrent DOS/386 (CDOS386) operating system.

Programs written for single-tasking operating systems such as MS-DOS/PC DOS can go into endless loops until interrupted; for example when waiting for a user to press a key. Whilst this is not a problem where there is no other process waiting to run, it wastes valuable processor time that could be used by other programs in a multi-tasking/multi-user environment like CDOS386. Applications designed for a multi-tasking environment use API calls to "sleep" when they are idle for a period of time but normal DOS applications do not do this so Idle Detection must be used.

The Concurrent DOS/386 release included an Idle Detection function in the operating system kernel which monitored DOS API calls to determine whether the application was doing useful work or in fact idle. If it was idle, the process was suspended allowing the dispatcher to schedule another process for execution.

5. Patent Litigation

BatteryMAX and the "idle detection" patent played an important role in an alleged patent infringement relating to software power management under operating system control.

On May 15, 2009, St. Clair Intellectual Property Consultants, Inc. filed civil action No. 09-354 in the United States District Court D. Delaware, against defendants Acer, Inc., Dell Inc., Gateway, Inc. and Lenovo Group, Inc. and on September 18, 2009 filed civil action No. 09-704 against Apple Inc., and Toshiba Corporation, Inc. The actions alleged infringement of several U.S. patents that they owned relating to software power management under operating system control.

St. Clair asserted that Henry Fung had invented software power management under operating system control and alleged that these companies had infringed St. Clair's patents and therefore owed St. Clair royalty payments. Microsoft intervened on behalf of the defendants and filed a declaratory judgment against St. Clair on April 7, 2010, seeking judgments of non-infringement and invalidity of the Fung patents. (D.I. 1, C.A. No. 10-282). Intel Corporation filed an intervention on behalf of the defendants and this was granted on June 4, 2010 (D.I. 178, C.A. No. 09-354).

Seattle law firm Perkins Coie, LLP acting for the defendants discovered BatteryMax and Gross’s Idle Detection Patent during a prior art search. Gross’s patent had an earlier priority date than Fung’s patents which if proven would undermine St. Clair's case. On February 28, 2011, Gross was hired by Intel as a Subject Matter Expert to provide expert witness testimony for the defendants in the case. Gross provided evidence in his expert report that he, not Fung, had invented software power management under operating system control and sited the Idle Detection patent and the existence of BatteryMax as proof of this.

St Clair filed a Motion to Exclude Opinions Concerning BatteryMax, in an attempt to have Gross’s expert report dismissed but on March 29, 2013 the district court denied St. Clair’s motion declaring Gross’s testimony for the defendants as admissible,^[3] stating that "The Court agrees with Defendants that there is sufficient corroborating evidence that BatteryMax was available to the public prior to the Fung patents' priority date. Further, the Court concludes that even if BatteryMax did not predate the Fung patents, Mr. Gross's testimony … would be relevant and helpful to the fact finder in an obviousness inquiry”.