Managing playback groups

文档序号：1802520 发布日期：2021-11-05 浏览：5次中文

阅读说明：本技术 管理回放组 (Managing playback groups ) 是由 D·伊耶 T·阿尔西娜 E·T·施密特 E·勒夫曼 D·P·萨拉希诺 A·伊 A·索南斯于 2019-03-29 设计创作，主要内容包括：本发明涉及管理回放组。在一些具体实施中,系统可被配置为管理回放设备组。例如,回放设备可以多种方式动态地分组。每个回放设备可存储定义所述回放设备所属的所述组的属性。每个回放设备可将其组属性发送到遥控设备,并且所述遥控设备可基于所述组属性来确定回放设备的组。然后,所述遥控设备可配置并呈现代表所述各组回放设备的图形用户界面。在一些具体实施中,一组回放设备可被配置为持久组。例如,一对回放设备(例如,无线扬声器)可存储和发送指示所述对回放设备是持久组的属性数据,使得遥控设备可将所述持久组作为单个设备呈现和控制。(The invention relates to managing playback groups. In some implementations, the system may be configured to manage groups of playback devices. For example, playback devices may be dynamically grouped in a variety of ways. Each playback device may store attributes defining the group to which the playback device belongs. Each playback device may send its group attributes to the remote control device, and the remote control device may determine the group of playback devices based on the group attributes. The remote control device may then configure and present a graphical user interface representative of the sets of playback devices. In some implementations, a group of playback devices can be configured as a persistent group. For example, a pair of playback devices (e.g., wireless speakers) may store and transmit attribute data indicating that the pair of playback devices is a persistent group, such that a remote control device may render and control the persistent group as a single device.)

1. A method, comprising:

storing, by a first computing device, a device identifier corresponding to an authorized computing device that has been authorized to access a playback device within an environment, wherein the device identifier corresponding to the authorized computing device is stored to an authorized user database associated with a user of the first computing device;

causing, by a first computing device, the first computing device to pair with a first playback device within the environment;

after the first computing device is paired with the first playback device, causing, by the first computing device, the first playback device to generate a pairing token for each of the authorized computing devices;

receiving, by the first computing device from the first playback device, the pairing token generated by the first playback device for each of the authorized computing devices; and

sending, by the first computing device, to the second computing device, a particular pairing token generated by the first playback device for the second computing device, wherein the second computing device uses the particular pairing token to access the service provided by the first playback device.

2. The method of claim 1, wherein the second computing device uses the particular pairing token to access a service provided by the first playback device without user input.

3. The method of claim 1, further comprising:

sending, by the first computing device, the device identifier to the first playback device;

receiving, by a first computing device, an association of the pairing token with a respective device identifier; and

storing, by the first computing device, the association of the pairing token with the respective device on the first computing device.

4. The method of claim 1, further comprising:

receiving, by a first computing device, a user input pairing the first computing device with a first playback device; and

automatically sending, by the first computing device, the device identifiers corresponding to the authorized computing devices to a first playback device, wherein the first playback device generates a unique pairing token for each of the device identifiers.

5. A method, comprising:

receiving, by a playback device, a request to pair a first computing device with the playback device;

causing, by the playback device, a first computing device to pair with the playback device;

receiving, by a playback device, a plurality of device identifiers from a first computing device upon pairing the first computing device with the playback device;

generating, by the playback device, a plurality of unique pairing tokens, each of the plurality of unique pairing tokens being associated with a respective one of the plurality of device identifiers;

storing, by the playback device, a mapping of the plurality of unique pairing tokens to respective device identifiers in an authorized user database associated with a user of a first computing device, wherein the plurality of device identifiers correspond to authorized computing devices for the first computing device; and

sending, by the playback device to the first computing device, a mapping of the plurality of unique pairing tokens to respective device identifiers.

6. The method of claim 5, further comprising:

receiving, by the playback device from a second computing device, a request to access a service provided by the playback device, the request including a particular device identifier corresponding to the second computing device and a first pairing token;

obtaining, by the playback device, a second pairing token associated with the particular device identifier from the stored mapping;

determining, by the playback device, that the second pairing token is the same as the first pairing token; and

based on the determination, a second computing device is allowed to access a service provided by the playback device.

7. The method of claim 6, wherein the first pairing token is sent from the playback device to the first computing device and not sent from the playback device to the second computing device.

8. The method of claim 5, further comprising:

obtaining, by the playback device, a second pairing token associated with the particular device identifier from the stored mapping;

determining, by the playback device, that the second pairing token is different from the first pairing token; and

based on the determination, a second computing device is prevented from accessing a service provided by the playback device.

9. The method of claim 5, further comprising:

determining, by the playback device, that the particular device identifier is not in the stored mapping; and

based on the determination, a second computing device is prevented from accessing a service provided by the playback device.

10. A system for managing playback groups, the system comprising:

one or more processors; and

a non-transitory computer-readable medium comprising one or more sequences of instructions which, when executed by the one or more processors, cause the processors to perform operations comprising:

causing, by a first computing device, the first computing device to pair with a first playback device within the environment;

receiving, by the first computing device from the first playback device, the pairing token generated by the first playback device for each of the authorized computing devices; and

11. The system of claim 10, wherein the second computing device uses the particular pairing token to access a service provided by the first playback device without user input.

12. The system of claim 10, wherein the instructions cause the processor to perform operations comprising:

sending, by the first computing device, the device identifier to the first playback device;

receiving, by a first computing device, an association of the pairing token with a respective device identifier; and

storing, by the first computing device, the association of the pairing token with the respective device on the first computing device.

13. The system of claim 10, wherein the instructions cause the processor to perform operations comprising:

receiving, by a first computing device, a user input pairing the first computing device with a first playback device; and

14. A system for managing playback groups, the system comprising:

one or more processors; and

a non-transitory computer-readable medium comprising one or more sequences of instructions which, when executed by the one or more processors, cause the processors to perform operations comprising:

receiving, by a playback device, a request to pair a first computing device with the playback device;

causing, by the playback device, a first computing device to pair with the playback device;

receiving, by a playback device, a plurality of device identifiers from a first computing device upon pairing the first computing device with the playback device;

generating, by the playback device, a plurality of unique pairing tokens, each of the plurality of unique pairing tokens being associated with a respective one of the plurality of device identifiers;

sending, by the playback device to the first computing device, a mapping of the plurality of unique pairing tokens to respective device identifiers.

15. The system of claim 14, wherein the instructions cause the processor to perform operations comprising:

obtaining, by the playback device, a second pairing token associated with the particular device identifier from the stored mapping;

determining, by the playback device, that the second pairing token is the same as the first pairing token; and

based on the determination, a second computing device is allowed to access a service provided by the playback device.

16. The system of claim 15, wherein a first pairing token is sent from the playback device to a first computing device and not sent from the playback device to a second computing device.

17. The system of claim 14, wherein the instructions cause the processor to perform operations comprising:

obtaining, by the playback device, a second pairing token associated with the particular device identifier from the stored mapping;

determining, by the playback device, that the second pairing token is different from the first pairing token; and

based on the determination, a second computing device is prevented from accessing a service provided by the playback device.

18. The system of claim 14, wherein the instructions cause the processor to perform operations comprising:

determining, by the playback device, that the particular device identifier is not in the stored mapping; and

based on the determination, a second computing device is prevented from accessing a service provided by the playback device.

19. A non-transitory computer-readable medium comprising one or more sequences of instructions which, when executed by one or more processors, causes the processors to perform the method of claim 1.

20. A non-transitory computer-readable medium comprising one or more sequences of instructions which, when executed by one or more processors, causes the processors to perform the method of claim 5.

Technical Field

The present disclosure relates generally to managing media playback across networked playback devices.

Background

Wireless audio/video (a/V) devices become ubiquitous. For example, wireless speaker systems are used in many homes to play music. Wireless streaming devices are used to play video to a television and/or audio through a connected speaker system. Sometimes, the wireless loudspeaker system and/or the streaming device is a smart computing device that can be configured to stream and/or receive streaming audio and video data. In some cases, several smart a/V devices may be placed around a home and in different configurations to provide various a/V functions in the home and/or different rooms of the home. A system is required to configure, monitor and control these different a/V devices.

Disclosure of Invention

In some implementations, the system can be configured to allow the remote control device to silently obtain status information related to various audio/video playback devices. For example, a streaming device (e.g., user device, phone, etc.) may establish a streaming connection with a playback device. The playback device may be configured to accept only a single streaming connection (i.e., primary connection). A remote control device (e.g., user device, phone, etc.) may squelch-connect (i.e., control the connection) to the playback device without interrupting the main connection to obtain state information related to the playback device and/or the media being streamed to the playback device. The remote control device may provide commands through the control connection to adjust playback of the streaming media at the playback device.

In some implementations, the system may be configured to manage groups of playback devices. For example, playback devices may be dynamically grouped in a variety of ways. Each playback device may store attributes that define the group to which the playback device belongs. Each playback device may send its group attributes to the remote control device, and the remote control device may determine the group of playback devices based on the group attributes. The remote control device may then configure and present a graphical user interface representing the sets of playback devices. In some implementations, a group of playback devices can be configured as a persistent group. For example, a pair of playback devices (e.g., wireless speakers) may be configured as a stereo pair. The pair of playback devices may store and transmit attribute data indicating that the pair of playback devices is a persistent group such that the remote control device may present and control the persistent group as a single device.

In some implementations, the system can be configured to ease the burden of pairing the user device with the playback device. For example, all users (or user devices) that typically operate within a particular environment (e.g., a home) may be configured as authorized users of the playback device within the particular environment. When one of the authorized users pairs a user device with the playback device, all user devices of all authorized users may be automatically paired with the playback device as a result of the single pairing. Thus, only a single authorized user is burdened with the pairing process in order to pair all authorized users with the playback device.

In some implementations, the system may be configured to route media data to the playback device based on a context associated with the media data. For example, media data may include audio and/or video data associated with media items such as music, movies, television programs, and the like. The media data may include software-generated audio and/or video data, such as audio/video output from a gaming application and/or operating system. A context may be determined based on a source of the media data, and the media data may be routed to the playback device based on the determined context. For example, when the context is a media context associated with a media item source, the media data may be routed to a remote playback device for presentation. When the context is a system context associated with a software source, the media data may be rendered by the local device.

The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features, aspects, and potential advantages will become apparent from the description and drawings, and from the claims.

Drawings

Fig. 1 is an exemplary Graphical User Interface (GUI) for controlling a playback device.

FIG. 2 illustrates an example graphical user interface for presenting controls for playback groups.

FIG. 3 is a block diagram of an example system for remotely controlling a playback device from a remote control device.

FIG. 4 is a block diagram of an example system for remotely controlling playback groups from a remote control device.

FIG. 5 is a block diagram of an example system for remotely controlling a non-discoverable playback device from a remote control device.

Fig. 6 is a block diagram of an example system for managing groups of dynamic playback devices.

FIG. 7 is a block diagram of an example system for managing persistent playback groups.

FIG. 8 is a block diagram of a system for streaming media items to a persistent group.

FIG. 9 is a block diagram of a system for streaming media items to a persistent group.

Fig. 10 is a block diagram of a system for presenting media items streamed from a primary playback device within a persistent group.

Fig. 11 is a block diagram of an example system for synchronizing playback resumption among playback devices in a playback group.

FIG. 12 is a block diagram of an example system for automatically pairing a user device with a playback device.

Fig. 13 is a block diagram of an example system for managing volume changes between networked playback devices.

Fig. 14 is a block diagram of an example media system configured to automatically establish a streaming media connection between playback devices.

Fig. 15 is a block diagram of an example media system configured to dynamically route media data to a playback device.

FIG. 16 is a block diagram of an example media system for dynamic routing based on playback device capabilities.

FIG. 17 is a block diagram of an example media system for providing access to media data in a second language.

Fig. 18 is a flow diagram of an example process 1800 for remotely controlling a playback device.

Fig. 19 is a flow diagram of an example process for managing playback groups.

FIG. 20 is a flow diagram of an example process for efficiently pairing an authorized user device with a playback device.

FIG. 21 is a flow diagram of an example process for generating pairing tokens for multiple user devices.

Fig. 22 is a flow diagram of an example process for contextual routing of media data.

Fig. 23 is a block diagram of an example computing device that may implement the features and processes of fig. 1-22.

Like reference symbols in the various drawings indicate like elements.

Detailed Description

Fig. 1 is an exemplary Graphical User Interface (GUI)100 for controlling a playback device. For example, GUI100 may be presented by a computing device, such as a smartphone, tablet, laptop, wearable computing device, or any other type of computing device with a connected display. To generate GUI100, a computing device (e.g., a remote control device, a streaming device, etc.) may wirelessly connect to various playback devices (e.g., wireless speakers, set-top boxes, televisions, etc.) and collect status and attribute information from the playback devices. Based on the received attribute data, the computing device may generate GUI100 that includes representations of individual playback devices (e.g., represented by graphical element 102) and/or groups of playback devices (e.g., represented by graphical elements 130 and 140). Using the state information provided by the playback device, the computing device may present information describing the media currently being played by the playback device, playback controls that may be used to adjust playback of the played media, and/or other information, as may be described further below.

In some implementations, GUI100 may include graphical elements 102 for selecting and/or controlling various playback devices. For example, each playback device may advertise the playback device's ability to receive media streamed from the computing device. When the computing device receives the information identifying the various playback devices, the computing device may generate a graphical element 102 identifying the playback devices. In some implementations, the computing device itself can be identified within the graphical element 102. For example, the graphical element 102 may include a display area 104 for identifying the media item (e.g., song, movie, television program, etc.) being played and the device playing the media. In the embodiment of FIG. 1, the display area 104 indicates that the user's phone is playing a song.

In some implementations, the graphical elements 102 may include graphical elements 108, 112, and/or 116 that identify playback devices. In the embodiment of FIG. 1, the computing device presenting GUI100 is the user's phone, and thus the user's phone is identified with graphical element 108. Additionally, the graphical element 108 may include an indicator (e.g., a check mark) that indicates that the user's phone is the currently selected playback device. The graphical elements 102 may also include a graphical element 112 indicating that a television or set-top box is available to play the selected media item. The graphical elements 102 may include a graphical element 116 indicating that wireless speakers are available to play the selected media item. When the computing device (e.g., the user's phone) receives a selection of one or both of the graphical elements 112 and/or 116, the computing device may stream the selected media item (e.g., song) to the selected playback device and stop playing the selected media item through an output component (e.g., speaker, display, etc.) of the computing device. When streaming media from a computing device, the computing device becomes a master device with respect to one or more playback devices to which the media item is streamed. In some implementations, each playback device is configured to have only one master device. Thus, if the second computing device begins streaming to one of the selected playback devices, the second computing device takes over (e.g., hijacks) the connection and becomes the master of the playback device.

In some implementations, the graphical element 102 may include a media playback control region 120. For example, region 120 may include media playback controls (e.g., a play button, a rewind button, a fast forward button, a volume control, etc.) for media played by or streamed from the computing device. In the embodiment of fig. 1, region 120 presents a volume control 122 for specifying and/or adjusting the volume at which the selected playback device plays the media item. For example, the user may slide the volume handle 124 along the volume slider 122 to adjust the volume up or down.

In some implementations, GUI100 may include a graphical element 130 representing a dynamic playback device group. For example, a user may provide input to the computing device to configure the playback device as a group of playback devices (i.e., a playback group). In some implementations, the user can provide input to a software application (e.g., home application 332, described below) on the computing device to indicate which playback devices should be included in a particular dynamic playback group. For example, a user may drag and drop playback devices into a particular dynamic playback group. The user may specify that playback devices within the same room of the user's house (e.g., as determined by the home application 332) should be part of a particular dynamic playback group. For example, a user may specify that two playback devices (e.g., wireless speakers) in the user's living room should play back media as a group. The dynamic playback groups may be configured and reconfigured according to the needs of the user. For example, a user may want to listen to music in the living room and create a set of speakers in the living room. Later, the user may wish to group speakers in the living room and kitchen, and may reconfigure playback devices in the living room and kitchen to the new group. In some implementations, a single playback device may be part of multiple different dynamic playback groups. For example, a user may configure a dynamic playback group that includes living room playback devices. The user may configure different dynamic playback groups including kitchen playback devices. The user may configure another dynamic playback group that includes living room and kitchen playback devices. Thus, the playback devices in the living room may belong to a living room playback group and a combined kitchen/living room playback group.

In response to receiving the group designation, the designated playback device may be dynamically configured with a group attribute that identifies to other devices (including computing devices) that the designated playback device belongs to the same group, as described in more detail below. For example, a software application on the computing device (e.g., the home application 332) may send a group attribute corresponding to a specified group for each playback device to each playback device.

When the computing device receives a group attribute from a playback device in the group, the computing device may determine that the playback device belongs to the same group and render graphical elements 130 representative of the playback group. For example, the graphical element 130 may include status information reported by the playback group (e.g., the name of the group, the media item the group is playing, the image 132 representing the group, the identifiers of the playback devices in the group, etc.). The user may select the graphical element 134 to cause the computing device to present the GUI200 of fig. 2 so that the user may view the status of and control the playback group.

In some implementations, GUI100 may include a graphical element 140 representing a persistent playback device group. For example, a user may want to configure two or more playback devices into a persistent playback device group (e.g., similar to a stereo configuration or a surround sound configuration). When a user creates a persistent playback device group, the playback devices may be processed by the computing device as if the persistent group of playback devices were a single device (e.g., a single playback device). Thus, the persistent playback device group does not undergo the same dynamic shuffle described above with respect to the dynamic playback device group. However, the persistent group may be a member of the dynamic group such that the persistent group is treated as a single playback device within the dynamic group device. Because the persistent playback device group is considered a single playback device, in some implementations, the persistent playback group can present a single playback device (e.g., similar to a television and/or speaker playback device) represented by graphical element 102. Similar to the dynamic playback device group, the user may select the graphical element 144 to cause the computing device to present the GUI200 of fig. 2 so that the user may view the state of the persistent playback group and control the playback group.

In some implementations, the computing device can establish a remote control connection (i.e., a control connection) to the playback device to collect state information and control playback at the playback device. For example, the control connection is a squelched connection that does not interrupt the main connection, as opposed to the main connection being hijacked by other streaming devices when they wish to stream media to the playback device. The control connection does not stream media to the playback device. Instead, the control connection is used to obtain status information and control playback of the media being played by the playback device. Thus, the computing device may stream media to a first set of playback devices and receive and present state information related to another set of playback devices.

FIG. 2 illustrates an example graphical user interface 200 for presenting controls for playback groups. For example, GUI200 may be presented by a computing device in response to a user selecting graphical element 134 or graphical element 144 of fig. 1, as described above. For example, when the computing device receives a selection of graphical element 134 or graphical element 144, the computing device may minimize graphical element 102 to correspond to graphical element 202 of display area 104 of fig. 1. Thus, the graphical element 102 represents a media item played or streamed by the computing device.

When the computing device receives a selection of graphical element 134 or graphical element 144, the computing device may expand the corresponding graphical element 130 or 140 representing the dynamic playback group or persistent playback group into graphical element 210 to present additional information and/or controls for the selected playback group. For example, the graphical element 210 may include an information area 212 identifying the name of the playback group and/or the media item that the playback group is playing (or recently playing).

The graphical element 210 may include a control area 220 for rendering controls for the playback group. For example, the controls presented in the control region 220 may be dynamically determined based on the capabilities and/or features of the playback devices in the playback group, the media items being played by the playback group, and/or the software application providing the media items being played by the playback group. For example, if the playback group includes a device having video capabilities, a video control may be presented in region 220. However, if the playback group does not include a video-capable device, only the audio controls may be presented. For example, the control region 220 may include a media playback timeline 222 and an indicator 224 (e.g., a play head) to indicate a current playback position of the media item in the playback timeline. The control region 220 can include playback controls 226 (e.g., play, pause, rewind, fast-forward, etc.) for controlling playback of the playing media items in the playback group. The control area 220 may include a volume control 228. For example, a user may use a touch input (e.g., touch, drag, release, etc.) by selecting volume handle 230 and sliding the handle along volume control 228 to adjust the playback volume at the playback devices within the playback group.

When a user interacts with the playback control to specify settings for various playback controls of the playback group, the computing device may send the specified settings to the playback group. In some implementations, the playback settings can be sent to a primary playback device in the playback group, and the primary playback device can propagate the playback settings to other playback devices within the playback group. In some implementations, the computing device may send the playback settings directly to each playback device in the playback group. In either case, the playback settings may be sent to the playback device using the non-hijacking (e.g., squelched) control connection described above.

FIG. 3 is a block diagram of an example system 300 for remotely controlling a playback device from a remote control device. For example, the remote control device 310 may correspond to a computing device that presents the graphical user interfaces 100 and 200, as described above. Fig. 3 is used herein to describe how playback device state data and control commands are managed between remote control device 310 and playback device 320.

As used throughout this specification, a remote control device (e.g., remote control device 310) represents a computing device (e.g., a smartphone, a tablet, a laptop, etc.) that establishes a squelched, non-hijacked control connection (e.g., a control channel, a control pipe, etc.) with a playback device (e.g., playback device 320) shown in the figures. However, the remote control device may establish a control connection with the playback device 320 to obtain state information of the playback device 320 and provide control inputs to the playback device 320 while also maintaining a streaming connection with another playback device (not shown). Thus, the remote control device 310 may also be a streaming device (i.e., a master device) with respect to another playback device, as described further below.

As used throughout this specification, a playback device (e.g., playback device 320) represents a computing device (e.g., wireless speaker, television, set-top box, etc.) configured to present audio and/or video to one or more users. The playback device may initiate the media stream through a software application installed on the playback device. The playback device may receive media streams from other computing devices. For example, playback devices may announce (e.g., using wireless signals) that they are capable of receiving and presenting media streams. Other computing devices (e.g., other playback devices, streaming devices, etc.) may detect the announcement and connect to the playback device to stream media to the playback device, as described above with reference to fig. 1. Thus, the playback device may be discovered by other devices in close proximity to the playback device and/or on the same local area network and/or otherwise reachable from the playback device. This is in contrast to other computing devices (e.g., a single user device such as a smartphone or tablet) that may not be discoverable, as described further below. Various devices (e.g., remote control devices, playback devices, streaming devices, etc.) may communicate using various types of networks, including a wide area network, a local area network, Wi-Fi, bluetooth, and/or various peer-to-peer connections (e.g., via bluetooth, Wi-Fi, etc.).

In some implementations, the system 300 includes a remote control device 310 and a playback device 320. In the embodiment of fig. 3, the playback device 320 initiates the media stream that is played by the playback device 320. For example, the playback device 320 may include a media application 322. The media application 322 may be a music application, a video application, or any other type of media software application. The media application 322 may obtain media for playback by the playback device 320 from a local media library on the playback device 320. The media application 322 may obtain media for playback by the playback device 320 from a remote source, such as an internet media service. The media application 322 may cause the playback device 320 to render the media by sending the media stream to the media server 324. For example, the media server 324 may be a software service that manages playback of media items on the playback device 320. Accordingly, the media server 324 can provide an interface to media presentation components (e.g., speakers, displays, etc.) of the playback device 320.

In some implementations, playback device 320 may include a media remote 326. For example, media remote 326 may be a software server or service that allows remote control of media server 324. A remote control device (e.g., remote control device 310) may request playback state information from media remote 326 and send media playback control settings to media remote 326. The media remote control 326 may communicate with the media server 324 to obtain playback state information and/or to provide playback control settings to the media server 324.

In some implementations, the playback device 320 may include a media receiver 328. For example, media receiver 320 provides a network interface and/or a logical interface for receiving media streams and remoting requests from other computing devices. The media sink 328 works with the session manager 330 to route messages to/from connected external devices, such as the remote control device 310. For example, session manager 330 manages network and/or logical communication channels for media connections and control connections of streaming playback device 320. Session manager 330 may maintain a database of channels or connections. For example, when a computing device connects to media receiver 320, session manager 330 may store information identifying the connection type (e.g., streaming/main connection or remote control connection) and an identifier (e.g., token) of the connecting computing device. Since the playback device 320 may have only one primary connection (e.g., an incoming streaming connection), the session manager 330 may store information describing a single primary connection and possibly multiple control connections. The media receiver 328 and/or the session manager 330 may use this connection data to route control messages and/or streaming media to the various devices connected to the playback device 320.

In some implementations, system 300 may include a remote control device 310. For example, a media remote 312 (e.g., a software service) on remote control device 310 may be configured to present graphical user interfaces 100 and/or 200 described above on a display of remote control device 310. To obtain the playback state information needed to generate GUI100 and GUI200, remote control device 310 must be connected to a proximate playback device that includes playback device 320. For example, remote control device 310 may detect an announcement message broadcast by playback device 320 indicating that playback device 320 is available to receive streaming playback. Based on the received announcement, media remote 312 may request status information from playback device 320. For example, the media remote 312 may send a message to the media server 314 on the remote control device 310 indicating that the media server 314 should request status information from the playback device 320. The media server 314 may send a message to the media receiver 328 on the playback device 320 requesting the playback status. The message may indicate that the request is a control request (e.g., as opposed to a streaming request) such that the request does not hijack the streaming media communication channel and such that the playback device 320 stops playing the currently playing media. The message may include a token or identifier that identifies the requesting remote control device 310.

In some implementations, media receiver 328 may cause session manager 330 to store communication channel information so that subsequent messages may be routed to remote control device 310. For example, the communication channel information may include a channel type (e.g., control, streaming) and a channel identifier (e.g., an identifier associated with the requesting device). After the media receiver 328 receives the playback status request, the media receiver 328 may send the request to the media remote control 326. Media remote control 326 may obtain playback state information from media server 324 and send the playback state information to media receiver 328. For example, the playback state information may include descriptive information about the media item being played (e.g., title, artwork, artist, length, etc.). The playback state information may indicate a current position or location within the media item being played by the playback device 320. The playback state information may include information describing the capabilities and/or features of the media application 322 and/or the playback device 320 so that the media remote control 312 may generate and present appropriate user interface controls. The media receiver 328 may then transmit the playback state information to the media server 314 on the remote control device 314 over the previously established control communication channel. The media server 314 may send playback state information to the media remote control 312. The media remote 312 may use the playback state information received from the playback device 320 to generate the GUI100 and/or the GUI 200.

In some implementations, after generating GUI100 and/or GUI200, media remote 312 on remote control device 310 may send a playback command to playback device 310. For example, a user of the remote control device may select a playback control (e.g., volume, fast forward, rewind, skip, pause, etc.) from one of the graphical user interfaces generated by media remote control 312. The media remote control 312 may detect the selection of the control and send a corresponding control command to the media server 314. The media server 314 may send control commands to the media receiver 328, and the media receiver may send control commands to the media remote 326. Media remote 326 may then cause media server 324 to execute the indicated media control commands (e.g., adjust volume, play, pause, fast forward, etc.). After executing the command, media remote 326 may send playback status information back to media remote 312 on remote control device 310, as described above, so that media remote 312 may update its graphical user interface.

Fig. 4 is a block diagram of an example system 400 for remotely controlling a playback group from a remote control device. For example, system 400 may be similar to system 300. However, in system 400, playback device 320 not only plays the media item (e.g., through local speakers), but also streams the media item to playback device 410 and playback device 420 for synchronized playback. Thus, playback device 320, playback device 410, and playback device 420 form a group of playback devices (e.g., dynamic or persistent). Depending on the configuration, the group may be dynamic or persistent, as described further below. Playback devices 410 and/or 420 may be configured similarly to playback device 320. The playback devices 410 and/or 420 may have the same characteristics (e.g., all wireless speakers) or may have different characteristics (e.g., set-top box and wireless speakers).

In some implementations, the remote control device 310 may connect to and receive playback state information from the playback device 410 and/or the playback device 420 in a manner similar to the playback device 320. For example, although all components of playback device 320 are not represented in playback device 410 and playback device 420, these components exist within these playback devices. Thus, remote control device 310 may establish a squelch control channel to media receiver 412 on playback device 410 and media receiver 422 on playback device 420 and receive playback status information using similar mechanisms as described above for playback device 320. Because the playback device 320 is a device that streams media to the playback device 410 and the playback device 420, the playback device 320 will establish a streaming communication channel (e.g., a primary channel) with the media receiver 412 on the playback device 410 and the media receiver 422 on the playback device 420.

In some implementations, the remote control device 310 will only send control commands to the playback device 320 (e.g., primary device, master device, etc.). For example, while remote control device 310 establishes a network connection with all three playback devices, the remote control device only sends information requests and commands to the primary or master playback device (e.g., discoverable streaming device) that controls playback of the media item. Remote control device 310 may determine the primary playback device based on group member attributes provided to remote control device 310 by each playback device. For example, when remote control device 310 establishes a network connection with each playback device, group member attributes may be sent from each playback device to remote control device 310.

The group member attributes may include a group identifier. The group identifier may be assigned to the playback device by the primary playback device. For example, each playback device 410, 420, and 320 may initially be considered one of a group, where each playback device is the primary device in the group, and each device has a different group identifier. When the user commands the playback device 320 to transmit media streams to the playback device 410 and the playback device 420, the playback device 320 may push its group identifier to the playback devices 410 and 420 so that they also have the same group identifier.

The group member attributes may include a group leader flag. For example, if the playback device (e.g., playback device 320) is a group leader (e.g., a primary playback device), the group leader flag will be set to true. If the playback device (e.g., playback device 410) is not the group leader, the group leader flag will be set to false. Thus, the media remote 312 on the remote control device 310 can quickly identify the primary playback device based on the group leader mark received from the playback device.

The group member attributes may include a flag indicating whether the group leader can be discovered. For example, some streaming devices are discoverable (e.g., wireless speakers, set-top boxes, televisions, etc.), and some streaming devices are not discoverable (e.g., single user devices, smart phones, tablets, etc.). The group leader discoverable flag indicates whether the group leader (e.g., primary playback device, streaming device, etc.) can be reached directly by remote control device 310. If the streaming device is not discoverable, one of the forwarding mechanisms described below will be used to deliver messages, requests, or commands to the non-discoverable streaming device.

In some implementations, the group member attributes can include a flag indicating whether the playback device supports relaying messages to non-discoverable streaming devices (e.g., primary or primary). If the flag is set to true, the playback device may be used to forward the message from remote control device 310 to the non-discoverable streaming device, as described below. In describing persistent groups, additional group member attributes may be described below.

In some implementations, media remote 312 may present a set of playback devices as a single entity on GUI100 and/or GUI200, as described above. For example, when remote control device 310 receives group member attributes from playback device 320, playback device 410, and playback device 420, media remote 312 may determine that all three playback devices have the same group identifier and thus belong to the same playback group. Thus, instead of presenting three different playback devices on GUI100 and/or GUI200, media remote 312 would present a single playback group graphical element (e.g., graphical element 130, graphical element 140) to represent all three devices.

When the user provides input to a playback control on GUI200 to adjust media playback (e.g., volume, play, pause, skip, etc.) for a playback group, media remote control 312 will send a command to the primary playback device (e.g., playback device 320) to adjust media playback, as indicated by the playback group member properties. Upon receiving the command, the primary playback device 320 will adjust media playback for all members of the playback group. For example, the primary playback device 320 will cause the secondary playback devices 410 and 420 to adjust playback in accordance with commands received from the media remote control 312.

Fig. 3 and 4 above describe a playback and remote control architecture in which a primary playback device (e.g., a streaming device, a master device, etc.) is directly reachable through a remote control device 310. For example, the playback device 320 is reachable because it advertises its presence and the ability to accept control and/or streaming connections. Fig. 5 below describes a playback and remote control architecture in which a primary playback device (e.g., streaming device, master device, etc.) is not directly reachable through remote control device 310. In this case, remote control device 310 relies on the playback device (e.g., playback device 320) to relay or forward requests and commands to the primary playback device using the streaming connection established by the primary playback device.

Fig. 5 is a block diagram of an example system 500 for remotely controlling a non-discoverable playback device from a remote control device. As described above, a non-discoverable playback device may be a computing device that does not advertise its presence and in which a connection with a non-discoverable device cannot be initiated by another device.

In some implementations, system 500 may include remote control device 310, playback device 320, and/or streaming device 510. For example, streaming device 510 may be a non-discoverable device. Streaming device 510 may be a computing device having features similar to remote control device 310. For example, the streaming device 510 may be a streaming device that streams media to the playback device 320 and a remote control device that connects to other playback devices (not shown).

In some implementations, the streaming device 510 can include a media application 512. For example, the media application 512 may be an application configured to play media from a local media library on the streaming device 510 or from a network resource (e.g., a network media service). A user of the streaming device 510 may provide input to the media application 512 to cause the media application 512 to stream media to the playback device 320. The media application 512 may send a request to the media server 514 to establish a streaming connection (e.g., a primary connection) with the playback device 320. The media server 514 may establish the streaming connection by sending a request to establish the streaming connection to the media receiver 328 on the playback device 320. If another streaming device has already streamed media to the playback device 320, the media receiver 328 may terminate the existing streaming connection and establish a streaming connection with the streaming device 510. Thus, the streaming device 510 effectively hijacks the streaming connection to the playback device 320. After establishing the streaming connection (represented by the arrowed thick line), the session manager 330 may store connection information indicating the type of connection (e.g., streaming connection or primary connection) and an identifier for the connection (e.g., a device identifier for the streaming device 510).

After establishing the streaming connection to the media receiver 328, the media application 512 may send media data to the media server 514, and the media server 514 may stream the media data (e.g., songs, movies, television programs, podcasts, etc.) to the media receiver 328. The media receiver 328 may send the streaming media data to the media server 324, and the media server 324 may cause the media data to be rendered by the playback device 320 (e.g., via speakers, a display, etc.). In some implementations, if the playback device 320 is part of a playback group, the playback device 320 can send the streaming media to other playback devices in the group for playback. In some implementations, if the playback device 320 is part of a playback group, the streaming device 510 can send the streaming media directly to other playback devices in the group for playback. The streaming device 510 may determine playback devices that are members of the same group based on the group attribute information described above.

In some implementations, the playback device 320 relays messages from the remote control device 310 to the streaming device 510. As described above, the remote control device 310 cannot send control messages directly to the streaming device 510 since the streaming device 510 is not discoverable. To obtain playback state information and send playback commands to streaming device 510, remote control device 310 may send requests and commands for a master device (e.g., streaming device 510) to playback device 320, and playback device 320 may forward the requests and commands to streaming device 510.

As described above, media remote 312 may receive group attribute information from playback device 320. If the group attribute indicates that the group leader is non-discoverable and the playback device 320 supports relaying the request to the group leader (e.g., the streaming device 510), the media remote control 312 can determine that remote control requests and commands should be routed to the streaming device 510 through the playback device 320.

In some implementations, the media remote 312 on the remote control device 310 may send a request to the media server 314 to obtain playback state information for the playback group corresponding to the playback device 320. The media receiver 328 can determine that the request should be forwarded to the streaming device 510 because the playback device 320 is not a group leader (e.g., a master device). The media receiver 328 may send a request for playback state information to the media server 514 on the streaming device 510 along with an identifier for the control channel established for the remote control device 310. The media server 514 may send a playback status request to the media remote 516 on the streaming device 510. Media remote 516 may determine the playback state information and send the playback state information to media receiver 328 on playback device 320 along with an identifier for the control channel associated with remote control device 310. The media receiver 328 may use the identifier to determine which control channel managed by the session manager 330 to use to send playback state information to the remote control device 310. After determining the correct control channel, the media receiver 328 may send playback state information to the media server 314 on the remote control device 310. Media server 314 may send the playback status information to media remote 312 on remote control device 310 so that media remote 312 may generate and present GUI100 and/or GUI200 with the status information provided by streaming device 510.

In some implementations, media playback control commands can be routed from remote control device 310 to streaming device 510 through playback device 320 in a manner similar to playback state information requests. When media remote 516 on streaming device 510 receives a playback control command, media remote 516 may execute the command locally (e.g., on streaming device 510) and cause all playback devices to be streamed to (e.g., playback device 320) to execute the same command. However, in some cases, media playback control commands forwarded by the playback device 320 may be intercepted and executed at the playback device 320. For example, instead of waiting to receive a "pause" command from streaming device 510 routed through playback device 320, playback device 320 may intercept the pause command and execute the pause command when the pause command is routed from remote control device 310 to streaming device 510 through playback device 320. Thus, the playback device 320 may stop playing the currently playing media faster than the playback device 320 waits to receive a pause command from the streaming device 510.

Fig. 6 is a block diagram of an example system 600 for managing groups of dynamic playback devices. In some implementations, the system 600 may be configured similarly to the systems 300, 400, and 500 described above. For example, system 600 may include remote control device 310 and playback devices 610, 620, and/or 630. The playback devices 610, 620, and/or 630 may be configured similarly to the playback device 320 described above. For example, playback devices 610, 620, and/or 630 may advertise their availability using wired or wireless network broadcasts. The playback devices 610, 620, and/or 630 may advertise the services they provide, such as the streaming media receiver and message relay services described above.

Upon receiving the announcement message, remote control device 310 may establish a network connection (e.g., wired, wireless, peer-to-peer, Wi-Fi, etc.) with each of playback devices 610, 620, and/or 630. These network connections may be maintained (e.g., persistent) even though the type of logical connection (e.g., primary connection, control connection, streaming connection, etc.) and/or the routing of data to or through these playback devices may change. Maintaining a persistent network connection with each of these playback devices allows remote control device 310 to adapt to dynamically changing network topologies (e.g., changing playback groups) without having to incur the expense (e.g., time expense and processing expense) of tearing down and re-establishing a network connection, which may be required if remote control device 310 only established a network connection with the primary playback devices in the group.

In some implementations, the remote control device 310 may store and maintain a pool of playback devices 602. For example, the device pool 310 may be a database that stores information describing or identifying each network connection to each playback device (e.g., playback devices 610, 620, 630). The device pool 310 may store all playback group attributes (e.g., dynamic and/or persistent group attributes) reported by each playback device. For example, and as briefly described above, each playback device may report (e.g., broadcast, announce, etc.) its playback group attributes to remote control device 310 when a network connection is established with remote control device 310 and/or whenever these playback group attributes change.

In some implementations, the playback group attribute can include a group identifier that identifies the dynamic playback group or groups to which the playback device belongs. The playback group attribute may include a group leader flag that, when set to true, indicates that the reporting playback device is the leader or primary device of the dynamic playback group. The playback group attribute may include a flag (e.g., true, false) indicating whether the dynamic playback group leader is discoverable, as described above. The playback group properties may include the following flags: which, when set to true, indicates that the reporting playback device supports relaying messages to/from the non-discoverable group leader (e.g., master device, streaming device, single user device, etc.).

In some implementations, the playback group property can include a persistent group property. For example, persistent group properties may include a persistent group identifier that may be used to identify playback devices (e.g., stereo playback device pairs, surround playback device groups) that belong to the same persistent group. In some implementations, playback devices with the same persistent group identifier can be treated as if they were a single device, as described above. The persistent group attribute may include a persistent group leader flag indicating whether the reporting playback device is a leader or a primary device within the persistent group. The persistent group attribute may include a group member reachable flag that indicates whether all other persistent group members are reachable. In the case of a stereo playback device pair (e.g., a persistent group of two devices), when the group member reachable flag is set to false, this indicates that the other playback device in the persistent group is unreachable. In the case of a group of surround-sound speakers (e.g., a persistent group of more than two playback devices), when the group members reachable flag is set to false, this indicates that at least one other playback device in the persistent group is unreachable. The reachable flag may affect streaming media and/or control message routing, as described further below.

After collecting the group attributes from each connected playback device (e.g., playback devices 610, 620, 630, etc.), the media remote 312 on the remote control device 310 may determine how to group the reporting playback devices based on the playback group attributes stored in the device pool 602. For example, the playback device 610 may report that the playback group identifier value is one (1), the group leader flag value is true, and the group leader is a discoverable flag value of true, among other group attributes. The playback device 620 may report that the playback group identifier value is one (1), the group leader flag value is false, and the group leader is a discoverable flag value of true, among other group attributes. The playback device 630 may report that the playback group identifier value is two (2), the group leader flag value is true, and the group leader is a discoverable flag value of true, among other group attributes.

Based on these reported group attributes, media remote control 312 may determine that playback device 610 and playback device 620 are members of the same playback group 640 because they reported the same playback group identifier (e.g., playback group identifier of 1). The media remote 312 may also determine that the playback device 610 is a group leader based on the fact that the playback device 610 reported that the playback group leader flag value is true. Accordingly, a logical control channel can be established between the playback device 610 and the remote control device 310 such that playback states and playback control requests of the playback group 640 can be directed to the playback device 610 because the playback device 610 is the leader or primary device in the group 640. Media remote 312 may also determine that the playback status and control request may be routed directly to playback device 610, e.g., rather than being forwarded or relayed through another device, because the playback group leader reported by playback device 610 is true for the value of the discoverable flag.

Similarly, the media remote control 312 may itself determine that the playback device 630 is in the group 650 because the playback device 630 is the playback device that uniquely reports a playback group identifier having a value of two (2). The media remote 312 may determine that the playback device 630 is the group leader of the playback group 650 based on the fact that the playback device 610 reported that the playback group leader flag value is true. Accordingly, a logical control channel can be established between the playback device 630 and the remote control device 310 such that playback states and playback control requests of the playback group 650 can be directed to the playback device 630 because the playback device 630 is the leader or primary device in the group 650. The media remote control 312 may also determine that the playback status and control request may be routed directly to the playback device 630, e.g., rather than being forwarded or relayed through another device, because the playback group leader reported by the playback device 610 is true for the value of the discoverable flag.

As described above, a single playback device may belong to multiple dynamic playback groups. For example, playback device 610 and playback device 620 may report a group attribute indicating that they belong to the same dynamic playback group 640. Playback device 620 and playback device 630 may report a group attribute indicating that they belong to the same dynamic playback group different from group 640. Thus, the playback device 620 may belong to two different playback dynamic groups and report the group attributes of the two different playback dynamic groups.

After media remote control 312 determines a playback group based on the reported playback group attributes, media remote control 312 may generate GUI100 and/or GUI200 based on the determined playback group. The user of remote control device 310 may then use the user interface features described above with respect to fig. 1 and 2 to view playback state information associated with the playback group and/or to control playback of the media being played by the playback group.

In some implementations, the playback groups can be dynamically reorganized. For example, a user may provide input to remote control device 310, a playback device (e.g., playback devices 610, 620, or 630), and/or streaming device 510 to combine or split the playback devices into new or different groups. For example, a user may provide an input to the playback device 630 indicating that the playback device 630 should transmit the media stream to the playback group 640 (or the respective playback devices 610 and 620). In response to the input, the playback device 630 can push its playback group identifier and group leader discoverable indicia to the playback devices 610 and 620. The playback devices 610 and 620 may change their playback group identifiers to match the group identifier of the playback device 630. The playback devices 610 and 620 may change their playback group leader discoverable indicia to match the indicia provided by the playback device 630. The playback device 610, which was previously the group leader of the playback group 640, may change its playback group leader flag to false to indicate that it is no longer the group leader.

After changing these playback group properties, playback devices 610, 620, and/or 630 may report the playback properties to remote control device 312, and remote control device 310 may store the playback group properties in device pool 602, as described above. After receiving updated playback group attributes from playback devices 610, 620, and/or 630 at remote control device 310, media remote 312 may determine, based on the reported playback group attributes, that playback devices 610, 620, and/or 630 now belong to the same playback group (e.g., playback group 650) and that playback device 630 is the primary playback device in the playback group. Media remote 312 may then reconfigure GUI100 and/or GUI200 to represent the new playback group topology and send the playback state information request and/or playback command for playback group 650 to the primary playback device, playback device 630. Thus, the playback group can be dynamically configured and reconfigured, and the media remote can dynamically configure and reconfigure the GUI required to remotely control the playback group.

In some implementations, the remote control device 310 may be a streaming device similar to the streaming device 510 described above. A user of remote control device 310 may provide input to remote control device 310 to transfer the media stream to playback group 650 (now comprising playback devices 610, 620, and 630). In some implementations, remote control device 310 may stream media to only the primary playback device (e.g., playback device 630) in playback group 650, and the primary playback device may stream the received media to the other playback devices in the group. In some implementations, remote control device 310 may stream media directly to each playback device in playback group 650 and avoid the delay and connection issues involved with forwarding the media stream from the primary playback device to the other playback devices in the playback group.

FIG. 7 is a block diagram of an example system 700 for managing persistent playback groups. For example, system 700 may correspond to system 600 described above. System 700 may include remote control device 310 and playback devices 710, 720, and/or 730. As described above, the remote control device 310 may establish a network connection with each of the playback devices 710, 720, and 730. Each playback device may report its playback group attributes, including the persistent group attributes, to remote control device 310. Remote control device 310 may store playback group attributes, network connection identifiers, control channel identifiers, and/or streaming identifiers in device pool 602.

In some implementations, the playback group attributes reported by the playback devices 710, 720, and/or 730 may include persistent group attributes. For example, a user may configure two or more devices as a persistent group. For example, a user may configure a persistent group to operate as a stereo smart speaker pair. The user may configure the persistent group to operate as a surround sound system (e.g., 5.1 surround sound).

In some implementations, the persistent group property can include a persistent group identifier. Similar to the dynamic playback group, playback devices that are members of the persistent playback group may be assigned the same persistent group identifier. For example, initially, the individual playback devices may each have a unique persistent group identifier. When the playback devices are combined into a persistent playback group, the playback group identifier of one of the playback devices (e.g., the playback device with which the user is interacting to create the persistent playback group) may be pushed to the other playback devices in the persistent playback group such that all of the playback devices in the persistent playback group have the same persistent group identifier. If the user provides input to the playback device 710 with persistent group identifier of 10 to create a persistent playback group with the playback device 720, the playback device 710 may send the persistent group identifier of 10 to the playback device 720 and the playback device 720 may change its persistent group identifier to 10. Thus, playback device 710 and playback device 720 may be configured as stereo pairs (e.g., speaker pairs) and may both be assigned a persistent group identifier of 10. When media remote control 312 analyzes the data in device pool 602, media remote control 312 may determine that playback device 710 and playback device 720 have the same persistent group identifier and may determine that playback device 710 and playback device 720 form persistent group 740. Media remote 312 may then present persistent group 740 on GUI100 and/or GUI200 as if persistent group 740 was a single device.

In some implementations, the persistent group attribute can include a flag indicating whether the reporting playback device is a persistent group leader. Media remote control 312 can use the leader marker to determine which playback device in the persistent group sent a control request (e.g., a request for information, a control command, etc.). For example, media telematics requests and/or commands are directed to the leader (e.g., primary device, master device, etc.) in each persistent group even though remote control device 310 maintains a network connection to each playback device.

In some implementations, the persistent group attribute may include a group member being reachable flag indicating whether the reporting playback device is reachable by other playback devices in the persistent group. For example, a member of the persistent group may monitor the availability of other members of the persistent group. For example, the playback device 710 may establish a control connection with the playback device 720. If the playback device 720 is unplugged, moved, or otherwise unavailable, the playback device 710 will determine that the playback device 720 is unreachable and set its group member reachable flag to false. After changing the persistent group property (or any group property), playback device 710 will report the updated group property to remote control device 310. Media remote 312 may then update its GUI to reflect the change in status of the persistent playback group.

In some implementations, the persistent group may be a playback device within the dynamic playback group. For example, persistent group 740 may be added to dynamic playback group 750, where playback device 730 is the primary device within the dynamic playback group. When the persistent group 740 is added to the dynamic group 750, the dynamic group identifier of the playback device 730 may be pushed to the playback devices 710 and 720, as described above with reference to fig. 6. However, playback devices 710 and 720 will have a persistent group identifier (e.g., identifier 10) that is different from playback device 730. Thus, playback device 710 and playback device 720 will be considered persistent group 740 within dynamic group 750.

This difference between the persistent group and the dynamic group may cause each playback device to present the media items differently. For example, a media item (e.g., a music track, a movie, etc.) may be composed of different audio/video channels (e.g., left, right, front left, front center, front right, back left, subwoofer, etc.). When combined into a persistent group, the playback device may only present one channel. For example, in stereo pair persistent group 740, playback device 710 may be configured to play a right audio channel of a music media item, while playback device 720 may be configured to play a left audio channel of the same music media item, thereby creating stereo playback. Similarly, in a 5.1 surround sound persistent group configuration having six playback devices, each playback device can be configured to present one of six audio channels (e.g., left front, front center, right front, right back, left back, subwoofer, etc.) associated with the movie media item soundtrack. This is different from how the playback device 730 would behave, as the playback device 730 is not part of the persistent group. When the same music media item is streamed to the playback device 730, the playback device 730 will present all of the audio channels of the music media item.

In some implementations, when members of the persistent group are unreachable, the remaining members revert to non-persistent group behavior. For example, in stereo pair persistent group 740, playback device 710 may be configured to play a right audio channel of a music media item, while playback device 720 may be configured to play a left audio channel of the same music media item, thereby creating stereo playback. If the playback device 720 becomes unreachable, the playback device 710 can revert to the non-persistent group behavior and play all audio channels (e.g., right and left audio channels) of the music media item. When the playback device 720 becomes reachable again, the playback device 710 and the playback device 720 may dynamically return to playing the right and left audio channels as a stereo pair persistent group. Playback devices in the persistent playback group corresponding to the 5.1 surround sound configuration may behave similarly to a stereo pair persistent group.

In some implementations, the persistent group may include a streaming device (e.g., streaming device 510). For example, a persistent group may include a streaming device 510 (e.g., a set-top box, a streaming media player, etc.) and one or more playback devices. The streaming device 510 may be configured as the primary playback device in the persistent group. In some implementations, the playback devices may correspond to persistent playback groups (e.g., stereo pairs, 5.1 surround sound, etc.). Thus, the persistent group may be configured to emulate the functionality of a wired home entertainment system that includes video (e.g., set-top box, television, etc.) and stereo or surround sound audio output. Further, by configuring the streaming device 510 and the playback device into a persistent group, audio output from the streaming device 510 will be routed to the playback device whenever any media item presented by the streaming device 510 provides audio output. Thus, the playback devices in the persistent group can play back the media item as if they were a single device.

In some implementations, the playback devices within the persistent group are not detachable. For example, if both playback device 710 and playback device 720 are reachable and are functioning properly, both playback device 710 and playback device 720 will play back the media item together or not at all. For example, if the playback device 710 is playing a music media item, the playback device 720 will play the same music media item. If the playback device 710 receives a command to pause playback, playback on the playback device 720 will also pause. If the connection to the playback device 720 is hijacked (e.g., the streaming device begins streaming media to the playback device 720), the connection to the playback device 710 will also be hijacked. This behavior of the persistent group ensures that the playback devices in the persistent group act as a single playback device.

In some implementations, older versions of remote control device 310 may not be able to determine dynamic and/or persistent groups based on group properties received from playback devices. Thus, instead of presenting one graphical element on GUI100 and/or GUI200 for each playback group (e.g., dynamic or persistent), an older remote control device may represent each playback device individually on GUI100 and/or GUI200, as described above. To avoid membership of an individual presentation group, the playback devices may be configured such that only a primary playback device (e.g., group leader, primary device, master device, etc.) in the playback group advertises its availability and connects to the remote control device. In another variation of the method, the primary playback device may be configured to announce to the older remote control device using an announce message that the older device is configured to receive, while the secondary playback devices in the playback group announce to the new remote control device (e.g., remote control device 310) using an announce message that only the newer remote control device is configured to receive. Thus, newer remote control devices may be configured to receive old and new announcement messages and generate and present playback groups based on the playback attributes they receive, while older remote control devices will only present primary playback devices in each playback group that can serve as proxies for the playback groups when presenting GUI100 and GUI200, as described above.

FIG. 8 is a block diagram of a system 800 for streaming media items to persistent groups. In some implementations, the streaming device may interact with the persistent group in various ways. For example, system 800 may correspond to any of the systems described above. System 800 may include streaming device 802 (e.g., corresponding to streaming device 510) and/or playback devices 810 and 820 (e.g., corresponding to playback device 320). Streaming device 802 may have all of the same capabilities of remote control device 310 as described above and thus be able to determine or detect dynamic and persistent playback groups.

In the example of fig. 8, playback devices 810 and 820 may be configured as a persistent group 830 (e.g., stereo pair). Based on its software and/or hardware configuration, the streaming device 802 may be capable of streaming to only one playback device, or the streaming device 802 may be capable of streaming to multiple playback devices simultaneously. In the example of fig. 8, the streaming device 802 is capable of streaming media items to multiple playback devices simultaneously. Thus, when a user of the streaming device 802 provides input indicating that the streaming device 802 should stream a media item to the persistent group 830, the cluster manager 804 of the streaming device 802 may establish and manage a streaming connection to both the playback device 810 and the playback device 820. When a streaming connection is established, cluster manager 812 and/or cluster manager 822 may determine (e.g., based on software or hardware version information provided by streaming device 802) that streaming device 802 is capable of streaming to multiple playback devices simultaneously and will not attempt to forward media streams to other playback devices in persistent group 830.

As described above, when playback devices 810 and 820 are configured as a stereo pair, one playback device (e.g., playback device 810) may be configured to present a left audio channel of a streaming media item and the other playback device (e.g., playback device 820) may be configured to present a right audio channel of the streaming media item. If the playback devices 810 in the persistent group 830 become unreachable (e.g., unplugged, out of range, etc.), the playback device 820 may detect the absence of the playback device 810 and automatically play the left and right audio channels. When the playback device 810 becomes reachable again, the playback device 820 can detect that the playback device 810 is reachable and send a message to the streaming device 802 to cause the streaming device 802 to reconnect to the playback device 810. The playback device 820 can then automatically resume rendering only the right audio channel, and the playback device 810 can resume playing the left audio channel of the media item streamed from the streaming device 802.

FIG. 9 is a block diagram of a system 900 for streaming media items to persistent groups. In some implementations, the streaming device may interact with the persistent group in various ways. For example, system 900 may correspond to any of the systems described above. System 900 may include streaming device 902 (e.g., configured similar to streaming device 510) and/or playback devices 810 and 820 (e.g., configured similar to playback device 320). Streaming device 802 may have all of the same capabilities of remote control device 310 as described above and thus be able to determine or detect dynamic and persistent playback groups.

In the example of fig. 9, playback devices 810 and 820 may be configured as a persistent group 830 (e.g., stereo pair). Based on its software and/or hardware configuration, the streaming device 902 may be capable of streaming to only one playback device, or the streaming device 902 may be capable of streaming to multiple playback devices simultaneously. In the example of fig. 9, the streaming device 902 is capable of streaming media items to only one playback device at a time. Thus, when the user of the streaming device 902 provides input indicating that the streaming device 902 should stream the media item to the persistent group 830, the streaming device 902 will establish a streaming connection to the leader or primary playback device in the persistent group 830, i.e., the playback device 820. When a streaming connection is established, the cluster manager 822 may determine (e.g., based on software or hardware version information provided by the streaming device 902) that the streaming device 902 cannot simultaneously stream to multiple playback devices and may forward the media stream to other playback devices (e.g., playback device 810) in the persistent group 830.

As described above, when playback devices 810 and 820 are configured as a stereo pair, one playback device (e.g., playback device 810) may be configured to present a left audio channel of a streaming media item and the other playback device (e.g., playback device 820) may be configured to present a right audio channel of the streaming media item. If the playback device 810 in the persistent group 830 becomes unreachable (e.g., unplugged, out of range, etc.), the playback device 820 may detect the absence of the playback device 810, will stop forwarding the media stream to the playback device 810, and will automatically begin playing the left and right audio channels. When the playback device 810 becomes reachable again, the playback device 820 can detect that the playback device 810 is reachable and resume forwarding the media stream to the playback device 810. The playback device 820 can then automatically resume rendering only the right audio channel, and the playback device 810 can resume playing the left audio channel of the media item streamed from the streaming device 902.

Fig. 10 is a block diagram of a system 1000 for presenting media items streamed from a primary playback device within a persistent group. For example, system 1000 may correspond to any of the systems described above. System 1000 may include playback devices 810 and 820 (e.g., configured similar to playback device 320). Playback devices 810 and/or 820 may have all or some of the same capabilities of remote control device 310 as described above, and thus be capable of determining and/or detecting dynamic and persistent playback groups.

In the example of fig. 10, playback devices 810 and 820 may be configured as persistent group 830 (e.g., stereo pair, 5.1 surround sound configuration, etc.). When a user provides an input (e.g., a voice input, a touch input, etc.) to the playback device 810 to cause the playback device 810 to begin playing a media item (e.g., from an internal media application, the media application 322, etc.), the playback device 810 may become the primary playback device in the persistent group 830. The cluster manager 812 on the playback device 810 may then control or manage the streaming connection to the playback devices (e.g., playback devices 820) within the persistent group and/or manage the streaming of the media item to the playback devices 820.

In some implementations, within the persistent group, the playback device that receives the user input becomes the primary playback device within the persistent group. Since the cluster manager is responsible for managing the devices within the persistent group, the cluster manager only runs on the primary device. Thus, the cluster manager may run on a different playback device depending on which playback device in the persistent group the user chooses to interact with. The cluster manager is configured such that when the primary playback device is playing a media item, the cluster manager causes the other playback devices in the persistent group to also play the media item as long as the other playback devices are available or reachable.

As described above, when playback devices 810 and 820 are configured as a stereo pair, one playback device (e.g., playback device 810) may be configured to present a left audio channel of a streaming media item and the other playback device (e.g., playback device 820) may be configured to present a right audio channel of the streaming media item. If a playback device 810 in the persistent group 830 becomes unreachable (e.g., unplugged, out of range, etc.), the cluster manager 822 on the playback device 820 may detect that the playback device 810 is not present, will cause the playback device 820 to stop streaming media to the playback device 810, and will cause the playback device 810 to automatically begin playing the left and right audio channels. When the playback device 810 becomes reachable again, the cluster manager 820 on the playback device 822 can detect that the playback device 810 is reachable and resume streaming the media stream to the playback device 810. The playback device 820 can then automatically resume rendering only the right audio channel, and the playback device 810 can resume playing the left audio channel of the media item streamed from the playback device 820.

Fig. 11 is a block diagram of an example system 1100 for playback resumption between playback devices in a synchronized playback group. For example, system 1100 may correspond to any of the systems described above. System 1100 can include playback devices 810 and 820 (e.g., configured similar to playback device 320). Playback devices 810 and/or 820 may have all or some of the same capabilities of remote control device 310 as described above, and thus be capable of determining and/or detecting dynamic and persistent playback groups. System 1100 may include a streaming device 1102. The streaming device 1102 may correspond to the streaming device 510 described above. The streaming device 1102 may correspond to a playback device, such as the playback device 320, 810, or 820 described above. The media items may be streamed from the streaming device 510 to the playback group 830 using any of the mechanisms described above.

In some implementations, the streaming device 1102 can synchronize playback recovery between playback devices. For example, when streaming media to playback devices 810 and 820, streaming device 1102 may send the media data to the playback device faster than the playback device can play the media data. Accordingly, each playback device 810 and 820 can store media data in the respective buffers 1110 and 1120 as the media data is received and render the media data according to a defined timeline or speed to synchronize audio and/or video output from the playback devices 810 and 820.

When a user provides input (e.g., touch, voice, etc.) to the streaming device 1102 to pause playback of the streaming media item, the streaming device 1102 may send a command to each of the playback devices 810 and 820 to stop playback of the media data. However, due to network delay issues or other reasons for the delay in receiving the stop command, the playback device 810 may stop playback of the media item at the media sample corresponding to location 1112 in the buffer 1110, and the playback device 820 may stop playback of the media item at the media sample corresponding to location 1122 in the buffer 1120. For example, position 1112 may correspond to a media sample at time 1:00 (e.g., one minute) into the media item, while position 1122 may correspond to a media sample at 1:05 into the media item. Since the played media samples are removed from the buffer, the playback device 820 does not have the media samples needed to resume playback from the location 1112 (e.g., time index 1: 00). Thus, if playback is resumed from position 1112, the playback device 820 will be muted until the playback device 810 reaches position 1122 (e.g., time index 1: 05).

To avoid the situation where the playback devices 810 in the playback group 830 play when the playback devices 820 in the playback group 830 are silent, playback can resume from locations in the buffers 1110 and 1120 where the playback devices 810 and 820 both have media samples available. To accomplish this, each playback device 810 and 820 may report the location within its respective buffer 1110 and 1120 at which they actually stopped playback in response to receiving a pause command from the streaming device 1102. In other words, each playback device 810 and 820 may report their first available media sample in their respective buffers 1110 and 1120. For example, the playback device 810 may send an identifier (e.g., a time index) of the media sample at location 1112 in the buffer 1110 to the streaming device 1102. Playback device 820 may send an identifier (e.g., a time index) of the media sample at location 1122 in buffer 1120 to streaming device 1102.

In some implementations, the streaming device can generate a resume playback command that includes a time index for anchoring the playback timeline and a network time, and a time index for playing audible sound, such that playback of the media item at each playback device 810 and 830 is synchronized. For example, the anchor time index may be used to identify media item samples in the media buffers 1110 and 1120. The anchor time index may be selected such that it occurs at or after the latest (e.g., largest) time index reported by each playback device in the playback group 830. Continuing with the example above, since playback device 820 reported the time index of the last played sample of 1:05 (e.g., corresponding to location 1122) and playback device 810 reported the time index of the last played sample of 1:00 (e.g., corresponding to location 1112), streaming device 1102 may select an anchor sample time index of 1:05 or later.

The streaming device 1102 may also select an anchor network time for playback of the timeline. For example, when the streaming device 1102 receives a user input indicating that the user wishes to resume playback, the streaming device 1102 may select a network time that is close to the current time.

The streaming device 1102 may also select a presentation sample time index for initiating audible (and/or visual) playback of the media item. For example, if the streaming device 1102 has determined that the anchor sample time index is 1:10 at network time "T," the playback timeline for the media item may begin at sample time index 1:10 at network time T. However, audible and/or visual playback of the media item need not occur until a later time (e.g., at time index 1:10) specified by the determined presentation sample time index. When the streaming device 1102 sends a command to the playback devices 810 and 820 to resume playback and specifies an anchor sample time index of 1:10 and an anchor network time "T" with a presentation sample time index of 1:15, each playback device 810 and 820 may then begin its respective playback timeline at sample index 1:10 at network time "T" (e.g., buffer location 1114/1124) and delay presenting any audio or video output until sample time index 1:15 (e.g., buffer location 1116/1126). This allows the devices to synchronize their playback timelines and also simultaneously start (resume) human perceptible playback. By specifying the anchor sample time index, the anchor network time, and the presentation sample time index, the streaming device 1102 can ensure that the two playback devices 810 and 820 resume playback at the same time.

Fig. 12 is a block diagram of an example system 1200 for automatically pairing a user device with a playback device. For example, system 1200 may correspond to any of the systems described above. Since a user device (e.g., streaming device, remote control device, etc.) may connect to a playback device through a peer-to-peer connection (e.g., bluetooth, peer-to-peer Wi-Fi, etc.), the user device typically needs to go through a pairing process in order to connect the playback device. The pairing process typically requires that each user device be connected to a playback device and that the user enter a code or password to pair with and interact with the playback device (e.g., stream media, obtain status information, etc.). This pairing process must typically be repeated for each playback device and each user device. System 1200 can relieve the burden of pairing a user device with a playback device by automatically pairing authorized user devices.

In some implementations, the user of the user device 1210 can generate the authorized user database 1212. For example, the user device 1210 can include a home application 332 that allows a user of the user device 1210 (e.g., a homeowner, a home administrator, etc.) to designate a user and/or user device (e.g., user device 1220) that is authorized for a user playback device (e.g., playback device 320) within the user's home or other environment. Authorized user database 1212 may include a user identifier and/or a device identifier for each authorized user and/or user device. If the identified user and/or user device has been paired with some playback device, authorized user database 1212 may include a pairing token generated and provided by the paired playback device. For example, authorized user database 1212 may include a mapping of authorized user device identifiers to corresponding pairing tokens generated for each authorized user device identifier. However, when the authorized user database 1212 is first created on the user device 1210, the authorized user database may not include any pairing tokens.

In some implementations, the user device 1210 can be paired with the playback device 320. For example, the user device 1210 may receive an announcement from the playback device 320 indicating that the playback device 320 is available and providing some service (e.g., media streaming, remote access, etc.). The user device 1210 may present a notification to a user of the user device 1210 indicating that the playback device 320 has been detected. A user of the user device 1210 may provide an input to the user device 1210 to initiate a pairing process between the playback device 320 and the user device 1210. For example, the playback device 320 may present the code to the user, and the user may enter the code into a user interface of the user device 1210. The user device 1210 may send a code to the playback device 320 to verify that the user device 1210 is near the playback device 320 and should be paired.

In some implementations, after pairing with the playback device 320, the user device 1210 can automatically pair the user device identified in the authorized users database 1212 with the playback device 320. To initiate pairing of the user device identified in authorized user database 1212 with playback device 320, user device 1210 may send authorized user database 1212 to playback device 320. For example, the user device 1210 may send the playback device 320 a database of authorized users 1212 or a portion of the database 1212 that includes user identifiers and/or device identifiers for authorized users in the authorized users database 1212. The playback device 320 may store the received portion of the authorized user database 1212 as the authorized user database 1202. The playback device 320 may then generate a unique pairing token for each identified user and/or identified user device in the authorized user database 1202. The playback device 320 may store the pairing tokens in the authorized user database 1202 in association with the respective user identifier and/or device identifier of each token. The playback device 320 may then send a copy of the authorized user database 1202 including the pairing token to the user device 1210 to complete the pairing process. The user device 1210 may then update the authorized user database 1212 with the pairing token received from the playback device 320 such that each user identifier and/or user device identifier in the authorized user database 1212 is associated with an appropriate pairing token generated by the playback device 320 for the user identifier and/or user device identifier.

In some implementations, the user device 1210 can synchronize the authorized user database 1212 with other authorized user devices. For example, user device 1220 may be an authorized user device of an authorized user identified in authorized user database 1212. User device 1210 may send a portion of authorized user database 1212 associated with a user of user device 1220 to user device 1220, including the pairing token generated by playback device 320. For example, user device 1220 may receive and store a user identifier, device identifier, and/or pairing token associated with a user of user device 1220 in authorized user database 1222. Since the user of the user device 1220 is not a home or environment administrator or owner, the user device 1220 will not receive and store user identifiers, device identifiers, and/or pairing tokens associated with other users of other devices.

User device 1220 may store received authorized user database 1212 as authorized user database 1222 or update authorized user database 1222 with data and/or tokens in authorized user database 1212. After saving or updating authorized user database 1222, database 1222 now has pairing tokens generated by playback device 320 for the device identifier of user device 1220 and/or the user identifier of the user of user device 1220. When the user device 1220 attempts to pair with the playback device 320 for the first time, the user device 1220 may send the pairing token and its device identifier and/or user identifier to the playback device 320 instead of requiring the user to participate in the pairing process by entering a code or other input. When the playback device 320 receives the user identifier or device identifier and the pairing token from the user device 1220, the playback device 320 may compare the pairing token with the pairing token stored in the authorized user database 1202 to verify that the received pairing token is the same as the pairing token generated by the playback device 320 for the identified user or device. After verifying (or confirming) the pairing token, the playback device 320 may allow the user device 1220 to use the services provided by the playback device 320. Thus, the user device 1220 can be paired with the playback device 320 without the user participating in the pairing process, as the pairing process is performed by the user device 1210 on behalf of the user device 1220. Thus, user device 1210 acts as a proxy for user device 1220 when performing the pairing process on behalf of user device 1220. If the pairing token cannot be verified, the playback device 320 may prevent the user device 1220 from accessing the playback device 320 and/or may initiate a user interaction pairing process with the user device 1220, as described above. For example, when the pairing token does not match a token in authorized user database 1202 or when a user identifier or device identifier provided by user device 1220 cannot be found in authorized user database 1202, then playback device 320 may initiate a user interaction pairing process with user device 1220, as described above.

Fig. 13 is a block diagram of an example system 1300 for managing volume changes between networked playback devices. For example, system 1300 may correspond to any of the systems described above. Remote control devices 1310 and/or 1320 may be configured similarly to remote control device 310 described above. Media remote 1312 and media remote 1322 may be configured to present GUI100 and/or GUI200 as described above, and may present volume controls for remotely controlling playback volume of playback device 320. Media remote 1312 and media remote 1322 may utilize the mechanisms described above to communicate with media remote 1302 to adjust playback volume on playback device 320 and/or a playback group (e.g., a dynamic or persistent group) in which playback device 320 is the primary or master playback device in the playback group.

To reduce network traffic associated with volume input errors, in some implementations, remote control device 1310 may implement an adaptive volume change threshold. For example, a change in volume at the remote control device 1310 relative to the volume at the playback device 320 (where the volume difference is less than a threshold amount) may be ignored and not transmitted to the playback device 320. Volume changes that are less than a threshold may be considered input errors (e.g., related to inaccuracies in touch input) and may be ignored. The threshold may be adaptive such that a change in volume at a higher volume (e.g., near the higher end of the volume range) has a larger change threshold (e.g., 5% of the volume range) that must be exceeded before the volume change is sent; while a volume change at a lower volume (e.g., near zero volume) has a smaller change threshold (e.g., 1% of the volume range) that must be exceeded before the volume change is sent to the playback device 320.

In some implementations, the remote control device 1310 may implement a delay before sending the volume change to the playback device 320. For example, rather than immediately sending a volume change to the playback device 320, the remote control device 1310 may cache the volume change for a period of time (e.g., 0.5 seconds, 1 second, etc.) after the user stops providing input to change the volume and before sending the volume change. Delaying the transmission of volume changes to the playback device 320 allows the user time to complete his or her volume change decision and prevents immediate transmission of volume changes that the user may not actually want to apply to the playback device 320.

In some implementations, the remote control device 1310 may delay updating the volume user interface control to reflect the current volume of the network device when the user is currently providing input to the volume user interface control or when the user has recently completed providing input to the user interface control. For example, a user of remote control device 1310 may be providing input to a volume user interface control (e.g., volume control 228, handle 230 of fig. 2), while another user of remote control device 1320 is also adjusting the volume of playback device 320. To avoid a situation where volume handle 230 is moved away from the user's finger when user input is provided to adjust the volume, remote control device 1310 may delay updating the volume control display to reflect the actual volume of playback device 320 until a period of time has elapsed after the user has stopped providing input to the volume control. For example, if the delay period is one second, any volume status information received from the playback device 320 will be ignored if the user is providing input or providing input within the last second. However, one second after the user stops providing the volume input, the volume control presented by media remote 1312 on remote control device 1310 will be updated to reflect the actual volume of playback device 320. Thus, the user will not be confused about volume controls that are inconsistent with the provided user input.

Fig. 14 is a block diagram of an example media system 1400 configured to automatically establish a streaming media connection between playback devices. For example, the streaming device may be configured to automatically establish and/or reestablish a media streaming connection with the playback device after the connection has been hijacked by another media streaming device.

In some implementations, the media system 1400 can include a streaming device 1410. For example, the streaming device 1410 may correspond to the streaming device 510 and/or the playback device 320 described above. For example, in some cases, the streaming device 1410 may be the playback device 320, which performs the media streaming functions described with reference to the streaming device 510.

In some implementations, the streaming device 1410 may include a routing manager 1412. For example, the routing manager 1412 may correspond to the session manager 330 described above. Routing manager 1412 may manage a repository of routing information describing available playback devices (e.g., playback devices 1420, 1430, etc.), current connections between streaming device 1410 and other devices, previous connections between streaming device 1410 and other devices, and/or playback group configurations (e.g., which playback devices are in which room of a house, which playback devices are in which dynamic and/or persistent playback groups, etc.).

In some implementations, the streaming device 1410 may stream media data to the playback device 1420 and/or the playback device 1430. For example, the streaming device 1410 may be a media streaming device connected to a television, speakers, etc. A user of the streaming device 1410 may provide input to the streaming device 1410 to cause the streaming device 1410 to stream media data (e.g., audio data, video data, etc.) to the playback device 1420 and/or the playback device 1430. In some implementations, this user input designating playback device 1420 and/or playback device 1430 as a playback device for streaming device 1410 may cause streaming device 1410 to automatically create a dynamic playback group that includes playback device 1420, playback device 1430, and/or streaming device 1410. The streaming device 1410 may establish a connection with the playback device 1420 and/or the playback device 1430 and stream the user-selected media to the playback device 1420 and/or the playback device 1430.

In some implementations, the routing manager 1412 may store routing information that identifies the route of media streamed to the playback device. For example, the routing manager 1412 may store routing information indicating the last (e.g., most recent) media routing configuration of the streaming device 1410. Accordingly, the routing manager 1412 may store routing information indicating that the streaming device 1410 is routing media data to the playback device 1420 and/or playback device 1430. The operative connections between the devices are represented by the solid double-arrowed lines in fig. 14. For example, the current streaming media connection between the streaming device 1410 and the playback device 1420 is represented by line 1402.

As described above, a streaming media connection is established between devices using a connection hijacking mechanism. For example, the last device requesting a streaming media connection may use the streaming media connection. Thus, when the streaming device 1440 (e.g., another device similar to the streaming device 1410) begins streaming media data to the playback device 1420 (e.g., connection 1442), the streaming device 1440 will hijack the streaming connection 1402 with the playback device 1420. Accordingly, the connection 1402 between the streaming device 1410 and the playback device 1420 may terminate as indicated by the dashed line 1404.

In some implementations, the streaming device 1410 can stop (e.g., pause) rendering (e.g., streaming, playing, etc.) the media item when the playback device is hijacked away from the streaming device 1410. For example, when the streaming device 1440 hijacks a connection with the playback device 1420, the streaming device 1410 may receive a message that the connection with the playback device 1420 has been hijacked. When the playback device 1420 is hijacked away from the streaming device 1410, the streaming device 1410 may stop presenting (e.g., playing, streaming, etc.) the media item that the streaming device 1410 is streaming to the playback device 1420. In some implementations, the streaming device 1410 will continue to present media items when the playback device hijacked by the streaming device 1440 is located in a different room (e.g., a house, office, building, etc.) than the streaming device 1410.

In some implementations, when the streaming device 1440 hijacks the playback device, the streaming device 1410 will continue to present video corresponding to the media item while muting audio corresponding to the media item. For example, when the streaming device 1410 is streaming live media (e.g., media that cannot be paused, a live sporting event, etc.), the streaming device 1410 may continue to present or stream video data corresponding to the live media while stopping the streaming of audio data when the playback device is hijacked away from the streaming device 1410.

In some implementations, the playback device 1420 may prevent the streaming device 1440 from hijacking the connection with the playback device 1420. For example, the playback device 1420 may receive information from the streaming device 1410 indicating the type of media item that was streamed from the streaming device 1410 to the playback device 1420. If the media item is of a particular type (e.g., movie), the playback device 1420 may deny the streaming media connection requested by another streaming device (e.g., streaming device 1440). Thus, one or more users of the streaming device 1410 may continue to enjoy a media item (e.g., a movie) being played uninterrupted by the streaming device 1410. The playback device 1420 may send a notification to the streaming device 1440 indicating the reason for the rejection of the connection. The streaming device 1440 may then present a message indicating the reason for the rejection of the connection (e.g., using voice) on a display associated with the streaming device 1440 or through a speaker associated with the streaming device 1440.

In some implementations, the streaming device 1410 may automatically reconnect to the playback device 1420. For example, the streaming device 1410 may be configured to automatically hijack a connection with a playback device identified in the last media routing configuration of the playback device 1420 stored by the routing manager 1412. For example, when the streaming device 1410 receives user input indicating that the streaming device 1410 should present a media item, the streaming device 1410 may determine the playback device (e.g., playback device 1420 and/or playback device 1430) identified in the last (e.g., previous) media routing configuration and re-hijack the media streaming connection with the playback devices 1420 and 1430 as needed. For example, the streaming device 1410 may re-hijack the connection with the playback device 1420, thereby establishing the streaming connection 1406 and terminating the connection 1442 between the streaming device 1440 and the playback device 1420, as indicated by the dashed line 1444.

In some implementations, this automatic hijacking mechanism may be implemented by a set of streaming devices 1410. For example, a dynamic playback group may be created that includes multiple streaming devices 1410. Each streaming device 1410 may be configured to stream media data to a different set of playback devices. When the set receives an input to begin presenting the media item, each of the streaming devices 1410 (e.g., video streaming devices) may re-hijack their respective last playback device and present the media item. Such examples may include multi-television environments (e.g., sports bars, homes with multiple TVs, etc.), where each streaming device 1410 simultaneously presents video of a media item on the respective television while streaming audio output for the media item to wireless speakers (e.g., playback devices).

Dynamic media routing

Fig. 15 is a block diagram of an example media system 1500 configured to dynamically route media data to a playback device. For example, media system 1500 may correspond to media system 1400 described above. In some implementations, the media system 1500 may be configured to dynamically route media data (e.g., audio data, video data, etc.) to playback devices based on the media data source context.

In some implementations, the media system 1500 may include a streaming device 1502. For example, the streaming device 1502 may correspond to the streaming device 510 and/or the playback device 320 described above. For example, in some cases, the streaming device 1502 may be a playback device 320 that performs the media streaming functions described with reference to the streaming device 510.

In some implementations, the streaming device 1502 may include a routing manager 1504. For example, the routing manager 1504 may correspond to the session manager 330 described above. The routing manager 1504 may manage a repository of routing information describing available playback devices (e.g., playback devices 1420, 1430, etc.), current connections between the streaming device 1410 and other devices, previous connections between the streaming device 1410 and other devices, and/or playback group configurations (e.g., which playback devices are in which room of the house, which playback devices are in which dynamic and/or persistent playback groups, etc.). The routing manager 1504 may be configured with rules that define how to route media data based on media data source context, playback device connection, type of playback device connected to the streaming device 1502, and/or other criteria.

In some implementations, the routing manager 1504 may be configured to route media data based on the media context 1506 and/or the system context 1508. For example, a media data source corresponding to a media item (such as music, a movie, a television program, a podcast, an audio book, etc.) may correspond to media context 1506. A media data source corresponding to software (e.g., a sound producing software application, a game application, an operating system, etc.) may correspond to the system context 1508. In other words, real media items (e.g., media files, media items, movies, music, etc.) may correspond to a media context, while media data generated by software and/or hardware (e.g., separate from the media items) may correspond to a system context 1508.

In some implementations, the routing manager 1504 can route media data corresponding to the media context 1506 to a playback device and/or playback group while media data corresponding to the system context 1508 is presented on or through the streaming device 1502. For example, the user may provide input to the streaming device 1502 indicating that the streaming device 1502 should stream media data to the playback group 1510. For example, playback group 1510 (e.g., a dynamic playback group, a persistent playback group, etc.) may include playback device 1520 and/or playback device 1530. The routing manager 1504 may determine a context (e.g., media context 1506, system context 1508) of the media data generated by the streaming device 1502 and may stream the media data to the playback group 1510 based on the context. For example, the routing manager 1502 may stream media data corresponding to the media context 1506 to the playback group 1510 while media data corresponding to the system context 1508 is locally presented by the streaming device 1502 or a personal playback device (e.g., headset, small personal speaker, small personal display screen) connected to the streaming device 1502. For example, when the streaming device 1502 streams audio for a movie to the playback group 1510 for presentation, operating system input sounds (e.g., clicks) generated by the streaming device 1502 may be presented by the streaming device 1502. If the streaming device 1502 is part of a persistent playback group (e.g., considered a logical device), the media data corresponding to the system context 1508 can be presented by each device in the persistent playback group.

In some implementations, the media system 1500 may include a headphone device 1540. For example, the headphone device 1540 may be a particular type of playback device 320. The headphone device 1540 may be a personal playback device worn on or in the ear of the user of the streaming device 1502, for example. The routing manager 1504 can determine how to route media data corresponding to the media context 1506 and/or the system context 1508 based on the type of playback device (e.g., headset, speakers, etc.) connected to the streaming device 1502. For example, the routing manager 1504 may implement special routing rules for headphone playback devices, as described below.

In some implementations, the routing manager 1504 can send media data corresponding to the system context 1508 to the headset device 1540. For example, if the streaming device 1502 is a personal device (e.g., a single user device, a smart phone, a smart watch, etc.), the routing manager 1504 may route (e.g., send) media data corresponding to the system context 1508 to the streaming device 1540 when the streaming device 1540 is connected to the streaming device 1502.

In some implementations, the routing manager 1504 can send media data corresponding to the media context 1506 to the headset device 1540. For example, if the streaming device 1502 is a common device (e.g., a set-top box, smart speakers, etc.), the routing manager 1504 may route (e.g., send) media data corresponding to the media context 1506 to the streaming device 1540 when the streaming device 1540 is connected to the streaming device 1502. As a particular example, the streaming device 1502 may stream audio for a movie to the playback group 1510. When a user connects the headset device 1540 to the streaming device 1502, the routing manager 1504 may automatically change the routing of the movie audio such that the headset device 1540 receives and presents the movie audio and the playback group 1510 no longer receives and/or presents the movie audio. When the user later disconnects the headset 1540 from the streaming device 1502, the routing manager 1504 may resume streaming media data corresponding to the media context 1506 to the playback group 1520.

In some implementations, the routing manager 1502 may be configured with time-based rules for routing media data. For example, the streaming device 1502 may be configured to have a time period of a playback device/playback group mapping that defines which playback devices route media data at corresponding times of the day. In a particular example, the routing manager 1504 may be configured to have a daytime routing configuration and a nighttime (e.g., 8pm to 9am) routing configuration. The daytime routing configuration may specify that during daytime periods (e.g., 9am to 8pm), media data streamed from the streaming device 1502 should be routed to a 5.1 surround sound speaker group (e.g., a dynamic playback group, a persistent playback group, etc.). The night routing configuration may specify that during night time periods (e.g., 8pm to 9am), media data streamed from streaming device 1502 should be routed to a single playback device or a small group of playback devices (e.g., stereo pair, dynamic playback group, persistent playback group, etc.). The daytime and/or nighttime routing configurations may specify other playback parameters, including the audio volume of the playback device (e.g., higher volume for daytime periods, lower volume for nighttime periods).

Fig. 16 is a block diagram of an example media system 1600 for dynamic routing based on playback device capabilities. For example, media system 1600 may correspond to media system 1500 described above. The media system 1600 may be configured to dynamically route media data to playback devices based on the capabilities of the respective playback devices. For example, in streaming media data to a playback group (e.g., playback group 1630), streaming device 1502 may determine a route for the media data based on the playback capabilities of the playback device. Alternatively, a primary playback device in the playback group (e.g., a group leader) may determine how to route media data received by the playback group based on the capabilities of the playback devices in the playback group.

In some implementations, media system 1600 may include playback group 1630. For example, playback group 1630 may be a dynamic or persistent playback group. Playback group 1630 may include playback device 1640, playback device 1650, and/or playback device 1660. Each playback device may have different capabilities. For example, playback device 1640 may be capable of audio output 1642 (e.g., output to speakers) and video output 1644 (e.g., output to a display), while playback device 1650 and/or 1660 may be capable of audio output 1652 and 1654, but not video output. For example, the capabilities of each playback device may be reported or broadcast to the devices in the playback group 1630 and/or the streaming device 1502. Thus, when the streaming device 1502 streams a media item that includes audio and video data, the streaming device 1502 may determine the playback capabilities of each device and route the media data of the media item accordingly. For example, streaming device 1502 may send audio and video media data to playback device 1640 while sending only audio media data to playback devices 1650 and 1660.

Alternatively, the streaming device 1502 may send the audio and video media data for the media item to the primary device in the playback group 1630. When the primary device (e.g., playback device 1650) receives the audio and video media data, the primary device may determine the playback capabilities of each device in the playback group 1630 and route the media data for the media item accordingly. For example, the playback device 1650 (e.g., a primary device) may render audio data for a media item and may transmit the audio and video media data to the playback device 1640 while transmitting only the audio media data to the playback device 1660.

In some implementations, each playback device in playback group 1630 may determine how to process the received media data based on the capabilities of each device. For example, each playback device in playback group 1630 may receive all media data (e.g., audio and/or video) for a media item streamed by streaming device 1502. Each device may or may not render the received audio media data and/or video media data based on the capabilities of each device. Further, the playback device may determine which media presentation subsystems of the playback device can be enabled based on the received media data. For example, playback device 1640 may be configured for audio output 1642 and video output 1644. When the playback device 1640 receives media data that includes audio instead of video data, the playback device 1640 can present the audio data while disabling video output. For example, the playback device 1640 may provide audio output through a speaker connected to the playback device 1640 while keeping a connected display powered off.

Fig. 17 is a block diagram of an example media system 1700 for providing access to media data in a second language. For example, system 1700 may correspond to media system 1500 described above.

In some implementations, the streaming device 1502 may present the media item while streaming audio data of the media item to the playback group 1710. Each playback device (e.g., playback device 1720, playback device 1730, etc.) in the playback group 1710 (e.g., dynamic group, persistent group, etc.) may present audio output 1722, 1732 according to a language (e.g., english) configured in or by the streaming device 1502.

In some implementations, the media items may include additional audio data that provides dialogs in different languages. For example, a media item (e.g., a movie) can include conversation soundtracks (e.g., speech translations corresponding to conversations in the movie) in various languages (e.g., french, chinese, vietnamese, etc.).

In some implementations, the routing manager 1504 can route conversation tracks to user devices based on a language specified by the user devices. For example, the media system 1700 may include a user device 1750 (e.g., a smartphone, a tablet, etc.). The user device 1750 may be configured to present data to a user in a different language (e.g., a second language) than the presentation language configured in the streaming device 1502. For example, while the streaming device 1502 is configured to present information and/or media items in English, the user device 1750 may be configured to present information and/or media items in Chinese.

A user of user device 1750 (e.g., a chinese user) may provide input to connect user device 1750 to streaming device 1504. For example, when connected to the streaming device 1502, the user device 1750 can send information to the streaming device 1504 specifying the presentation language (e.g., chinese) of the user device 1750. When the streaming device 1502 receives the language specification of the user device 1750, the routing manager 1503 may generate routing data that indicates that chinese media data (e.g., a chinese conversation soundtrack for a movie) should be routed to the user device 1750. Thus, when the streaming device 1502 and/or the playback group 1710 present media items in a first language (e.g., english), the streaming device 1502 can stream media data (e.g., chinese conversation soundtrack) corresponding to a second language of the user device 1750 to the user device 1750.

In some implementations, the media system 1700 can include a playback device 1740. For example, the playback device 1740 may be a headset, speakers, or other audio output device that provides audio output 1742. A user of the user device 1750 may connect the playback device 1740 to the user device 1750 so that media tracks in the second language received by the user device 1750 from the streaming device 1502 may be rendered by the playback device 1740. For example, while watching a movie presented by streaming device 1502 on television, a chinese user may wear a headset (playback device 1740) that presents a movie conversation in chinese while other users listen to the movie conversation presented in english through playback group 1710.

Artificial intelligence interface

In some implementations, the media system described herein can be configured to provide an artificial intelligence interface that can process spoken speech input provided by a user of the media system. For example, an Artificial Intelligence (AI) interface may determine how to process media related to an input command based on the type of media item, a playback group (e.g., dynamic playback group, persistent playback group, etc.), and/or a particular playback device specified in the user voice input. For example, the spoken voice input may be received by a streaming device (e.g., streaming device 1502) through an AI interface of the streaming device.

In some implementations, the streaming device 1502 can receive voice input commands to play media items at each place. For example, "per place" may include all playback devices connected to a network environment (e.g., home, work, etc.) or associated with an environment (e.g., home, work, etc.) configured in the home application 332. In some implementations, "per place" can include all playback devices for which the routing manager 1504 has connection and/or routing information. When the streaming device 1502 receives a "play everywhere" command for a media item, the routing manager 1504 can determine how to route the media item based on the type of the media item. For example, if the media item is an audio media item (e.g., music, audiobooks, podcasts, etc.), the routing manager 1504 may stream the audio media item to all playback devices capable of audio output, as described above. Alternatively, if the media item is an audio media item (e.g., music, audiobooks, podcasts, etc.), the routing manager 1504 may stream the audio media item only to playback devices capable of audio-only output. If the media item is an audio/video media item (e.g., movie, television program, etc.), the routing manager 1504 may stream the audio media item to all playback devices capable of audio output or video output, as described above.

In some implementations, the streaming device 1502 may receive a voice input command to play a media item to one or more playback groups. For example, when the streaming device 1502 receives a "play to group" voice command, the routing manager 1504 may determine, based on the playback group data stored on the streaming device 1504, the playback device associated with the playback group identified in the voice command. For example, the playback group may correspond to a dynamic group, a persistent group, a room group, or any other type of configuration group. The streaming device 1502 may then stream the media items identified in the voice input command to the specified group. In some implementations, the routing manager 1504 may stream media items to playback devices in a specified group based on the output capabilities of the playback devices, as described above.

In some implementations, the streaming device 1502 can receive voice input commands to play media items to a particular type of device. For example, the different types of devices may include set-top boxes, smart speakers, specific models of devices, and so forth. The voice input command may specify, for example, that the streaming device 1502 should send the media item to all set-top boxes or all streaming devices. When the streaming device 1502 receives a voice input command, the routing manager 1504 can determine which playback devices correspond to the specified type of device and stream the media item identified in the voice input command to the specified type of playback device.

Example procedure

In order to enable the reader to clearly understand the technical concepts described herein, the following process describes specific steps performed in a particular order. However, one or more steps of a particular process may be rearranged and/or omitted while remaining within the intended scope of the techniques disclosed herein. Further, different processes and/or steps thereof may be combined, recombined, rearranged, omitted, and/or performed in parallel to create different process flows that are also within the intended scope of the techniques disclosed herein. Moreover, although the following processes may omit or briefly summarize some details of the techniques disclosed herein for the sake of clarity, details described in the above paragraphs may be combined with process steps described below to obtain a more complete and thorough understanding of these processes and the techniques disclosed herein.

Fig. 18 is a flow diagram of an example process 1800 for remotely controlling a playback device. For example, process 1800 may be performed by a playback device to allow a remote control device to provide remote control commands over a control connection while the playback device maintains an active streaming connection (e.g., a primary connection) with a streaming device. The remote control connection and the main connection may be separate connections with separate functions. For example, the remote control connection may be used to receive commands from the remote control device and/or to send status information to the remote control device without interrupting, affecting, or hijacking the master connection. The primary connection may be used to receive streaming media data from and/or communicate with the streaming device.

At step 1802, the playback device may establish a primary connection between the playback device and the streaming device. For example, a playback device may broadcast a message announcing its availability to other devices. The message may include data that a receiving device (e.g., a streaming device) may use to connect to a playback device. For example, the message may include a device identifier of the playback device, which the streaming device may use to connect to the playback device over a local area network, a wi-fi network, or some other network to which both the playback device and the streaming device are connected. When the streaming device receives the announcement, the streaming device may present a graphical user interface identifying the playback device. The user of the streaming device may then select the playback device as the playback device for the selected media item or other media data. Upon receiving a user selection of a playback device, the streaming device may communicate with the playback device to establish a primary connection. Since playing multiple media items simultaneously at a playback device would create an unpleasant experience for the user, the playback device may only manage a single master connection at a time.

At step 1804, the playback device may receive the media item from the streaming device over the primary connection. For example, the streaming device may stream the media item to the playback device over the primary connection, send the entire media item over the primary connection, or send a reference (e.g., a link, URL, etc.) to the media item over the primary connection. Thus, when this specification describes sending or streaming a media item from a streaming device to a playback device, the sending or streaming may be performed by streaming the media item to the playback device over a primary connection, sending the entire media item over the primary connection, or sending a reference (e.g., a link, URL, etc.) to the media item that the playback device may use to obtain the media item. Alternatively, the streaming device may send an identifier of the media item to the playback device over the primary connection, and the playback device may obtain the media item from another source (e.g., a network source, locally from memory on the playback device, etc.).

At step 1806, the playback device can render the media item at the playback device. For example, if the media item is an audio media item (e.g., music), the playback device may play the audio media item through speakers of the playback device. If the media item is a video media item, the playback device may present the media item using a display of the playback device.

At step 1808, the playback device may establish a control connection between the playback device and the remote control device. For example, a remote control device may receive an announcement message broadcast by a playback device as described above. The remote control device may send a message to the playback device using data in the announcement message to establish a control connection that allows the remote control device to obtain playback state information and/or to send commands that allow the remote control device to control playback of media items presented by the playback device. Since multiple remote control devices may present playback state information and may provide remote control commands, the playback device may manage multiple control connections with multiple different remote control devices. Furthermore, since the control connection is not a master connection, the control connection may be established without interrupting playback of the currently playing media item and without interrupting or hijacking the master connection.

At step 1810, the playback device may receive a media command from a remote control device over a control connection. For example, the media command may be a request for playback status information (e.g., identification of the currently playing media item, location of playback in the media item, current volume level, functionality supported by an application presenting the media item, capabilities of the playback device, etc.). The media command may be a playback control command that stops, starts, skips, fast forwards, rewind, adjusts volume, or commands some other change to the playback of the currently playing media item.

At step 1812, the playback device may process the media command. For example, the playback device may process the media command by executing the media command locally at the playback device. For example, a stop playback command, status request, etc. may be executed locally at the playback device. Alternatively, the playback device may process the media command by forwarding the media command to the streaming device over the primary connection. For example, because the streaming device is the source of the media item, the streaming device is managing playback of the media item, and may need to coordinate playback among multiple playback devices. Accordingly, the playback device may forward media commands (e.g., status requests, skip commands, fast forward commands, pause commands, volume adjustments, etc.) to the streaming device so that the streaming device may process the media commands and make corresponding adjustments at the playback device that presented the media item.

Fig. 19 is a flow diagram of an example process 1900 for managing playback groups. For example, the process 1900 may be performed by a computing device (e.g., a remote control device, a streaming device, etc.) to determine groupings of playback devices based on playback device attributes received from various playback devices. After determining the playback device group, the computing device may present the playback device group on a display of the computing device, and a user of the computing device may select the playback group to which to stream the media item such that all playback devices in the selected group may present the user-selected media item.

At step 1902, the computing device may receive a playback group attribute corresponding to a first playback device. For example, the computing device may receive a playback group attribute in a message broadcast by the playback device that advertises the availability and/or capabilities of the playback device. The playback group attribute may include a first playback group identifier. For example, the first playback group identifier may be a dynamic playback group identifier. The first playback group identifier may be a persistent playback group identifier. The playback group attributes may include other attributes as described above.

At step 1904, the computing device may receive a playback group attribute corresponding to the second playback device. For example, the computing device may receive a playback group attribute in a message broadcast by the playback device that advertises the availability and/or capabilities of the playback device. The playback group attribute may include a second playback group identifier. For example, the second playback group identifier may be a dynamic playback group identifier. The second playback group identifier may be a persistent playback group identifier. The playback group attributes may include other attributes as described above.

At step 1906, the computing device may determine that the first playback group identifier is equal to the second playback group identifier. For example, the computing device may compare the first playback group identifier to the second playback group identifier and determine that the first playback group identifier and the second playback group identifier are the same and that the first playback device and the second playback device belong to the same playback device group.

At step 1908, the computing device may generate a first playback group that includes the first playback device and the second playback device. For example, the computing device may store playback group data indicating that the first playback device and the second playback device are in the same playback device group. The playback group data may also include information identifying the type of playback group (e.g., persistent, dynamic) and/or capabilities of the playback devices in the playback group. In some implementations, a single playback device may belong to multiple dynamic playback groups. Thus, the second playback device may provide playback group attributes that identify multiple dynamic playback groups. Further, a single playback device may belong to both the persistent playback group and the dynamic playback group. For example, the persistent playback group including the second playback device may also be a playback device included in the dynamic playback group, as described above. Thus, the second playback device may provide a playback group attribute that identifies multiple dynamic playback groups and a single persistent playback group.

At step 1910, the computing device may present the first playback group on a display of the computing device. For example, the computing device may present the first playback device and the second playback device as a single entity or as a single device on a display of the computing device. This allows a user to make a single group selection when the user wishes to send playback of a media item to multiple playback devices, rather than selecting multiple playback devices. As described above, when a user selects a playback group, the computing device may send (e.g., stream) the user-selected media item to the playback group so that each playback device in the selected playback group may present the media item in synchronization with other playback devices in the same playback group.

Fig. 20 is a flow diagram of an example process 2000 for efficiently pairing an authorized user device with a playback device. For example, process 2000 may be performed by a user device (e.g., a streaming device, a remote control device, etc.). For example, a user device may be configured with a device identifier (or user identifier) for a device authorized to access or interact with a playback device within an environment (e.g., a home environment, an office environment, etc.). The environment may be defined based on a geographic region. The environment may be defined based on a network used to manage or interact with the playback devices within the environment. When the user device is paired with the playback device, the user device may send an authorized device identifier to the playback device to cause the playback device to generate a pairing token for the authorized device identifier. Thus, the user device may act as a proxy for other authorized user devices and perform pairing procedures on behalf of the other authorized user devices.

At step 2002, the user device may store a device identifier corresponding to the authorized computing device. For example, an administrator or other authorized user of the environment may provide input to the user device or another computing device to identify the user and/or the user device authorized to access the playback device within the environment. For example, an administrator (e.g., a parent) within the home environment may provide input to the user device to identify other users (e.g., spouse, child, friend, etc.) that should be allowed access to the playback device within the home environment. The user device may then store the device identifier of the authorized computing device in an authorized user database on the user device. The authorized user database or individual records therein may be shared or synchronized with other authorized computing devices.

At step 2004, the user device may pair the user device with a first playback device. For example, a user of a user device (e.g., a first computing device) may provide an input to the user device indicating that the user device should connect to or pair with a first playback device. The user device and the first playback device may perform a pairing process, for example, including receiving user input of a pairing code to pair the user device and the first playback device. If the pairing is successful, the user device may send a pairing token to the first playback device, which the first playback device may use to access services and/or functions of the first playback device without having to perform the pairing process again. For example, the user device may include the pairing token in a subsequent request for the first playback device. The first playback device may determine, based on the pairing token, that the user device is authorized to access the first playback device, as described above.

At step 2006, the user device may cause the first playback device to generate a pairing token for each authorized computing device. For example, after successfully pairing the user device with the playback device, the user device may automatically send a device identifier of an authorized computing device (e.g., other user device) to the first playback device. Upon receiving the authorized device identifiers, the first playback device may generate a pairing token for each authorized device identifier. Thus, by sending the authorized device identifier to the first playback device to generate the pairing token, the user device has performed a pairing process on behalf of each of the identified authorized devices, thereby relieving the user of the authorized device from having to perform the pairing process himself, which may be more cumbersome when pairing with multiple playback devices.

At step 2008, the user device can receive a pairing token generated for each authorized computing device. For example, after the first playback device generates a pairing token for each authorized device identifier, the first playback device may send data to the user device that maps each authorized device identifier to its respective pairing token. The user device may then store a mapping of the device identifier to the pairing token in an authorized user database stored on the user device.

At step 2010, the user device may send the pairing token generated for the second computing device to the second computing device. For example, after performing the pairing process on behalf of the authorized computing devices, the user device may send a pairing token to each authorized computing device. For example, a pairing token generated by a first playback device for a second computing device may be sent to the second computing device. The second computing device may then use the pairing token to access functions, features, and/or services of the first playback device.

Although the process 2000 is described with reference to a single playback device (e.g., a first playback device), the environment may include multiple playback devices. Thus, the process 2000 may be performed for each playback device within the environment to pair the authorized computing device with each playback device without forcing the pairing process for the user of the authorized computing device with each playback device. However, as described above, if the playback device that receives the pairing token from the computing device fails to verify the pairing token, or if the playback device does not have an identifier of the computing device stored on the playback device, the playback device may prevent the computing device from accessing the playback device until the computing device performs a pairing process with the computing device that requires the user to input the code or performs some other pairing process.

Fig. 21 is a flow diagram of an example process 2100 for generating pairing tokens for multiple user devices. For example, process 2100 may be performed by a playback device to generate pairing tokens for multiple authorized user devices (e.g., authorized computing devices) such that a separate pairing process involving the user need not be performed for each authorized user device.

At step 2102, the playback device may receive a request to pair the first computing device with the playback device. For example, the playback device may receive a request from the user device to pair the user device with the playback device.

At step 2104, the playback device may pair the first computing device with the playback device. For example, the playback device may present code that a user of a user device (e.g., a first computing device) may enter the user device. The user device may transmit the code to the playback device, and the playback device may generate a pairing token for the user device if the playback device determines that the code received from the user device matches the code presented by the playback device. The playback device may send the pairing token to the user device so that the user device may use the pairing token to access the playback device. Once the playback device sends the pairing token to the user device, the devices pair.

At step 2106, the playback device may receive a device identifier from the first computing device. For example, the paired user device may send device identifiers of other authorized user devices (e.g., authorized computing devices) to the playback device to initiate pairing on behalf of the other authorized user devices. The user device may send the device identifier after pairing with the playback device and/or along with a pairing token generated for the paired user device, such that the playback device may determine that the user device is authorized to perform the pairing process on behalf of other authorized user devices.

At step 2108, the playback device may generate a pairing token for each received device identifier. For example, the playback device may generate a unique pairing token for each identified authorized user device.

At step 2110, the playback device may store a mapping of pairing tokens to device identifiers. For example, the playback device may store a database (e.g., an authorized user database) that maps device identifiers to corresponding unique pairing tokens, such that when a pairing token is later received from a computing device attempting to access the playback device, the playback device may compare the device identifier and pairing token provided by the computing device to the mapping to determine whether the computing device is currently paired with the playback device.

At step 2112, the playback device can send the mapping to the first computing device. For example, the playback device may send a mapping of device identifiers to pairing tokens to the first computing device. The first computing device may then distribute the pairing token to the appropriate authorized computing devices, as described above.

At step 2114, the playback device may receive the pairing token sent from the second computing device to the first computing device. For example, the playback device may receive a particular pairing token and device identifier from the second computing device. The playback device may receive the pairing token generated by the playback device from the second computing device even though the playback device may have never previously communicated with or provided the pairing token to the second computing device.

At step 2116, the playback device may allow the second computing device to access the playback device based on the pairing token. For example, the playback device may compare (e.g., map) the device identifier and pairing token received from the second computing device with the device identifier and pairing token stored in an authorized user database stored on the playback device. The playback device may allow the second computing device to access the playback device if the pairing token-device identifier pair is present within the authorized user database. If the device identifier is not present in the authorized user database, or if the token mapped to the device identifier does not match the received pairing token, the playback device may prevent the second computing device from accessing the playback device until the second computing device is successfully paired with the computing device.

Fig. 22 is a flow diagram of an example process 2200 for contextual routing of media data. For example, process 2200 may be performed by a computing device (e.g., a streaming device) to route audio and/or video output associated with a media item, software application, and/or operating system to an appropriate playback device.

At step 2202, a computing device may obtain first media data to present. For example, the media data may correspond to a media item (e.g., a movie, music, audio book, etc.). The media data may correspond to sound or images generated by software, such as game application sound, operating system sound, and the like. Thus, the computing device may obtain the first media data from a software application configured to render movies, music, etc. from a gaming software application, operating system software, or any other audio or video generating component of the computing device.

At step 2204, the computing device may determine a context associated with the first media data. For example, the context may be a system context associated with a software-generated sound or image. The context may be a media context associated with presentation of a media item (such as a movie, music, etc.). The context may be determined based on the source of the media data. For example, if the source is a movie or music application, the computing device may determine that the context is a media context. If the source is a gaming application or operating system, the computing device may determine that the context is a system context.

At step 2206, the computing device may obtain a media routing rule that specifies how to route the first media data based on the context. For example, a rule may specify that media data associated with a system context should be routed locally. For example, local routing may include rendering the media data on a local computing device or through a personal playback device (e.g., headphones, personal speakers, personal display device, etc.) connected to the local computing device. The rule may specify that media data associated with the media context should be routed to the remote playback device. For example, if the computing device is currently routing playback of the media item to the remote playback device (or group of devices), or if the computing device has previously routed playback of the media item to the remote playback device, the computing device may route media data associated with the media context to the remote playback device.

At step 2208, the computing device may select one or more playback devices for presenting the media data based on the determined context and the media routing rules. For example, the determined context may be compared to media routing rules to determine which playback device to select to present the media data. Based on the rules, the computing device may select the computing device (e.g., local device and/or personal playback device) as the playback device when the media data is associated with the system context. Based on the rules, the computing device may select a remote playback device (or group of playback devices) as the playback device when the media data is associated with the media context.

At step 2210, the computing device may transmit the first media data to the selected one or more playback devices. For example, the computing device may send the first media data to a speaker and/or display of the computing device or a personal playback device connected to the computing device. The computing device may send the first media data to a remote playback device or group of playback devices for presentation.

In some implementations, the computing device may route system contextual media data and media contextual media data simultaneously. For example, the computing device may stream a movie to the remote playback group while video game output is presented on the display and through the speakers of the computing device. Thus, a computing device may process and route multiple instances of media data to different playback devices simultaneously.

Graphic user interface

The present disclosure describes various Graphical User Interfaces (GUIs) for implementing various features, processes, or workflows above. These GUIs may be presented on a variety of electronic devices including, but not limited to, laptop computers, desktop computers, computer terminals, television systems, tablets, e-book readers, and smart phones. One or more of these electronic devices may include a touch-sensitive surface. The touch-sensitive surface may process multiple simultaneous input points, including processing data related to the pressure, degree, or location of each input point. Such processing may facilitate gestures performed with multiple fingers, including pinching and swiping.

When the present disclosure refers to "selecting" a user interface element in a GUI, these terms are understood to include clicking or "hovering" over the user interface element using a mouse or other input device, or touching, tapping, or gesturing on the user interface element using one or more fingers or a stylus. The user interface elements may be virtual buttons, menus, selectors, switches, sliders, brushes, knobs, thumbnails, links, icons, radio boxes, check boxes, and any other mechanism for receiving input from or providing feedback to a user.

Privacy

The present disclosure recognizes that the use of such personal information data in the present technology may be useful to benefit the user. For example, the personal information data may be used to deliver target content that is of greater interest to the user. Thus, the use of such personal information data enables planned control of delivered content. In addition, the present disclosure also contemplates other uses for which personal information data is beneficial to a user.

The present disclosure also contemplates that entities responsible for the collection, analysis, disclosure, transmission, storage, or other use of such personal information data will comply with established privacy policies and/or privacy practices. In particular, such entities should enforce and adhere to the use of privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining privacy and security of personal information data. For example, personal information from a user should be collected for legitimate and legitimate uses by an entity and not shared or sold outside of these legitimate uses. In addition, such collection should only be done after the user has informed consent. In addition, such entities should take any required steps to secure and protect access to such personal information data, and to ensure that others who are able to access the personal information data comply with their privacy policies and procedures. In addition, such entities may subject themselves to third party evaluations to prove compliance with widely accepted privacy policies and practices.

Regardless of the foregoing, the present disclosure also contemplates embodiments in which a user selectively prevents use or access to personal information data. That is, the present disclosure contemplates that hardware elements and/or software elements may be provided to prevent or block access to such personal information data. For example, in the case of an ad delivery service, the techniques of the present invention may be configured to allow a user to opt-in to "join" or "opt-out of" participating in the collection of personal information data during registration with the service. As another example, the user may choose not to provide location information for the targeted content delivery service. As another example, the user may choose not to provide accurate location information, but to permit transmission of location area information.

Example System architecture

Fig. 23 is a block diagram of an exemplary computing device 2300 in which the features and processes of fig. 1-22 may be implemented. Computing device 2300 may include a memory interface 2302, one or more data processors, image processors, and/or central processing units 2304, and a peripheral interface 2306. The memory interface 2302, the one or more processors 2304, and/or the peripherals interface 2306 can be separate components or can be integrated into one or more integrated circuits. The various components in computing device 2300 may be coupled by one or more communication buses or signal lines.

Sensors, devices, and subsystems can be coupled to peripherals interface 2306 to facilitate multiple functions. For example, motion sensor 2310, light sensor 2312, and proximity sensor 2314 may be coupled to peripheral interface 2306 to facilitate orientation, lighting, and proximity functions. Other sensors 2316 may also be connected to the peripheral device interface 2306, such as a Global Navigation Satellite System (GNSS) (e.g., GPS receiver), temperature sensors, biometric sensors, magnetometers, or other sensing devices to facilitate related functions.

Camera subsystem 2320 and optical sensor 2322, such as a Charge Coupled Device (CCD) or Complementary Metal Oxide Semiconductor (CMOS) optical sensor, may be utilized to facilitate camera functions, such as taking photographs and video clips. The camera subsystem 2320 and optical sensor 2322 may be used to collect images of a user to be used during authentication of the user, for example, by performing facial recognition analysis.

Communication functions may be facilitated by one or more wireless communication subsystems 2324, which may include radio frequency receivers and transmitters and/or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the communication subsystem 2324 may be dependent upon the one or more communication networks with which the computing device 2300 is intended to operate. For example, computing device 2300 may include a network designed to communicate over a GSM network, GPRS network, EDGE network, Wi-Fi or WiMax network, and Bluetooth^TMA communication subsystem 2324 for network operations. In particular, the wireless communication subsystem 2324 may include a host protocol such that the device 100 may be configured as a base station for other wireless devices.

An audio subsystem 2326 may be coupled to a speaker 2328 and a microphone 2330 to facilitate voice-enabled functions such as speaker recognition, voice replication, digital recording, and telephony functions. The audio subsystem 2326 may be configured to facilitate, for example, processing of voice commands, voiceprint authentication, and voice authentication.

The I/O subsystem 2340 may include a touch-surface controller 2342 and/or one or more other input controllers 2344. Touch-surface controller 2342 may be coupled to touch surface 2346. Touch surface 2346 and touch-surface controller 2342 may detect contact and motion or breaks thereof, for example, using any of a variety of touch-sensitive technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with touch surface 2346.

One or more other input controllers 2344 may be coupled to other input/control devices 2348, such as one or more buttons, rocker switches, thumb wheels, infrared ports, USB ports, and/or pointer devices (such as a stylus). The one or more buttons (not shown) may include an up/down button for volume control of the speaker 2328 and/or the microphone 2330.

In one implementation, depressing the button for a first duration releases the lock on the touch surface 2346; and pressing the button for a second duration that is longer than the first duration can turn power on or off to computing device 2300. Pressing the button for a third duration of time can activate a voice control or voice command, a module that enables the user to speak a command into the microphone 2330 to cause the device to execute the spoken command. The user can customize the functionality of one or more buttons. For example, virtual or soft buttons and/or a keyboard may also be implemented using touch surface 2346.

In some implementations, computing device 2300 may present recorded audio and/or video files, such as MP3, AAC, and MPEG files. In some implementations, computing device 2300 may include the functionality of an MP3 player, such as an iPod^TM。

Memory interface 2302 can be coupled to memory 2350. The memory 2350 may include high-speed random access memory and/or non-volatile memory, such as one or more magnetic disk storage devices, one or more optical storage devices, and/or flash memory (e.g., NAND, NOR). Memory 2350 may store an operating system 2352, such as Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embedded operating system (such as VxWorks).

Operating system 2352 may include instructions for handling basic system services and for performing hardware related tasks. In some implementations, operating system 2352 can be a kernel (e.g., UNIX kernel). In some implementations, the operating system 2352 can include instructions for performing voice authentication. For example, the operating system 2352 may implement features as described with reference to fig. 1-22.

The memory 2350 may also store communication instructions 2354 to facilitate communication with one or more additional devices, one or more computers, and/or one or more servers. Memory 2350 may include graphical user interface instructions 2356 to facilitate graphical user interface processing; sensor processing instructions 2358 to facilitate sensor-related processing and functions; telephone instructions 2360 to facilitate telephone-related processes and functions; electronic message instructions 2362 that facilitate processes and functions related to electronic message processing; web browsing instructions 2364 to facilitate web browsing-related processes and functions; media processing instructions 2366 to facilitate media processing-related processes and functions; GNSS/navigation instructions 2368 that facilitate GNSS and navigation related processes and instructions; and/or camera instructions 2370 that facilitate camera-related processes and functions.

Memory 2350 may store other software instructions 2372 to facilitate other processes and functions, such as those described with reference to fig. 1-22.

Memory 2350 may also store other software instructions 2374, such as Web video instructions to facilitate Web video-related processes and functions; and/or online shopping instructions that facilitate processes and functions related to online shopping. In some implementations, the media processing instructions 2366 are divided into audio processing instructions and video processing instructions to facilitate audio processing-related processes and functions and video processing-related processes and functions, respectively.

Each of the instructions and applications identified above may correspond to a set of instructions for performing one or more functions described above. The instructions need not be implemented as separate software programs, procedures or modules. Memory 2350 may include additional instructions or fewer instructions. Further, various functions of the computing device 2300 may be implemented in hardware and/or software, including in one or more signal processing and/or application specific integrated circuits.

59页详细技术资料下载

Managing playback groups

相关技术

网友询问留言