Patent Description:
The disclosure is related to consumer goods and, more particularly, to methods, systems, products, features, services, and other elements directed to media playback and aspects thereof.

Options for accessing and listening to digital audio in an out-loud setting were limited until in <NUM>, when Sonos, Inc. filed for one of its first patent applications, entitled "Method for Synchronizing Audio Playback between Multiple Network devices," and began offering a media playback system for sale in <NUM>. The Sonos Wireless HiFi System enables people to experience music from many sources via one or more networked playback devices. Through a software control application installed on a smartphone, tablet, or computer, one can play what he or she wants in any room that has a networked playback device. Additionally, using the controller, for example, different songs can be streamed to each room with a playback device, rooms can be grouped together for synchronous playback, or the same song can be heard in all rooms synchronously.

Given the ever-growing interest in digital media, there continues to be a need to develop consumer-accessible technologies to further enhance the listening experience.

<CIT> describes a method for a media playback system in which a playback device has a corresponding first set of device attributes used by a first controller application. The method involves identifying a second set of device attributes used by a second controller application to control the playback device, selecting a second device attribute for the playback device from the second set of device attributes based at least in part on a first device attribute, storing the selected second device attribute in the first set of device attributes and controlling at least one function of the playback device using the selected second device attribute.

Aspects of the invention are defined in the appended independent claims.

The present disclosure describes systems and methods for, among other things, controlling multi-site media playback systems. Controlling multi-site media playback systems is important for media playback systems where a single user has multiple media playback devices deployed at multiple physical locations, where all of the media playback devices are associated with (and controlled by) the single user for multiple reasons. For example, sometimes it is desirable for certain configuration changes that the user makes to the media playback devices in one location to be applied to the user's media playback devices in other locations. Similarly, it is sometimes helpful for media playback devices at one physical location to have information about actions performed by media playback devices at a different physical location, for example, for the purpose of facilitating development of user preferences based on media playback activity. By facilitating multi-site management of geographically dispersed media playback systems associated with a single user, the systems and methods disclosed and described herein improve upon current media playback systems lacking such functionality by making configuration changes consistent across a multi-site deployment and correlating usage history data from geographically dispersed playback devices, thereby making the media playback system easier for users to configure and manage.

A first example embodiment involves a computing system receiving, from a first media playback device connected to a first network, a first registration message. The computing device then, in response to receiving the first registration message, assigns a system identifier and a first subsystem identifier to the first media playback device. The system identifier is associated with the computing system, and the first subsystem identifier is associated with the system identifier. Next, the computing device receives, from a second media playback device connected to the first network, a second registration message. Then, in response to receiving the second registration message, the computing device assigns the system identifier and the first subsystem identifier to the second media playback device. The computing device then determines that the second media playback device is disconnected from the first network and connected to a second network. Next, in response to determining that the second media playback device is connected to the second network, the computing device assigns a second subsystem identifier to the second media playback device. The second subsystem identifier is associated with the system identifier. The computing system then transmits to the second media playback device, a message comprising the second subsystem identifier. Finally, the computing device receives a request directed to devices associated with the second subsystem identifier, and based on the request being directed to devices associated with the second subsystem identifier, causes the second media playback device to process the request.

This above-described procedure is useful in scenarios where it is difficult for a cloud computing system to keep track of where devices are located so that the cloud computing system can determine which devices might need configuration changes at a second location when a user makes configuration changes to the devices at a second location. For example, when a user issues a command to the cloud computing system to skip the currently playing song, the user likely wants the command to be applied to the devices that are connected in the same location as the user. In response to receiving the command, the cloud computing system issues a skip song command only to devices at the location at which the user is connected. By assigning subsystem identifiers to playback devices based on location, a cloud computing system can more effectively route commands that are intended for devices that are in a particular location (e.g., devices that have a particular subsystem identifier).

A second example embodiment involves a first media playback device connecting to a first network. The first media playback device then transmits to a computing system, a first registration message. Next, the first media playback device receives, from the computing system, a system identifier and a first subsystem identifier. The first subsystem identifier is associated with the system identifier. Later, after the first media playback device disconnects from the first network, the first media playback device connects to a second network. After connecting to the second network, the first media playback device transmits, to the computing system, a second registration message. After transmitting the second registration message, the first media playback device then receives, from the computing system, a second subsystem identifier. The second subsystem identifier is associated with the system identifier. Next, the first media playback device configures the first media playback device to use the second subsystem identifier. Finally, the first media playback device receives, from the computing system, one or more commands to implement a change affecting all devices to which the first subsystem identifier has been assigned.

Some embodiments include an article of manufacture comprising tangible, non-transitory, computer-readable media storing program instructions that, upon execution by one or more processors of a playback device, cause the playback device to perform operations in accordance with the example embodiments disclosed herein.

Some embodiments include a playback device comprising one or more processors, as well as tangible, non-transitory, computer-readable media storing program instructions that, upon execution by the one or more processors, cause the playback device to perform operations in accordance with the example embodiments disclosed herein.

This summary overview is illustrative only and is not intended to be limiting.

The drawings are for the purpose of illustrating example embodiments, but it is understood that the inventions are not limited to the arrangements and instrumentalities shown in the drawings.

A media playback system according to some embodiments disclosed herein includes a number of media playback devices connected to a computing system. The media playback devices may include audio playback devices, video playback devices, and/or networked microphone devices. In operation, the computing system assigns the media playback devices a system identifier, which indicates that each of the media playback devices is part of the media playback system. In this type of media playback system, when a change (e.g., setting and/or configuration) is made on one of the media playback devices, the computing system issues one or more commands to implement the change on the other media playback devices that were assigned the system identifier. The media playback devices then implement the change in response to receiving the one or more commands from the computing system.

While using a system identifier may be effective in media playback systems located on one local area network (LAN), it might not be as effective in media playback systems spread across multiple LANs. This is due in part to typical computing systems being limited to issuing commands on one network. For example, a user may have a first media playback device in a first location (e.g., a playback device at work) and a second media playback device in a second location (e.g., a networked microphone device at home). Using a conventional computing system, if a user makes a configuration change on the first media playback device, the change would not be applied to the second media playback device. To implement the configuration change on the second media playback device, the user would have to subsequently make the configuration change on the second media playback device, resulting in duplicative efforts. However, with the development of cloud server technology in accordance with aspects described herein, the computing system according to some embodiments has the ability to propagate changes made on the first media playback device to the second media playback device, even though the first and second media playback devices are located on different LANs.

One challenge with using a computing system individually or in combination with cloud server technology to propagate changes to media playback devices connected to different networks in different locations is that a system identifier might not adequately identify which media playback device belongs to each network, and/or it may not accurately or adequately indicate which media playback devices are connected to which network. To overcome this challenge, in some embodiments, the computing system assigns a subsystem identifier to each media playback device in the media playback system. The subsystem identifier is unique to the network to which the media playback device is connected. In operation, the computing system assigns a first subsystem identifier to a first media playback device connected to a first network (e.g., a playback device connected to a user's home network) and a second subsystem identifier to a second media playback device connected to a second network (e.g., a networked microphone device connected to a user's work network). Then, if a user makes a configuration change on the first media playback device, the computing system (i) sends a command to implement the change to all other media playback devices that have been assigned the first subsystem identifier, and subsequently (ii) send a command to implement the change to all other media playback devices that have been assigned the second subsystem identifier.

In some embodiments, a user may set up and connect a first media playback device and second media playback device to a first network. In response, the computing system may assign the same subsystem identifier to the first and second media playback devices. Subsequently, the user may move the second media playback device and connect it to a second network. The computing system may then determine the second media playback system has been disconnected from the first network and connected to the second network, then assign a different subsystem identifier to the second media playback device. As explained in further detail below, the computing system may assign media playback devices different subsystem identifiers based on a physical location and information about the media playback devices themselves.

<FIG> shows an example configuration of a media playback system <NUM> in which one or more embodiments disclosed herein may be practiced or implemented. The media playback system <NUM> as shown is associated with an example home environment having several rooms and spaces, such as for example, a master bedroom, an office, a dining room, and a living room. As shown in the example of <FIG>, the media playback system <NUM> includes playback devices <NUM>-<NUM>, control devices <NUM> and <NUM>, and a wired or wireless network router <NUM>. In operation, any of the playback devices (PBDs) <NUM>-<NUM> may be voice-enabled devices (VEDs) as described earlier.

<FIG> shows a functional block diagram of an example playback device <NUM> that may be configured to be one or more of the playback devices <NUM>-<NUM> of the media playback system <NUM> of <FIG>. As described above, a playback device (PBD) <NUM> is one type of voice-enabled device (VED).

The playback device <NUM> includes one or more processors <NUM>, software components <NUM>, memory <NUM>, audio processing components <NUM>, audio amplifier(s) <NUM>, speaker(s) <NUM>, a network interface <NUM> including wireless interface(s) <NUM> and wired interface(s) <NUM>, and microphone(s) <NUM>. In one case, the playback device <NUM> may not include the speaker(s) <NUM>, but rather a speaker interface for connecting the playback device <NUM> to external speakers. In another case, the playback device <NUM> may include neither the speaker(s) <NUM> nor the audio amplifier(s) <NUM>, but rather an audio interface for connecting the playback device <NUM> to an external audio amplifier or audio-visual receiver.

In some examples, the one or more processors <NUM> include one or more clock-driven computing components configured to process input data according to instructions stored in the memory <NUM>. The memory <NUM> may be a tangible, non-transitory computer-readable medium configured to store instructions executable by the one or more processors <NUM>. For instance, the memory <NUM> may be data storage that can be loaded with one or more of the software components <NUM> executable by the one or more processors <NUM> to achieve certain functions. In one example, the functions may involve the playback device <NUM> retrieving audio data from an audio source or another playback device. In another example, the functions may involve the playback device <NUM> sending audio data to another device or playback device on a network. In yet another example, the functions may involve pairing of the playback device <NUM> with one or more playback devices to create a multi-channel audio environment.

Certain functions may involve the playback device <NUM> synchronizing playback of audio content with one or more other playback devices. During synchronous playback, a listener will preferably not be able to perceive time-delay differences between playback of the audio content by the playback device <NUM> and the one or more other playback devices. <CIT> entitled, "System and method for synchronizing operations among a plurality of independently clocked digital data processing devices," which is hereby incorporated by reference, provides in more detail some examples for audio playback synchronization among playback devices.

The memory <NUM> may further be configured to store data associated with the playback device <NUM>, such as one or more zones and/or zone groups the playback device <NUM> is a part of, audio sources accessible by the playback device <NUM>, or a playback queue that the playback device <NUM> (or some other playback device) may be associated with. The data may be stored as one or more state variables that are periodically updated and used to describe the state of the playback device <NUM>. The memory <NUM> may also include the data associated with the state of the other devices of the media system, and shared from time to time among the devices so that one or more of the devices have the most recent data associated with the system. Other embodiments are also possible.

The audio processing components <NUM> may include one or more digital-to-analog converters (DAC), an audio preprocessing component, an audio enhancement component or a digital signal processor (DSP), and so on. In one embodiment, one or more of the audio processing components <NUM> may be a subcomponent of the one or more processors <NUM>. In one example, audio content may be processed and/or intentionally altered by the audio processing components <NUM> to produce audio signals. The produced audio signals may then be provided to the audio amplifier(s) <NUM> for amplification and playback through speaker(s) <NUM>. Particularly, the audio amplifier(s) <NUM> may include devices configured to amplify audio signals to a level for driving one or more of the speakers <NUM>. The speaker(s) <NUM> may include an individual transducer (e.g., a "driver") or a complete speaker system involving an enclosure with one or more drivers. A particular driver of the speaker(s) <NUM> may include, for example, a subwoofer (e.g., for low frequencies), a mid-range driver (e.g., for middle frequencies), and/or a tweeter (e.g., for high frequencies). In some cases, each transducer in the one or more speakers <NUM> may be driven by an individual corresponding audio amplifier of the audio amplifier(s) <NUM>. In addition to producing analog signals for playback by the playback device <NUM>, the audio processing components <NUM> may be configured to process audio content to be sent to one or more other playback devices for playback.

Audio content to be processed and/or played back by the playback device <NUM> may be received from an external source, such as via an audio line-in input connection (e.g., an auto-detecting <NUM> audio line-in connection) or the network interface <NUM>.

The network interface <NUM> may be configured to facilitate a data flow between the playback device <NUM> and one or more other devices on a data network, including but not limited to data to/from other VEDs (e.g., commands to perform an SPL measurement, SPL measurement data, commands to set a system response volume, and other data and/or commands to facilitate performance of the features and functions disclosed and described herein). As such, the playback device <NUM> may be configured to receive audio content over the data network from one or more other playback devices in communication with the playback device <NUM>, network devices within a local area network, or audio content sources over a wide area network such as the Internet. The playback device <NUM> may transmit metadata to and/or receive metadata from other devices on the network, including but not limited to components of the networked microphone system disclosed and described herein. In one example, the audio content and other signals (e.g., metadata and other signals) transmitted and received by the playback device <NUM> may be transmitted in the form of digital packet data containing an Internet Protocol (IP)-based source address and IP-based destination addresses. In such a case, the network interface <NUM> may be configured to parse the digital packet data such that the data destined for the playback device <NUM> is properly received and processed by the playback device <NUM>.

As shown, the network interface <NUM> may include wireless interface(s) <NUM> and wired interface(s) <NUM>. The wireless interface(s) <NUM> may provide network interface functions for the playback device <NUM> to wirelessly communicate with other devices (e.g., other playback device(s), speaker(s), receiver(s), network device(s), control device(s) within a data network the playback device <NUM> is associated with) in accordance with a communication protocol (e.g., any wireless standard including IEEE <NUM>. 11a, <NUM>. 11b, <NUM>, <NUM>. 11n, <NUM>. 11ac, <NUM>, <NUM> mobile communication standard, and so on). The wired interface(s) <NUM> may provide network interface functions for the playback device <NUM> to communicate over a wired connection with other devices in accordance with a communication protocol (e.g., IEEE <NUM>). While the network interface <NUM> shown in <FIG> includes both wireless interface(s) <NUM> and wired interface(s) <NUM>, the network interface <NUM> may in some embodiments include only wireless interface(s) or only wired interface(s).

The microphone(s) <NUM> may be arranged to detect sound in the environment of the playback device <NUM>. For instance, the microphone(s) may be mounted on an exterior wall of a housing of the playback device. The microphone(s) may be any type of microphone now known or later developed such as a condenser microphone, electret condenser microphone, or a dynamic microphone. The microphone(s) may be sensitive to a portion of the frequency range of the speaker(s) <NUM>. One or more of the speaker(s) <NUM> may operate in reverse as the microphone(s) <NUM>. In some aspects, the playback device <NUM> might not have microphone(s) <NUM>.

In one example, the playback device <NUM> and one other playback device may be paired to play two separate audio components of audio content. For instance, playback device <NUM> may be configured to play a left channel audio component, while the other playback device may be configured to play a right channel audio component, thereby producing or enhancing a stereo effect of the audio content. The paired playback devices (also referred to as "bonded playback devices", "bonded group", or "stereo pair") may further play audio content in synchrony with other playback devices.

In another example, the playback device <NUM> may be sonically consolidated with one or more other playback devices to form a single, consolidated playback device. A consolidated playback device may be configured to process and reproduce sound differently than an unconsolidated playback device or playback devices that are paired, because a consolidated playback device may have additional audio drivers through which audio content may be rendered. For instance, if the playback device <NUM> is a playback device designed to render low frequency range audio content (i.e. a subwoofer), the playback device <NUM> may be consolidated with a playback device designed to render full frequency range audio content. In such a case, the full frequency range playback device, when consolidated with the low frequency playback device <NUM>, may be configured to render only the mid and high frequency components of audio content, while the low frequency range playback device <NUM> renders the low frequency component of the audio content. The consolidated playback device may further be paired with a single playback device or yet another consolidated playback device.

By way of illustration, Sonos, Inc. presently offers (or has offered) for sale certain playback devices including a "PLAY:<NUM>," "PLAY:<NUM>," "PLAY:<NUM>," "PLAYBAR," "CONNECT:AMP," "CONNECT," and "SUB. " Any other past, present, and/or future playback devices may additionally or alternatively be used to implement the playback devices of example embodiments disclosed herein. Additionally, it is understood that a playback device is not limited to the example illustrated in <FIG> or to the Sonos product offerings. For example, a playback device may include a wired or wireless headphone. In another example, a playback device may include or interact with a docking station for personal mobile media playback devices. In yet another example, a playback device may be integral to another device or component such as a television, a lighting fixture, or some other device for indoor or outdoor use.

Referring back to the media playback system <NUM> of <FIG>, the environment may have one or more playback zones, each with one or more playback devices and/or other VEDs. The media playback system <NUM> may be established with one or more playback zones, after which one or more zones may be added, or removed to arrive at the example configuration shown in <FIG>. Each zone may be given a name according to a different room or space such as an office, bathroom, master bedroom, bedroom, kitchen, dining room, living room, and/or balcony. In one case, a single playback zone may include multiple rooms or spaces. In another case, a single room or space may include multiple playback zones.

As shown in <FIG>, the balcony, dining room, kitchen, bathroom, office, and bedroom zones each have one playback device, while the living room and master bedroom zones each have multiple playback devices. In the living room zone, playback devices <NUM>, <NUM>, <NUM>, and <NUM> may be configured to play audio content in synchrony as individual playback devices, as one or more bonded playback devices, as one or more consolidated playback devices, or any combination thereof. Similarly, in the case of the master bedroom, playback devices <NUM> and <NUM> may be configured to play audio content in synchrony as individual playback devices, as a bonded playback device, or as a consolidated playback device.

In one example, one or more playback zones in the environment of <FIG> may each be playing different audio content. For instance, the user may be grilling in the balcony zone and listening to hip hop music being played by the playback device <NUM> while another user may be preparing food in the kitchen zone and listening to classical music being played by the playback device <NUM>. In another example, a playback zone may play the same audio content in synchrony with another playback zone. For instance, the user may be in the office zone where the playback device <NUM> is playing the same rock music that is being playing by playback device <NUM> in the balcony zone. In such a case, playback devices <NUM> and <NUM> may be playing the rock music in synchrony such that the user may seamlessly (or at least substantially seamlessly) enjoy the audio content that is being played out-loud while moving between different playback zones. Synchronization among playback zones may be achieved in a manner similar to that of synchronization among playback devices, as described in previously referenced <CIT>.

Further, different playback zones of the media playback system <NUM> may be dynamically combined into zone groups or split up into individual playback zones. For instance, the dining room zone and the kitchen zone may be combined into a zone group for a dinner party such that playback devices <NUM> and <NUM> may render (e.g., play back) audio content in synchrony. On the other hand, the living room zone may be split into a television zone including playback device <NUM>, and a listening zone including playback devices <NUM>, <NUM>, and <NUM>, if the user wishes to listen to music in the living room space while another user wishes to watch television.

<FIG> shows a functional block diagram of an example control device <NUM> that may be configured to be one or both of the control devices <NUM> and <NUM> of the media playback system <NUM>. As shown, the control device <NUM> may include one or more processors <NUM>, memory <NUM>, a network interface <NUM>, a user interface <NUM>, microphone(s) <NUM>, and software components <NUM>. In one example, the control device <NUM> may be a dedicated controller for the media playback system <NUM>. In another example, the control device <NUM> may be a network device on which media playback system controller application software may be installed, such as for example, an iPhone™, iPad™ or any other smart phone, tablet or network device (e.g., a networked computer such as a PC or Mac™).

The one or more processors <NUM> may be configured to perform functions relevant to facilitating user access, control, and configuration of the media playback system <NUM>. The memory <NUM> may be data storage that can be loaded with one or more of the software components executable by the one or more processors <NUM> to perform those functions. The memory <NUM> may also be configured to store the media playback system controller application software and other data associated with the media playback system <NUM> and the user.

In one example, the network interface <NUM> may be based on an industry standard (e.g., infrared, radio, wired standards including IEEE <NUM>, wireless standards including IEEE <NUM>. 11a, <NUM>. 11b, <NUM>, <NUM>. 11n, <NUM>. 11ac, <NUM>, <NUM>, <NUM>, or <NUM> mobile communication standards, and so on). The network interface <NUM> may provide a means for the control device <NUM> to communicate with other devices in the media playback system <NUM>. In one example, data and information (e.g., such as a state variable) may be communicated between control device <NUM> and other devices via the network interface <NUM>. For instance, playback zone and zone group configurations in the media playback system <NUM> may be received by the control device <NUM> from a playback device or another network device, or transmitted by the control device <NUM> to another playback device or network device via the network interface <NUM>. In some cases, the other network device may be another control device.

Playback device control commands such as volume control and audio playback control may also be communicated from the control device <NUM> to a playback device via the network interface <NUM>. As suggested above, changes to configurations of the media playback system <NUM> may also be performed by a user using the control device <NUM>. The configuration changes may include adding/removing one or more playback devices to/from a zone, adding/removing one or more zones to/from a zone group, forming a bonded or consolidated player, separating one or more playback devices from a bonded or consolidated player, among others. Accordingly, the control device <NUM> may sometimes be referred to as a controller, whether the control device <NUM> is a dedicated controller or a network device on which media playback system controller application software is installed.

Control device <NUM> may include microphone(s) <NUM>. Microphone(s) <NUM> may be arranged to detect sound in the environment of the control device <NUM>. Microphone(s) <NUM> may be any type of microphone now known or later developed such as a condenser microphone, electret condenser microphone, or a dynamic microphone. The microphone(s) may be sensitive to a portion of a frequency range. Two or more microphones <NUM> may be arranged to capture location information of an audio source (e.g., voice, audible sound) and/or to assist in filtering background noise.

The user interface <NUM> of the control device <NUM> may be configured to facilitate user access and control of the media playback system <NUM>, by providing a controller interface such as the example controller interface <NUM> shown in <FIG>. The controller interface <NUM> includes a playback control region <NUM>, a playback zone region <NUM>, a playback status region <NUM>, a playback queue region <NUM>, and an audio content sources region <NUM>. The user interface <NUM> as shown is just one example of a user interface that may be provided on a network device such as the control device <NUM> of <FIG> (and/or the control devices <NUM> and <NUM> of <FIG>) and accessed by users to control a media playback system such as the media playback system <NUM>. Other user interfaces of varying formats, styles, and interactive sequences may alternatively be implemented on one or more network devices to provide comparable control access to a media playback system.

For example, as shown, a "group" icon may be provided within each of the graphical representations of playback zones. The "group" icon provided within a graphical representation of a particular zone may be selectable to bring up options to select one or more other zones in the media playback system to be grouped with the particular zone. Once grouped, playback devices in the zones that have been grouped with the particular zone will be configured to play audio content in synchrony with the playback device(s) in the particular zone. Analogously, a "group" icon may be provided within a graphical representation of a zone group. In this case, the "group" icon may be selectable to bring up options to deselect one or more zones in the zone group to be removed from the zone group. Other interactions and implementations for grouping and ungrouping zones via a user interface such as the user interface <NUM> are also possible. The representations of playback zones in the playback zone region <NUM> may be dynamically updated as playback zone or zone group configurations are modified.

The playback status region <NUM> may include graphical representations of audio content that is presently being played, previously played, or scheduled to play next in the selected playback zone or zone group. The selected playback zone or zone group may be visually distinguished on the user interface, such as within the playback zone region <NUM> and/or the playback status region <NUM>. The graphical representations may include track title, artist name, album name, album year, track length, and other relevant information that may be useful for the user to know when controlling the media playback system via the user interface <NUM>.

Referring back to the user interface <NUM> of <FIG>, the graphical representations of audio content in the playback queue region <NUM> may include track titles, artist names, track lengths, and other relevant information associated with the audio content in the playback queue. In one example, graphical representations of audio content may be selectable to bring up additional selectable icons to manage and/or manipulate the playback queue and/or audio content represented in the playback queue. For instance, a represented audio content may be removed from the playback queue, moved to a different position within the playback queue, or selected to be played immediately, or after any currently playing audio content, among other possibilities. A playback queue associated with a playback zone or zone group may be stored in a memory on one or more playback devices in the playback zone or zone group, on a playback device that is not in the playback zone or zone group, and/or some other designated device.

As indicated previously, one or more playback devices in a zone or zone group may be configured to retrieve for playback audio content (e.g. according to a corresponding URI or URL for the audio content) from a variety of available audio content sources. In one example, audio content may be retrieved by a playback device directly from a corresponding audio content source (e.g., a line-in connection). In another example, audio content may be provided to a playback device over a network via one or more other playback devices or network devices.

Example audio content sources may include a memory of one or more playback devices in a media playback system such as the media playback system <NUM> of <FIG>, local music libraries on one or more network devices (such as a control device, a network-enabled personal computer, or a networked-attached storage (NAS), for example), streaming audio services providing audio content via the Internet (e.g., the cloud), or audio sources connected to the media playback system via a line-in input connection on a playback device or network devise, among other possibilities.

<FIG> shows an example plurality of network devices <NUM> that can be configured to provide an audio playback experience with voice control. One having ordinary skill in the art will appreciate that the devices shown in <FIG> are for illustrative purposes only, and variations including different and/or additional (or fewer) devices may be possible. As shown, the plurality of network devices <NUM> includes computing devices <NUM>, <NUM>, and <NUM>; network microphone devices (NMDs) <NUM>, <NUM>, and <NUM>; playback devices (PBDs) <NUM>, <NUM>, <NUM>, and <NUM>; and a controller device (CR) <NUM>. As described previously, any one or more (or all) of the NMDs <NUM>-<NUM>, PBDs <NUM>-<NUM>, and/or CR <NUM> may be voice-enabled devices (VEDs).

Each of the plurality of network devices <NUM> are network-capable devices that can establish communication with one or more other devices in the plurality of devices according to one or more network protocols, such as NFC, Bluetooth™, Ethernet, and IEEE <NUM>, among other examples, over one or more types of networks, such as wide area networks (WAN), local area networks (LAN), and personal area networks (PAN), among other possibilities.

As shown, the computing devices <NUM>, <NUM>, and <NUM> are part of a cloud network <NUM>. The cloud network <NUM> may include additional computing devices (not shown). In one example, the computing devices <NUM>, <NUM>, and <NUM> may be different servers. In another example, two or more of the computing devices <NUM>, <NUM>, and <NUM> may be modules of a single server. Analogously, each of the computing device <NUM>, <NUM>, and <NUM> may include one or more modules or servers. For ease of illustration purposes herein, each of the computing devices <NUM>, <NUM>, and <NUM> may be configured to perform particular functions within the cloud network <NUM>. For instance, computing device <NUM> may be a source of audio content for a streaming music service.

As shown, the computing device <NUM> may be configured to interface with NMDs <NUM>, <NUM>, and <NUM> via communication path <NUM>. NMDs <NUM>, <NUM>, and <NUM> may be components of one or more "Smart Home" systems. In one case, NMDs <NUM>, <NUM>, and <NUM> may be physically distributed throughout a household, similar to the distribution of devices shown in <FIG>. In another case, two or more of the NMDs <NUM>, <NUM>, and <NUM> may be physically positioned within relative close proximity of one another. Communication path <NUM> may comprise one or more types of networks, such as a WAN including the Internet, LAN, and/or PAN, among other possibilities.

In one example, one or more of the NMDs <NUM>, <NUM>, and <NUM> are devices configured primarily for audio detection. In another example, one or more of the NMDs <NUM>, <NUM>, and <NUM> may be components of devices having various primary utilities. For instance, as discussed above in connection to <FIG>, one or more of NMDs <NUM>, <NUM>, and <NUM> may be (or at least may include or be a component of) the microphone(s) <NUM> of playback device <NUM> or the microphone(s) <NUM> of network device <NUM>. Further, in some cases, one or more of NMDs <NUM>, <NUM>, and <NUM> may be (or at least may include or be a component of) the playback device <NUM> or network device <NUM>. In an example, one or more of NMDs <NUM>, <NUM>, and/or <NUM> may include multiple microphones arranged in a microphone array. In some embodiments, one or more of NMDs <NUM>, <NUM>, and/or <NUM> may be a microphone on a mobile computing device (e.g., a smartphone, tablet, or other computing device).

As shown, the computing device <NUM> is configured to interface with CR <NUM> and PBDs <NUM>, <NUM>, <NUM>, and <NUM> via communication path <NUM>. In one example, CR <NUM> may be a network device such as the network device <NUM> of <FIG>. Accordingly, CR <NUM> may be configured to provide the controller interface <NUM> of <FIG>. Similarly, PBDs <NUM>, <NUM>, <NUM>, and <NUM> may be playback devices such as the playback device <NUM> of <FIG>. As such, PBDs <NUM>, <NUM>, <NUM>, and <NUM> may be physically distributed throughout a household as shown in <FIG>. For illustration purposes, PBDs <NUM> and <NUM> are shown as members of a bonded zone <NUM>, while PBDs <NUM> and <NUM> are members of their own respective zones. As described above, the PBDs <NUM>, <NUM>, <NUM>, and <NUM> may be dynamically bonded, grouped, unbonded, and ungrouped. Communication path <NUM> may comprise one or more types of networks, such as a WAN including the Internet, LAN, and/or PAN, among other possibilities.

In one example, as with NMDs <NUM>, <NUM>, and <NUM>, CR <NUM> and PBDs <NUM>, <NUM>, <NUM>, and <NUM> may also be components of one or more "Smart Home" systems. In one case, PBDs <NUM>, <NUM>, <NUM>, and <NUM> may be distributed throughout the same household as the NMDs <NUM>, <NUM>, and <NUM>. Further, as suggested above, one or more of PBDs <NUM>, <NUM>, <NUM>, and <NUM> may be one or more of NMDs <NUM>, <NUM>, and <NUM>. For example, any one or more (or perhaps all) of NMDs <NUM>-<NUM>, PBDs <NUM>-<NUM>, and/or CR <NUM> may be voice-enabled devices (VEDs).

The NMDs <NUM>, <NUM>, and <NUM> may be part of a local area network, and the communication path <NUM> may include an access point that links the local area network of the NMDs <NUM>, <NUM>, and <NUM> to the computing device <NUM> over a WAN (communication path not shown). Likewise, each of the NMDs <NUM>, <NUM>, and <NUM> may communicate with each other via such an access point.

Similarly, CR <NUM> and PBDs <NUM>, <NUM>, <NUM>, and <NUM> may be part of a local area network and/or a local playback network as discussed in previous sections, and the communication path <NUM> may include an access point that links the local area network and/or local playback network of CR <NUM> and PBDs <NUM>, <NUM>, <NUM>, and <NUM> to the computing device <NUM> over a WAN. As such, each of the CR <NUM> and PBDs <NUM>, <NUM>, <NUM>, and <NUM> may also communicate with each over such an access point.

In one example, communication paths <NUM> and <NUM> may comprise the same access point. In an example, each of the NMDs <NUM>, <NUM>, and <NUM>, CR <NUM>, and PBDs <NUM>, <NUM>, <NUM>, and <NUM> may access the cloud network <NUM> via the same access point for a household.

As shown in <FIG>, each of the NMDs <NUM>, <NUM>, and <NUM>, CR <NUM>, and PBDs <NUM>, <NUM>, <NUM>, and <NUM> may also directly communicate with one or more of the other devices via communication means <NUM>. Communication means <NUM> as described herein may involve and/or include one or more forms of communication between the devices, according to one or more network protocols, over one or more types of networks, and/or may involve communication via one or more other network devices. For instance, communication means <NUM> may include one or more of for example, Bluetooth™ (IEEE <NUM>), NFC, Wireless direct, and/or Proprietary wireless, among other possibilities.

In one example, CR <NUM> may communicate with NMD <NUM> over Bluetooth™, and communicate with PBD <NUM> over another local area network. In another example, NMD <NUM> may communicate with CR <NUM> over another local area network, and communicate with PBD <NUM> over Bluetooth™. In a further example, each of the PBDs <NUM>, <NUM>, <NUM>, and <NUM> may communicate with each other according to a spanning tree protocol over a local playback network, while each communicating with CR <NUM> over a local area network, different from the local playback network.

In some cases, communication means between the NMDs <NUM>, <NUM>, and <NUM>, CR <NUM>, and PBDs <NUM>, <NUM>, <NUM>, and <NUM> may be different (or perhaps change) depending on types of communication requirements between the devices, network conditions, and/or latency demands. For instance, communication means <NUM> may be used when NMD <NUM> is first introduced to the household with the PBDs <NUM>, <NUM>, <NUM>, and <NUM>. In one case, the NMD <NUM> may transmit identification information corresponding to the NMD <NUM> to PBD <NUM> via NFC, and PBD <NUM> may in response, transmit local area network information to NMD <NUM> via NFC (or some other form of communication). However, once NMD <NUM> has been configured within the household, communication means between NMD <NUM> and PBD <NUM> may change. For instance, NMD <NUM> may subsequently communicate with PBD <NUM> via communication path <NUM>, the cloud network <NUM>, and communication path <NUM>. In another example, the NMDs and PBDs may never communicate via local communications means <NUM>. In a further example, the NMDs and PBDs may communicate primarily via local communications means <NUM>.

In an illustrative example, NMDs <NUM>, <NUM>, and <NUM> may be configured to receive voice inputs to control PBDs <NUM>, <NUM>, <NUM>, and <NUM>. The available control commands may include any media playback system controls previously discussed, such as playback volume control, playback transport controls, music source selection, and grouping, among other possibilities. In one instance, NMD <NUM> may receive a voice input to control one or more of the PBDs <NUM>, <NUM>, <NUM>, and <NUM>. In response to receiving the voice input, NMD <NUM> may transmit via communication path <NUM>, the voice input to computing device <NUM> for processing. In one example, the computing device <NUM> may convert the voice input to an equivalent text command, and parse the text command to identify a command. Computing device <NUM> may then subsequently transmit the text command to the computing device <NUM>, and computing device <NUM> in turn may then control one or more of PBDs <NUM>-<NUM> to execute the command. In another example, the computing device <NUM> may convert the voice input to an equivalent text command, and then subsequently transmit the text command to the computing device <NUM>. The computing device <NUM> may then parse the text command to identify one or more playback commands, and then computing device <NUM> may additionally control one or more of PBDs <NUM>-<NUM> to execute the command.

For instance, if the text command is "Play `Track <NUM>' by `Artist <NUM>' from `Streaming Service <NUM>' in 'Zone <NUM>'," The computing device <NUM> may identify (i) a URL for "Track <NUM>" by "Artist <NUM>" available from "Streaming Service <NUM>," and (ii) at least one playback device in "Zone <NUM>. " In this example, the URL for "Track <NUM>" by "Artist <NUM>" from "Streaming Service <NUM>" may be a URL pointing to computing device <NUM>, and "Zone <NUM>" may be the bonded zone <NUM>. As such, upon identifying the URL and one or both of PBDs <NUM> and <NUM>, the computing device <NUM> may transmit via communication path <NUM> to one or both of PBDs <NUM> and <NUM>, the identified URL for playback. One or both of PBDs <NUM> and <NUM> may responsively retrieve audio content from the computing device <NUM> according to the received URL, and begin playing "Track <NUM>" by "Artist <NUM>" from "Streaming Service <NUM>.

One having ordinary skill in the art will appreciate that the above is just one illustrative example, and that other implementations are also possible. In one case, operations performed by one or more of the plurality of network devices <NUM>, as described above, may be performed by one or more other devices in the plurality of network devices <NUM>. For instance, the conversion from voice input to the text command may be alternatively, partially, or wholly performed by another device or devices, such as CR <NUM>, NMD <NUM>, computing device <NUM>, PBD <NUM>, and/or PBD <NUM>. Analogously, the identification of the URL may be alternatively, partially, or wholly performed by another device or devices, such as NMD <NUM>, computing device <NUM>, PBD <NUM>, and/or PBD <NUM>.

<FIG> shows a function block diagram of an example network microphone device <NUM> that may be configured to be one or more of NMDs <NUM>, <NUM>, and <NUM> of <FIG>, and/or any of the VEDs disclosed and described herein. As shown, the network microphone device <NUM> includes one or more processors <NUM>, tangible, non-transitory computer-readable memory <NUM>, a microphone array <NUM> (e.g., one or more microphones), a network interface <NUM>, a user interface <NUM>, software components <NUM>, and speaker(s) <NUM>. One having ordinary skill in the art will appreciate that other network microphone device configurations and arrangements are also possible. For instance, network microphone devices may alternatively exclude the speaker(s) <NUM> or have a single microphone instead of microphone array <NUM>.

The one or more processors <NUM> may include one or more processors and/or controllers, which may take the form of a general or special-purpose processor or controller. For instance, the one or more processors <NUM> may include microprocessors, microcontrollers, application-specific integrated circuits, digital signal processors, and the like. The tangible, non-transitory computer-readable memory <NUM> may be data storage that can be loaded with one or more of the software components executable by the one or more processors <NUM> to perform those functions. Accordingly, memory <NUM> may comprise one or more non-transitory computer-readable storage mediums, examples of which may include volatile storage mediums such as random access memory, registers, cache, etc. and non-volatile storage mediums such as read-only memory, a hard-disk drive, a solid-state drive, flash memory, and/or an optical-storage device, among other possibilities.

The microphone array <NUM> may be a plurality of microphones arranged to detect sound in the environment of the network microphone device <NUM>. Microphone array <NUM> may include any type of microphone now known or later developed such as a condenser microphone, electret condenser microphone, or a dynamic microphone, among other possibilities. In one example, the microphone array may be arranged to detect audio from one or more directions relative to the network microphone device. The microphone array <NUM> may be sensitive to a portion of a frequency range. In one example, a first subset of the microphone array <NUM> may be sensitive to a first frequency range, while a second subset of the microphone array may be sensitive to a second frequency range. The microphone array <NUM> may further be arranged to capture location information of an audio source (e.g., voice, audible sound) and/or to assist in filtering background noise. Notably, in some embodiments the microphone array may consist of only a single microphone, rather than a plurality of microphones.

The network interface <NUM> may be configured to facilitate wireless and/or wired communication between various network devices, such as, in reference to <FIG>, CR <NUM>, PBDs <NUM>- <NUM>, computing devices <NUM>-<NUM> in cloud network <NUM>, and other network microphone devices, among other possibilities. As such, network interface <NUM> may take any suitable form for carrying out these functions, examples of which may include an Ethernet interface, a serial bus interface (e.g., FireWire, USB <NUM>, etc.), a chipset and antenna adapted to facilitate wireless communication, and/or any other interface that provides for wired and/or wireless communication. In one example, the network interface <NUM> may be based on an industry standard (e.g., infrared, radio, wired standards including IEEE <NUM>, wireless standards including IEEE <NUM>. 11a, <NUM>. 11b, <NUM>, <NUM>. 11n, <NUM>. 11ac, <NUM>, <NUM> mobile communication standard, and so on).

The user interface <NUM> of the network microphone device <NUM> may be configured to facilitate user interactions with the network microphone device. In one example, the user interface <NUM> may include one or more of physical buttons, graphical interfaces provided on touch sensitive screen(s) and/or surface(s), among other possibilities, for a user to directly provide input to the network microphone device <NUM>. The user interface <NUM> may further include one or more of lights and the speaker(s) <NUM> to provide visual and/or audio feedback to a user. In one example, the network microphone device <NUM> may further be configured to playback audio content via the speaker(s) <NUM>.

In previous media playback systems, media playback devices were intended to remain stationary in a user's home or workplace. When media playback devices were moved from one location to another (e.g., from a user's home to the user's workplace), previous settings on the playback devices might not have carried over, and the user might have had to set up a new media playback system at the new location. The media playback devices at the user's home might not have been able to interact with the media playback devices at the user's workplace. Users have the ability to control their media playback system while connected to networks other than the network to which the media playback system is connected via the cloud. However, this development has presented unique technical challenges for controlling media playback systems with media playback devices connected in multiple locations. These technical challenges, among others, may include a cloud server being unable to distinguish which media playback devices are connected at which locations.

For example, if a first media playback device and a second media playback device are first powered on and initialized at a first location, the cloud server assigns a system identifier to the first media playback device and the second media playback device. The system identifier indicates that the first media playback device and the second media playback device are members of a single media playback system, and connected to the cloud server. However, if the second media playback device is subsequently moved to a second location, the second media playback device retains the same system identifier but might be unable to communicate with the first media playback device because the two devices are on different local area networks. Accordingly, if the cloud server sends a command to implement a configuration change to devices associated with the system identifier, one of the first media playback device or the second media playback device receives and handles the request, but the other media playback device might not receive the command from the cloud server after having been moved to the second location. This may result in an undesirable outcome if a user was attempting to issue the configuration change to a specific media playback device or both the first media playback device and the second media playback device. For example, if a user updates a playlist for the media playback system via the cloud server, one of the first or second media playback devices might update the playlist but the other of the first or second playback devices may not receive the playlist update command from the cloud server because of the first and second playback devices being connected to different local networks in different locations.

To overcome this problem, some embodiments include the cloud server assigning a subsystem identifier to the first media playback device and second media playback device. The subsystem identifier is a site-specific identifier that provides a cloud server the ability to identify which media playback devices are connected to which local networks, where each location has a separate local network. The cloud server updates the subsystem identifier for the various media playback devices when they move locations (including returning to a previous location). Thus, the embodiments described herein facilitate the control of media playback devices that are in different locations and/or connected to different networks.

<FIG> is a communication flow diagram of an example media playback system <NUM> that includes PBDs <NUM> and <NUM> at location <NUM> that are connected to computing system <NUM>. The communication flow shown in <FIG> depicts the communication between PBDs <NUM> and <NUM> upon initialization (e.g., when PBDs <NUM> and <NUM> are powered on and connected to the Internet for the first time). While the media playback devices shown in <FIG> are PBDs, any networked device may be used (e.g., NMDs and/or VEDs).

PBDs <NUM> and <NUM> are connected to computing system <NUM> through any of communication means <NUM>, as described above with respect to <FIG>. For example, PBD <NUM> may be connected to computing system <NUM> over the Internet via a router. The router may include a wired or wireless network router, such as network router <NUM> as described above with respect to <FIG>. Computing system <NUM> includes a cloud-based server system configured to remotely communicate with PBDs <NUM> and <NUM>, such as cloud network <NUM> as described above with respect to <FIG>.

In some embodiments, PBDs <NUM> and <NUM> are powered on and connected to the Internet. Once connected, PBDs <NUM> and <NUM> begin communicating with computing system <NUM>. In operation, PBD <NUM> may transmit registration message <NUM> to computing system <NUM>. Registration message <NUM> includes information pertaining to PBD <NUM>, such as parameters that include a cached system identifier, a cached subsystem identifier, a cached user identifier, and a cached location identifier. The parameters may be stored in a settings file in the memory of PBD <NUM>.

The system identifier is a unique short string that identifies the "household" to which PBD <NUM> belongs. A household may refer to the media playback system as a whole. Thus, the system identifier may indicate membership as part of the media playback system. The system identifier may be computer generated to ensure it is unique. <CIT> contains further discussion with respect to system identifiers, the entire contents of which is incorporated by reference herein.

The subsystem identifier includes a semi-persistent unique identifier that corresponds to a partition (e.g., location) of the media playback system that has been assigned the system identifier. For example, if the media playback system is split between two locations, media playback devices that are connected in a first location are assigned a first subsystem identifier and media playback devices that are connected in a second location are assigned a second subsystem identifier. The subsystem identifier is a unique string or integer. If PBD <NUM> has not previously had a subsystem identifier assigned to it on initialization, the subsystem identifier is a placeholder string with a null value (e.g., "NULL") or no value (e.g., ""). As discussed further below, computing system <NUM> receives this placeholder string and assigns PBD <NUM> a new subsystem identifier based on the location to which it is connected.

The user identifier is a short string that identifies a user or family of users that can access the media playback system. In some embodiments, the user identifier relates to the name of the user (e.g., "John") or can be a string of alphanumeric or other characters. In other embodiments, the user identifier relates to a user profile with permission to add additional media playback devices and/or services to the media playback system. A user profile relates to an account linked to a particular user (e.g., "Mark's Profile" or "Dad's Profile").

The location identifier can be a property that pertains to the local area network (LAN) to which PBD <NUM> is connected. For example, the location identifier can be any property discoverable by a player that is unique to the LAN to which PBD <NUM> is connected and semi-persistent. Examples of a location identifier include a network identifier associated with the router to which PBD <NUM> is connected, a Dynamic Host Configuration Protocol (DHCP) server media access control (MAC) address, a DHCP server MAC address with the addition of the network address portion of PBD <NUM>'s local IP address, and/or a wireless beacon (e.g., a globally unique wireless beacon).

In some embodiments, after PBD <NUM> transmits the registration message, computing system <NUM> receives the registration message. Computing system <NUM> can store the parameters contained in the registration message in a file stored on computing system <NUM>. This may be beneficial because it provides computing system <NUM> with the ability to track active and previously used identifiers. Computing system <NUM> then determines if the system identifier, user identifier, and location identifier already exist on another media playback device connected to media playback system <NUM>. Computing system <NUM> can determine if the system identifier, user identifier, and location identifier exist by (i) searching the system identifier, user identifier, and location identifiers of all other media playback devices currently connected to media playback system <NUM>, (ii) searching a database containing the previously used system identifier, user identifier, and location identifiers of media playback devices connected to media playback system <NUM>, and/or (iii) searching a file stored on computing system <NUM> that contains the previously registered system identifier, user identifier, and location identifiers of media playback devices connected to media playback system <NUM>. If the combination of system identifier, user identifier, and location identifier does not already exist on another media playback device, then computing system <NUM> sends a configuration message to PBD <NUM> that contains a new subsystem identifier. If the combination of system identifier, user identifier, and location identifier does exist on another media playback device, then computing system <NUM> sends a configuration message to PBD <NUM> that contains a subsystem identifier that is the same as the other media playback device that has the same combination.

The value of the new subsystem identifier may be different for every media playback device that is connected to media playback system <NUM> with a different combination of system identifier, subsystem identifier, user identifier, and location identifier. In some embodiments, the value for the subsystem identifier can be generated based on another identifier associated with the media playback system (e.g., user identifier, system identifier, location identifier). The subsystem identifier can be generated based on a combination of the generated identifier and another identifier associated with the media playback system (e.g., user identifier, system identifier, location identifier). For example, the value for the subsystem identifier may be a hash of the system identifier combined with the system identifier. Hashing the system identifier and combining the hash with the system identifier may be a beneficial way to set a unique value for the subsystem identifier. In other embodiments, the value of the new subsystem identifier may be an integer that is one value higher sequentially from the existing subsystem identifiers associated with the media playback system.

For example, if PBD <NUM> is the first media playback device powered on and connected to media playback system <NUM>, computing system <NUM> sends PBD <NUM> a configuration message containing a first subsystem identifier. If PBD <NUM> is subsequently connected to media playback system <NUM> at a different location, computing system <NUM> assigns PBD <NUM> a second subsystem identifier.

In operation, PBD <NUM> may be powered on and connected to the Internet. PBD <NUM> sends registration message <NUM> to computing system <NUM>. Registration message <NUM> contains a system identifier, subsystem identifier with a null initial value, a user identifier, and a location identifier. Computing system <NUM> then determines that no other media playback devices are connected to media playback system <NUM>. In response to this determination, computing system <NUM> sends configuration message <NUM> to PBD <NUM>. Configuration message <NUM> contains a first subsystem identifier.

Subsequently, PBD <NUM> is powered on and connected to the Internet. PBD <NUM> sends registration message <NUM> to computing system <NUM>. Registration message <NUM> contains a system identifier, subsystem identifier with a null initial value, a user identifier, and a location identifier. Computing system <NUM> then determines that PBD <NUM> has the same system identifier, user identifier, and a location identifier as PBD <NUM>. Upon determining that PBDs <NUM> and <NUM> have the same system identifier, user identifier, and a location identifier, computing system <NUM> transmits configuration message <NUM> to PBD <NUM>. Configuration message <NUM> contains a subsystem identifier identical to the subsystem identifier in configuration message <NUM> (e.g., the first subsystem identifier).

In some scenarios, one or both of PBDs <NUM> and <NUM> may be moved to a different location. This may be beneficial when a user wants to set up one or more playback devices in one location (e.g., at home) and one or more playback devices in another location (e.g., at work). In line with the discussion above, this movement of media playback devices was a potential problem in conventional media playback systems due to an inability for a computing system to discern which media playback devices needed to execute which commands.

<FIG> is a communication flow diagram of an example media playback system <NUM> that includes PBDs <NUM> and <NUM> at location <NUM> that are initially connected to computing system <NUM>. <FIG> further includes PBD <NUM> at location <NUM> connected to computing system <NUM> and PBD <NUM> at location <NUM> connected to computing system <NUM> after an action <NUM> takes place.

PBDs <NUM> and <NUM> are connected to computing system <NUM> in a similar manner as in media playback system <NUM> as described in <FIG>. PBDs <NUM> and <NUM> are configured to send registration messages <NUM>, <NUM>, <NUM>, and <NUM>, as well as receive configuration messages <NUM>, <NUM>, <NUM>, and <NUM> and return queries <NUM> and <NUM>. As discussed above, registration messages <NUM>, <NUM>, <NUM>, and <NUM> are messages configured to connect PBDs <NUM> and <NUM> to computing system <NUM>, and may contain information about PBDs <NUM> and <NUM> such as parameters that include a cached system identifier, subsystem identifier, user identifier, and location identifier. Configuration messages <NUM>, <NUM>, <NUM>, and <NUM> are messages configured to cause PBDs <NUM> and <NUM> to update their subsystem identifier.

Action <NUM> includes an action on one or both of PBDs <NUM> and <NUM>. In some embodiments, action <NUM> includes a physical relocation of PBD <NUM> to location <NUM>. In other embodiments, action <NUM> includes powering off PBD <NUM> and/or <NUM>.

Computing system <NUM> in media playback system <NUM> can be configured in the same or similar way as in media playback system <NUM>. In some embodiments, computing system <NUM> is configured to (i) receive registration messages <NUM>, <NUM>, <NUM>, and <NUM>, (ii) transmit configuration messages <NUM>, <NUM>, <NUM>, and <NUM>, and (iii) perform queries <NUM> and <NUM>.

Registration messages <NUM>, <NUM>, <NUM>, and <NUM> contain the same or similar information as registration messages <NUM> and <NUM> in <FIG>. Configuration messages <NUM>, <NUM>, <NUM>, and <NUM> contain the same or similar information as configuration messages <NUM> and <NUM>.

Queries <NUM> and <NUM> are location verification messages configured to verify that PBD <NUM> and/or PBD <NUM> are still able to communicate with computing system <NUM>. Queries <NUM> and <NUM> contain expected information about PBDs <NUM> and/or <NUM>, such as a multi-character string that corresponds to the state of PBDs <NUM> and/or <NUM>. Computing system <NUM> sends queries <NUM> and <NUM> in response to receiving a registration message from a newly connected media playback device or from an existing media playback device connected to a new location.

In operation, after PBD <NUM> is powered on and connected to the Internet, PBD <NUM> sends registration message <NUM> to computing system <NUM>. The registration message <NUM> can include a cached system identifier, a cached subsystem identifier with a null value, a cached user identifier, and a cached location identifier. As previously discussed, the cached subsystem identifier has a null value because computing system <NUM> has not yet assigned a subsystem identifier to PBD <NUM>. Computing system <NUM> receives registration message <NUM> and determines whether any other media playback devices that are in communication with computing system <NUM> are using the same system identifier, same user identifier, and/or same location identifier included in the registration message <NUM>. Upon determining that no other media playback devices in communication with the computing system <NUM> are using the same system identifier, same user identifier, and same location identifier, computing system <NUM> sends configuration message <NUM> to PBD <NUM>. In some embodiments, configuration message <NUM> assigns PBD <NUM> a first subsystem identifier.

If/when PBD <NUM> is subsequently powered on and connected to the Internet, PBD <NUM> sends registration message <NUM> to computing system <NUM>. Registration message <NUM> includes one or more of a cached system identifier, a subsystem identifier with a null value, a user identifier, and a location identifier. The subsystem identifier in registration message <NUM> has a null value because computing system <NUM> has not previously assigned a subsystem identifier to PBD <NUM>. Computing system <NUM> receives registration message <NUM> and determines whether any other media playback devices in communication with the computing system <NUM> are configured with one or more of the system identifier, user identifier, and location identifier contained in registration message <NUM>. Upon determining that PBD <NUM> is using one or more of the system identifier, user identifier, and location identifier, computing system <NUM> sends configuration message <NUM> to PBD <NUM>. In some embodiments, configuration message <NUM> assigns PBD <NUM> the first subsystem identifier (which is identical to the subsystem identifier assigned to PBD <NUM>).

After this registration and configuration takes place and the media playback system is configured for operation at location <NUM> (e.g., the user's home), the user may move one of the playback devices to a different location (e.g., the user's office). This movement from a first location to a second location is illustrated as action <NUM> in <FIG>. In <FIG>, action <NUM> corresponds to PBDs <NUM> and <NUM> being powered off, and PBD <NUM> being moved and/or relocated to location <NUM>.

PBD <NUM> is subsequently re-powered on and re-connected to the Internet via a router at location <NUM>. PBD <NUM> then determines that its location identifier has changed. For example, PBD <NUM> determines that it is no longer connected to the router at location <NUM> by (i) determining a GPS coordinate associated with PBD <NUM> has changed above a threshold value or (ii) the IP address of PBD <NUM> has changed due to a change in DHCP. In response to determining that its location identifier has changed, PBD <NUM> sends registration message <NUM> to computing system <NUM>. Registration message <NUM> contains parameters including the same cached system identifier, user identifier, and location identifier as in registration message <NUM>, along with the cached first subsystem identifier (which was previously assigned by computing system <NUM>). Computing system <NUM> receives registration message <NUM> and, in response to receiving registration message <NUM>, sends query <NUM> to any media playback devices connected at location <NUM> to determine whether any media playback devices have the same parameters as PBD <NUM>. In response to determining that no devices at location <NUM> have the same parameters as PBD <NUM>, computing system <NUM> sends configuration message <NUM> to PBD <NUM>. Configuration message <NUM> contains the same parameters as registration message <NUM>, including the cached first subsystem identifier.

Next, PBD <NUM> is re-powered on and re-connected to the Internet via a router at location <NUM>. PBD <NUM> sends registration message <NUM> to computing system <NUM>. Registration message <NUM> contains parameters including the same cached system identifier, user identifier, and location identifier as in registration message <NUM>, along with the cached first subsystem identifier (which was previously assigned by computing system <NUM>). Computing system <NUM> receives registration message <NUM> and, in response to receiving registration message <NUM>, sends query <NUM> to PBD <NUM> to determine that PBD <NUM> is still active at location <NUM>. PBD <NUM> receives query <NUM> and responds with its parameters, indicating that PBD <NUM> is powered on and has been assigned the first subsystem identifier. Upon receiving a response to query <NUM>, computing system sends configuration message <NUM> to PBD <NUM>. Configuration message <NUM> contains a new subsystem identifier. The new subsystem identifier can be a second subsystem identifier that is different from the first subsystem identifier and generated in the same way as the first subsystem identifier.

In some embodiments, after PBDs <NUM> and <NUM> are connected and assigned their respective subsystem identifiers, computing system <NUM> may receive a request directed to media playback devices active at location <NUM>. This may also be a request directed to media playback devices with the second subsystem identifier. The request may be a command to change a configuration setting of the devices connected at location <NUM>, such as a command to change the media playback system volume or to pause media playback. In response to receiving the request, computing system <NUM> causes PBD <NUM>, and any other media playback devices connected to location <NUM> but not shown in <FIG>, to process the request. As discussed above, this may be beneficial because it may avoid the problem of computing system <NUM> accidentally causing media playback devices with the first subsystem identifier to carry out the request directed only towards media playback devices with the second subsystem identifier.

In some embodiments, PBDs <NUM> and <NUM> are powered on and initialized at a first location, then powered off. PBD <NUM> is subsequently moved, powered on, and connected at a second location. In these embodiments, computing system <NUM> assigns the subsystem identifier that was associated with the first location to the second. This may be beneficial because it is unknown whether media playback devices will be connected at the first location, and thus it may be more efficient to only have subsystem identifiers that are associated with locations that computing system <NUM> expects media playback devices to be connected.

<FIG> is a communication flow diagram of an example media playback system <NUM> that includes PBD <NUM> connected to computing system <NUM> via the Internet at location <NUM> and PBD <NUM> connected to computing system <NUM> via the Internet at location <NUM>. Although not shown, PBDs <NUM> and <NUM> were previously connected to computing system <NUM> at location <NUM> and powered off. PBD <NUM> was then moved to location <NUM> and powered on. When PBDs <NUM> and <NUM> were powered on and connected to computing system <NUM>, computing system <NUM> assigned PBDs <NUM> and <NUM> a first subsystem identifier.

In operation, PBD <NUM>, upon being connected to the Internet, sends registration message <NUM> to computing system <NUM>. Registration message <NUM> contains parameters that include a system identifier, the first subsystem identifier, a user identifier, and a location identifier. Computing system <NUM> receives registration message <NUM> and sends query <NUM> to location <NUM>, which is where PBD <NUM> was previously connected. Upon determining that PBD <NUM> is no longer connected at location <NUM> (since it is powered off), computing system <NUM> sends configuration message <NUM> to PBD <NUM>. Configuration message <NUM> contains parameters configured to assign PBD <NUM> a subsystem identifier with a value <NUM>.

PBD <NUM> is then powered on and connected to the Internet. PBD <NUM> sends registration message <NUM> to computing system <NUM>. Registration message <NUM> contains parameters including a system identifier, the first subsystem identifier, a user identifier, and a location identifier. Computing system <NUM> receives registration message <NUM> and sends query <NUM> to location <NUM> to (i) determine whether PBD <NUM> is still connected at location <NUM> and (ii) retrieve the subsystem identifier assigned to PBD <NUM>. Upon determining that PBD <NUM> is still connected at location <NUM> and that PBD <NUM> has the first subsystem identifier, computing system <NUM> sends configuration message <NUM> to PBD <NUM>. Configuration message <NUM> contains parameters configured to assign PBD <NUM> a second subsystem identifier, which indicates it is in a different location than PBD <NUM>.

Action <NUM> is then performed. In <FIG>, action <NUM> includes powering off and moving PBD <NUM> to location <NUM>.

PBD <NUM> is then powered on and connected to the Internet via a router at location <NUM>. Upon being powered on, PBD <NUM> sends registration message <NUM> to computing system <NUM>. Registration message <NUM> contains parameters that include a system identifier, the first subsystem identifier, a user identifier, and a location identifier. In response to receiving registration message <NUM>, computing system <NUM> sends query <NUM> to PBD <NUM> to (i) determine whether PBD <NUM> is still connected at location <NUM> and (ii) retrieve the subsystem identifier assigned to PBD <NUM>. Upon determining that PBD <NUM> is still connected at location <NUM> and that PBD <NUM> has the second subsystem identifier, computing system <NUM> sends configuration message <NUM> to PBD <NUM>. Configuration message <NUM> contains parameters configured to assign PBD <NUM> the second subsystem identifier, which indicates it is now in the same location as PBD <NUM>. In this scenario, while the first subsystem identifier is lost, the second subsystem identifier has all of the previous parameters associated with the first subsystem identifier.

In some embodiments, a third media playback device (not shown) may be added to media playback system <NUM>. The third media playback device is powered on and connected to the Internet via a router at location <NUM>. The third media playback device sends a registration message to computing system <NUM>. The registration contains the same or similar parameters as registration messages <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> as described in <FIG>. Upon receiving the registration message, computing system <NUM> queries the network at location <NUM> to (i) determine whether PBDs <NUM> and <NUM> are still connected at location <NUM> and (ii) retrieve the second subsystem identifier that was assigned to PBDs <NUM> and <NUM> (which are identical). Computing system <NUM> then sends a configuration message to the third playback device. The configuration message contains the same or similar parameters to configuration messages <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> as described in <FIG>. The configuration message is configured to assign the third media playback device the first subsystem identifier. Computing system <NUM> assigns the third media playback device the first subsystem identifier because the first subsystem identifier is not being used. Computing system <NUM> also sends a command to cause the third media playback device to process any requests that were previously directed at the media playback devices that were assigned the first subsystem identifier. This may be beneficial because it may allow a user to avoid having to reconfigure new media playback devices that are added to a previously configured location.

In some embodiments, when PBDs <NUM> and <NUM> are connected at different locations, such as location <NUM> and <NUM>, the third media playback device may be powered on and connected at a third location (not shown). In these embodiments, the configuration message sent by computing system <NUM> contains a third subsystem identifier generated by computing system <NUM>. The third subsystem identifier can be generated by the computing system <NUM> in a similar manner to the first subsystem identifier.

In some embodiments, PBDs <NUM> or <NUM>, after receiving a configuration message containing a subsystem identifier from computing device <NUM>, may store the subsystem identifier in a settings file. The settings file is stored in memory <NUM> on PBDs <NUM> and <NUM>, as described with respect to <FIG>.

In some embodiments, after PBDs <NUM> and <NUM> are powered on and connected to computing system <NUM>, PBDs <NUM> and <NUM> may transmit an advertisement message to computing system <NUM>. The advertisement message contains PBDs <NUM> or <NUM>'s respective subsystem identifier. This may be beneficial because computing system <NUM> may receive the advertisement message from PBDs <NUM> and/or <NUM> and determine the subsystem identifier assigned to each of PBDs <NUM> and <NUM>. In some embodiments, the advertisement message may include the subsystem identifier that is stored in the settings file of PBDs <NUM> and/or <NUM>.

In some embodiments, a DCHP change may occur at location <NUM> and/or location <NUM>. This change may occur due to a connection loss at the router to which PBDs <NUM> and/or <NUM> are connected. Either or both of PBDs <NUM> and <NUM> can detect the DHCP change. In scenarios where both PBDs <NUM> and <NUM> detect a DHCP change, PBDs <NUM> and <NUM> send a re-registration message to computing system <NUM>. The re-registration message includes parameters including the same system identifier, subsystem identifier, and user identifier, but may include a different location identifier. Computing system <NUM> receives the re-registration message and sends a re-configuration message with the same parameters back to PBDs <NUM> and <NUM>. The re-configuration message includes a message configured to assign PBDs <NUM> and <NUM> a subsystem identifier with the same value as the re-registration message. This may be beneficial because it results in computing system <NUM> having an updated location identifier for PBDs <NUM> and <NUM>.

In some embodiments, only one of PBDs <NUM> and <NUM> detects the DHCP change. For example, PBD <NUM> may detect the DHCP change, while PBD <NUM> does not detect the DHCP change. In this scenario, PBD <NUM> sends a message to computing system <NUM>. The message includes parameters including the same system identifier, subsystem identifier, and user identifier, but may include a different location identifier. Computing system <NUM> receives the message and sends a message with the same parameters back to PBD <NUM>. While PBD <NUM> is sending the message and receiving the message, PBD <NUM> is sending replicated copies of the re-registration message and the re-configuration message to PBD <NUM>. In response to receiving the replicated messages from PBD <NUM>, PBD <NUM> sends a re-registration message to computing system <NUM>. Computing system <NUM> receives the re-registration message and sends a re-configuration message back to PBD <NUM>. In response to receiving the re-configuration message from computing system <NUM>, PBD <NUM> updates its DHCP to match the DHCP of PBD <NUM>.

<FIG> shows an example embodiment of a method <NUM> that can be implemented by a media playback system, for example, the media playback system <NUM> of <FIG>, the media playback system <NUM> of <FIG>, and/or the media playback system <NUM> of <FIG>.

Various embodiments of method <NUM> include one or more operations, functions, and actions illustrated by blocks <NUM> through <NUM>. Although the blocks are illustrated in sequential order, these blocks may also be performed in parallel, and/or in a different order than the order disclosed and described herein. Also, the various blocks may be combined into fewer blocks, divided into additional blocks, and/or removed based upon a desired implementation.

In addition, for the method <NUM> and other processes and methods disclosed herein, the flowchart shows functionality and operation of one possible implementation of some embodiments. In this regard, each block may represent a module, a segment, or a portion of program code, which includes one or more instructions executable by one or more processors for implementing specific logical functions or steps in the process. The program code may be stored on any type of computer readable medium, for example, such as a storage device including a disk or hard drive. The computer readable medium may include non-transitory computer readable media, for example, such as tangible, non-transitory computer-readable media that stores data for short periods of time like register memory, processor cache, and Random Access Memory (RAM). The computer readable medium may also include non-transitory media, such as secondary or persistent long term storage, like read only memory (ROM), optical or magnetic disks, compact-disc read only memory (CD-ROM), for example. The computer readable media may also be any other volatile or non-volatile storage systems. The computer readable medium may be considered a computer readable storage medium, for example, or a tangible storage device. In addition, for the method <NUM> and other processes and methods disclosed herein, each block in <FIG> may represent circuitry that is wired to perform the specific logical functions in the process.

Method <NUM> begins at block <NUM>, which includes a computing system receiving, from a first media playback device connected to a first network, a first registration message.

At block <NUM>, method <NUM> includes in response to receiving the first registration message, assigning a system identifier and a first subsystem identifier to the first media playback device. In some embodiments, the system identifier is associated with the computing system, and the first subsystem identifier is associated with the system identifier.

At block <NUM>, method <NUM> includes receiving, from a second media playback device connected to the first network, a second registration message.

At block <NUM>, method <NUM> includes, in response to receiving the second registration message, assigning the system identifier and the first subsystem identifier to the second media playback device.

At block <NUM>, method <NUM> includes determining that the second media playback device is disconnected from the first network and connected to a second network.

At block <NUM>, method <NUM> includes, in response to determining that the second media playback device is connected to the second network, assigning a second subsystem identifier to the second media playback device. In some embodiments, the second subsystem identifier is associated with the system identifier.

At block <NUM>, method <NUM> includes transmitting, to the second media playback device, a message comprising the second subsystem identifier.

At block <NUM>, method <NUM> includes receiving a request directed to devices associated with the second subsystem identifier.

At block <NUM>, method <NUM> includes, based on the request being directed to devices associated with the second subsystem identifier, causing the second media playback device to process the request.

In some embodiments, determining that the second media playback device is disconnected from the first network and connected to a second network may involve receiving, from the second media playback device on the second network, a third registration message.

In some embodiments, determining that the second media playback device is disconnected from the first network and connected to a second network includes (i) querying the first network to determine whether the second media playback device is a member of the first network, and (ii) based on the determination that the second media playback device is not a member of the first network, querying the second network to determine whether the second media playback device is a member of the second network.

Some embodiments further include (i) determining that the second media playback device is disconnected from the second network and connected to the first network, and (ii) in response to determining the second media playback device is connected to the first network, assigning the first subsystem identifier to the second media playback device.

In some embodiments, the computing system has one associated system identifier for the computing system. The system identifier has an associated subsystem identifier for each media playback device connected to the computing system.

In some embodiments, assigning the first subsystem identifier includes (i) determining whether the first media playback device has a cached subsystem identifier, and (ii) in response to determining that the first media playback device has a pre-existing subsystem identifier, assigning the cached subsystem identifier as the first subsystem identifier to the first media playback device.

In some embodiments, the request includes a command to change a configuration setting of the devices associated with the second subsystem identifier and causing the second media playback device to process the request includes implementing the configuration setting on the second media playback device.

Some embodiments further include (i) receiving, from a third media playback device connected to the second network, a third registration message, (ii) in response to receiving the third registration message, transmitting, to the third media playback device, a message comprising the second subsystem identifier, and (iii) causing the third media playback device to process the request.

Method <NUM> in <FIG> shows an embodiment of a method that can be implemented within an operating environment including or involving, for example, the media playback system <NUM> of <FIG>, one or more playback devices <NUM> of <FIG>, one or more control devices <NUM> of <FIG>, the user interface of <FIG>, the configuration shown in <FIG>, the NMD shown in <FIG>, the media playback system <NUM> in <FIG> the media playback system <NUM>, in <FIG>, and/or the media playback system <NUM> in <FIG>. Method <NUM> may include one or more operations, functions, or actions as illustrated by one or more of blocks <NUM> through <NUM>. Although the blocks are illustrated in sequential order, these blocks may also be performed in parallel, and/or in a different order than those described herein. Also, the various blocks may be combined into fewer blocks, divided into additional blocks, and/or removed based upon the desired implementation.

In addition, for the method <NUM> and other processes and methods disclosed herein, the flowchart shows functionality and operation of one possible implementation of some embodiments. In this regard, each block may represent a module, a segment, or a portion of program code, which includes one or more instructions executable by one or more processors for implementing specific logical functions or steps in the process. The program code may be stored on any type of computer readable medium, for example, such as a storage device including a disk or hard drive. The computer readable medium may include non-transitory computer readable medium, for example, such as tangible, non-transitory computer-readable media that stores data for short periods of time like register memory, processor cache and Random Access Memory (RAM). The computer readable medium may also include non-transitory media, such as secondary or persistent long term storage, like read only memory (ROM), optical or magnetic disks, compact-disc read only memory (CD-ROM), for example. The computer readable media may also be any other volatile or non-volatile storage systems. The computer readable medium may be considered a computer readable storage medium, for example, or a tangible storage device. In addition, for the method <NUM> and other processes and methods disclosed herein, each block in <FIG> may represent circuitry that is wired to perform the specific logical functions in the process.

Method <NUM> begins at block <NUM>, which includes a first media playback device connecting to a first network.

At block <NUM>, method <NUM> includes transmitting, to a computing system, a first registration message.

At block <NUM>, method <NUM> includes receiving, from the computing system, a system identifier and a first subsystem identifier. In some embodiments, the first subsystem identifier may be associated with the system identifier.

At block <NUM>, method <NUM> includes disconnecting from the first network.

At block <NUM>, method <NUM> includes connecting to a second network.

At block <NUM>, method <NUM> includes transmitting, to the computing system, a second registration message.

At block <NUM>, method <NUM> includes receiving, from the computing system, a second subsystem identifier. In some embodiments, the second subsystem identifier may be associated with the system identifier.

At block <NUM>, method <NUM> includes configuring the first media playback device to use the second subsystem identifier.

At block <NUM>, method <NUM> includes receiving, from the computing system, one or more commands to implement a change affecting all devices to which the first subsystem identifier has been assigned.

Some embodiments further include after configuring the first media playback device to use the second subsystem identifier, transmitting, to the computing system, an advertisement message. In some embodiments, the advertisement message includes the second subsystem identifier.

Some embodiments further include receiving, from the computing system, a third subsystem identifier, wherein the third subsystem identifier is associated with the system identifier.

In some embodiments, configuring the first media playback device to use the second subsystem identifier includes storing the second subsystem identifier in a settings file of the first media playback device.

In some embodiments, after configuring the first media playback device to use the second subsystem identifier, transmitting, to the computing system, an advertisement message. In some embodiments, the advertisement message includes the second subsystem identifier stored in the settings file of the first media playback device.

Some embodiments further include (i) after transmitting the second registration message, waiting to receive, from the computing system, the second subsystem identifier, and (ii) after receiving the second subsystem identifier, transmitting, to the computing system, an advertisement message, wherein the advertisement message includes the second subsystem identifier.

Some embodiments further include (i) determining a location identifier of the first media playback device has changed, and (ii) in response to determining the location identifier has changed, sending, to the computing system, a third registration message.

In some embodiments, determining the location identifier of the first media playback device has changed includes determining that a GPS coordinate of the first media playback device has adjusted above a threshold value.

In some embodiments, determining the location identifier of the first media playback device has changed includes determining that the first media playback device in connected to a third network.

In some embodiments, determining the location identifier of the first media playback device has changed includes determining that the second network has experienced a DHCP change.

In some embodiments, the third registration message includes a re-registration message configured to update the computing system with respect to the DHCP change.

Additionally, references herein to "embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one example embodiment of an invention. The appearances of this phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. As such, the embodiments described herein, explicitly and implicitly understood by one skilled in the art, can be combined with other embodiments.

The specification is presented largely in terms of illustrative environments, systems, procedures, steps, logic blocks, processing, and other symbolic representations that directly or indirectly resemble the operations of data processing devices coupled to networks. These process descriptions and representations are typically used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. Numerous specific details are set forth to provide a thorough understanding of the present disclosure. However, it is understood to those skilled in the art that certain embodiments of the present disclosure can be practiced without certain, specific details. In other instances, well known methods, procedures, components, and circuitry have not been described in detail to avoid unnecessarily obscuring aspects of the embodiments. Accordingly, the scope of the present disclosure is defined by the appended claims rather than the forgoing description of embodiments.

Claim 1:
A method for a computing system (<NUM>) comprising:
receiving, from a first media playback device (<NUM>) connected to a first network, a first registration message (<NUM>);
in response to receiving the first registration message, assigning a system identifier and a first subsystem identifier to the first media playback device (<NUM>), wherein the system identifier is associated with the computing system (<NUM>), and wherein the first subsystem identifier is associated with the system identifier and the first network;
receiving, from a second media playback device (<NUM>) connected to a second network, a second registration message;
determining, based on the second registration message, that the second media playback device (<NUM>) is connected to the second network and assigning a second subsystem identifier to the second media playback device (<NUM>), wherein the second subsystem identifier is associated with the system identifier and the second network;
transmitting, to the second media playback device (<NUM>), a message comprising the second subsystem identifier;
receiving a request directed to devices associated with the second subsystem identifier;
based on the request being directed to devices associated with the second subsystem identifier, causing the second media playback device (<NUM>) to process the request; and
in response to determining that the second media playback device (<NUM>) is disconnected from the second network and connected to the first network, assigning the system identifier and the first subsystem identifier to the second media playback device (<NUM>), the first subsystem identifier associated with the system identifier and the first network, and transmitting, to the second media playback device (<NUM>), a message comprising the first subsystem identifier.