Patent Description:
Access to electronic media, such as music and video content, has expanded dramatically over time. As a departure from physical media, media content providers stream media to electronic devices across wireless networks, improving the convenience with which users can digest and experience such content.

In a typical media content casting scenario, a user of a media-providing service may select content on a first device (e.g., a smartphone) to be presented on another device (e.g., a smart speaker or smart television). Some modem presentation devices, however, include a low power mode. When a presentation device goes into a low power mode, the media providing service often loses the ability to communicate directly with the presentation device (otherwise communication between the media providing service and the presentation device would prevent the media presentation device from entering low power mode for prolonged periods of time). This is especially true when the presentation device is a third-party device with respect to the media providing service. Although the user may wake the presentation device by interacting with the presentation device (e.g., by uttering a command such as "Hey Device, play my daily playlist"), a problem arises when the user tries to use the first device (e.g., their smartphone) to issue playback commands to the presentation device. In this case, the first device typically communicates with the media providing service, which is unable to communicate with the presentation device while in the low power mode. Thus, there is a need for improved methods of communicating with devices in a low power mode.

<CIT> discloses a method for playing media content on a target device in which a first device receives a voice command from a first user of a second device. The first device determines, from content in the voice command, one or more characteristics of a target device and media content to be played on the target device. The first device identifies, using the characteristics of the target device, a third device. In response to identifying the third device: the first device modifies account information for the third device to associate the third device with the first user and transmits instructions to the third device to play the media content.

<CIT> discloses maintaining knowledge of a network address (e.g., a MAC address) for a playback device while changing power states.

The problem described above is solved by transmitting a request to a third-party server (e.g., one associated with the presentation device) to wake up the presentation device. In other words, in some embodiments, the media providing service transmits a request to the third-party to wake up their own presentation device. Thus, in some embodiments, only one entity (the third-party) can remotely wake the presentation device, which allows the presentation device to remain in a low power mode for longer periods of time. Once the presentation device exits the low power mode (in response to an instruction from the third-party), it sends a message back to the media providing service indicating that communication has been reestablished. At this point, the media providing service is again able to communicate with the third-party device (e.g., via an embedded software development kit), without requiring that the user directly interact with the presentation device.

In accordance with some embodiments, a method is performed at a first server system configured to communicate with a first client device through a first application executing on the first client device. The method includes determining that communication with the first client device through the first application has been lost due to the first client device entering an idle mode. The method further includes after determining that the communication with the first client device through the first application has been lost, receiving a request from a second client device, distinct from the first client device, that triggers reestablishing communication with the first client device through the first application. The method further includes, in response to the request from the second client device that triggers reestablishing communication with the first client device through the first application, transmitting a request to a second server system to wake the first client device from the idle mode. The method further includes receiving, from the first application on the first client device, an indication that communication has been reestablished between the first server system and the first application. The method further includes after receiving, from the first application on the first client device, the indication that communication has been reestablished between the first server system and the first application, transmitting, to the first application on the first client device, a control command to control the first client device.

In accordance with some embodiments, a first server system configured to communicate with a first client device through a first application executing on the first client device includes one or more processors and memory. The memory stores one or more programs. The one or more programs include instructions for determining that communication with the first client device through the first application has been lost due to the first client device entering an idle mode. The one or more programs further include instructions for, after determining that the communication with the first client device through the first application has been lost, receiving a request from a second client device, distinct from the first client device, that triggers reestablishing communication with the first client device through the first application. The one or more programs further include instructions for, in response to the request from the second client device that triggers reestablishing communication with the first client device through the first application, transmitting a request to a second server system to wake the first client device from the idle mode. The one or more programs further include instructions for receiving, from the first application on the first client device, an indication that communication has been reestablished between the first server system and the first application. The one or more programs further include instructions for, after receiving, from the first application on the first client device, the indication that communication has been reestablished between the first server system and the first application, transmitting, to the first application on the first client device, a control command to control the first client device.

In accordance with some embodiments, a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) includes one or more programs for execution by a first server system configured to communicate with a first client device through a first application executing on the first client device. The one or more programs include instructions for determining that communication with the first client device through the first application has been lost due to the first client device entering an idle mode. The one or more programs further include instructions for, after determining that the communication with the first client device through the first application has been lost, receiving a request from a second client device, distinct from the first client device, that triggers reestablishing communication with the first client device through the first application. The one or more programs further include instructions for, in response to the request from the second client device that triggers reestablishing communication with the first client device through the first application, transmitting a request to a second server system to wake the first client device from the idle mode. The one or more programs further include instructions for receiving, from the first application on the first client device, an indication that communication has been reestablished between the first server system and the first application. The one or more programs further include instructions for, after receiving, from the first application on the first client device, the indication that communication has been reestablished between the first server system and the first application, transmitting, to the first application on the first client device, a control command to control the first client device.

Thus, systems are provided with improved methods for communicating with a device in a low power mode (e.g., waking the device up from the low power mode). These systems and methods save power by allowing such devices to remain in the low power mode for longer periods of time, while reducing friction in allowing users to select such devices to perform operations (such as media presentation), as described in detail below.

The embodiments disclosed herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings. Like reference numerals refer to corresponding parts throughout the drawings and specification.

Reference will now be made to embodiments, examples of which are illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide an understanding of the various described embodiments.

It will also be understood that, although the terms first, second, etc. are, in some instances, used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first electronic device could be termed a second electronic device, and, similarly, a second electronic device could be termed a first electronic device, without departing from the scope of the various described embodiments. The first electronic device and the second electronic device are both electronic devices, but they are not the same electronic device.

The terminology used in the description of the various embodiments described herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used in the description of the various described embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any possible combination of one or more of the associated listed items. It will be further understood that the terms "includes," "including," "comprises," and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As used herein, an idle mode is a mode entered by a device in response to a period of inactivity (e.g., a period during which services (such as presenting media) are not provided to the user and during which user inputs are not received). In an idle mode, certain services of the device are reduced or unavailable when the device is in the idle mode. For example, in the idle mode, the device may not be able to respond to requests from an application (e.g., SDK or API) running on the device. In some circumstances, the idle mode saves power as compared to normal operation (e.g., the baseline power consumption, when the device is not servicing any user request is lower in the low-power mode than when not in the low-power mode). Thus, an example of an idle mode is a low-power mode (e.g., a mode in which the device consumes a lower baseline amount of power). Note that the disclosed embodiments may also provide benefits other than saving power, for example, in restoring communication after a network outage. Thus, it is not necessary that the idle modes described herein save power.

As used herein, to wake a device from an idle mode (e.g., a low-power mode) means to exit the idle mode (e.g., by restoring or making available the services that were reduced in the idle mode). For example, in some embodiments, waking the device from the idle mode allows the device to respond to requests from an application (e.g., SDK or API) running on the device that the device could not respond to when the device was in the idle mode.

<FIG> is a block diagram illustrating a media content delivery system <NUM>, in accordance with some embodiments. The media content delivery system <NUM> includes one or more electronic devices <NUM> (e.g., electronic device <NUM>-<NUM> to electronic device <NUM>-m, where m is an integer greater than one), one or more media content servers <NUM>, and/or one or more content distribution networks (CDNs) <NUM>. The one or more media content servers <NUM> are associated with (e.g., at least partially compose) a media-providing service. The one or more CDNs <NUM> store and/or provide one or more content items (e.g., to electronic devices <NUM>). In some embodiments, the CDNs <NUM> are included in the media content servers <NUM>. One or more networks <NUM> communicably couple the components of the media content delivery system <NUM>. In some embodiments, the one or more networks <NUM> include public communication networks, private communication networks, or a combination of both public and private communication networks. For example, the one or more networks <NUM> can be any network (or combination of networks) such as the Internet, other wide area networks (WAN), local area networks (LAN), virtual private networks (VPN), metropolitan area networks (MAN), peer-to-peer networks, and/or ad-hoc connections.

In some embodiments, an electronic device <NUM> is associated with one or more users. In some embodiments, an electronic device <NUM> is a personal computer, mobile electronic device, wearable computing device, laptop computer, tablet computer, mobile phone, feature phone, smartphone, digital media player, an in-vehicle infotainment (IVI) system, a speaker, television (TV), digital versatile disk (DVD) player, and/or any other electronic device capable of presenting media content (e.g., controlling playback of media items, such as music tracks, videos, etc.). Electronic devices <NUM> may connect to each other wirelessly and/or through a wired connection (e.g., directly through an interface, such as an HDMI interface). In some embodiments, an electronic device <NUM> is a headless client. In some embodiments, electronic devices <NUM>-<NUM> and <NUM>-m are the same type of device (e.g., electronic device <NUM>-<NUM> and electronic device <NUM>-m are both speakers). Alternatively, electronic device <NUM>-<NUM> and electronic device <NUM>-m include two or more different types of devices.

In some embodiments, electronic devices <NUM>-<NUM> and <NUM>-m send and receive media-control information through network(s) <NUM>. For example, electronic devices <NUM>-<NUM> and <NUM>-m send media control requests (e.g., requests to play music, movies, videos, or other media items, or playlists thereof) to media content server <NUM> through network(s) <NUM>. Additionally, electronic devices <NUM>-<NUM> and <NUM>-m, in some embodiments, also send indications of media content items to media content server <NUM> through network(s) <NUM>. In some embodiments, the media content items are uploaded to electronic devices <NUM>-<NUM> and <NUM>-m before the electronic devices forward the media content items to media content server <NUM>.

In some embodiments, electronic device <NUM>-<NUM> communicates directly with electronic device <NUM>-m (e.g., as illustrated by the dotted-line arrow), or any other electronic device <NUM>. As illustrated in <FIG>, electronic device <NUM>-<NUM> is able to communicate directly (e.g., through a wired connection and/or through a short-range wireless signal, such as those associated with personal-area-network (e.g., BLUETOOTH / BLE) communication technologies, radio-frequency-based near-field communication technologies, infrared communication technologies, etc.) with electronic device <NUM>-m. In some embodiments, electronic device <NUM>-<NUM> communicates with electronic device <NUM>-m through network(s) <NUM>. In some embodiments, electronic device <NUM>-<NUM> uses the direct connection with electronic device <NUM>-m to stream content (e.g., data for media items) for playback on the electronic device <NUM>-m.

In some embodiments, electronic device <NUM>-<NUM> and/or electronic device <NUM>-m include a media application <NUM> (<FIG>) that allows a respective user of the respective electronic device to upload (e.g., to media content server <NUM>), browse, request (e.g., for playback at the electronic device <NUM>), and/or present media content (e.g., control playback of music tracks, videos, etc.). In some embodiments, one or more media content items are stored locally by an electronic device <NUM> (e.g., in memory <NUM> of the electronic device <NUM>, <FIG>). In some embodiments, one or more media content items are received by an electronic device <NUM> in a data stream (e.g., from the CDN <NUM> and/or from the media content server <NUM>). The electronic device(s) <NUM> are capable of receiving media content (e.g., from the CDN <NUM>) and presenting the received media content. For example, electronic device <NUM>-<NUM> may be a component of a network-connected audio/video system (e.g., a home entertainment system, a radio/alarm clock with a digital display, or an infotainment system of a vehicle). In some embodiments, the CDN <NUM> sends media content to the electronic device(s) <NUM>.

In some embodiments, the CDN <NUM> stores and provides media content (e.g., media content requested by the media application <NUM> of electronic device <NUM>) to electronic device <NUM> via the network(s) <NUM>. Content (also referred to herein as "media items," "media content items," and "content items") is received, stored, and/or served by the CDN <NUM>. In some embodiments, content includes audio (e.g., music, spoken word, podcasts, etc.), video (e.g., short-form videos, music videos, television shows, movies, clips, previews, etc.), text (e.g., articles, blog posts, emails, etc.), image data (e.g., image files, photographs, drawings, renderings, etc.), games (e.g., <NUM>- or <NUM>-dimensional graphics-based computer games, etc.), or any combination of content types (e.g., web pages that include any combination of the foregoing types of content or other content not explicitly listed). In some embodiments, content includes one or more audio media items (also referred to herein as "audio items," "tracks," and/or "audio tracks").

In some embodiments, media content server <NUM> receives media requests (e.g., commands) from electronic devices <NUM>. In some embodiments, media content server <NUM> includes a voice API (e.g., voice recognition module <NUM>, <FIG>), a connect API, and/or key service (e.g., key database <NUM>, <FIG>). In some embodiments, media content server <NUM> validates (e.g., using key service) electronic devices <NUM> by exchanging one or more keys (e.g., tokens) with electronic device(s) <NUM>.

In some embodiments, media content server <NUM> and/or CDN <NUM> stores one or more playlists (e.g., information indicating a set of media content items). For example, a playlist is a set of media content items defined by a user and/or defined by an editor associated with a media-providing service. The description of the media content server <NUM> as a "server" is intended as a functional description of the devices, systems, processor cores, and/or other components that provide the functionality attributed to the media content server <NUM>. It will be understood that the media content server <NUM> may be a single server computer or may be multiple server computers. Moreover, the media content server <NUM> may be coupled to CDN <NUM> and/or other servers and/or server systems, or other devices, such as other client devices, databases, content delivery networks (e.g., peer-to-peer networks), network caches, and the like. In some embodiments, the media content server <NUM> is implemented by multiple computing devices working together to perform the actions of a server system (e.g., cloud computing).

<FIG> is a block diagram illustrating an electronic device <NUM> (e.g., electronic device <NUM>-<NUM> and/or electronic device <NUM>-m, <FIG>), in accordance with some embodiments. The electronic device <NUM> includes one or more central processing units (CPU(s), i.e., processors or cores) <NUM>, one or more network (or other communications) interfaces <NUM>, memory <NUM>, and one or more communication buses <NUM> for interconnecting these components. The communication buses <NUM> optionally include circuitry (sometimes called a chipset) that interconnects and controls communications between system components.

In some embodiments, the electronic device <NUM> includes a user interface <NUM>, including output device(s) <NUM> and /or input device(s) <NUM>. In some embodiments, the input devices <NUM> include a keyboard, mouse, or track pad. Alternatively, or in addition, in some embodiments, the user interface <NUM> includes a display device that includes a touch-sensitive surface, in which case the display device is a touch-sensitive display. In electronic devices that have a touch-sensitive display, a physical keyboard is optional (e.g., a soft keyboard may be displayed when keyboard entry is needed). In some embodiments, the output devices (e.g., output device(s) <NUM>) include a speaker <NUM> (e.g., speakerphone device) and/or an audio jack <NUM> (or other physical output connection port) for connecting to speakers, earphones, headphones, or other external listening devices. Furthermore, some electronic devices <NUM> use a microphone and voice recognition device to supplement or replace the keyboard. Optionally, the electronic device <NUM> includes an audio input device (e.g., a microphone) to capture audio (e.g., speech from a user).

Optionally, the electronic device <NUM> includes a location-detection device <NUM>, such as a global navigation satellite system (GNSS) (e.g., GPS (global positioning system), GLONASS, Galileo, Badious) or other geo-location receiver, and/or location-detection software for determining the location of the electronic device <NUM> (e.g., module for finding a position of the electronic device <NUM> using trilateration of measured signal strengths for nearby devices).

In some embodiments, the one or more network interfaces <NUM> include wireless and/or wired interfaces for receiving data from and/or transmitting data to other electronic devices <NUM>, a media content server <NUM>, a CDN <NUM>, and/or other devices or systems. In some embodiments, data communications are carried out using any of a variety of custom or standard wireless protocols (e.g., NFC, RFID, IEEE <NUM>. <NUM>, Wi-Fi, ZigBee, 6LoWPAN, Thread, Z-Wave, Bluetooth, ISA100.11a, WirelessHART, MiWi, etc.). Furthermore, in some embodiments, data communications are carried out using any of a variety of custom or standard wired protocols (e.g., USB, Firewire, Ethernet, etc.). For example, the one or more network interfaces <NUM> include a wireless interface <NUM> for enabling wireless data communications with other electronic devices <NUM>, media presentations systems <NUM>, and/or or other wireless (e.g., Bluetooth-compatible) devices (e.g., for streaming audio data to the media presentations system <NUM> of an automobile). Furthermore, in some embodiments, the wireless interface <NUM> (or a different communications interface of the one or more network interfaces <NUM>) enables data communications with other WLAN-compatible devices (e.g., a media presentations system <NUM>) and/or the media content server <NUM> (via the one or more network(s) <NUM>, <FIG>).

In some embodiments, electronic device <NUM> includes one or more sensors including, but not limited to, accelerometers, gyroscopes, compasses, magnetometer, light sensors, near field communication transceivers, barometers, humidity sensors, temperature sensors, proximity sensors, range finders, and/or other sensors/devices for sensing and measuring various environmental conditions.

Memory <NUM> includes high-speed random-access memory, such as DRAM, SRAM, DDR RAM, or other random-access solid-state memory devices; and may include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. Memory <NUM> may optionally include one or more storage devices remotely located from the CPU(s) <NUM>. Memory <NUM>, or alternately, the non-volatile memory solid-state storage devices within memory <NUM>, includes a non-transitory computer-readable storage medium. In some embodiments, memory <NUM> or the non-transitory computer-readable storage medium of memory <NUM> stores the following programs, modules, and data structures, or a subset or superset thereof:.

<FIG> is a block diagram illustrating a media content server <NUM>, in accordance with some embodiments. The media content server <NUM> typically includes one or more central processing units/cores (CPUs) <NUM>, one or more network interfaces <NUM>, memory <NUM>, and one or more communication buses <NUM> for interconnecting these components.

Memory <NUM> includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices; and may include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. Memory <NUM> optionally includes one or more storage devices remotely located from one or more CPUs <NUM>. Memory <NUM>, or, alternatively, the non-volatile solid-state memory device(s) within memory <NUM>, includes a non-transitory computer-readable storage medium. In some embodiments, memory <NUM>, or the non-transitory computer-readable storage medium of memory <NUM>, stores the following programs, modules and data structures, or a subset or superset thereof:.

In some embodiments, the media content server <NUM> includes web or Hypertext Transfer Protocol (HTTP) servers, File Transfer Protocol (FTP) servers, as well as web pages and applications implemented using Common Gateway Interface (CGI) script, PHP Hyper-text Preprocessor (PHP), Active Server Pages (ASP), Hyper Text Markup Language (HTML), Extensible Markup Language (XML), Java, JavaScript, Asynchronous JavaScript and XML (AJAX), XHP, Javelin, Wireless Universal Resource File (WURFL), and the like.

Each of the above identified modules stored in memory <NUM> and <NUM> corresponds to a set of instructions for performing a function described herein. The above identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules may be combined or otherwise re-arranged in various embodiments. In some embodiments, memory <NUM> and <NUM> optionally store a subset or superset of the respective modules and data structures identified above. Furthermore, memory <NUM> and <NUM> optionally store additional modules and data structures not described above.

Although <FIG> illustrates the media content server <NUM> in accordance with some embodiments, <FIG> is intended more as a functional description of the various features that may be present in one or more media content servers than as a structural schematic of the embodiments described herein. In practice, and as recognized by those of ordinary skill in the art, items shown separately could be combined and some items could be separated. For example, some items shown separately in <FIG> could be implemented on single servers and single items could be implemented by one or more servers. In some embodiments, media content database <NUM> and/or metadata database <NUM> are stored on devices (e.g., CDN <NUM>) that are accessed by media content server <NUM>. The actual number of servers used to implement the media content server <NUM>, and how features are allocated among them, will vary from one implementation to another and, optionally, depends in part on the amount of data traffic that the server system handles during peak usage periods as well as during average usage periods.

<FIG> is a block diagram illustrating media content delivery to a media presentation system <NUM> (e.g., a smart speaker, also referred to as a personal assistant device, a smart television, a headset, etc.) associated with a third-party server <NUM>, in accordance with some embodiments. (Note that media presentation system <NUM> is an instance of the client devices <NUM> described with respect to <FIG>. ) In particular, <FIG> illustrates a process for waking the media presentation system <NUM> from a low power mode (an example of an idle mode) through third-party server <NUM> (which maintains some ability to communicate with media presentation system <NUM> even when media presentation system <NUM> is in the low power mode).

Note the devices in <FIG> may communicate through any type of network (e.g., networks <NUM>, <FIG>). For example, the one or more networks <NUM> can be any network (or combination of networks) such as the Internet, other wide area networks (WAN), local area networks (LAN), virtual private networks (VPN), metropolitan area networks (MAN), peer-to-peer networks, and/or ad-hoc connections.

In some embodiments, media content server <NUM> is a server for a media providing service (e.g., for streaming media). Under normal operations (e.g., when the media presentation system <NUM> is not in a low power mode), media content server <NUM> communicates with media presentation system <NUM> via an application <NUM> installed on the media presentation system <NUM>. For example, media presentation system <NUM> is linked to an account of user <NUM> through application <NUM> (client device <NUM>-<NUM> is linked to the same account through media application <NUM>). In a typical scenario, a user <NUM> of client device <NUM>-<NUM> selects, using media application <NUM> (<FIG>), media content (e.g., audio tracks) to be played back. User <NUM> also selects, device via device picker <NUM>, media presentation system <NUM> as the presentation device. Media content server <NUM> keeps track of which user is active on media presentation system <NUM> by logging that user into media presentation system <NUM> at backend <NUM>. Media content server <NUM> also transmits instructions to media presentation system <NUM> to present the selected media content. In some embodiments, media presentation system <NUM> retrieves the selected media from a content distribution network <NUM> (<FIG>).

In some circumstances, media presentation system <NUM> enters a low power mode (e.g., without user intervention, based on a period of inactivity). In the low power mode, media content server <NUM> is not capable of communicating directly with application <NUM> because media presentation system <NUM> is essentially turned off from the viewpoint of media content server <NUM> (e.g., communication between media content server <NUM> and application <NUM> is terminated when media presentation system <NUM> enters the low power mode). More particularly, media presentation system <NUM> is not capable of waking media presentation system <NUM> from the low power mode by directly communicating with application <NUM>, because to maintain such direct communication between application <NUM> and media content server <NUM> (e.g., without going through third-party server <NUM>, as described below) would prevent media presentation system <NUM> from entering the low power mode in the first place.

Media content server <NUM> determines that the media presentation system has entered the low power mode. For example, in some embodiments, when in normal operation, application <NUM> sends periodic messages (e.g., pings) to media content server <NUM>. In some embodiments, the media content server <NUM> determines that these periodic messages have ceased, and thus determines that media presentation system <NUM> is (at best) in a low power mode. As another example, in some embodiments, application <NUM> sends media content server <NUM> a message explicitly informing the media content server <NUM> that media presentation system <NUM> has entered the low power mode. In some embodiments, the message explicitly informing the media content server <NUM> that media presentation system <NUM> has entered the low power mode is a request to log user <NUM> out of media presentation system <NUM>.

At some point later, media content server <NUM> receives a request from client device <NUM>-<NUM> that triggers reestablishing communication with the media presentation system <NUM> (or at least attempting to reestablish communication, as media content server <NUM> may not know whether media presentation system <NUM> is in a low power mode or turned off completely). In some embodiments, the request is based on a user interaction with the client device <NUM>-<NUM> (e.g., a user interaction with media application <NUM>). For example, the request that triggers reestablishing communication with the media presentation system <NUM> may result from the user <NUM> opening media application <NUM> (e.g., bringing media application <NUM> to the foreground of the client device <NUM>-<NUM>), or opening device picker <NUM>, or requesting to play media content. For example, the user <NUM> may have paused media content playing back on media presentation system <NUM> for a sufficiently long time such that media presentation system <NUM> entered a low power mode, and the request that triggers reestablishing communication with the media presentation system <NUM> is based on the user requesting to resume (un-pause) the media content.

In response to the request from client device <NUM>-<NUM>, media content server <NUM> sends a request to third-party server <NUM> to wake the media presentation system <NUM> from the low power mode. As noted above, third-party server <NUM> maintains some ability to communicate with media presentation system <NUM> even when media presentation system <NUM> is in the low power mode, and, more particularly, maintains an ability to wake media presentation system <NUM> from the low power mode. In response to request to wake media presentation system <NUM> from the low power mode, third-party server <NUM> does so (e.g., by sending a message to media presentation system <NUM> that wakes media presentation system <NUM>). Upon media presentation system <NUM> waking, application <NUM> sends an indication to media content server <NUM> indicating that communication with the media presentation system <NUM> has been reestablished. Thus, rather than maintaining constant periodic communication with media presentation system <NUM>, which would prevent media presentation system <NUM> from entering a low power mode, media content server <NUM> wakes media presentation system <NUM> by sending messages that go through third-party server <NUM>.

After waking media presentation system <NUM>, media content server can once again transmit playback commands to application <NUM> to cause media presentation system <NUM> to present media content.

<FIG> illustrates a graphical user interface <NUM> displayed by a display of a client device <NUM>-<NUM> associated with a user (e.g., Sara). In some embodiments, the graphical user interface on device <NUM> includes a device selection portion <NUM> (e.g., a device picker). The device selection portion <NUM> includes user interface objects that correspond to one or more presentation devices, such as "This Phone" <NUM>, "Living Room" <NUM> (e.g., which may correspond to media presentation system <NUM>), and "More devices" <NUM>. In some embodiments, the device <NUM>-<NUM> receives a user input at a location that corresponds to a presentation device user interface object in the device selection portion <NUM> to select a presentation device for presentation of the media content (e.g., received by device <NUM>-<NUM> from media content server <NUM>). For example, the device receives a user input (e.g., from Sara) at a location corresponding to the displayed user interface object labeled "This Phone" <NUM> to select client device <NUM>-<NUM> as the presentation device. In this manner, client device <NUM>-<NUM> is selected as the playback device.

<FIG> are flow diagrams illustrating a method <NUM> of communicating with a device in a low power (e.g., idle) mode, in accordance with some embodiments. Method <NUM> may be performed (<NUM>) at a first server system (e.g., media content server <NUM>) configured to communicate with a first client device (e.g., media presentation system <NUM>) through a first application (e.g., application <NUM>) executing on the first client device. In some embodiments, the first client device includes one or more speakers (e.g., the first client device is a smart speaker). In some embodiments, the first client device includes a display (e.g., the first client device is a smart television, a headset, etc.) In some embodiments, the method <NUM> is performed by executing instructions stored in the memory (e.g., memory <NUM>, <FIG>) of the first server system. In some embodiments, the method <NUM> is performed by a combination of the server system (e.g., including media content server <NUM> and CDN <NUM>) and an electronic device (e.g., a client device). In some embodiments, the server system provides tracks (e.g., media items) for playback to the electronic device(s) <NUM>/<NUM> of the media content delivery system <NUM>.

As described in greater detail below, method <NUM> obviates the need for the first server system to maintain constant (e.g., periodic) contact with the first client device, which would otherwise prevent the first client device from entering a low power mode. Thus, method <NUM> conserves power while simultaneously reducing friction when communications need to be reestablished between the first server system and the first client device.

The first server system determines (<NUM>) that communication with the first client device through the first application has been lost due to the first client device entering an idle mode (e.g., a low power mode). In some embodiments, the first client device is a media presentation system. In some embodiments, the first application is an embedded in firmware of the first client device. In some embodiments, the first application include an application programming interface (API). In some embodiments, the first application is a software development kit (eSDK) embedded in firmware of the first client device (e.g., the first application is "embedded" on the media presentation system <NUM>). In some embodiments, the eSDK is integrated with firmware on the media presentation system <NUM>. As will be apparent to one of skill in the art, configuring the first client device to communicate with the first server system (e.g., by embedding the first application in the firmware of the first client device) alleviates difficulties in the technical process of discovering local devices for media playback (e.g., so that such devices may be shown in a device picker <NUM>).

In some embodiments, determining that communication with the first client device through the first application has been lost due to the first client device entering an idle mode includes receiving (<NUM>) a message from application <NUM> explicitly informing the media content server <NUM> that the first client device has entered the idle mode. In some embodiments, determining that communication with the first client device through the first application has been lost due to the first client device entering an idle mode includes receiving (<NUM>) (e.g., from application <NUM>) a log-out request indicating that a user of the second client device is to be logged out of the first client device. In some embodiments, the method <NUM> includes, after determining that communication with the first client device through the first application has been lost due to the first client device entering an idle mode, logging the user of the second client device out of the first client device (e.g., at backend <NUM>, <FIG>).

In some embodiments, in normal operation (e.g., when the first client device is not in the idle mode), the first application sends periodic messages (e.g., "pings") to the first server system. In some embodiments, determining that communication with the first client device through the first application has been lost includes determining (<NUM>) that periodic messages from the first client device to the first server system have ceased (e.g., that a predefined number of scheduled pings have not arrived, or that no pings have been received for a predefined amount of time).

In some embodiments, the first server system is not capable of communicating (e.g., directly) with the first application when the first client device is in the idle mode. In some embodiments, the first server system is not capable of communicating (e.g., directly) with the first client device when the first client device is in the idle mode. Preventing the first server system from communicating directly with the first client device (e.g., through an eSDK) allows the first client device to remain in the idle mode for longer periods of time, thus saving power.

After determining that the communication with the first client device through the first application has been lost (e.g., at some later time), the first server system receives (<NUM>) a request from a second client device , distinct from the first client device (e.g., client device <NUM>-<NUM>, <FIG>, distinct from the first client device), that triggers reestablishing communication with the first client device through the first application.

In response to the request from the second client device that triggers reestablishing communication with the first client device through the first application, the first server system transmits (<NUM>) a request to a second server system (e.g., third-party server <NUM>) to wake the first client device from the idle mode. In some embodiments, the second server system maintains the ability to communicate with the first client device when the first client device is in the idle mode (e.g., maintains the ability to wake the first client device from the idle mode). In some embodiments, the second server system is the only server system that maintains the ability to communicate with the first client device when the first client device is in the idle mode. By transmitting a message to the second server system to wake the first client device from the idle mode, method <NUM> maintains the benefit of allowing the first client device to be "discoverable" (e.g., such that a user can select the first client device as a presentation device through a device picker <NUM>), while at the same time allowing the first client device to remain in the idle mode for as long as possible, thus saving power.

In some embodiments, the request that triggers reestablishing communication with the first client device is based on a user interaction at the second client device. In some embodiments, the request the triggers reestablishing communication with the first client device is based on a user interaction, on the second client device, with an application associated with the first server system (e.g., a media application <NUM> associated with media content server <NUM>). In some embodiments, the request that triggers reestablishing communication with the first client device is provided in response to the user interaction. Allowing a user to wake the first client device through interaction with the second client device eliminates the need for the user to directly interact with the first client device in order to wake the first client device, reducing friction during the process of local device discovery, while providing the aforementioned benefits with respect to keeping the first client device in the idle mode whenever possible.

In some embodiments, the request from the second client device that triggers reestablishing communication with the first client device indicates (<NUM>) that a user has opened, on the second client device, a user interface for selecting a device for presenting media content (e.g., a device picker). In some embodiments, in response to the request from the second client device that triggers reestablishing communication with the first client device, the first server system transmits (<NUM>) an instruction back to the second client device to display the user interface for selecting the device for presenting media content. In some embodiments, in response to the request from the second client device that triggers reestablishing communication with the first client device, the first server system transmits (<NUM>) an instruction back to the second client device to display an option for selecting the second client device in the user interface for selecting the device for presenting media content (e.g., the device picker displays the first client device as an option only once communication with the first client device has been reestablished).

In some embodiments, the request from the second client device that triggers reestablishing communication with the first client device indicates (<NUM>) a user has opened an application associated with the first server system (e.g., media application <NUM>). For example, a user may open the application by launching the application in the first instance, or by bringing the application to the foreground (e.g., of client device <NUM>-<NUM>).

In some embodiments, the request from the second client device that triggers reestablishing communication with the first client device is (<NUM>) a request to control media presentation by the first client device (e.g., a request to present media content or to resume presentation of media content).

In some embodiments, the request to the second server system to wake the first client device from the idle mode includes (<NUM>) an identifier of the user. In some embodiments, the request from the second server system to wake the first client device includes an identifier of the first client device. In some embodiments, the identifier of the first client device is based on a usage history of the user. For example, although the user is logged out of the first client device, the first server system keeps track of which presentation devices the user has previously been logged into (e.g., within the last hour, day, or week). In response to the user opening the device picker, the first server system attempts to reestablish communication with the presentation devices that the user has previously logged into (e.g., by performing method <NUM>).

The first server system receives (<NUM>), from the first application on the first client device, an indication that communication has been reestablished between the first server system and the first application. In some embodiments, the indication that communication has been reestablished includes the identifier of the user. In some embodiments, the indication that communication has been reestablished is (<NUM>) a request to log the user of the second client device back into the first client device. In some embodiments, the instruction back to the second device (operation <NUM>) to display the option for selecting the first client device as the presentation device is transmitted in response to receiving the indication that communication has been reestablished.

In some embodiments, after receiving, from the first application on the first client device, the indication that communication has been reestablished between the first server system and the first application, the first server system transmits (<NUM>), to the first application on the first client device, a control command to control the first client device.

In some embodiments, the first server system is associated with a media providing service and the control command is (<NUM>) a command to provide playback of media content at the second client device (e.g., a command to play or resume content, fast forward, begin a new track, etc.).

Although <FIG> illustrate a number of logical stages in a particular order, stages which are not order dependent may be reordered and other stages may be combined or broken out. Some reordering or other groupings not specifically mentioned will be apparent to those of ordinary skill in the art, so the ordering and groupings presented herein are not exhaustive. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software, or any combination thereof.

Claim 1:
A method (<NUM>) comprising, at a media content server system (<NUM>) configured to deliver media content to a first client device (<NUM>) through a first application (<NUM>) executing on the first client device:
determining (<NUM>) that communication with the first client device through the first application has been lost due to the first client device entering an idle mode;
after determining (<NUM>) that the communication with the first client device through the first application has been lost, receiving (<NUM>) a request from a second client device (<NUM>), distinct from the first client device (<NUM>), that triggers reestablishing communication with the first client device through the first application (<NUM>);
in response to the request from the second client device that triggers reestablishing communication with the first client device through the first application, transmitting (<NUM>) a request to a third-party server (<NUM>) with which the first client device is associated, to wake the first client device (<NUM>) from the idle mode;
receiving (<NUM>), from the first application (<NUM>) on the first client device (<NUM>), an indication that communication has been reestablished between the media content server system (<NUM>) and the first application; and
after receiving (<NUM>), from the first application on the first client device, the indication that communication has been reestablished between the media content server system and the first application, transmitting (<NUM>), to the first application (<NUM>) on the first client device (<NUM>), a playback command to cause the first client device to present the media content.