BACKGROUND In the world of portable electronics, smaller is better.

Referring to cellular telephones as an example, the three pound"bag telephone"of several years ago has given way to today's pocket-sized models weighing less than a pound.

The driving force behind down-sized electronics is public demand. A quick survey of current sales literature depicts scenes such as an ant next to a cellular telephone, or a cellular telephone neatly nestled in the palm of the hand of its lucky owner. Not surprisingly, physical dimensions commonly appear before performance dimensions in sales material.

Historically, manufacturers have reduced the size of portable devices such as cellular telephones in one of two ways. First, fewer and smaller electrical components are more compactly arranged within the device. Second, battery size is reduced.

Additionally, as the cellular telephone market has evolved, technology-savvy consumers have added demands for greater performance to their desire for compact packaging. Consequently, telephonic range, features, and so-called"stand-by"times are now critical selling points.

These additional consumer demands have created vexing conflicts for cellular telephone manufacturers. Specifically, a direct conflict exists between demands for reduced battery size and demands for increased stand-by times. Greater stand-by times require more battery power which, in turn, requires a larger (and less desirable) battery. While it is true that numerous recent advances in battery technology have provided smaller batteries with greater power, further revolutionary developments in battery technology are uncertain.

Consequently, there is a need to increase stand-by time and other power-related performance features in portable electronic devices within constraints placed by current battery and electronics technology.

There is yet another need to increase performance characteristics of portable electronic devices without adding significantly to the physical size or weight of such electronic devices. Finally, there is a need to increase performance characteristics of portable electronics devices without substantially re-designing the devices.

SUMMARY OF THE PRESENT INVENTION The present invention satisfies the above-stated needs by providing a method for reducing power consumption in an electronic device.

Typically, every electronic device is comprised of a plurality of subsystems. A"subsystem"may be a grouping of individual components which accomplish a single function. Additionally, a subsystem may be an individual component which functions alone to

accomplish a particular function. For the purposes of this disclosure, the term"subsystem"shall be liberally construed to include both categories.

The present invention identifies a plurality of particularly important subsystems ("selected subsystems") from the plurality of subsystems within the electronic device. The method of the present invention begins by determining whether a functional interdependency exists between any of the selected subsystems. The term"functional interdependency", as hereafter used, refers to a relation between subsystems whereby a first subsystem is dependent on the operation of a second subsystem in order to perform its intended function in an intended manner. The first subsystem may be dependent on another subsystem or on a number of other subsystems with or without the other subsystem (s) being dependent on the first subsystem.

For each of the selected subsystems having a functional interdependency with another of the selected subsystems, the existence and character of the functional interdependency is recorded in a table which may be included with other tables in a database. Next, the current operational state of each of the selected subsystems is determined and similarly recorded in a state table, which may be integrally incorporated into the database. In an embodiment of the present invention, the current operational state recorded in the state table may contain at least one performance criteria from the group of performance criteria including clock speed, mode and bandwidth.

Additionally, the state table may include information relating to at least one factor from a group of factors including physical devices, logical devices, sequencing requirements, subsystem requirements by mode, domain or subsystem bandwidth requirements, and turn off delays.

When an electrical device employing the method of the present invention receives a"change command"to change the current

operational state of a specific selected subsystem within the electronic device (e. g. from"on"to"off'), the method of the present invention determines whether each of the functional interdependencies relating to the selected subsystem has been satisfied. If so, the current operational state of the selected subsystem is changed and the new operational state is recorded in the state table. If not, the current operational state remains unchanged.

Accordingly, by considering functional interdependencies before changing the operational state of a subsystem, the present invention avoids situations in which a first subsystem is, for instance, turned"off'because the first subsystem is not needed, then turned back "on"because another subsystem is dependent on the first subsystem for operation. The resulting lack of device responsiveness, efficiency and unnecessarily large expenditure of power is avoided by implementation of the method of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram illustrating an exemplary arrangement for implementation of the method of the present invention.

Fig. 2 is a flow diagram illustrating exemplary steps taken by the present invention when a subsystem requests a device to be turned on.

Fig. 3 is a flow diagram illustrating exemplary steps taken by the present invention when a subsystem requests a device to be turned off.

Fig. 4 is a system diagram that illustrates an exemplary environment suitable for implementing various embodiments of the present invention.

DETAILED DESCRIPTION Referring now to the drawings in which like numerals refer to like elements throughout the several view, Fig. 1 is a block diagram

illustrating an exemplary functional arrangement 10 for implementation of the method of the present invention.

Specifically, a portable electronic device implementing the method of the present invention would, optimally, include a power management subsystem 20, a database 30, a subsystem request conduit 40, a processor speed control circuit 50, and a subsystem power control circuit 60.

The power management subsystem 20 is the"brains"of the invention and provides logic, discrimination and determination capabilities by receiving requests from certain subsystems and comparing those requests to internally accessible information to determine how subsystems will be"handled."In other words, when the power management subsystem 20 receives a request from a first subsystem to cut power to that subsystem, the power management subsystem evaluates operational needs of other subsystems to determine whether such a change in power status for the first subsystem is advisable. Ultimately, the power management subsystem 20 is capable of exercising control over processor clock speed and mode (sleeping or not), as well as the state of all subsystems. The power management subsystem 20 may be any one of a large number of widely recognized and readily available microprocessors.

The power management subsystem 20 has communicative access to at least one database 30. The database 30 is the central repository for information relating to both individual subsystems within the portable electronic device, as well as the relation of individual subsystems to each other. Such relations between individual subsystems are generically referred to as functional interdependencies.

In an exemplary embodiment of the present invention, the database 30 comprises a number of tables, each table containing

information relating to certain selected subsystems within the portable electronic device. For example, a processor bandwidth table 32 may contain information relating to the bandwidth required for certain subsystems. Ideally, this table should identify the processor bandwidth required by each selected subsystem in all possible operating modes. A subsystem state table 34 may contain information as to both the current state and possible turn-off delay of every controllable subsystem. In the context of portable electronic devices, the turn-off delay of a device is used for devices that have long power-up or power-down requirements and could impact short duty cycle subsystem power cycling requirements.

The turn-off delay is typically set to a value that is slightly longer than the sum of the power-up and power-down delays.

A subsystem dependency table 36 captures and allows implementation of dependencies between subsystems. For instance, if a command to power-up a first subsystem is received, and if a functional interdependency exists between the first subsystem and a second subsystem, the power management subsystem 20 would detect the functional interdependency during a query of the subsystem dependency table 36 in the database 30. As a result, not only would the first subsystem be powered-up, but so would the second subsystem, in order that the first subsystem would be rendered operational. The same principle is applicable with power-down situations. More specifically, if a command to power-down a device is received, the power management subsystem 20 inquires within the subsystem table 36 for devices having a functional interdependency with the first subsystem. If such a functionally interdependent second subsystem exists, and if the second subsystem is in a power-on state, the first subsystem would not be allowed to power-down at that time.

Subsystem requests 40 typically originate with a man-to- machine interface, such as a physical keypad or other type of switch integral to the portable electronic device. Optionally, subsystem requests 40 may originate with the arrival of an incoming communication signal, pre-programmed transmission of an outgoing communication signal, a message generated by a different subsystem, or any other of a wide variety of ways of prompting action or response by a portable electronic device. In a preferred embodiment of the present invention, subsystem requests 40 are routed to the power management subsystem 20 for evaluation and action. As previously discussed, the power management subsystem then solicits information from the database 30 before directing an action relating to power allocation and use within the portable electronic device.

Each time a subsystem request 40 is received by the power management subsystem 20 to change the bandwidth requirements, the processor bandwidth table 32 is updated and the overall processor bandwidth requirement is assessed. If any subsystem originates a subsystem request 40 indicating a requirement for a specific amount of bandwidth, the highest bandwidth currently requested is used to determine the current processor clock speed. For example, if a first and a second subsystem indicate a low bandwidth requirement, but a third subsystem indicates a high bandwidth requirement, the processor clock speed is set to maximize processor bandwidth.

If all subsystems indicate a"sleep"mode, the processor is then placed into a sleep mode. When the processor comes out of the sleep mode due to an external stimulus such as those varieties discussed above, it initially operates at full clock speed. Once processing of the event that caused the"wake up"is completed the power management subsystem 20 is triggered to re-evaluate bandwidth requirements and possibly change

processor clock speeds or put the processor back to"sleep."It should be noted that the actual process of putting the processor completely to sleep is optimally taken care of by the operating system of the portable electronic device because such a processor status should only be reached during periods of complete task inactivity.

Finally, the power management subsystem 20 can implement power-up or power-down determinations reached in the above articulated fashion via a subsystem power control unit 60. As suggested by its name, the subsystem power control unit 60 functions to effect power-up or power-down directives issued by the power management subsystem 20.

Referring now to Fig. 2, a flow diagram illustrating exemplary steps taken by the present invention when a subsystem requests a device to be turned on is depicted. The exemplary method begins at step 210 when a change command for a subsystem is received.

Typically, such change commands originate with a man-to-machine interface, such as a physical keypad or other type of switch integral to the portable electronic device. Optionally, change command (also referred to as subsystem requests or commands) may originate with the arrival of an incoming communication signal, pre-programmed transmission of an outgoing communication signal, a message generated by a subsystem, or any other of a wide variety of ways of prompting action or response by a portable electronic device.

Upon receipt of a change command, the present invention checks the current operational state of the subsystem at step 220. The state of some or all of the subsystems of the portable electronic device are recorded in a subsystem state table within a database, as previously described. At decision block 230, if the subsystem subject to the change command is already"on", any pending turn off delay is canceled at step 240 and the method ends at step 299.

If, on the other hand, the subsystem is not already"on", an inquiry as to whether the subsystem requires any other subsystems for operation is made at step 250. If such other subsystems are required for operation of the subsystem which was the subject of the change command, those other subsystems are powered on at step 260.

After it has been determined that the subsystem which is the subject of the change command is not already on and after all other subsystems on which the subsystem relies have been powered on, the subsystem which is the subject of the change command is powered on at step 270. Responsive to the change of state of the subsystem, information relating to the state of the subsystem is updated in the state register (also referred to as a subsystem state table) at step 280 and the method ends at step 299.

Fig. 3 is a flow diagram illustrating exemplary steps taken by the present invention when a subsystem requests a device to be turned off.

The exemplary method begins at step 310 when a change command for a subsystem is received. Typically, such change commands originate with a man-to-machine interface, such as a physical keypad or other type of switch integral to the portable electronic device. Optionally, change command (also referred to as subsystem requests or commands) may originate with the arrival of an incoming communication signal, pre- programmed transmission of an outgoing communication signal, a message generated by a subsystem, or any other of a wide variety of ways of prompting action or response by a portable electronic device.

Upon receipt of a change command, the present invention checks the current operational state of the subsystem at step 320. The state of some or all of the subsystems of the portable electronic device are recorded in a subsystem state table within a database, as previously

described. If, at decision block 330, the subsystem is already off, the method ends at step 399.

If, on the other hand, the subsystem is not already off, an inquiry is made at decision block 340 as to whether other subsystems require the subsystem that is the subject of the change command to remain on. This inquiry is satisfied by examination of an information source such as a subsystem dependency table in a database, as previously described. If no other subsystems require the subsystem to remain on, the change command is acted upon, the subsystem is powered off at step 360.

Because powering off the subsystem is a change in the state of the subsystem, subsystem information stored in the subsystem state table (also referred to as state register) is updated at step 370 and the method ends at step 399.

Otherwise, if the other subsystems are already off, the method ends at step 399.

It is important to note that the above described methods are generally applicable not only to turning various subsystems on and off, but are also applicable to bandwidth determinations. For instance, assuming there is a correlation between an increase in bandwidth and an increase in power consumption, subsystems within a portable electronic device have a known bandwidth requirement. In other words, for particular subsystems to perform as intended, they require a certain amount of bandwidth.

As previously discussed, other information such as bandwidth requirements and clock rates for various subsystems may also be recorded in terms of functional interdependencies in a database table such as a processor bandwidth table. In the case of bandwidth requirements, when a change command is received by the present invention that would lower the processor bandwidth, an inquiry is made

as to what subsystems are currently operating. A further inquiry is made into the processor bandwidth table to determine the bandwidth requirements for each of the operating subsystems. If the change command will result in a bandwidth so low that the operating subsystems are unable to perform their intended functions, the bandwidth reduction change command is either ignored, delayed or modified so that the intended functionality of the portable electronic device may continue.

EXEMPLARY OPERATING ENVIRONMENT Fig. 4 is a system diagram that illustrates an exemplary environment suitable for implementing various embodiments of the present invention. Fig. 4 and the following discussion provide a general overview of a platform onto which the invention may be integrated or implemented. Although in the context of the exemplary environment the invention will be described as consisting of instructions within a software program being executed by a processing unit, those skilled in the art will understand that portions of the invention, or the entire invention itself may also be implemented by using hardware components, state machines, or a combination of any of these techniques. In addition, a software program implementing an embodiment of the invention may run as a stand-alone program or as a software module, routine, or function call, operating in conjunction with an operating system, another program, system call, interrupt routine, library routine, or the like. The term program module will be used to refer to software programs, routines, functions, macros, data, data structures, or any set of machine readable instructions or object code, or software instructions that can be compiled into such, and executed by a processing unit.

Those skilled in the art will appreciate that the system illustrated in Fig. 1 may take on many forms and may be directed towards performing a variety of functions. Examples of such forms and functions

include cellular telephones, radio telephones, portable telephones, two- way pagers, personal computers, hand-held devices such a personal data assistants and calculators, consumer electronics, note-book computers, lap-top computers, and a variety of other applications, each of which may serve as an exemplary environment for embodiments of the present invention.

The exemplary system illustrated in Fig. 4 includes a computing device 410 that is made up of various components including, but not limited to a processing unit 412, non-volatile memory 414, volatile memory 416, and a system bus 418 that couples the non-volatile memory 414 and volatile memory 416 to the processing unit 412. The non-volatile memory 414 may include a variety of memory types including, but not limited to, read only memory (ROM), electronically erasable read only memory (EEROM), electronically erasable and programmable read only memory (EEPROM), electronically programmable read only memory (EPROM), electronically alterable read only memory (EAROM), FLASH memory, bubble memory, and battery backed random access memory (RAM). The non-volatile memory 414 provides storage for power on and reset routines (bootstrap routines) that are invoked upon applying power or resetting the computing device 410.

In some configurations the non-volatile memory 414 provides the basic input/output system (BIOS) routines that are utilized to perform the transfer of information between elements within the various components of the computing device 410.

The volatile memory 416 may include, but is not limited to, a variety of memory types and devices including, but not limited to, random access memory (RAM), dynamic random access memory (DRAM), FLASH memory, EEPROM, bubble memory, registers, or the like. The volatile memory 416 provides temporary storage for routines, modules,

functions, macros, data etc. that are being or may be executed by, or are being accessed or modified by the processing unit 412. In general, the distinction between non-volatile memory 414 and volatile memory 416 is that when power is removed from the computing device 410 and then reapplied, the contents of the non-volatile memory 414 remain in tact, whereas the contents of the volatile memory 416 are lost, corrupted, or erased.

The computing device 410 may access one or more external display devices 430 such as a CRT monitor, LCD panel, LED panel, electro-luminescent panel, or other display device, for the purpose of providing information or computing results to a user. In some embodiments, the external display device 430 may actually be incorporated into the product itself. The processing unit 412 interfaces to each display device 430 through a video interface 420 coupled to the processing unit 410 over the system bus 418.

The computing device 410 may send output information, in addition to the display 430, to one or more output devices 432 such as a speaker, modem, printer, plotter, facsimile machine, RF or infrared transmitter, computer or any other of a variety of devices that can be controlled by the computing device 410. The processing unit 412 interfaces to each output device 432 through an output interface 422 coupled to the processing unit 412 over the system bus 418. The output interface may include one or more of a variety of interfaces, including but not limited to, an RS-232 serial port interface or other serial port interface, a parallel port interface, a universal serial bus (USB), an optical interface such as infrared or IRDA, an RF or wireless interface such as Bluetooth, or other interface.

The computing device 410 may receive input or commands from one or more input devices 434 such as a keyboard, pointing device,

mouse, modem, RF or infrared receiver, microphone, joystick, track ball, light pen, game pad, scanner, camera, computer or the like. The processing unit 412 interfaces to each input device 434 through an input interface 424 coupled to the processing unit 412 over the system bus 418.

The input interface may include one or more of a variety of interfaces, including but not limited to, an RS-232 serial port interface or other serial port interface, a parallel port interface, a universal serial bus (USB), an optical interface such as infrared or IrDA, an RF or wireless interface such as Bluetooth, or other interface.

It will be appreciated that program modules implementing various embodiments of the present invention may be may be stored in the non-volatile memory 414, the volatile memory 416, or in a remote memory storage device accessible through the output interface 422 and the input interface 424. The program modules may include an operating system, application programs, other program modules, and program data.

The processing unit 412 may access various portions of the program modules in response to the various instructions contained therein, as well as under the direction of events occurring or being received over the input interface 424.

The computing device 410 may transmit signals to, or receive signals from, one or more communications systems 436 such as a cellular network, RF network, computer network, cable network, optical network or the like. The processing unit 412 interfaces to each communications system 436 through a transmitter 426 and a receiver 428, both coupled to the processing unit 412 over the system bus 418. The transmitter 426 and the receiver 428 may include one or more of a variety of transmission techniques such as a radio frequency interface (AM, FM, PSK, QPSK, TDMA, CDMA, Bluetooth or other technique) or an optical interface such as infrared or IrDA.

Alternative embodiments will become apparent to those skilled in the art to which the present invention pertains without deviating from its spirit and scope. Accordingly, the scope of the present invention is described by the appended claims and is supported by the foregoing description.