SYSTEMS AND METHODS FOR POWER MANAGEMENT IN RELATION TO A WIRELESS STORAGE DEVICE

Abstract

Various embodiments of the present invention provide systems and methods for reducing power consumption in a device including a memory system. As one example, a system may include a memory system with a hard disk drive and a flash memory. The flash memory maintains a menu file that includes a list of content objects available on the hard disk drive. In addition, the system includes a processor that executes software maintained on the memory system to update the menu file when a previously unavailable content object becomes available on the hard disk drive. Further, in some cases, the processor executes software that is operable to update the menu file when a previously available content object becomes unavailable on the hard disk drive. Additionally, the systems may include instructions executable by the processor to receive a play list, and to copy a first content object identified on the play list from the hard disk drive to the flash memory, and to copy a second content object identified on the play list from the hard disk drive to the flash memory. With the content objects thus moved to the flash memory, they can be uploaded to either the application device that supplied the play list, or to another application device designated as the recipient of the content objects.

Description

BACKGROUND OF THE INVENTION

The present invention is generally related to power management in consumer devices, and in particular to systems and methods for managing power in a wireless device including a non-volatile data storage component.

A variety of consumer devices exist today that are intended for wireless operation where the power source is limited to a battery. Because of the limited power source, most wireless consumer devices utilize some level of power management. For example, cellular telephones turn off power to their transmitter when it is not being used, and turn off power to an included graphical display when it is not used. As another example, laptop computers may include a sleep mode whereby non-essential functions of the computer are turned off after a certain period where no activity is detected. In some cases, such a sleep mode may include a variety of levels that each saves a different amount of power and each incurs a different recovery period. The aforementioned approaches provide for substantial power savings. However, the power savings are generally limited to maintaining elements of a device in an inaccessible state when the overall device is not being used. Thus, these approaches don't offer substantial power savings in situations where a device is fully operational.

Hence, for at least the aforementioned reason, there exists a need in the art for advanced systems and methods for power management.

BRIEF SUMMARY OF THE INVENTION

The present invention is generally related to power management in consumer devices, and in particular to systems and methods for managing power in a wireless device including a non-volatile data storage component.

Some embodiments of the present invention provide systems for reducing power consumption in a storage device. Such systems include a memory system with a hard disk drive and a flash memory. The flash memory maintains a menu file that includes a list of content objects available on the hard disk drive. In addition, the system includes a processor that executes software maintained on the memory system to update the menu file when a previously unavailable content object becomes available on the hard disk drive. Further, in some cases, the processor executes software that is operable to update the menu file when a previously available content object becomes unavailable on the hard disk drive. In some cases, the menu file is in a format usable to drive a user interface of a controlling application device. In one particular case, the controlling application device is a cellular telephone, and the user interface is a graphical user interface. In one particular case, the menu file is an XML format file.

In some instances of the aforementioned embodiments, the memory system further includes instructions executable by the processor to receive a play list, and to copy a first content object identified on the play list from the hard disk drive to the flash memory, and to copy a second content object identified on the play list from the hard disk drive to the flash memory. With the content objects thus moved to the flash memory, they can be uploaded to either the application device that supplied the play list, or to another application device designated as the recipient of the content objects. In various cases, the aforementioned application devices are communicably coupled to the memory system via a wireless network. In particular cases, the wireless network is a Bluetooth™ network. In various instances of the aforementioned embodiments, the first content object and the second content object are maintained in a flash memory upon power down of higher power requirement portions of a memory system.

Other embodiments of the present invention provide methods for power reduction. Such methods include providing a memory system that comprises at least a hard disk drive and a flash memory. The methods further include storing a content object to the hard disk drive, and maintaining a menu file in the flash memory that identifies the content object. The menu file is in a format usable to drive a user interface of an application device communicably coupled to the memory system via a wireless network. Such an approach relies on file based transfers and not necessarily on block based transfers. Because it is a file based transfer and not a block based transfer, it is known what requirements a particular file has in relation to a transfer. Therefore, power requirements may be tailored for exactly the file type, and not generically to a number of file types as would be required in a block based transfer system. In some instances of the aforementioned embodiments, another content object is stored to the hard disk drive. In such instances, the methods further provide for updating the menu file to reflect the availability of the added content object on the hard disk drive. In some cases, the application device is a cellular telephone, and the user interface is a graphical user interface that is integrated into the cellular telephone. In one particular case, the menu file is an XML format file. It should be noted that other file types may also be used. For example, a file type that is less complex than XML may be utilized in accordance with various embodiments of the present invention.

In other instances of the aforementioned embodiments, the methods further include receiving a play list that includes the first content object and the second content object, and is received from an application device communicably coupled to the memory system via a wireless network. Based at least in part on the play list, copying the first content object from the hard disk drive to the flash memory; and based at least in part on the play list, copying the second content object from the hard disk drive to the flash memory. In some cases, a more generic approach of a low power memory device and a high power memory device may be used where the low power memory device generically represents the hard disk drive, and the high power memory device generically represents the flash memory. In such cases, different low power and high power devices may be selected in accordance with various embodiments of the present invention. Further, the methods include executing the play list such that the first content object and the second content object are provided to a receiving application device.

Yet other embodiments of the present invention provide methods for reducing power that include providing a memory system with a hard disk drive and a flash memory. A first content object and a second content object are stored on the hard disk drive. The methods further include receiving a play list that identifies the first content object and the second content object. Based at least in part on the play list, the first and second content objects are copied from the hard disk drive to the flash memory.

This summary provides only a general outline of some embodiments according to the present invention. Many other objects, features, advantages and other embodiments of the present invention will become more fully apparent from the following detailed description, the appended claims and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the various embodiments of the present invention may be realized by reference to the figures which are described in remaining portions of the specification. In the figures, like reference numerals are used throughout several figures to refer to similar components. In some instances, a sub-label consisting of a lower case letter is associated with a reference numeral to denote one of multiple similar components. When reference is made to a reference numeral without specification to an existing sub-label, it is intended to refer to all such multiple similar components.

FIG. 1 depicts various UMCS devices and UMCS enabled application devices in accordance with some embodiments of the present invention;

FIG. 2 is a block diagram of an exemplary UMCS device interacting with an application device in accordance with various embodiments of the present invention;

FIG. 3 is a block diagram of an exemplary UMCS device with a non-volatile memory system including a flash memory and another non-flash memory component in accordance with various embodiments of the present invention;

FIGS. 4 a-4f are block diagrams of a power conserving memory allocation approach that may be applied to the non-volatile memory system of FIG. 3 in accordance with some embodiments of the present invention;

FIG. 5 is a flow diagram showing a method for power efficient memory management in accordance with one or more embodiments of the present invention; and

FIG. 6 is a flow diagram showing another method for power efficient memory management in accordance with various embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is generally related to power management in consumer devices, and in particular to systems and methods for managing power in a wireless device including a non-volatile data storage component.

Various embodiments of the present invention provide systems and methods for reducing power consumption in a device including a memory system. Such systems may include a memory system with a hard disk drive and a flash memory. The flash memory maintains a menu file that includes a list of content objects available on the hard disk drive. In addition, the system includes a processor that executes software maintained on the memory system to update the menu file when a previously unavailable content object becomes available on the hard disk drive. Further, in some cases, the processor executes software that is operable to update the menu file when a previously available content object becomes unavailable on the hard disk drive. Additionally, the systems may include instructions executable by the processor to receive a play list, and to copy a first content object identified on the play list from the hard disk drive to the flash memory, and to copy a second content object identified on the play list from the hard disk drive to the flash memory. With the content objects thus moved to the flash memory, they can be uploaded to either the application device that supplied the play list, or to another application device designated as the recipient of the content objects. As one of many advantages, such an approach may be used to reduce overall power usage by keeping the duty cycle of the higher power.

As an example, various embodiments of the present invention may be implemented in relation to a Universal Mobile Connected Storage (“UMCS”) device. The UMCS may include a memory system comprising a flash memory and another form of non-volatile memory such as a hard disk drive. The combination of flash memory with the other form of non-volatile memory is used to limit the power consumption of the UMCS. Where the other non-volatile memory is a hard disk drive that expends considerable power when it is initially spun up to perform a read or write operation, appreciable power savings may be achieved when the number of spin ups are reduced. To this end, some embodiments of the present invention carefully tailor the size and allocation of flash memory to match the expected access requirements of the UMCS. For example, when accesses to the hard disk drive are performed large amounts of properly selected data are moved from the hard disk drive to the flash memory. In contrast to other approaches where large contiguous blocks of data are pulled from a hard disk drive to a cache memory, the data pulled from the hard disk drive to the flash memory is not necessarily contiguous. Further, in some cases, the data copied from the hard disk drive to the flash memory is dictated by the particular memory type and/or a media assemblage of a number of content objects.

Turning to FIG. 1, a diagram depicts an exemplary content usage network 100 in accordance with various embodiments of the present invention. Exemplary content usage network 100 includes a UMCS 110 at the core thereof. UMCS 110 is able to receive content from one or more online and wireless content providers as well as from various self maintained application devices such as, for example, audio recorders and video recorders. In some cases, UMCS 110 may be intermittently wired to a personal computer 115 via a cable 1117. In such cases, UMCS 110 may be configured via personal computer 115 using the standard I/O interfaces associated with personal computer 115.

Wireless network 120 may be any wireless network known in the art. Thus, for example, wireless network 120 may be, but is not limited to, a Bluetooth™ network as is known in the art. It should be noted that while UMCS 110 may be configured across wireless network 120 using the user interface of another application device, and it may also be configured using other approaches. Thus, for example, UMCS 110 may be self configuring. In such a case, UMCS 110 is implemented with enough intelligence to auto detect an available wireless network as well as devices attached via the wireless network. As a particular example, UMCS 110 may be implemented such that when power is applied to the device it automatically scans for Bluetooth™ devices that are within range of UMCS 110. Based on the detected Bluetooth™ devices, UMCS 110 may form a service offering as is more fully discussed below.

UMCS 110 is capable of interacting with various devices and classes of devices via wireless network 120. For example, in some cases, UMCS 110 is operable to interact directly with UMCS enabled application devices via wireless network 120. Such UMCS enabled application devices include capability to authenticate to UMCS 110 and to accept and transfer information from/to UMCS 110, and to provide digital rights management whereby content is secured not only in the transfer between UMCS 110 and the UMCS enabled application device, but is also maintained secure within the UMCS enabled application device. In the situation where wireless network 120 is a Bluetooth™ network, the aforementioned UMCS enabled application devices would include Bluetooth™ capability.

In various cases, UMCS 110 is operable to interact directly with non-UMCS enabled application devices via wireless network 120. In such cases, either UMCS 110 includes capability to tailor output and receive input from the non-UMCS enabled application device, or the non-UMCS enabled application devices may interact with UMCS 110 via a specialized UMCS converter that is tailored for operation with a class of devices. Thus, for example, where wireless network 120 is a Bluetooth™ network, the UMCS converter may be enabled to receive from and provide information to a non-UMCS enabled application device via any one of a number of communication approaches, and to communicate the information to/from UMCS 110 using a Bluetooth™ protocol. As an example, UMCS 110 may interact with digital audio devices (e.g., a digital audio player 151 and a digital audio recorder 152) via a UMCS digital audio converter 150. As another example, a cellular telephone 161 or personal digital assistant (not shown) may interact with UMCS 110 either directly or via a UMCS audio/video converter 160. As yet another example, UMCS 110 may interact with video devices (e.g., a set top box 166, a video cassette player 167, a digital video recorder 168 and a television 169) via a UMCS digital video converter 165. As yet a further example, UMCS 110 may interact with still image devices such as a digital still camera 171 or a printer (not shown) via a UMCS digital image converter 170. As yet another example, UMCS 110 may interact with a GPS receiver/display 176 via a UMCS GPS converter 175.

In various cases, UMCS 110 is operable to interact directly with non-UMCS enabled application devices via a UMCS composite converter 140. UMCS composite converter 140 is operable to provide for UMCS interaction with multiple classes of recipient devices. Thus, for example, where wireless network 120 is a Bluetooth™ network, UMCS composite converter 140 may be enabled to receive from and provided information to different classes of non-UMCS enabled application devices via any one of a number of communication approaches, and to communicate the information to/from UMCS 110 using a Bluetooth™ protocol. As an example, UMCS composite converter 140 may couple UMCS 110 to, for example, a digital audio player 141, a digital video recorder 142, a television 143, a set top box 144, a digital still camera 145, a video cassette player 146, a digital audio recorder 147, a cellular telephone 148, and a GPS receiver 149, or some combination of the aforementioned device classes. In such cases, decoding of content accessed from a storage medium included in UMCS 110 is done using a decoder provided in UMCS composite converter 140. Thus, the content is unwrapped by UMCS 110 and the unwrapped content is provided to the UMCS composite converter 140 via wireless network 120. UMCS composite converter 140 decodes the content and provides it to the appropriate recipient device while at the same time assuring that any demanded digital rights management is maintained. In some cases, UMCS composite converter 140 may be implemented as a dongle associated with one or more recipient devices.

Further discussion of content usage networks including UMCS devices is provided in the patent application entitled “Systems and Methods for Mobile Data Storage and Acquisition” that was previously incorporated herein by reference for all purposes.

Turning to FIG. 2, a mobile data acquisition, storage and/or distribution system (“mobile storage system”) 201 in accordance with one or more embodiments of the present invention is depicted. Mobile storage system 201 includes a UMCS 211 communicably coupled to a mobile application device 241 via a wireless network 221. Wireless network 221 may be any wireless network capable of transferring information between UMCS 211 and mobile application device 241. Thus, for example, wireless network 221 may be, but is not limited to, a Bluetooth™ network or a Wi-Fi network that is, for example, 802.11 compliant. Based on the disclosure provided herein, one of ordinary skill in the art will recognize a variety of wireless networks that may be used in relation to one or more embodiments of the present invention. In some embodiments, communication between UMCS 211 and mobile application device 241 is accomplished directly between the two devices without utilizing an intervening wired hub.

UMCS 211 includes a memory system 207 that includes both application memory 219 and user data memory 217. As used herein, the phrase “application memory” is used in its broadest sense to mean memory allocated to include software or firmware applications. As known in the art, such software and firmware applications include instructions executable by a processor to perform one of a number of desired operations. As used herein, the phrase “user data memory” is used in its broadest sense to mean any memory allocated for data other than application data. Thus, for example, user data memory may store, for example, audio files, video files, documents and other types of user data. As is more fully discussed below in relation to FIGS. 3-4, memory system 207 may be implemented with one or both of volatile and non-volatile memory media. As used herein, the phrase “non-volatile memory” is used in its broadest sense to mean any memory that maintains its contents when power is removed from the memory. As used herein, the phrase “volatile memory” is used in its broadest sense to mean any memory that does not maintain its contents when power is removed from the memory.

UMCS 211 also includes a memory access system 215 that may be any circuitry and/or programmable controller that provides for access to and from memory system 207. UMCS 211 also includes a processor 203 that is capable of directing operation of UMCS 211. In one particular case, processor 203 is capable of accessing application memory 219 that includes instructions executable by processor 203 to receive a user data set via wireless distribution interface 213; store the user data set to memory system 207; receive a request initiated through a remote user interface to provide the user data set to a recipient device; and provide the user data set to the recipient device via the wireless interface. Based on the disclosure provided herein, one of ordinary skill in the art will recognize a myriad of instructions that maybe executable by processor 203 to cause any of a number of operations to be performed by UMCS 211.

UMCS 211 further includes a wireless interface that includes a wireless distribution interface 213 and an antenna 223. Wireless distribution interface 213 includes all of the circuitry required to format data for transmission via a wireless protocol recognized by wireless network 221. Thus, where wireless network 221 is a Bluetooth™ network, wireless distribution interface 213 may be any Bluetooth™ interface for transferring data between UMCS 211 and wireless network 221. As will be appreciated by one of ordinary skill in the art, where wireless network 221 uses another wireless protocol, wireless distribution interface 213 may be any interface capable of transferring data between UMCS 211 and wireless network 221 using the other interface protocol.

It should be noted that while mobile storage system 201 may include any number of application devices (mobile application device 241 is exemplary of such application devices) that are communicably coupled to UMCS 211 via wireless interface 221. In some cases, one or more of the aforementioned application devices may be mobile application devices, while others are wired application devices. As used herein, the phrase “mobile application device” is used in its broadest sense to mean any electronic device capable of performing one or more functions without being wired to any other device or power source. Thus, for example, a mobile application device may be, but is not limited to, a cellular telephone, a wireless headset, a personal digital assistant, a laptop computer, an MP3 player, and a mobile DVD player. Based on the disclosure provided herein, one of ordinary skill in the art will recognize a variety of mobile application devices that may be used in relation to one or more embodiments of the present inventions.

Mobile application device 241 includes a wireless interface that comprises a wireless network interface 243 and an antenna 225. Wireless network interface 243 may be any wireless interface known in the art that is capable of transferring data between mobile application device 241 and another device on wireless network 221. Mobile application device also includes a processor 245 that controls operation of the device. Mobile application device 241 includes a memory system comprising a cache 247, a random access memory 249 and a non-volatile random access memory 251. Further, mobile application device 241 includes a variety of input/output services including a graphical user interface controller 261, an audio controller 263 and a USER I/O controller 265. Graphical user interface controller 261 supports a graphical user interface 286 that may be integrated with mobile application device 241. Audio controller 263 supports an audio input device such as microphone 287 and an audio output device such as speaker 288. User I/O controller supports a keyboard 289 and in some cases a mouse interface device, a pen interface device, or a motion sensor device as are known in the art.

Further discussion of the interaction of a UMCS device with a remote user interface incorporated into an application device is provided in the patent application entitled “Systems and Methods for Mobile Data Storage and Acquisition” that was previously incorporated herein by reference for all purposes.

Turning to FIG. 3, a UMCS 300 in accordance with one or more embodiments of the present invention is depicted. UMCS 300 includes a hard disk drive 305 that is accessible to a processor 310 via a hard disk drive interface 315. Hard disk drive interface 315 may be any interface known in the art that allows for transferring data to and from hard disk drive 305. Further, hard disk drive 305 may be any hard disk drive known in the art. In one particular case, hard disk drive interface 315 is a standard ATA interface and hard disk drive 305 is an ATA hard disk drive. It should be noted that hard disk drive 305 is representative of a variety of storage media that may be used in relation to various embodiments of the present invention.

In addition, UMCS 300 includes multiple transmission paths 330 each coupled to processor 310 via a system bus 350. As depicted, UMCS 300 includes three distinct transmission paths each including a transmitter/receiver 332, 334, 336 electrically coupled to a respective antenna 341, 342, 343 and a local buffering memory 331, 333, 335. It should be noted that UMCS 300 may include more or fewer transmission paths depending upon the intended use and/or design of UMCS 300.

UMCS 300 also includes a memory system comprising a flash memory 358 and a system memory 354 electrically coupled to processor 310 via system bus 310. Some embodiments of the present invention utilize the combination of hard disk drive 305 and flash memory 358 to limit the power consumption of UMCS 300. As considerable power is expended spinning up hard disk drive 305, larger less frequent accesses to hard disk drive offers considerable power savings for UMCS 300. Based in part on this, some embodiments of the present invention carefully tailor the size and allocation of flash memory 358 such that the access to hard disk drive 305 is limited. When such accesses to hard disk drive 305 are performed, large amounts of properly selected data are moved from hard disk drive 305 to flash memory 358. In contrast to other approaches where large contiguous blocks of data are pulled from a hard disk drive to a cache memory, the data pulled from hard disk drive 305 to flash memory 358 is not necessarily contiguous. Further, in some cases, the data copied from hard disk drive 305 to flash memory 358 is dictated by the particular memory type and/or a media assemblage of a number of content objects. By segregating and operating portions of the memory system as discussed above, some embodiments of the present invention may yield some advantages in reduced shock sensitivity.

Further discussion of UMCS devices that may be utilized in relation to one or more embodiments of the present invention is provided in the patent application entitled “Systems and Methods for Mobile Data Storage and Acquisition” that was previously incorporated herein by reference for all purposes.

Turning to FIGS. 4a-4f, a power efficient memory allocation approach is graphically displayed in accordance with various embodiments of the present invention. Turning to FIG. 4a, a memory system 400 includes a hard disk drive 401 and a flash memory 403. In some cases, a file allocation table 405 describing the schema of hard disk drive 401 is included in flash memory 403. File allocation table 405 may be a standard file structure table used in relation to operating a memory system. Initially, the remaining portion of flash memory 403 may be unallocated memory 407. It should be noted that in some cases file allocation table 405 may be maintained in another memory area (not shown). Further, it should be noted that hard disk drive 401 may be any hard disk drive known in the art, or other non-volatile memory that offers a random memory access and may incur substantial power penalties for an initial memory access, followed by less substantial power consumption for subsequent memory reads/writes in the same memory access. Flash memory 403 may be either a flash memory as are known in the art, or another non-volatile memory that is capable of retaining its contents during a power down situation without relying on a maintenance power supply such as that typically used where a non-volatile memory system is implemented using a DRAM and a constant power supply.

In operation, content objects are received by the device in which memory system 400 is implemented. These content objects are files that are to be stored to hard disk drive 401. As used herein, the phrase “content object” is used in its broadest sense to mean any digital representation of media. Thus, for example, a content object may be a video file or an audio file. Based on the disclosure provided herein, one of ordinary skill in the art will recognize a variety of content objects and content object types that may be utilized in relation to one or more embodiments of the present invention. For example, a data file such as a *.doc file or an application file such as a *.exe file may be considered a content object. As the content objects are received and stored on hard disk drive 401, one or more menu files that are maintained on flash memory 403 are updated to reflect the presence of the new content object on hard disk drive 401. As used herein, the phrase “menu file” is used in its broadest sense to mean a context aware menu file that will know the value of the particular object and allow handling of the particular object. This updating process is shown in FIG. 4b where a content object (i.e., file 1 of type content class A 413) is stored to hard disk drive 401. In addition to storing file 1 to hard disk drive 401, a menu file 423 and a menu file 425 are updated to reflect the presence of file 1. Menu file 423 is designed to reflect all available content objects of all of content object class A 413 and a content object class B 415. Menu file 423 is allocated a portion 417 of flash memory 403. Menu file 425 is designed to reflect all available content objects of content object class A 413. Menu file 425 is allocated a portion 421 of flash memory 403. It should be noted that the aforementioned is merely exemplary, and that a variety of content classes may be used in accordance with different embodiments of the present invention.

Menu file 423 and menu file 425 are tailored for use by particular types of application devices that may access the device in which memory system is implemented. In particular, as more fully described in the patent application entitled “Systems and Methods for Mobile Data Storage and Acquisition” that was previously incorporated herein by reference for all purposes, an application device may request a menu of content objects that are available from memory system 400. In response, memory system 400 provides the menu file applicable to the requesting application device. A user interface associated with the requesting application device then utilizes the received menu file to present a list of available content objects to a user of the application device. The user may then select one or more of the listed content objects for transfer from the memory system to either the application device including the user interface, or to another application device. Different menu files may be developed and maintained that are particular to certain types of application devices. Thus, for example, one application device may include both video and audio output capabilities, while another application device may include only audio output capability. In such a case, content class A 413 may comprised audio content objects, while content class B 415 may be comprise video content objects. Where the requesting application device offers both video and audio capability, menu file 423 may be provided as it reflects both video and audio content objects. In contrast, where the requesting application device provides only audio capability, menu file 425 may be provided as it reflects content objects useful to the requesting device.

As can be seen in FIG. 4c, when another content object is received (file 7) it is both stored to hard disk drive 401 and updated to the appropriate menu file(s). In this case, file 7 is of a type that is included in content class B 415. As such, it is reflected in menu file 423 and a menu file 427. Menu file 427 is designed to reflect all available content objects of content object class B 415. Menu file 425 is allocated a portion 419 of flash memory 403. A shown in FIG. 4c, the process continues until a number of content objects (files 1-15) are stored to hard disk drive 401 and reflected in the appropriate menu files 423, 425, 427. In addition to updating menu files 423, 425, 427, file allocation table 405 is also updated to reflect the changes. It should be noted that as content objects are removed from memory system 400 not only is file allocation table 405 updated, but file menus 423, 425, 427 are also updated to reflect the changes.

In some embodiments of the present invention, memory system 400 represents hard disk drive 305 and flash memory 358 of UMCS 300. In such cases, the previously described updates of menu files 423, 425, 427 are controlled by processor 310 of UMCS 300. This control may be done by executing software instructions that are maintained on one or more of hard disk drive 305, flash memory 358 or system memory 354.

By maintaining a file based image (i.e., menu files 423, 425, 427) of the contents of hard disk drive 401, substantial power savings may be achieved as serving a list of available contents to a requesting application device merely requires a random access to the flash memory. In contrast, where the file image is not available, each request for content object availability from an application device would require a search of the hard disk drive requiring a spin up of the hard disk drive and the power dissipation associated therewith. Based on the disclosure provided herein, one of ordinary skill in the art will recognize a variety of approaches for maintaining and updating menu files 423, 4256, 427 in the flash memory that may be used in relation to various embodiments of the present invention. Further, based on the disclosure provided herein, one of ordinary skill in the art will recognize a variety of content object classes that may be used in relation to various embodiments of the present invention, as well as a variety of different menu files that may be defined depending upon the different content object classes and possible requesting application devices.

FIGS. 4 e-4f depict an additional power saving approach that may be employed in relation to various embodiments of the present invention. In particular, as shown in FIG. 4e, a particular play list B 461 may be defined using a requested menu file displayed via a user interface of the requesting device. In this case, play list B 461 includes a number of content objects (file 7, file 10, file 11 and file 14) of type content class B 415. Each content object in play list B 461 is copied into flash memory 403. Thus, when uploading content objects from play list B 461 to the requesting application device, the uploaded content objects are accessible from flash memory 403 and hard disk drive 401 does not need to be spun up. This results in considerable power savings. Further, when the device in which memory system 400 is implemented is powered down, play list B 461 is maintained due to the retention characteristics of flash memory 403. Thus, when the device in which memory system 400 is implemented is powered on again, play list B 461 is still available. Where play list B 461 is still desired, hard disk drive 401 does not need to be accessed. As previously discussed, by limiting access to hard disk drive 401 considerable power savings result.

Turning to FIG. 4f, a play list A 471 is shown loaded into flash memory 403. Play list A 471 may include a different set of content objects or a different class of content objects that other play lists. As depicted, it may be that a play list comprised of one type of content objects may have many fewer content objects than that of another type of content objects. The length of a play list is dependent upon the amount of unallocated flash available and the size of the content objects that are to be maintained in the play list. It should be pointed out that while the drawings show only a single play list in flash memory 403 at a time, that in accordance with some embodiments of the present invention more than one play list may be maintained in flash memory 403 at any given time depending upon the length of the play list, the size of unallocated memory 407 and the size of each of the content objects in the play list.

In many instances, the same play list(s) will be used over and over. Thus, by moving the content objects of the play list to flash memory 403, hard disk drive 401 does not need to be spun up in order to enjoy full operation of the device in which memory system 400 is implemented. This results in considerable power savings where the power required to operate hard disk drive 401 is more than that to access information from flash memory 403.

Turning to FIG. 5, a flow diagram 500 shows a method in accordance with some embodiments of the present invention for updating menu files maintained in a flash memory as content objects are stored to a hard disk drive. It should be noted that while flow diagram 500 only shows the process of adding a content object to the hard disk drive, a reverse process can be applied to removing a content object from the hard disk drive. Following flow diagram 500, a content object is received by a device in which memory system 400 is implemented (block 505). This may include, for example, receiving a request to obtain the content object and to access the content object from a source device as is described in the patent application entitled “Systems and Methods for Mobile Data Storage and Acquisition” that was previously incorporated herein by reference for all purposes. Based on the disclosure provided herein, one of ordinary skill in the art will recognize a variety of mechanisms and/or approaches that may be employed in relation to various embodiments of the present invention for requesting and/or receiving content objects to be stored in memory system 400.

Upon receiving the content object (block 505), it is stored to hard disk drive 401 (block 510). In addition, one or more menu files 423, 425, 427 reflecting the particular type of content object are updated to reflect the availability of the content object on hard disk drive 401. The updated menu files are then stored on flash memory 403. Menu files 423, 425, 427 may be created in a form that is useful to an application device without modification. Thus, for example, in one embodiment of the present invention, menu files 423, 425, 427 are maintained in XML format. In other embodiments of the present invention, menu files 423, 425, 427 are maintained in a format that must be translated by a receiving application device before the menu file may be used to drive a user interface. Based on the disclosure provided herein, one of ordinary skill in the art will recognize a variety of formats in which the menu files may be maintained.

At some point later a request is received from an application device asking for a listing of content objects available on hard disk drive 401 (block 520). In response to the request (block 520), the menu file appropriate for the requesting application device is accessed from flash memory 403 (block 525). The accessed menu file is then provided to the requesting application device (block 530). The requesting application device can then use the received menu file to drive a user interface that allows for selection of one or more content objects maintained on hard disk drive 401. The selected content object(s) are indicated to the device in which memory system 400 is implemented, and the selection information is provided to memory system 400 (block 535). It is determined if the selected content object is in flash memory 403 (block 540). Where the selected content object is in flash memory 403 (block 540), it is accessed from flash memory 403 (block 555) and provided to the requesting application device (block 560). Alternatively, where the selected content object is only available in hard disk drive 401 (block 540), the content object is accessed on hard disk drive 401 (block 545) and copied to flash memory 403 (block 550). The content object is then provided to the requesting application device (blocks 555, 560).

Turning to FIG. 6, a flow diagram 600 shows a method in accordance with some embodiments of the present invention for maintaining a play list in flash memory such that accesses to hard disk drive 401 is limited. Following flow diagram 600, a play list is received from an application device that is communicably coupled to the device in which memory system 400 is implemented (block 605). The play list may list any number of content objects and any type of content objects. Thus, for example, the play list may include both video content objects and audio content objects, or may be composed of solely video content objects or audio content objects. The makeup of the play list in many cases will reflect the type of content objects that are useful to the application device receiving the content objects.

One of the content objects from the received play list is selected (block 610), and it is determined if the selected content object is already in flash memory 403 (block 615). Where the selected content object is not already in flash memory 403 (block 615), the content object is retrieved from hard disk drive 401 and copied to flash memory 403 (block 620). It is then determined if there are more content objects in the received play list (block 630). Where there is another content object in the play list (block 630), the next content object from the play list is selected (block 635) and the processes of blocks 615 and 620 are repeated for the next content object.

Alternatively, where there are not any more content objects in the received play list (block 630), then all of the content objects in the play list exist in flash memory 403. The play list may then be supplied one content object at a time from memory system 400 to an identified application device (block 640). As stated above, in many instances the same play list(s) will be used over and over. Thus, by moving the content objects of the play list to flash memory 403, hard disk drive 401 does not need to be spun up in order to enjoy full operation of the device in which memory system 400 is implemented. This results in considerable power savings where the power required to operate hard disk drive 401 is more than that to access information from flash memory 403.

It is determined whether there is a request for either a new play list or a change to the play list is requested (block 645). Where such a change to the play list is requested (block 645), the processes of blocks 605-640 are repeated to assure that the modified play list is included in flash memory 403. Alternatively, where no change to the play list is requested (block 645), it is determined whether the device in which memory system 400 is implemented has been turned off (block 650). If the power off switch is selected (block 650), the power is turned off (block 655). This removes power from memory system 400. As flash memory 403 is used, the contents of the play list(s) are maintained during the power off situation. Where either the power off switch is not selected (block 650) or the power is turned back on (block 660), the play list continues to be provided one or more content objects at a time. By maintaining the play list even in a power down condition, substantial power savings may be achieved as hard disk drive 401 does not need to be spun up on power up to provide the play list.

In conclusion, the present invention provides novel systems, devices, methods and arrangements for power management in relation to device including a non-volatile storage component. While detailed descriptions of one or more embodiments of the invention have been given above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without varying from the spirit of the invention. Therefore, the above description should not be taken as limiting the scope of the invention, which is defined by the appended claims.

Claims

1. A system for reducing power consumption in a mobile data storage device, the system comprising: a memory system including: a hard disk drive;a flash memory, wherein the flash memory includes a menu file, andwherein the menu file includes a list of content objects available on the hard disk drive; and a processor, wherein the memory system includes instructions executable by the processor to update the menu file when a previously unavailable content object becomes available on the hard disk drive.

2. The system of claim 1, wherein the memory system further includes instructions executable by the processor to update the menu file when a previously available content object becomes unavailable on the hard disk drive.

3. The system of claim 1, wherein the memory system further includes instructions executable by the processor to: receive a play list; andcopy a first content object identified on the play list from the hard disk drive to the flash memory, and copy a second content object identified on the play list from the hard disk drive to the flash memory.

4. The system of claim 3, wherein the memory system further includes instructions executable by the processor to provide the first content object identified on the play list to a receiving application device.

5. The system of claim 3, wherein the play list is provided from an application device communicably coupled to the memory system via a wireless network.

6. The system of claim 5, wherein the wireless network is a Bluetooth network.

7. The system of claim 3, wherein the menu file is in a format usable to drive a user interface of a controlling application device.

8. The system of claim 7, wherein the controlling application device is a cellular telephone, and wherein the user interface is a graphical user interface.

9. The system of claim 7, wherein the menu file is an XML format file.

10. The system of claim 3, wherein the first content object and the second content object are maintained in the flash memory upon power down of the memory system.

11. A method for power reduction, the method comprising: providing a memory system, wherein the memory system includes a hard disk drive and a flash memory;storing a content object to the hard disk drive; andmaintaining a menu file in the flash memory, wherein the menu file identifies the content object, and wherein the menu file is in a format usable to drive a user interface of an application device communicably coupled to the memory system via a wireless network.

12. The method of claim 11, wherein the content object is a first content object, wherein the method further comprises: storing a second content object to the hard disk drive; andupdating the menu file to reflect the availability of the second content object on the hard disk drive.

13. The method of claim 11, wherein the application device is a cellular telephone, and wherein the user interface is a graphical user interface.

14. The method of claim 13, wherein the menu file is an XML format file.

15. The method of claim 11, wherein the method further comprises: receiving a play list, wherein the play list includes the first content object and the second content object, and wherein the play list is received from an application device communicably coupled to the memory system via a wireless network; andbased at least in part on the play list, copying the first content object from the hard disk drive to the flash memory; andbased at least in part on the play list, copying the second content object from the hard disk drive to the flash memory.

16. The method of claim 15, wherein the method further includes: executing the play list, wherein the first content object and the second content object are provided to a receiving application device.

17. A method for reducing power consumption in relation to memory access operations, the method comprising: providing a memory system, wherein the memory system includes a hard disk drive and a flash memory, and wherein a first content object and a second content object are stored on the hard disk drive;receiving a play list, wherein the play list includes the first content object and the second content object;based at least in part on the play list, copying the first content object from the hard disk drive to the flash memory; andbased at least in part on the play list, copying the second content object from the hard disk drive to the flash memory.

18. The method of claim 17, wherein the method further includes: executing the play list, wherein the first content object and the second content object are provided to a receiving application device.

19. The method of claim 17, wherein the flash memory maintains a menu file, wherein the menu file indicates the first content object and the second content object, and wherein the menu file is in a format usable to drive a user interface of an application device communicably coupled to the memory system via a wireless network.

20. The method of claim 19, wherein the method further comprises: storing a third content object to the hard disk drive; andupdating the menu file to reflect the availability of the third content object on the hard disk drive.

21. The method of claim 19, wherein the method further comprises: deleting the second content object from the hard disk drive; andupdating the menu file to reflect the unavailability of the first content object on the hard disk drive.

22. The method of claim 19, wherein the application device is a cellular telephone, and wherein the user interface is a graphical user interface integrated with the cellular telephone.

23. The method of claim 22, wherein the menu file is an XML format file.

24. The method of claim 17, wherein the play list is received from an application device, and wherein the application device is communicably coupled to the memory system via a wireless network.

25. The method of claim 21, wherein the application device is a cellular telephone.

26. The method of claim 13, wherein the menu file is an XML format file.