Media content caching

A playback device includes tangible storage configured to receive transfer of media content from a remote communications device to the playback device while the remote communications device is operating in a high power mode. Interface logic is coupled to the tangible storage and configured to signal the remote communications device during the transfer to prepare the remote communications device to enter a low power mode after the transfer is complete. The remote communications device includes a content manager configured to transfer of media content from the remote communications device to a playback device while the remote communications device is operating in a high power mode. Power logic is coupled to the content manager and configured to prepare the remote communications device to enter a low power mode after the transfer is complete, responsive to receipt of a signal from the playback device during the transfer is complete.

BACKGROUND

When a user plays a movie or other content on a mobile device, such as a tablet or a smart phone, he or she can wirelessly stream the movie from a storage device, such as a remote battery-powered storage device. However, having a storage device stream a movie or other content to a mobile device can unnecessarily use extra power.

SUMMARY

Implementations described and claimed herein manage power of a remote communications device in the context of loading streamable media content to a client device (e.g., a device executing a media player).

A playback device includes tangible storage configured to receive transfer of media content from a remote communications device (e.g., a personal WiFi device, a remote storage device providing gateway access to another network, etc.) to the playback device while the remote communications device is operating in a high power mode. Interface logic is coupled to the tangible storage and configured to signal the remote communications device during the transfer to prepare the remote communications device to enter a low power mode after the transfer is complete.

A remote communications device includes a content manager configured to transfer of media content from the remote communications device to a playback device while the remote communications device is operating in a high power mode. Power logic is coupled to the content manager and configured to prepare the communications storage device to enter a low power mode after the transfer is complete, responsive to receipt of a signal from the playback device during the transfer.

DETAILED DESCRIPTIONS

FIG. 1illustrates an example remote storage device100communicating with a client device102. In the illustrated implementation, the remote storage device100is a battery-powered external hard-drive with wireless communications capabilities with one or more other devices through a wireless channel104. It should be understood that neither battery-power nor wireless communications are required in certain applications of the described technology. The illustrated client device102is represented as a mobile phone, although other computing devices, including without limitation tablet computers, mobile computers, and desktop computers may be employed within the described technology.

The client device102can play a movie or audio content (examples of a streamable media content resource) through its display106or through other output interfaces, such as speakers or tactile outputs. See for example the sound signals represented by waves108. The movie has been transferred from the remote storage device100and wirelessly loaded onto the client device102. If the client device102streams the movie from the remote storage device100, the remote storage device100would typically be operating in a standard power mode (e.g., with the disc spinning or flash media active, data being read, data being received and transmitted, etc.) for most of the length of the movie. In an example of a two-hour movie, the remote storage device100is operated in a standard power mode for about two hours as the media content is concurrently loaded from and displayed on the client device102(e.g., with a small amount of buffering, where the buffering can be employed to reduce or eliminate jitter during playback on the client device102). Other examples of media content may include without limitation audio content, slide shows, documents, video games, and other streamable data content that may be presented (e.g., played) to a user while loading onto the user's device.

In an alternative mode, however, the client device102receives media content data from the remote storage device100at a faster rate than that employed in a typical buffered streaming mode. Rather than loading data at a relatively minimum rate sufficient for playback (potentially with a smaller amount of buffering), the client device102starts to concurrently load and playback the media content, but the client device102also loads the entire media content resource at a relatively faster rate into local storage of the client device102(e.g., to a hard drive, to solid state memory, to flash media, to RAM (random access memory), etc.). After the loading has completed, the remote storage device100can enter a low power mode to conserve energy. When a new movie is selected for playback, the client device102can restore communications with the remote storage device100, which can resume standard power mode and begins transfer of the new movie content to the client device102.

It should be understood that, in other implementations, while the transfer of an entire or substantially entire media content resource may trigger the entry into low power mode, other segments of the resource may be configured to trigger entry into low power mode. For example, the remote storage device100may quickly transfer a smaller portion of the resource, such an hour of a two hour movie (or some similar segment thereof, such as may be limited by available storage capacity on the client device102or user settings), enter a lower power mode of a period of time, and then resume its transfer in a standard power mode thereafter.

In one implementation, the client device102initiates the transfer of the media content with a Transfer API (application programming interface) call to the IP (internet protocol) address of the remote storage device100, which causes the remote storage device100to initiate the transfer of the media content resource. While receiving the media content, the client device102can begin playback of the media content resource (e.g., in a streaming playback mode). However, the Transfer API call also causes the remote storage device100to enter a new state in which the remote storage device100disables its gateway. In one implementation, the remote storage device100disables its gateway by deleting addresses in the DHCP gateway address setting and the DNS (domain name server) address setting. A gateway refers to a router in a TCP/IP (transmission control protocol/internet protocol) network that serves as an access point to another network. When the client device102attempts to renew its DHCP lease with the remote storage device100, the gateway is disabled and so the client device102terminates attempts to re-connect with the remote storage device100for other purposes. Accordingly, the remote storage device100maintains its communication connection with the client device102via the remote storage device's IP address to continue transferring the media content resource but terminates the client device's ability to access the client device102as an access point (e.g., terminating gateway accesses to the remote storage device100by the client device102). Accordingly, after the media content resource is transferred to the client device102(and assuming no other client devices are accessing the remote storage device100), the remote storage device100detects a period of communication inactivity and enters a low power mode. Meanwhile, the client device102can continue playback of the media content from its local storage without interaction with the remote storage device100.

After playback of the media content resources is terminated at the client device102, the client device102“wakes up” the remote storage device100by issuing a Wake API call to the IP address of the remote storage device100, which directs the remote storage device100to restore its gateway. “Waking up” the remote storage device100involves transitioning the remote storage device100into a higher power mode and/or an enabling of additional or different functionality in the remote storage device100. In one implementation, restoration of the gateway in the remote storage device100involves restoring valid addresses to the DHCP gateway address setting and the DNS address setting. In this state, the remote storage device100can establish access point connections with the client device102and other devices.

After a successful restoration of the gateway in the remote storage device100, the client device102can issue a Restore API call to reset the communications connection with the remote storage device100. In one implementation, resetting the communications connection involves the client device102renewing its DHCP lease with the gateway in the remote storage device100.

FIG. 2illustrates an example client device200for communicating with a remote storage device202. The client device200is communicatively coupled to the remote storage device202via a communication channel204, which is typically a wireless communication channel (including WiFi, Bluetooth, IR (infrared), etc.) but which may be wired in some implementations.

The client device200includes communications interface logic206. In one implementation, the communications interface logic206includes a proxy server that interfaces between media player logic208in the client device200and gateway logic in the remote storage device202. In other implementations the communications interface logic206does not include the proxy server but still provides a communications interface between the media player logic208and the gateway logic in the remote storage device202. The presence of the proxy server in the client device200isolates the media player logic208from the specific implementation of the gateway interaction between the client device200and the remote storage device202. In this manner, various existing media player applications may be employed with the described technology without modification.

As described with regard toFIG. 1, the client device200can initiate the loading of media content from the remote storage device202by issuing an API call to the remote storage device202. In response to the API call, the remote storage device202initiates transfer of the requested media content and enters a state in which the remote storage device202may enter a low power mode upon completion of the transfer. In one implementation, the remote storage device202deletes its DHCP gateway address setting and its DNS server address setting and increases the lease time to prevent frequent DHCP negotiations that wake up the remote storage device202from its low power mode, which it will enter after completion of the media content transfer.

Concurrently, when the client device200receives a sufficient segment of the content media resource from the remote storage device202to storage210(e.g., flash memory, a solid state drive, etc.) to provide enough buffering for uncorrupted playback, the media player logic208plays the media content via an output interface212, such as a video display, a speaker, etc. DHCP settings may be stored in the storage210or in separate storage.

At some future point, the client device200will attempt to renew its DHCP lease with the remote storage device202. Because the DHCP gateway address and DNS server address settings are null on the remote storage device202, the corresponding address settings are deleted at the client device200. Accordingly, the operating system of the client device200will stop trying to connect to the Internet through the gateway of remote storage device202. In absence of communications with the client device200, the remote storage device202can enter a low power mode. Therefore, if no other devices are connected to the remote storage device202, the remote storage device202will enter a low power mode when it has completed its transfer of the media content resource (or predetermined segment thereof) to the client device200.

Gateway logic in the remote storage device provides gateway functionality to devices communicating through the remote storage device202, allowing such devices to access a network through the gateway logic. DHCP settings for the gateway logic are stored in settings storage in the remote storage device202. Example DHCP settings include without limitation the DHCP gateway address, the DNS server address, and a lease time.

A power logic and supply module provides power from a battery or other power supply (e.g., an electrical connection) and manages the power consumption of the remote storage device202. In one implementation, the power logic and supply module manages multiple power modes, examples of which are shown below:Streaming mode: content is retrieved from the storage device as it is played on a client device (100% power consumption)Idle mode: certain electronics are turned off or put in low power mode; system controller set to a lower clock frequency (80% power consumption)Standby mode: low power idle mode plus the hard drive is transitioned to a spin down state (50% power consumption)Suspend mode: system image is stored on RAM or Flash memory and then the entire remote storage system is put in lowest power mode; system is only responsive to a new request from a client device—communications interface is still active (10% power consumption)

It should be understood that a “low power mode” is an operational mode of a device that consumes relatively less power than a “high power mode.”

The remote storage device202also includes a content manager that manages content stored on the remote storage device202. The content manager, among other functions, (1) manages receipt of content one or more storage interfaces; (2) stores such content in and accesses such content from content storage; and (3) transfers such content from the content storage to other devices. Storage modules may be combined into an integrated module and may include combinations of memory, SSD (solid state drive), magnetic storage discs, and other storage components. The content manager processes the API calls from one or more client devices to manage content transfers, communications, and power management.

FIG. 3illustrates another example client device300for communicating with a remote storage device302. The client device300is communicatively coupled to the remote storage device302via a communication channel304, which is typically a wireless communication channel (including WiFi, Bluetooth, IR, etc.) but which may be wired in some implementations.

The client device300includes communications interface logic306. In the illustrated implementation, the communications interface logic306is coupled to a proxy server314that interfaces between communications interface logic316of media player logic308in the client device300and gateway logic in the remote storage device302. The media player logic308connects through its communications interface logic316to the proxy server314, requesting a service, such as the transfer of media content from the remote storage device302, and the proxy server314evaluates the request as a way to simplify and control their complexity. The presence of the proxy server in the client device300isolates the media player logic308from the specific implementation of the gateway interaction between the client device300and the remote storage device302. In this manner, various existing media player applications may be employed with the described technology without modification.

As described with regard toFIG. 1, the client device300can initiate the loading of media content from the remote storage device302by issuing an API call to the remote storage device302. In response to the API call, the remote storage device302initiates transfer of the requested media content and enters a state in which the remote storage device302may enter a low power mode upon completion of the transfer. In one implementation, the remote storage device302deletes its DHCP gateway address setting and its DNS server address setting and increases the lease time to prevent frequent DHCP negotiations that wake up the remote storage device302from its low power mode, which it will enter after completion of the media content transfer.

Concurrently, when the client device300receives a sufficient segment of the content media resource from the remote storage device302to storage310(e.g., flash memory, a solid state drive, etc.) to provide enough buffering for uncorrupted playback, the media player logic308plays the media content via an output interface312, such as a video display, a speaker, etc. DHCP settings may be stored in the storage310or in separate storage.

At some future point, the client device300will attempt to renew its DHCP lease with the remote storage device302. Because the DHCP gateway address and DNS server address settings are null on the remote storage device302, the corresponding address settings are deleted at the client device300. Accordingly, the operating system of the client device300will stop trying to connect to the Internet through the gateway of remote storage device302. In absence of communications with the client device300, the remote storage device302can enter a low power mode. Therefore, if no other devices are connected to the remote storage device302, the remote storage device302will enter a low power mode when it has completed its transfer of the media content resource (or predetermined segment thereof) to the client device300.

FIG. 4illustrates example operations400for managing loading of media content. A receiving operation402receives a request to play media content, such as from a user selecting content for playback via a touch screen interface on the client device. Other selection and receiving implementations may be employed. Responsive to the receiving operation402, an initiation operation404initiates retrieval of the selected media content from the remote storage device. Such retrieval may include communications through a client-resident proxy server or through other interface mechanisms.

After the transfer from the remote storage device has been initiated, a decision operation406determines whether sufficient content has been received for smooth playback on the client device. Typically, a media player requests a buffer of a few seconds to ensure jitter-free playback to the user. If sufficient content has been received, a playback operation408initiates playback of the content on the client device while continuing to receive additional media content from the remote storage device, which is referred to as “streaming” The rate at which the media content is played on the client device is referred to herein as “playback speed.” The transfer of the media content from the remote storage device exceeds the playback speed.

A signaling operation410sends an API call to the remote storage device to prepare to enter a low power mode (e.g., “suspend” mode). In one implementation, such preparation involved disabling the gateway of the remote storage device, although in other implementations, other mechanisms may be employed or combined with the gateway disabling operation, including without limitation, setting a timer for entering low power mode to trigger low power mode, setting a transfer monitor to trigger low power mode, etc. Media content transfer continues in a retrieval operation411.

A decision operation412monitors the media content transfer and determines whether the transfer of the media content resource (or a specified segment thereof) is complete. If not, another decision operation414determines whether the client device has sufficient available storage capacity for additional media content. If so, media content transfer continues via the retrieval operation411. Otherwise, a clearing operation416makes additional storage capacity available on the client device by partially clearing storage space (e.g., by deleting already-played portions of the media content, by clearing other unneeded data, etc.), before returning to the retrieval operation411.

If the decision operation412determines that the transfer is complete, then the remote storage device goes into a low power mode (e.g., suspend mode). At some point in time thereafter, another signaling operation418sends a Wake API call from the client device to the remote storage device to bring the remote storage device into a higher power mode (e.g., in order to retrieve another media content resource, in order to access another network through the gateway, etc.). In one implementation, the Wake API call causes the remote storage device to restore its gateway settings, although other mechanisms may be employed including setting timers, setting conditions, etc. After the gateway is restored in the remote storage device, an access operation420sends a Restore API call from the client device to the remote storage device to re-negotiate the DHCP lease so that the client can access the gateway in the remote storage device.

During standard operation, the remote storage device is in one or more high power modes that support standard operations, such as data storage and retrieval, communications with one or more client devices, communications with other networks, etc. As such, the remote storage device can communicate with a client device, such as to load media content to the client device for playback.

When a user selects a media selection for playback on the client device, a Transfer API call is sent from the client device to the remote storage device. The call initiates the transfer of the selected media content resource from the remote storage device to the client device for playback and also causes the remote storage device to disable its gateway. In one implementation, disabling the gateway involves the clearing of the DHCP gateway address and the DNS server address and the increasing of the lease time (e.g., from a typical 5 minutes to 6 hours). For example, the DHCP configuration of a disabled gateway may be set as follows:

When the media content resource (or a predetermined segment thereof) is completely transferred to the client device, and if no other devices are in communicative connection with the remote storage device, the remote storage device enters a low power mode (e.g., lower power consumption than in standard operation). In one implementation, the entire media content resource is transferred before entering low power mode. In another implementation, the issuance of a Transfer API call may be conditioned on an available capacity check at the client device (to ensure there is enough storage space available for the requested media content resource). In yet another implementation, the issuance of the Transfer API call may cause a negotiation between the client device and the remote storage device about the size of segments of the media content resource loaded in each loading phase. For example, the media content may be incrementally loaded to the client device in segments between which the remote storage device may enter a low power state until the next segment is requested.

After the transfer of the media content is completed, the client device can wake up the remote storage device by issuing a Wake API call to the IP address of the remote storage device. This API call may be made in background processing on the client device. Responsive to this API call, the remote storage device transitions to a higher power mode and restores its gateway settings. An example of such settings are shown below:

Although the Wake API call restores the gateway at the remote storage device, the DHCP settings in the client device are not yet restore. Therefore, the client device does not have gateway access to the remote storage device. Accordingly, the client device can issue a Restore API call to the IP address of the remote storage device. This API call may also be made in background processing on the client device. Responsive to this API call, the remote storage device and the client device reset the communications connection (e.g., renewing the DHCP lease for the client device), which sets the client device's DHCP gateway address and DNS server address to match those of the remote storage device. Accordingly, the remote storage device returns to the standard operation with regard to the client device. Discussions ofFIGS. 5, 6, and 7provide more details regarding example implementations of the API calls.

FIG. 5illustrates example operations500between a client device and a remote storage device for managing loading of media content. A retrieval operation502at the client device receives a selection of a specified media content resource residing on or accessible by the remote storage device and issues a Transfer API call to the remote storage device to instruct the remote storage device to transfer the selected resource and configure itself to enter a low power mode after the transfer is complete. The remote storage device receives the API call and resource selection in a receiving operation504and begins transferring the selected media content resource in a transferring operation506. The transferring operation506continues until the transfer of the selected media content resource (or a specified segment thereof) is complete, as illustrated by dashed arrow507. The remote storage device also disables its gateway in a disabling operation508(e.g., setting the DHCP gateway address and DNS server address to NULL and increasing the lease time).

The client device receives the media content from the remote storage device in a receiving operation510and begins playing the media content in a playback operation512. At some point during playback, the client device attempts to renew its DHCP lease (e.g., 5 minutes after its last renewal attempt). Based on the disabled gateway at the remote storage device, the renewal attempt by the client device results in its DHCP settings being modified to reflect the disabled state of the gateway (e.g., setting the DHCP gateway address and DNS server address to NULL and increasing the lease time). Because the lease time is increased to such a long time (e.g., 6 hours), the client device will not frequently wake up the remote storage device after in enters low power mode in an attempt to renew the lease.

The client device and remote storage device complete the media content transfer in transfer operations516and518, respectively. Thereafter, the client device continues to playback the media content from its internal storage in a playback operation520, and the remote storage device enters a low power mode in a suspend operation522.

FIG. 6illustrates example operations600between a client device and a remote storage device for restoring network access at the remote storage device. The client device issues a Wake API call to wake up the remote storage device in an API call operation602. The remote storage device receives the Wake API call in a receiving operation604, transitioning from a low power mode to a higher power mode, and restores its DHCP gateway settings in a restoring operation606.

FIG. 7illustrates example operations700between a client device and a remote storage device for restoring network access at the client device. The client device attempts to re-initiate activity with the remote storage device by issuing a Restore API call to the remote storage device in a signaling operation704. The remote storage device receives the API call in the receiving operation706, and the two devices renegotiate the DHCP settings in negotiation operations708and710. Based on this renewal of the DHCP lease, the client device restores its gateway access to the remote storage device in a restoring operation712.

FIG. 8illustrates an example computing system800that may be useful in implementing the presently disclosed technology. The computing system800is capable of executing a computer program product embodied in a tangible computer-readable storage medium to execute a computer process. Data and program files may be input to the computing system800, which reads the files and executes the programs therein using one or more processors. Some of the elements of a computing system800are shown inFIG. 8wherein a processor802is shown having an input/output (I/O) section804, a Central Processing Unit (CPU)806, and a memory section808. There may be one or more processors802, such that the processor802of the computing system800comprises a single central-processing unit806, or a plurality of processing units, commonly referred to as a parallel processing environment. The processors may be single core or multi-core processors. The computing system800may be a conventional computer, a distributed computer, or any other type of computer. The described technology is optionally implemented in software devices loaded in memory808, a disc storage unit812, and/or communicated via a wired or wireless network link814on a carrier signal (e.g., Ethernet, 3G wireless, 4G wireless, LTE (Long Term Evolution)) thereby transforming the computing system800inFIG. 8to a special purpose machine for implementing the described operations.

The I/O section804may be connected to one or more user-interface devices (e.g., a keyboard, a touch-screen display unit818, etc.) or a disc storage unit812. Computer program products containing mechanisms to effectuate the systems and methods in accordance with the described technology may reside in the memory section804or on the storage unit812of such a system800.

A communication interface824is capable of connecting the computer system800to a network via the network link814, through which the computer system can receive instructions and data embodied in a carrier wave. When used in a local area networking (LAN) environment, the computing system800is connected (by wired connection or wirelessly) to a local network through the communication interface824, which is one type of communications device. When used in a wide-area-networking (WAN) environment, the computing system800typically includes a modem, a network adapter, or any other type of communications device for establishing communications over the wide area network. In a networked environment, program modules depicted relative to the computing system800or portions thereof, may be stored in a remote memory storage device. It is appreciated that the network connections shown are examples of communications devices for and other means of establishing a communications link between the computers may be used.

In an example implementation, interface logic, media player logic, proxy server logic, gateway functionality, media content transfer modules, power management modules, API calling modules, and other modules and services may be embodied by instructions stored in memory808and/or the storage unit812and executed by the processor802. Further, local computing systems, remote data sources and/or services, and other associated logic represent firmware, hardware, and/or software configured to manage gateway access, communications, and power management. Such services may be implemented using a general purpose computer and specialized software (such as a server executing service software), a special purpose computing system and specialized software (such as a mobile device or network appliance executing service software), or other computing configurations. In addition, program data, such as media content, DHCP settings, data read from and written to a storage device or a playback device, and other data may be stored in the memory808and/or the storage unit812and executed by the processor802.

FIG. 9illustrates example operations900for managing loading of media content. An initiation operation902initiates retrieval of the selected media content from the remote storage device. Such retrieval may include communications through a client-resident proxy server or through other interface mechanisms.

A signaling operation904sends an API call to the remote storage device to prepare to enter a low power mode (e.g., “suspend” mode). In one implementation, such preparation involved disabling the gateway of the remote storage device, although in other implementations, other mechanisms may be employed or combined with the gateway disabling operation, including without limitation, setting a timer for entering low power mode to trigger low power mode, setting a transfer monitor to trigger low power mode, etc.

FIG. 10illustrates an example playback device1000for communicating with a remote communications device1002. The playback device1000is communicatively coupled to the remote communications device1002via a communication channel1004, which is typically a wireless communication channel (including WiFi, Bluetooth, IR, etc.) but which may be wired in some implementations.

The playback device1000includes communications interface logic1006. In one implementation, the communications interface logic1006includes a proxy server that interfaces between media player logic in the playback device1000and gateway logic in the remote communications device1002. In other implementations, the communications interface logic1006does not include the proxy server but still provides a communications interface between the media player logic and the gateway logic in the remote communications device1002. The presence of the proxy server in the playback device1000isolates the media player logic from the specific implementation of the gateway interaction between the playback device1000and the remote communications device1002. In this manner, various existing media player applications may be employed with the described technology without modification.

As described with regard toFIG. 1, the playback device1000can initiate the loading of media content from the remote communications device1002by issuing an API call to the remote communications device1002. In response to the API call, the remote communications device1002initiates transfer of the requested media content and enters a state in which the remote communications device1002may enter a low power mode upon completion of the transfer. In one implementation, the remote communications device1002deletes its DHCP gateway address setting and its DNS server address setting and increases the lease time to prevent frequent DHCP negotiations that wake up the remote communications device1002from its low power mode, which it will enter after completion of the media content transfer.

Concurrently, when the playback device1000receives a sufficient segment of the content media resource from the remote communications device1002to tangible storage1008(e.g., flash memory, a solid state drive, etc.) to provide enough buffering for uncorrupted playback, the media player logic plays the media content via an output interface, such as a video display, a speaker, etc. DHCP settings may be stored in the tangible storage1008or in separate storage.

At some future point, the playback device1000will attempt to renew its DHCP lease with the remote communications device1002. Because the DHCP gateway address and DNS server address settings are null on the remote communications device1002, the corresponding address settings are deleted at the playback device1000. Accordingly, the operating system of the playback device1000will stop trying to connect to the Internet through the gateway of remote communications device1002. In absence of communications with the playback device1000, the remote communications device1002can enter a low power mode. Therefore, if no other devices are connected to the remote communications device1002, the remote communications device1002will enter a low power mode when it has completed its transfer of the media content resource (or predetermined segment thereof) to the playback device1000.

Gateway logic in the remote communications device1002provides gateway functionality to devices communicating through the remote communications device1002, allowing such devices to access a network through the gateway logic. DHCP settings for the gateway logic are stored in settings storage in the remote communications device1002. Example DHCP settings include without limitation the DHCP gateway address, the DNS server address, and a lease time. A power logic and supply module provides power from a battery or other power supply (e.g., an electrical connection) and manages the power consumption of the remote communications device1002.

FIG. 11illustrates an example remote communications device1100for communicating with a client device1102. The remote storage device1100is communicatively coupled to the client device1102via a wireless or wired communications link1104and optionally to another network via a wireless or wired communications link1106. Gateway logic in the remote communications device1100provides gateway functionality to devices communicating through the remote communications device1100, allowing such devices to access the network through the gateway. DHCP settings for the gateway logic are stored in DHCP settings storage. Example DHCP settings include without limitation the DHCP gateway address, the DNS server address, and a lease time.

A power logic and supply module1110provides power from a battery or other power supply (e.g., an electrical connection) and manages the power consumption of the remote communications device1100. In one implementation, the power logic and supply module1110manages multiple power modes, examples of which are shown below:Streaming mode: content is retrieved from the storage device as it is played on a client device (100% power consumption)Idle mode: certain electronics are turned off or put in low power mode; system controller set to a lower clock frequency (80% power consumption)Standby mode: low power idle mode plus the hard drive is transitioned to a spin down state (50% power consumption)Suspend mode: system image is stored on RAM or Flash memory and then the entire remote storage system is put in lowest power mode; system is only responsive to a new request from a client device—communications interface is still active (10% power consumption)

It should be understood that a “low power mode” is an operational mode of a device that consumes relatively less power than a “high power mode.”

The remote communications device1100also includes a content manager1108that manages content stored on the remote communications device1100. The content manager1108, among other functions, (1) manages receipt of content; (2) stores such content in and accesses such content from content storage; and (3) transfers such content from the content storage to other devices. Storage modules may be combined into an integrated module and may include combinations of memory, SSD, magnetic storage discs, and other storage components. The content manager1108processes the API calls from one or more client devices to manage content transfers, communications, and power management.

The implementations of the invention described herein are implemented as logical steps in one or more computer systems. The logical operations of the present invention are implemented (1) as a sequence of processor-implemented steps executing in one or more computer systems and (2) as interconnected machine or circuit modules within one or more computer systems. The implementation is a matter of choice, dependent on the performance requirements of the computer system implementing the invention. Accordingly, the logical operations making up the implementations of the invention described herein are referred to variously as operations, steps, objects, or modules. Furthermore, it should be understood that logical operations may be performed in any order, unless explicitly claimed otherwise or a specific order is inherently necessitated by the claim language. Furthermore, one of more portions of the various processes disclosed above with respect toFIG. 8may be implemented by software, hardware, firmware or combination thereof.

It should be understood that described and recited operations may be performed in any order, unless explicitly claimed otherwise or a specific order is inherently necessitated by the claim language. The data storage and/or memory may be embodied by various types of storage, such as hard disc media, optical media, solid-state drive technology, ROM (read only memory), RAM, and other technology. The operations may be implemented in firmware, software, hard-wired circuitry, gate array technology and other technologies, whether executed or assisted by a microprocessor, a microprocessor core, a microcontroller, special purpose circuitry, or other processing technologies.

The above specification, examples, and data provide a complete description of the structure and use of exemplary embodiments of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended. Furthermore, structural features of the different embodiments may be combined in yet another embodiment without departing from the recited claims.