U.S. patent application number 16/045501 was filed with the patent office on 2018-11-15 for distributed computer system architecture for networked playback systems to facilitate producing music service media applications and to utilize music services.
The applicant listed for this patent is SONOS, INC.. Invention is credited to Jerry Anderson, Ron Kuper, Kate Moloney-Egnatios.
Application Number | 20180332341 16/045501 |
Document ID | / |
Family ID | 47556756 |
Filed Date | 2018-11-15 |
United States Patent
Application |
20180332341 |
Kind Code |
A1 |
Moloney-Egnatios; Kate ; et
al. |
November 15, 2018 |
Distributed Computer System Architecture for Networked Playback
Systems to Facilitate Producing Music Service Media Applications
and to Utilize Music Services
Abstract
A distributed architecture is disclosed for networked playback
systems to facilitate producing music services' media applications
and to utilize music services. In example embodiments, a controller
is configured to authenticate a playback system with multiple music
services and then access each music service to perform a respective
search when it receives a search request. The controller then
outputs indications of applicable music content provided by any of
the music services. The controller receives a selection of an
indication and then causes one or more playback devices of the
playback system to playback the music content from the appropriate
music service. In other embodiments, a computing system provides
API services through which music services can iteratively evaluate
media applications using playback systems. The playback systems
provide evaluation data to the computing system that are indicative
of respective operations of the playback systems while provisioned
with a particular media application version.
Inventors: |
Moloney-Egnatios; Kate; (Los
Altos, CA) ; Kuper; Ron; (Arlington, MA) ;
Anderson; Jerry; (Santa Barbara, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
SONOS, INC. |
Santa Barbara |
CA |
US |
|
|
Family ID: |
47556756 |
Appl. No.: |
16/045501 |
Filed: |
July 25, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13554214 |
Jul 20, 2012 |
|
|
|
16045501 |
|
|
|
|
61509939 |
Jul 20, 2011 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04N 21/47202 20130101;
H04N 21/4122 20130101; H04N 21/8113 20130101; H04N 21/43615
20130101; H04L 12/2812 20130101; H04N 21/485 20130101 |
International
Class: |
H04N 21/436 20060101
H04N021/436; H04L 12/28 20060101 H04L012/28; H04N 21/81 20060101
H04N021/81; H04N 21/41 20060101 H04N021/41; H04N 21/472 20060101
H04N021/472; H04N 21/485 20060101 H04N021/485 |
Claims
1. A controller device of an audio playback system, the controller
device comprising: a network interface configured to
communicatively couple the controller device to (i) at least one
playback device of the audio playback system and (ii) a plurality
of music service computing systems located remote to the controller
device, wherein each music service computing system corresponds to
a given music service; an input interface; at least one processor;
a non-transitory computer-readable medium having instructions
stored thereon, wherein the instructions, when executed by the at
least one processor, cause the controller device to: authenticate
the audio playback system with a first music service computing
system; authenticate the audio playback system with second music
service computing system; receive, via the input interface, a first
input indicative of a search request related to music content;
based on the first input: access, via the network interface, the
first music service computing system to perform a first search in
accordance with the search request; and access, via the network
interface, the second music service computing system to perform a
second search in accordance with the search request; based on the
first and second searches, output a plurality of indications of
music content, wherein each given indication of music content
corresponds to music content provided by either the first music
service computing system or the second music service computing
system; receive, via the input interface, a second input indicative
of a selected indication of music content of the plurality of
indications of music content, wherein the selected indication of
music content corresponds to a selected music content provided by
the first music service computing system; and based on the second
input, cause the at least one playback device to playback the
selected music content from the first music service computing
system via a music identifier corresponding to the selected music
content.
2. The controller device of claim 1, wherein authenticating the
audio playback system with the first music service computing system
comprises: obtaining, via the network interface, from the first
music service computing system a first access credential in
response to a first session identifier request comprising account
information related to the first music service computing system;
and wherein authenticating the audio playback system with the
second music service computing system comprises: obtaining, via the
network interface, from the second music service computing system a
second access credential in response to a second session identifier
request comprising account information related to the second music
service computing system.
3. The controller device of claim 2, wherein the first access
credential is a first token and the second access credential is a
second token, and wherein (i) accessing the first music service
computing system to perform the first search in accordance with the
search request comprises: transmitting a first search request that
comprises the first token, and (ii) accessing the second music
service computing system to perform the second search in accordance
with the search request comprises: transmitting a second search
request that comprises the second token.
4. The controller device of claim 2, wherein the first access
credential is a first time-dependent token and the second access
credential is a second time-dependent token.
5. The controller device of claim 1, wherein the instructions, when
executed by the at least one processor, further cause the
controller device to: in response to authenticating the audio
playback system with the first music service computing system, add
the music service corresponding to the first music service
computing system to the audio playback system, wherein adding the
music service corresponding to the first music service computing
system to the audio playback system comprises causing the audio
playback system to store a first access credential for the first
music service computing system.
6. The controller device of claim 1, wherein the instructions, when
executed by the at least one processor, further cause the
controller device to: in response to authenticating the audio
playback system with the second music service computing system, add
the music service corresponding to the second music service
computing system to the audio playback system, wherein adding the
music service corresponding to the second music service computing
system to the audio playback system comprises causing the audio
playback system to store a second access credential for the second
music service computing system.
7. The controller device of claim 1, wherein causing the at least
one playback device to playback the selected music content from the
first music service computing system via the music identifier
corresponding to the selected music content comprises: transmitting
to the at least one playback device, via the network interface, a
playback request comprising the music identifier.
8. The controller device of claim 1, wherein causing the at least
one playback device to playback the selected music content from the
first music service computing system via the music identifier
corresponding to the selected music content comprises: causing, via
the network interface, the at least one playback device to obtain
from the first music service computing system the music identifier
corresponding to the selected music content.
9. A computer-implemented method comprising: authenticating, via a
communication network, an audio playback system with a first music
service computing system; authenticating, via the communication
network, the audio playback system with a second music service
computing system; receiving a first input indicative of a search
request related to music content; based on the first input:
accessing the first music service computing system to perform a
first search in accordance with the search request; and accessing
the second music service computing system to perform a second
search in accordance with the search request; based on the first
and second searches, outputting a plurality of indications of music
content, wherein each given indication of music content corresponds
to music content provided by either the first music service
computing system or the second music service computing system;
receiving a second input indicative of a selected indication of
music content of the plurality of indications of music content,
wherein the selected indication of music content corresponds to a
selected music content provided by the first music service
computing system; and based on the second input, causing, via a
communication network, at least one playback device of the audio
playback system to playback the selected music content from the
first music service computing system via a music identifier
corresponding to the selected music content.
10. The computer-implemented method of claim 9, wherein
authenticating the audio playback system with the first music
service computing system comprises: obtaining, via the
communication network, from the first music service computing
system a first access credential in response to a first session
identifier request comprising account information related to the
first music service computing system; and wherein authenticating
the audio playback system with the second music service computing
system comprises: obtaining, via the communication network, from
the second music service computing system a second access
credential in response to a second session identifier request
comprising account information related to the second music service
computing system.
11. The computer-implemented method of claim 10, wherein the first
access credential is a first token and the second access credential
is a second token, and wherein (i) accessing the first music
service computing system to perform the first search in accordance
with the search request comprises: transmitting, via the
communication network, a first search request that comprises the
first token, and (ii) accessing the second music service computing
system to perform the second search in accordance with the search
request comprises: transmitting, via the communication network, a
second search request that comprises the second token.
12. The computer-implemented method of claim 9, wherein the first
access credential is a first time-dependent token and the second
access credential is a second time-dependent token.
13. The computer-implemented method of claim 9, further comprising:
in response to authenticating the audio playback system with the
first music service computing system, adding a music service
corresponding to the first music service computing system to the
audio playback system, wherein adding the music service
corresponding to the first music service computing system to the
audio playback system comprises causing the audio playback system
to store a first access credential for the first music service
computing system.
14. The computer-implemented method of claim 9, further comprising:
in response to authenticating the audio playback system with the
second music service computing system, add a music service
corresponding to the second music service computing system to the
audio playback system, wherein adding the music service
corresponding to the second music service computing system to the
audio playback system comprises causing the audio playback system
to store a second access credential for the second music service
computing system.
15. The computer-implemented method of claim 9, wherein causing the
at least one playback device to playback the selected music content
from the first music service computing system via the music
identifier corresponding to the selected music content comprises:
transmitting to the at least one playback device, via the
communication network, a playback request comprising the music
identifier.
16. The computer-implemented method of claim 9, wherein causing the
at least one playback device to playback the selected music content
from the first music service computing system via the music
identifier corresponding to the selected music content comprises:
causing, via the communication network, the at least one playback
device to obtain from the first music service computing system the
music identifier corresponding to the selected music content.
17. A computing system comprising: a network interface configured
to communicatively couple the computing system to (i) a plurality
of audio playback systems, wherein each networked audio playback
system is located remote to the computing system and comprises at
least one playback device and at least one controller device, and
(ii) a plurality of music service computing systems, wherein each
music service computing system is located remote to the computing
system and the plurality of networked media playback systems and is
configured to provide a music-related service for networked
devices; at least one processor; a non-transitory computer-readable
medium having instructions stored thereon, wherein the
instructions, when executed by the at least one processor, cause
the computing system to: for each given music service computing
system of the plurality of music service computing systems: cause,
via the network interface, a first audio playback system to be
provisioned with a first version of an audio application
corresponding to the given music service computing system, wherein
causing the first networked audio playback system to be provisioned
with the first version of the audio application comprises enabling
the first networked audio playback system with a first access
credential that limits access to the first version of the audio
application to the first audio playback system; receive from the
first audio playback system, via the network interface, first
evaluation data indicative of operation of the at least one
playback device and the at least one controller device of the first
audio playback system while provisioned with the first version of
the audio application; based at least on the received first
evaluation data, cause, via the network interface, at least a
second and a third audio playback system to be provisioned with a
second version of the audio application corresponding to the given
music service computing system, wherein causing the at least second
and third audio playback systems to be provisioned with the second
version of the audio application comprises enabling the at least
second and third audio playback systems with a second access
credential that limits access to the second version of the audio
application to the at least second and third audio playback
systems; receive, via the network interface, (i) from the second
audio playback system second evaluation data indicative of
operation of the at least one playback device and the at least one
controller device of the second audio playback system while
provisioned with the second version of the audio application and
(ii) from the third audio playback system third evaluation data
indicative of operation of the at least one playback device and the
at least one controller device of the third audio playback system
while provisioned with the second version of the audio application;
and based at least on the second and third evaluation data, publish
to any of the plurality of audio playback systems, via the network
interface, a third version of the audio application corresponding
to the given music service computing system.
18. The computing system of claim 17, wherein the computing system
is configured according to the Simple Object Access Protocol
(SOAP), wherein at least one of the plurality of music service
computing systems is configured according to a protocol other than
the SOAP, and wherein the instructions, when executed by the at
least one processor, further cause the computing system to:
translate a command from the at least one of the plurality of music
service computing systems directed to at least one of the first,
second, or third audio playback systems into the SOAP format; and
provide, via the network interface, the translated command to the
at least one of the first, second, or third audio playback
systems.
19. The computing system of claim 17, wherein the first evaluation
data comprises at least one of first usage data or first
performance data, wherein the second evaluation data at least one
of second usage data or second performance data, wherein the third
evaluation data at least one of third usage data or third
performance data, and wherein the first, second, and third usage
data comprises one or more of (i) data indicative of a number of
provisioned audio playback systems or (ii) data indicative of an
amount of use, and wherein the first, second, and third performance
data comprises one or more of (i) data indicative of a number of
errors or (ii) data indicative of results of a load test.
20. The computing system of claim 17, wherein enabling the first
audio playback system with the first access credential that limits
access to the first version of the audio application to the first
audio playback system comprises: receiving, via the network
interface, from the first audio playback system account information
for the given music service computing system; translating the
account information into the first access credential; and
transmitting, via the network interface, the first access
credential to the first audio playback system, thereby providing
the first audio playback system access to the first version of the
audio application.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of, and claims the
benefit of priority under 35 USC .sctn. 120 to, U.S. patent
application Ser. No. 13/554,214, filed on Jul. 20, 2012, which in
turn claims the benefit of priority under 35 USC .sctn. 119(e) to
U.S. Provisional Patent Application No. 61/509,939, filed on Jul.
20, 2011, each of which is herein incorporated by reference in its
entirety.
FIELD
[0002] The presently disclosed technology is directed towards
technology for use in the area of consumer electronics. In
particular, certain embodiments are directed to facilitating
configuration of and access to multimedia content from a variety of
content providers.
BACKGROUND
[0003] Music is very much a part of our everyday lives. Thanks to
the advancement of technology, music content is now more accessible
than ever. The same can be said of other types of media, such as
television, movies, and other audio and video content. In fact, now
a user can even access the content over the Internet through an
online store, an Internet radio station, online music service,
online movie service, and the like, in addition to the more
traditional means of accessing audio and video content.
[0004] The demand for such audio and video content continues to
surge. Given the high demand over the years, technology used to
access and play such content has likewise improved. Even still,
technology used in accessing the content and the playback of such
content can be significantly improved or developed in ways that the
market or end users may not anticipate.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] Features, aspects, and advantages of the presently disclosed
technology are better understood with regard to the following
description, appended claims, and accompanying drawings where:
[0006] FIG. 1 shows an example configuration in which certain
embodiments may be practiced;
[0007] FIG. 2A shows an illustration of an example zone player
having a built-in amplifier and speakers;
[0008] FIG. 2B shows an illustration of an example zone player
having a built-in amplifier and connected to external speakers;
[0009] FIG. 2C shows an illustration of an example zone player
connected to an A/V receiver and speakers;
[0010] FIG. 3 shows an illustration of an example controller;
[0011] FIG. 4 shows an internal functional block diagram of an
example zone player;
[0012] FIG. 5 shows an internal functional block diagram of an
example controller;
[0013] FIG. 6 depicts an illustrative network audio system
operating in accordance with a decentralized communication,
organization, and control structure.
[0014] FIG. 7 shows a flow diagram for an example process by which
a content partner may access, validate, test, and launch content to
users.
[0015] FIG. 8 depicts a flow diagram for an example integration
process between a multimedia content developer and a multimedia
content platform/service.
[0016] FIGS. 9A-9B depict example controller interfaces to
facilitate beta testing and general availability of new
content.
[0017] FIG. 10 illustrates a flow diagram for an example
cross-functional workflow for development, integration, beta, and
launch of new content services.
[0018] FIG. 11 illustrates an example integration testing system
and associated process flow.
[0019] FIG. 12 provides an example infrastructure for open beta
testing of content services.
[0020] FIG. 13 illustrates an example music service performance
feedback dashboard.
[0021] FIG. 14 illustrates an example authentication service.
[0022] FIG. 15 illustrates an example integration of a music system
with a music service.
[0023] FIG. 16 illustrates an example system and sequence diagram
for content playback.
[0024] FIGS. 17 and 18 depict example interactions between music
services and playback devices.
[0025] FIG. 19 is a block diagram of an example processor system
that may be used to implement the systems, apparatus, articles of
manufacture, and methods described herein.
[0026] In addition, the drawings are for the purpose of
illustrating certain embodiments, but it is understood that the
inventions are not limited to the arrangements and instrumentality
shown in the drawings.
DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS
I. Overview
[0027] Example embodiments described herein relate to integration
between new partner content services and a content access and
playback system. The embodiments are particularly useful to partner
content services, such as media providers, as a simpler mechanism
and process to provide digital media from more remote media sources
over the cloud to high fidelity playback systems. In some
instances, certain embodiments enable content services to make
themselves available via the cloud to connected playback systems
about sixty percent faster than before. In some instances, certain
embodiments give users of playback systems early access to the
content service during the development and testing phases.
Additionally, the embodiments are particularly useful when used in
conjunction with a playback device, as certain embodiments
described herein are configured to deliver more access to audio
over the cloud that can be positioned in various ways. The
embodiments may also find utility, for example, in connection with
any environment and system for which flexibility in developing,
testing, validating, and deploying a variety of media content is
desired.
[0028] Although the following discloses example methods, apparatus,
systems, and articles of manufacture including, among other
components, firmware and/or software executed on hardware, it
should be noted that such methods, apparatus, systems, and/or
articles of manufacture are merely illustrative and should not be
considered as limiting. For example, it is contemplated that any or
all of these firmware, hardware, and/or software components could
be embodied exclusively in hardware, exclusively in software,
exclusively in firmware, or in any combination of hardware,
software, and/or firmware. Accordingly, while the following
describes example methods, apparatus, systems, and/or articles of
manufacture, the examples provided are not the only way(s) to
implement such methods, apparatus, systems, and/or articles of
manufacture.
[0029] When any of the appended claims are read to cover a purely
software and/or firmware implementation, at least one of the
elements in at least one example is hereby expressly defined to
include a tangible medium such as a memory, DVD, CD, Blu-ray, and
so on, storing the software and/or firmware.
[0030] These embodiments and many additional embodiments are
described more below. Further, the detailed description 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 invention may 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.
[0031] Reference 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 the 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, may be combined with other embodiments.
II. Example Environment
[0032] Referring now to the drawings, in which like numerals may
refer to like parts throughout the figures. FIG. 1 shows an example
system configuration 100 in which one or more embodiments described
and disclosed herein may be practiced.
[0033] By way of illustration, the system configuration 100
represents a home with multiple zones, though the home could have
been configured with only one zone. Each zone, for example,
represents a different room or space, such as an office, bathroom,
bedroom, kitchen, dining room, family room, home theater room,
utility or laundry room, and patio. A single zone might also
include multiple rooms or spaces if so configured. One or more of
zone players 102-124 are shown in each respective zone. A zone
player 102-124, also referred to as a playback device, multimedia
unit, speaker, player, and so on, provides audio, video, and/or
audiovisual output. A controller 130 (e.g., shown in the kitchen
for purposes of illustration) provides control to the system
configuration 100. Controller 130 may be fixed to a zone, or
alternatively, mobile such that it can be moved about the zones.
System 100 may also include more than one controller 130. The
system configuration 100 illustrates an example whole house audio
system, though it is understood that the technology described
herein is not limited to its particular place of application or to
an expansive system like a whole house audio system 100 of FIG.
1.
[0034] a. Example Zone Players
[0035] FIGS. 2A, 2B, and 2C show example types of zone players.
Zone players 200, 202, and 204 of FIGS. 2A, 2B, and 2C,
respectively, can correspond to any of the zone players 102-124 of
FIG. 1, for example. In some embodiments, audio is reproduced using
only a single zone player, such as by a full-range player. In some
embodiments, audio is reproduced using two or more zone players,
such as by using a combination of full-range players or a
combination of full-range and specialized players. In some
embodiments, zone players 200-204 may also be referred to as a
"smart speaker," because they contain processing capabilities
beyond the reproduction of audio, more of which is described
below.
[0036] FIG. 2A illustrates zone player 200 that includes sound
producing equipment 208 capable of reproducing full-range sound.
The sound may come from an audio signal that is received and
processed by zone player 200 over a wired or wireless data network.
Sound producing equipment 208 includes one or more built-in
amplifiers and one or more speakers. A built-in amplifier is
described more below with respect to FIG. 4. A speaker or acoustic
transducer can include, for example, any of a tweeter, a mid-range
driver, a low-range driver, and a subwoofer. In some embodiments,
zone player 200 can be statically or dynamically configured to play
stereophonic audio, monaural audio, or both. In some embodiments,
zone player 200 is configured to reproduce a subset of full-range
sound, such as when zone player 200 is grouped with other zone
players to play stereophonic audio, monaural audio, and/or surround
audio or when the audio content received by zone player 200 is less
than full-range.
[0037] FIG. 2B illustrates zone player 202 that includes a built-in
amplifier to power a set of detached speakers 210. A detached
speaker can include, for example, any type of loudspeaker. Zone
player 202 may be configured to power one, two, or more separate
loudspeakers. Zone player 202 may be configured to communicate an
audio signal (e.g., right and left channel audio or more channels
depending on its configuration) to the detached speakers 210 via a
wired path.
[0038] FIG. 2C illustrates zone player 204 that does not include a
built-in amplifier, but is configured to communicate an audio
signal, received over a data network, to an audio (or
"audio/video") receiver 214 with built-in amplification.
[0039] Referring back to FIG. 1, in some embodiments, one, some, or
all of the zone players 102 to 124 can retrieve audio directly from
a source. For example, a zone player may contain a playlist or
queue of audio items to be played (also referred to herein as a
"playback queue"). Each item in the queue may comprise a uniform
resource identifier (URI) or some other identifier. The URI or
identifier can point the zone player to the audio source. The
source might be found on the Internet (e.g., the cloud), locally
from another device over data network 128 (described further
below), from the controller 130, stored on the zone player itself,
or from an audio source communicating directly to the zone player.
In some embodiments, the zone player can reproduce the audio
itself, send it to another zone player for reproduction, or both
where the audio is played by the zone player and one or more
additional zone players in synchrony. In some embodiments, the zone
player can play a first audio content (or not play at all), while
sending a second, different audio content to another zone player(s)
for reproduction.
[0040] By way of illustration, SONOS, Inc. of Santa Barbara, Calif.
presently offers for sale zone players referred to as a "PLAY:5,"
"PLAY:3," "CONNECT:AMP," "CONNECT," and "SUB." Any other past,
present, and/or future zone players can additionally or
alternatively be used to implement the zone players of example
embodiments disclosed herein. Additionally, it is understood that a
zone player is not limited to the particular examples illustrated
in FIG. 2A, 2B, and 2C or to the SONOS product offerings. For
example, a zone player may include a wired or wireless headphone.
In yet another example, a zone player might include a sound bar for
television. In yet another example, a zone player can include or
interact with a docking station for an Apple IPOD.TM. or similar
device.
[0041] b. Example Controllers
[0042] FIG. 3 illustrates an example wireless controller 300 in
docking station 302. By way of illustration, controller 300 can
correspond to controlling device 130 of FIG. 1. Docking station
302, if provided, may be used to charge a battery of controller
300. In some embodiments, controller 300 is provided with a touch
screen 304 that allows a user to interact through touch with the
controller 300, for example, to retrieve and navigate a playlist of
audio items, control operations of one or more zone players, and
provide overall control of the system configuration 100. In certain
embodiments, any number of controllers can be used to control the
system configuration 100. In some embodiments, there can be a limit
set on the number of controllers that can control the system
configuration 100. The controllers might be wireless like wireless
controller 300 or wired to data network 128.
[0043] In some embodiments, if more than one controller is used in
system 100, then each controller may be coordinated to display
common content, and may all be dynamically updated to indicate
changes made from a single controller. Coordination can occur, for
instance, by a controller periodically requesting a state variable
directly or indirectly from one or more zone players; the state
variable may provide information about system 100, such as current
zone group configuration, what is playing in one or more zones,
volume levels, and other items of interest. The state variable may
be passed around on data network 128 between zone players (and
controllers, if so desired) as needed or as often as
programmed.
[0044] In addition, an application running on any network-enabled
portable device, such as an IPHONE.TM. IPAD.TM. ANDROID.TM. powered
phone, or any other smart phone or network-enabled device can be
used as controller 130. An application running on a laptop or
desktop personal computer (PC) or MAC.TM. can also be used as
controller 130. Such controllers may connect to system 100 through
an interface with data network 128, a zone player, a wireless
router, or using some other configured connection path. Example
controllers offered by Sonos, Inc. of Santa Barbara, Calif. include
a "Controller 200," "SONOS.RTM. CONTROL," "SONOS.RTM. Controller
for IPHONE.TM.," "SONOS.RTM. Controller for IPAD.TM.," "SONOS.RTM.
Controller for ANDROID.TM.," "SONOS.RTM. Controller for MAC.TM. or
PC."
[0045] c. Example Data Connection
[0046] Zone players 102 to 124 of FIG. 1 are coupled directly or
indirectly to a data network, such as data network 128. Controller
130 may also be coupled directly or indirectly to data network 128
or individual zone players. Data network 128 is represented by an
octagon in the figure to stand out from other representative
components. While data network 128 is shown in a single location,
it is understood that such a network is distributed in and around
system 100. Particularly, data network 128 can be a wired network,
a wireless network, or a combination of both wired and wireless
networks. In some embodiments, one or more of the zone players
102-124 are wirelessly coupled to data network 128 based on a
proprietary mesh network. In some embodiments, one or more of the
zone players 102-124 are wirelessly coupled to data network 128
using a non-mesh topology. In some embodiments, one or more of the
zone players 102-124 are coupled via a wire to data network 128
using Ethernet or similar technology. In addition to the one or
more zone players 102-124 connecting to data network 128, data
network 128 can further allow access to a wide area network, such
as the Internet.
[0047] In some embodiments, connecting any of the zone players
102-124, or some other connecting device, to a broadband router,
can create data network 128. Other zone players 102-124 can then be
added wired or wirelessly to the data network 128. For example, a
zone player (e.g., any of zone players 102-124) can be added to the
system configuration 100 by simply pressing a button on the zone
player itself (or perform some other action), which enables a
connection to be made to data network 128. The broadband router can
be connected to an Internet Service Provider (ISP), for example.
The broadband router can be used to form another data network
within the system configuration 100, which can be used in other
applications (e.g., web surfing). Data network 128 can also be used
in other applications, if so programmed. An example, second network
may implement SONOSNET.TM. protocol, developed by SONOS, Inc. of
Santa Barbara. SONOSNET.TM. represents a secure, AES-encrypted,
peer-to-peer wireless mesh network. Alternatively, in certain
embodiments, the data network 128 is the same network, such as a
traditional wired or wireless network, used for other applications
in the household.
[0048] d. Example Zone Configurations
[0049] A particular zone can contain one or more zone players. For
example, the family room of FIG. 1 contains two zone players 106
and 108, while the kitchen is shown with one zone player 102. In
another example, the home theater room contains additional zone
players to play audio from a 5.1 channel or greater audio source
(e.g., a movie encoded with 5.1 or greater audio channels). In some
embodiments, one can position a zone player in a room or space and
assign the zone player to a new or existing zone via controller
130. As such, zones may be created, combined with another zone,
removed, and given a specific name (e.g., "Kitchen"), if so desired
and programmed to do so with controller 130. Moreover, in some
embodiments, zone configurations may be dynamically changed even
after being configured using controller 130 or some other
mechanism.
[0050] In some embodiments, if a zone contains two or more zone
players, such as the two zone players 106 and 108 in the family
room, then the two zone players 106 and 108 can be configured to
play the same audio source in synchrony, or the two zone players
106 and 108 can be paired to play two separate sounds in left and
right channels, for example. In other words, the stereo effects of
a sound can be reproduced or enhanced through the two zone players
106 and 108, one for the left sound and the other for the right
sound. In certain embodiments, paired zone players (also referred
to as "bonded zone players") can play audio in synchrony with other
zone players in the same or different zones.
[0051] In some embodiments, two or more zone players can be
sonically consolidated to form a single, consolidated zone player.
A consolidated zone player (though made up of multiple, separate
devices) can be configured to process and reproduce sound
differently than an unconsolidated zone player or zone players that
are paired, because a consolidated zone player will have additional
speaker drivers from which sound can be passed. The consolidated
zone player can further be paired with a single zone player or yet
another consolidated zone player. Each playback device of a
consolidated playback device can be set in a consolidated mode, for
example.
[0052] According to some embodiments, one can continue to do any
of: group, consolidate, and pair zone players, for example, until a
desired configuration is complete. The actions of grouping,
consolidation, and pairing are preferably performed through a
control interface, such as using controller 130, and not by
physically connecting and re-connecting speaker wire, for example,
to individual, discrete speakers to create different
configurations. As such, certain embodiments described herein
provide a more flexible and dynamic platform through which sound
reproduction can be offered to the end-user.
[0053] e. Example Audio Sources
[0054] In some embodiments, each zone can play from the same audio
source as another zone or each zone can play from a different audio
source. For example, someone can be grilling on the patio and
listening to jazz music via zone player 124, while someone is
preparing food in the kitchen and listening to classical music via
zone player 102. Further, someone can be in the office listening to
the same jazz music via zone player 110 that is playing on the
patio via zone player 124. In some embodiments, the jazz music
played via zone players 110 and 124 is played in synchrony.
Synchronizing playback amongst zones allows for someone to pass
through zones while seamlessly (or substantially seamlessly)
listening to the audio. Further, zones can be put into a "party
mode" such that all associated zones will play audio in
synchrony.
[0055] Sources of audio content to be played by zone players
102-124 are numerous. In some embodiments, music on a zone player
itself may be accessed and a played. In some embodiments, music
from a personal library stored on a computer or networked-attached
storage (NAS) may be accessed via the data network 128 and played.
In some embodiments, Internet radio stations, shows, and podcasts
can be accessed via the data network 128. Music or cloud services
that let a user stream and/or download music and audio content can
be accessed via the data network 128. Further, music can be
obtained from traditional sources, such as a turntable or CD
player, via a line-in connection to a zone player, for example.
Audio content can also be accessed using a different protocol, such
as AIRPLAY.TM., which is a wireless technology by Apple, Inc., for
example. Audio content received from one or more sources can be
shared amongst the zone players 102 to 124 via data network 128
and/or controller 130. The above-disclosed sources of audio content
are referred to herein as network-based audio information sources.
However, network-based audio information sources are not limited
thereto.
[0056] In some embodiments, the example home theater zone players
116, 118, 120 are coupled to an audio information source such as a
television 132. In some examples, the television 132 is used as a
source of audio for the home theater zone players 116, 118, 120,
while in other examples audio information from the television 132
can be shared with any of the zone players 102-124 in the audio
system 100.
III. Example Zone Players
[0057] Referring now to FIG. 4, there is shown an example block
diagram of a zone player 400 in accordance with an embodiment. Zone
player 400 includes a network interface 402, a processor 408, a
memory 410, an audio processing component 412, one or more modules
414, an audio amplifier 416, and a speaker unit 418 coupled to the
audio amplifier 416. FIG. 2A shows an example illustration of such
a zone player. Other types of zone players may not include the
speaker unit 418 (e.g., such as shown in FIG. 2B) or the audio
amplifier 416 (e.g., such as shown in FIG. 2C). Further, it is
contemplated that the zone player 400 can be integrated into
another component. For example, the zone player 400 could be
constructed as part of a television, lighting, or some other device
for indoor or outdoor use.
[0058] In some embodiments, network interface 402 facilitates a
data flow between zone player 400 and other devices on a data
network 128. In some embodiments, in addition to getting audio from
another zone player or device on data network 128, zone player 400
may access audio directly from the audio source, such as over a
wide area network or on the local network. In some embodiments, the
network interface 402 can further handle the address part of each
packet so that it gets to the right destination or intercepts
packets destined for the zone player 400. Accordingly, in certain
embodiments, each of the packets includes an Internet Protocol
(IP)-based source address as well as an IP-based destination
address.
[0059] In some embodiments, network interface 402 can include one
or both of a wireless interface 404 and a wired interface 406. The
wireless interface 404, also referred to as a radio frequency (RF)
interface, provides network interface functions for the zone player
400 to wirelessly communicate with other devices (e.g., other zone
player(s), speaker(s), receiver(s), component(s) associated with
the data network 128, and so on) in accordance with a communication
protocol (e.g., any wireless standard including IEEE 802.11a,
802.11b, 802.11g, 802.11n, or 802.15). Wireless interface 404 may
include one or more radios. To receive wireless signals and to
provide the wireless signals to the wireless interface 404 and to
transmit wireless signals, the zone player 400 includes one or more
antennas 420. The wired interface 406 provides network interface
functions for the zone player 400 to communicate over a wire with
other devices in accordance with a communication protocol (e.g.,
IEEE 802.3). In some embodiments, a zone player includes multiple
wireless 404 interfaces. In some embodiments, a zone player
includes multiple wired 406 interfaces. In some embodiments, a zone
player includes both of the interfaces 404 and 406. In some
embodiments, a zone player 400 includes only the wireless interface
404 or the wired interface 406.
[0060] In some embodiments, the processor 408 is a clock-driven
electronic device that is configured to process input data
according to instructions stored in memory 410. The memory 410 is
data storage that can be loaded with one or more software module(s)
414, which can be executed by the processor 408 to achieve certain
tasks. In the illustrated embodiment, the memory 410 is a tangible
machine-readable medium storing instructions that can be executed
by the processor 408. In some embodiments, a task might be for the
zone player 400 to retrieve audio data from another zone player or
a device on a network (e.g., using a uniform resource locator (URL)
or some other identifier). In some embodiments, a task may be for
the zone player 400 to send audio data to another zone player or
device on a network. In some embodiments, a task may be for the
zone player 400 to synchronize playback of audio with one or more
additional zone players. In some embodiments, a task may be to pair
the zone player 400 with one or more zone players to create a
multi-channel audio environment. Additional or alternative tasks
can be achieved via the one or more software module(s) 414 and the
processor 408.
[0061] The audio processing component 412 can include one or more
digital-to-analog converters (DAC), an audio preprocessing
component, an audio enhancement component or a digital signal
processor, and so on. In some embodiments, the audio processing
component 412 may be part of processor 408. In some embodiments,
the audio that is retrieved via the network interface 402 is
processed and/or intentionally altered by the audio processing
component 412. Further, the audio processing component 412 can
produce analog audio signals. The processed analog audio signals
are then provided to the audio amplifier 416 for play back through
speakers 418. In addition, the audio processing component 412 can
include circuitry to process analog or digital signals as inputs to
play from zone player 400, send to another zone player on a
network, or both play and send to another zone player on the
network. An example input includes a line-in connection (e.g., an
auto-detecting 3.5 mm audio line-in connection).
[0062] The audio amplifier 416 is a device(s) that amplifies audio
signals to a level for driving one or more speakers 418. The one or
more speakers 418 can include an individual transducer (e.g., a
"driver") or a complete speaker system that includes an enclosure
including one or more drivers. A particular driver can be a
subwoofer (e.g., for low frequencies), a mid-range driver (e.g.,
for middle frequencies), and a tweeter (e.g., for high
frequencies), for example. An enclosure can be sealed or ported,
for example. Each transducer may be driven by its own individual
amplifier.
[0063] A commercial example, presently known as the PLAY:5, is a
zone player with a built-in amplifier and speakers that is capable
of retrieving audio directly from the source, such as on the
Internet or on the local network, for example. In particular, the
PLAY:5 is a five-amp, five-driver speaker system that includes two
tweeters, two mid-range drivers, and one woofer. When playing audio
content via the PLAY:5, the left audio data of a track is sent out
of the left tweeter and left mid-range driver, the right audio data
of a track is sent out of the right tweeter and the right mid-range
driver, and mono bass is sent out of the subwoofer. Further, both
mid-range drivers and both tweeters have the same equalization (or
substantially the same equalization). That is, they are both sent
the same frequencies but from different channels of audio. Audio
from Internet radio stations, online music and video services,
downloaded music, analog audio inputs, television, DVD, and so on,
can be played from the PLAY:5.
IV. Example Controller
[0064] Referring now to FIG. 5, there is shown an example block
diagram for controller 500, which can correspond to the controlling
device 130 in FIG. 1. Controller 500 can be used to facilitate the
control of multi-media applications, automation and others in a
system. In particular, the controller 500 may be configured to
facilitate a selection of a plurality of audio sources available on
the network and enable control of one or more zone players (e.g.,
the zone players 102-124 in FIG. 1) through a wireless or wired
network interface 508. According to one embodiment, the wireless
communications is based on an industry standard (e.g., infrared,
radio, wireless standard including IEEE 802.11a, 802.11b 802.11g,
802.11n, or 802.15, and so on). Further, when a particular audio is
being accessed via the controller 500 or being played via a zone
player, a picture (e.g., album art) or any other data, associated
with the audio and/or audio source can be transmitted from a zone
player or other electronic device to controller 500 for
display.
[0065] Controller 500 is provided with a screen 502 and an input
interface 514 that allows a user to interact with the controller
500, for example, to navigate a playlist of many multimedia items
and to control operations of one or more zone players. The screen
502 on the controller 500 can be an LCD screen, for example. The
screen 500 communicates with and is commanded by a screen driver
504 that is controlled by a microcontroller (e.g., a processor)
506. The memory 510 can be loaded with one or more application
modules 512 that can be executed by the microcontroller 506 with or
without a user input via the user interface 514 to achieve certain
tasks. In some embodiments, an application module 512 is configured
to facilitate grouping a number of selected zone players into a
zone group and synchronizing the zone players for audio play back.
In some embodiments, an application module 512 is configured to
control the audio sounds (e.g., volume) of the zone players in a
zone group. In operation, when the microcontroller 506 executes one
or more of the application modules 512, the screen driver 504
generates control signals to drive the screen 502 to display an
application specific user interface accordingly.
[0066] The controller 500 includes a network interface 508 that
facilitates wired or wireless communication with a zone player. In
some embodiments, the commands such as volume control and audio
playback synchronization are sent via the network interface 508. In
some embodiments, a saved zone group configuration is transmitted
between a zone player and a controller via the network interface
508. The controller 500 can control one or more zone players, such
as 102-124 of FIG. 1. There can be more than one controller for a
particular system, and each controller may share common information
with another controller, or retrieve the common information from a
zone player, if such a zone player stores configuration data (e.g.,
such as a state variable). Further, a controller can be integrated
into a zone player.
[0067] It should be noted that other network-enabled devices such
as an IPHONE.RTM., IPAD.RTM. or any other smart phone or
network-enabled device (e.g., a networked computer such as a PC or
MAC.RTM.) can also be used as a controller to interact or control
zone players in a particular environment. In some embodiments, a
software application or upgrade can be downloaded onto a
network-enabled device to perform the functions described
herein.
[0068] In certain embodiments, a user can create a zone group (also
referred to as a bonded zone) including at least two zone players
from the controller 500. The zone players in the zone group can
play audio in a synchronized fashion, such that all of the zone
players in the zone group play back an identical audio source or a
list of identical audio sources in a synchronized manner such that
no (or substantially no) audible delays or hiccups are to be heard.
Similarly, in some embodiments, when a user increases the audio
volume of the group from the controller 500, the signals or data of
increasing the audio volume for the group are sent to one of the
zone players and causes other zone players in the group to be
increased together in volume.
[0069] A user via the controller 500 can group zone players into a
zone group by activating a "Link Zones" or "Add Zone" soft button,
or de-grouping a zone group by activating an "Unlink Zones" or
"Drop Zone" button. For example, one mechanism for `joining` zone
players together for audio play back is to link a number of zone
players together to form a group. To link a number of zone players
together, a user can manually link each zone player or room one
after the other. For example, assume that there is a multi-zone
system that includes the following zones: Bathroom, Bedroom, Den,
Dining Room, Family Room, and Foyer.
[0070] In certain embodiments, a user can link any number of the
six zone players, for example, by starting with a single zone and
then manually linking each zone to that zone.
[0071] In certain embodiments, a set of zones can be dynamically
linked together using a command to create a zone scene or theme
(subsequent to first creating the zone scene). For instance, a
"Morning" zone scene command can link the Bedroom, Office, and
Kitchen zones together in one action. Without this single command,
the user must manually and individually link each zone. The single
command may include a mouse click, a double mouse click, a button
press, a gesture, or some other programmed action. Other kinds of
zone scenes can be programmed.
[0072] In certain embodiments, a zone scene can be triggered based
on time (e.g., an alarm clock function). For instance, a zone scene
can be set to apply at 8:00 am. The system can link appropriate
zones automatically, set specific music to play, and then stop the
music after a defined duration. Although any particular zone can be
triggered to an "On" or "Off" state based on time, for example, a
zone scene enables any zone(s) linked to the scene to play a
predefined audio (e.g., a favorable song, a predefined playlist) at
a specific time and/or for a specific duration. If, for any reason,
the scheduled music failed to be played (e.g., an empty playlist,
no connection to a share, failed Universal Plug and Play (UPnP), no
Internet connection for an Internet Radio station, and so on), a
backup buzzer can be programmed to sound. The buzzer can include a
sound file that is stored in a zone player, for example.
V. Example Decentralized Synchrony Groups
[0073] In certain embodiments, one or more playback devices operate
in a decentralized network to facilitate one or more synchrony
groups with one or more interchangeable master-slave relationships.
Using a decentralized network, communication, and control model, a
playback device may provide content to another playback device even
if the first playback device is not outputting that content for a
listener. Additionally, a playback device may serve as a master
device or control at one point in time and may receive instructions
(e.g., content and/or synchronization) from another device serving
as a master device at another point in time.
[0074] FIG. 6 depicts an illustrative network audio system 610
operating in accordance with a decentralized communication,
organization, and control structure. With reference to the example
of FIG. 6, the network audio system 610 includes a plurality of
zone players 611(1) through 611(N) (generally identified by
reference numeral 611(n)) interconnected by a local network 612,
all of which operate under control of one or more user interface
modules generally identified by reference numeral 613. The zone
players 611(n) may be the same or similar to the playback device(s)
described above. One or more of the zone players 611(n) may also be
connected to one or more audio information sources, which will
generally be identified herein by reference numeral 614(n)(s),
and/or one or more audio reproduction devices, which will generally
be identified by reference numeral 615(n)(r). In the reference
numeral 614(n)(s), index "n" refers to the index "n" of the zone
player 611(n) to which the audio information source is connected,
and the index "s" (s=1, . . . , Sn) refers to the "s-th" audio
information source connected to that "n-th" zone player 611(n).
Thus, if, for example, a zone player 611(n) is connected to four
audio information sources 614(n)(1) through 614(n)(4), the audio
information sources may be generally identified by reference
numeral 614(n)(s), with Sn=4. It will be appreciated that the
number of audio information sources Sn may vary among the various
zone players 11(n), and some zone players may not have any audio
information sources connected thereto.
[0075] Similarly, in the reference numeral 615(n)(r), index "n"
refers to the index "n" of the zone player 611(n) to which the
audio reproduction device is connected, and the index "r" (r=1, . .
. , Rn) refers to the "r-th" audio information source connected to
that "n-th" zone player 611(n). In addition to the audio
information sources 614(n)(s), the network audio system 610 may
include one or more audio information sources 616(1) through 616(M)
connected through appropriate network interface devices (not
separately shown) to the local network 612. Furthermore, the local
network 612 may include one or more network interface devices (also
not separately shown) that are configured to connect the local
network 612 to other networks, including a wide area network such
as the Internet, the public switched telephony network (PSTN) or
other networks, over which connections to audio information sources
may be established.
[0076] The zone players 611(n) associated with system 610 may be
distributed throughout an establishment such as residence, an
office complex, a hotel, a conference hall, an amphitheater or
auditorium, or other types of establishments. For example, if the
zone players 611(n) and their associated audio information
source(s) and/or audio reproduction device(s) are distributed
throughout a residence, one may be located in a living room,
another may be located in a kitchen, another may be located in a
dining room, and yet others may be located in respective bedrooms,
to selectively provide entertainment in those rooms.
[0077] On the other hand, if the zone players 611(n) and their
associated audio information source(s) and/or audio reproduction
device(s) are distributed throughout an office complex, one may,
for example, be provided in each office to selectively provide
entertainment to the employees in the respective offices.
Similarly, if the zone players 611(n) and associated audio
information source(s) and/or audio reproduction device(s) are used
in a hotel, they may be distributed throughout the rooms to provide
entertainment to the guests. Similar arrangements may be used with
zone players 611(n) and associated audio information source(s)
and/or audio reproduction device(s) used in an amphitheater or
auditorium. Other arrangements in other types of environments will
be apparent to those skilled in the art. In each case, the zone
players 611(n) may be used to selectively provide entertainment in
the respective locations, for example.
[0078] The audio information sources 614(n)(s) and 616(m) may be
any of a number of types of conventional sources of audio
information, including, for example, compact disc (CD) players, AM
and/or FM radio receivers, analog or digital tape cassette players,
analog record turntables, and the like. In addition, the audio
information sources 614(n)(s) and 616(m) may comprise digital audio
files stored locally on, for example, personal computers (PCs),
personal digital assistants (PDAs), or similar devices capable of
storing digital information in volatile or non-volatile form. As
noted above, the local network 612 may also have an interface to a
wide area network, over which the network audio system 610 may
obtain audio information. Moreover, one or more of the audio
information sources 614(n)(s) may also include an interface to a
wide area network such as the Internet, the public switched
telephony network (PSTN), or any other source of audio information.
In addition, one or more of the audio information sources 614(n)(s)
and 616(m) may include interfaces to radio services delivered over,
for example, satellite. Audio information obtained over the wide
area network may include, for example, streaming digital audio
information such as Internet radio, digital audio files stored on
servers, and other types of audio information and sources.
[0079] Generally, the audio information sources 614(n)(s) and
616(m) provide audio information associated with audio programs to
the zone players for playback. A zone player that receives audio
information from an audio information source 614(n)(s) that is
connected thereto may provide playback and/or forward the audio
information, along with playback timing information, over the local
network 612 to other zone players for playback. Similarly, each
audio information source 616(m) that is not directly connected to a
zone player may transmit audio information over the network 612 to
any zone player 611(n) for playback.
[0080] In addition, the respective zone player 611 (n) may transmit
the audio information that it receives either from an audio
information source 614(n)(s) connected thereto, or from an audio
information source 616(m), to selected ones of the other zone
players 611(n'), 611(n''), . . . (n not equal to n', n'', . . . )
for playback by those other zone players. The other zone players
611(n'), 611(n''), . . . to which the zone player 611(n) transmits
the audio information for playback may be selected by a user using
the user interface module 613. In that operation, the zone player
611(n) transmits the audio information to the selected zone players
611(n'), 611(n''), . . . over the network 612. The zone players
611(n), 611(n'), 611(n''), . . . operate such that the zone players
611(n'), 611(n''), . . . synchronize their playback of the audio
program with the playback by the zone player 611(n), so that the
zone players 611(n), 611(n'), 611(n'') provide the same audio
program at the same time.
[0081] Users, using user interface module 613, may also enable
different groupings or sets of zone players to provide audio
playback of different audio programs synchronously. For example, a
user, using a user interface module 613, may enable zone players
611(1) and 611(2) to play one audio program, audio information for
which may be provided by, for example, one audio information source
614(1)(1). The same or a different user may, using the same or a
different user interface module 613, enable zone players 611(4) and
611(5) to contemporaneously play another audio program, audio
information for which may be provided by a second audio information
source, such as audio information source 614(5)(2). Further, a user
may enable zone player 611(3) to contemporaneously play yet another
audio program, audio information for which may be provided by yet
another audio information source, such as audio information source
616(1). As yet another possibility, a user may contemporaneously
enable zone player 611(1) to provide audio information from an
audio information source connected thereto, such as audio
information source 614(1)(2), to another zone player, such as zone
player 611(6) for playback.
[0082] In the following, the term "synchrony group" is used to
refer to a set of one or more zone players that are to play the
same audio program synchronously. Thus, in the above example, zone
players 611(1) and 611(2) comprise one synchrony group, zone player
611(3) comprises a second synchrony group, zone players 611(4) and
611(5) comprise a third synchrony group, and zone player 611(6)
comprises yet a fourth synchrony group. Thus, while zone players
611(1) and 611(2) are playing the same audio program, the zones
players 611(1) and 611(2) play the audio program synchronously.
Similarly, while zone players 611(4) and 611(5) are playing the
same audio program, zone players 611(4) and 611(5) play the audio
program synchronously. On the other hand, zone players that are
playing different audio programs may do so with unrelated timings.
That is, for example, the timing with which zone players 611(1) and
611(2) play their audio program may have no relationship to the
timing with which zone player 611(3), zone players 611(4) and
611(5), and zone player 611(6) play their audio programs. It will
be appreciated that, since "synchrony group" is used to refer to
sets of zone players that are playing the same audio program
synchronously, zone player 611(1) is not part of zone player
611(6)'s synchrony group, even though zone player 611(1) is
providing the audio information for the audio program to zone
player 611(6).
[0083] In the network audio system 610, the synchrony groups are
not fixed. Users may enable them to be established and modified
dynamically. Continuing with the above example, a user may enable
the zone player 611(1) to begin providing playback of the audio
program provided thereto by audio information source 614(1)(1), and
subsequently enable zone player 611(2) to join the synchrony
group.
[0084] Similarly, a user may enable the zone player 611(5) to begin
providing playback of the audio program provided thereto by audio
information source 614(5)(2), and subsequently enable zone player
611(4) to join that synchrony group. In addition, a user may enable
a zone player to leave a synchrony group and possibly join another
synchrony group. For example, a user may enable the zone player
611(2) to leave the synchrony group with zone player 611(1), and
join the synchrony group with zone player 611(6). As another
example, the user may enable the zone player 611(1) to leave the
synchrony group with zone player 611(2) and join the synchrony
group with zone player 611(6). In connection with this example, the
zone player 611(1) may continue providing audio information from
the audio information source 614(1)(1) to the zone player 611(2)
for playback thereby.
[0085] A user, using the user interface module 613, may enable a
zone player 611(n) that is currently not a member of a synchrony
group to join a synchrony group, after which the zone player 611(n)
is enabled to play an audio program that is currently being played
by that synchrony group. Similarly, a user, also using the user
interface module 613, may enable a zone player 611(n) that is
currently a member of one synchrony group to disengage from that
synchrony group and join another synchrony group, after which that
zone player plays the audio program associated with the other
synchrony group.
[0086] For example, if a zone player 611(6) is currently not a
member of any synchrony group, it, under control of the user
interface module 613, may become a member of a synchrony group,
after which the zone player plays the audio program being played by
the other members of the synchrony group, in synchrony with the
other members of the synchrony group. In becoming a member of the
synchrony group, zone player 611(6) may notify the zone player that
is the master device for the synchrony group that the zone player
wishes to become a member of its synchrony group, after which that
zone player also transmits audio information associated with the
audio program, as well as timing information, to the zone player
611(6). As the zone player 611(6) receives the audio information
and the timing information from the master device, the zone player
611(6) plays the audio information with the timing indicated by the
timing information, which enables the zone player 611(6) to play
the audio program in synchrony with the other zone player(s) in the
synchrony group.
[0087] Similarly, if a user, using the user interface module 613,
enables a zone player 611(n) associated with a synchrony group to
disengage from that synchrony group, and, if the zone player 611(n)
is not the master device of the synchrony group, the zone player
611(n) may notify the master device, after which the master device
may terminate transmission of the audio information and timing
information to the zone player lien). If the user also enables the
zone player 611(n) to begin playing another audio program using
audio information from an audio information source 614(n)(s)
connected thereto, it acquires the audio information from the audio
information source 614(n)(s) and initiate playback thereof. If the
user enables another zone player 611(n') to join the synchrony
group associated with zone player 611(n), operations in connection
therewith may proceed as described immediately above.
[0088] In another example, if a user, using the user interface
module 613, enables a zone player 611(n) associated with a
synchrony group to disengage from that synchrony group and join
another synchrony group, and, if the zone player is not the master
device of the synchrony group from which it is disengaging, the
zone player 611(n) may notify the master device of the synchrony
group from which it is disengaging, after which that zone player
terminates transmission of audio information and timing information
to the zone player 611(n) that is disengaging.
[0089] Contemporaneously, the zone player 611(n) may notify the
master device of the synchrony group that it (that is, zone player
611(n)) is joining, after which the master device may begin
transmission of audio information and timing information to that
zone player 611(n). The zone player 611(n) may thereafter begin
playback of the audio program defined by the audio information, in
accordance with the timing information so that the zone player
611(n) plays the audio program in synchrony with the master
device.
[0090] As another example, a user, using the user interface module
613, may enable a zone player 611(n) that is not associated with a
synchrony group, to begin playing an audio program using audio
information provided to it by an audio information source 614(n)(s)
connected thereto. In that case, the user, also using the user
interface module 613 or a user interface device that is specific to
the audio information source 614(n)(s), may enable the audio
information source 614(n)(s) to provide audio information to the
zone player 611(n). After the zone player 611(n) has begun
playback, or contemporaneously therewith, the user, using the user
interface module 613, may enable other zone players 611(n'),
611(n''), . . . to join zone player 611(n)'s synchrony group and
enable that zone player 611(n) to transmit audio information and
timing information thereto as described above, to facilitate
synchronous playback of the audio program by the other zone players
611(n'), 611(n'') . . . . A user may use the user interface module
613 to control other aspects of the network audio system 10,
including but not limited to the selection of the audio information
source 614(n)(s) that a particular zone player 611(n) is to
utilize, the volume of the audio playback, and so forth. In
addition, a user may use the user interface module 613 to turn
audio information source(s) 614(n)(s) on and off and to enable them
to provide audio information to the respective zone players
611(n).
VI. Example Web-Based Music Partner Systems and Methods
[0091] Certain embodiments provide systems and methods for content
services to integrate with content access and playback networks.
For example, certain embodiments enable a music content provider to
integrate a music service with a playback device or a network or
group of playback devices (e.g., organized in zones, groups, and so
on as described above) without requiring updates or configuration
changes to the playback device or the network or group of playback
devices. In another example, certain embodiments enable a
hardware/software manufacturer of playback devices to provide a
simple interface for music content providers to make their content
available (e.g., free access or through a paid subscription) to the
end-users of the playback devices. As such, someone using a
playback device, for example, may easily access new content
providers to explore and discover new media content with minimal
effort. The technology and business applications are useful in many
other ways, such as described and understood from the description
herein. Further, the description below is generally directed to
music, however, it is understood that the technology may be used
for purposes of video and other types of audio.
[0092] In certain embodiments, one or more zone players may be
organized to play high-fidelity (HiFi) audio with respect to a
wired or wireless network (e.g., the SONOS.RTM. Wireless HiFi
System). Using the network system, a user may access one or more
stored music libraries, as well as Internet radio stations, online
music services, and so on. Certain embodiments assist a content
provider in configuring, developing, testing, certifying, and
making available a music service to a playback device and/or a
wired or wireless network playback system.
[0093] Certain embodiments provide a system to enable a content
service access to web services from a central location. Technical
details of a partner's content service for integration are entered
via a web site, and a setting for one or more servers causes the
service to appear in a customer's firmware without any interaction
by the customer.
[0094] In certain embodiments, content services access a
self-service web-based platform to sign agreements, download tools
and documents, and certify and register their services to
facilitate integration of content services into playback devices
and playback networks. In certain examples, the tools include user
interfaces (UIs) and application programming interfaces (APIs) to
connect the content services with the playback devices. The API
(e.g., the SONOS.RTM. Music API) may be an open web-services API
that provides a consistent way for content to be delivered by
web-based music services to the SONOS.RTM. and/or other media
playback system.
[0095] Certain embodiments enable a content provider to leverage
web services (e.g., AMAZON.TM. Web Services or other services in
"the cloud"). Certain embodiments provide scalability and low cost
to developers, platform/system providers, and end users. Certain
embodiments enable on-going "out of band" (e.g., no firmware
update) new partner launches.
[0096] In certain embodiments, an automated certification process
notifies the content services as to where they are in the partner
certification process, for example. The content partner has
visibility to its status in the process and is guided through the
process (i.e., the process is transparent to the partner). The
content partner reaches gates or milestones in the process and is
instructed what to do next. Using the process, tools, and
milestones in a flexible, scalable program, time to launch for new
music or other multimedia content may be reduced (e.g., cut in half
from a content provider working directly with a hardware/software
manufacturer).
[0097] In certain embodiments, a content release cycle involves
several phases including development or pre-alpha, alpha release
(e.g., initial testing and validation), beta release (e.g.,
usability and functional testing of feature-complete content), and
general availability (e.g., release or launch to the general market
upon review and validation completion from beta phase). The general
availability release is considered to be the "final" stable and
bug-free version of the content and/or content delivery service
(e.g., Internet radio or streaming service, and so on).
[0098] In certain embodiments, the content partner may run its own
beta with music listeners and receive feedback using tools and the
like. For example, beta self-service tools are provided so that a
partner may view real customer feedback and iterate quickly, to
create a better customer experience. Through the beta and eventual
full content release, partners benefit from web site placement,
customer communication, and in-product music menu placement (e.g.,
via a beta or test area, such as SONOS LABS.TM., as part of a music
content menu, and so on). Certain embodiments provide performance
or usage monitoring, or a combination of both performance and usage
monitoring, for example.
[0099] Using an open beta, the music delivery system may facilitate
crowd-sourcing of testing efforts by offering a test playground for
music services to demonstrate and iterate in a live environment, in
front of real customers (e.g., music listeners and system users).
For example, an in-product open beta feature (e.g., "Sonos Labs")
may be made available to listeners. Listeners may access the latest
music and participate in beta testing. Using the open beta with
crowd-sourced testing efforts, issues with content may be
identified sooner than with traditional techniques that are largely
content provider driven and not exposed to the platform or the
listener in advance. Testing may concurrently surface issues across
multiple services, for example. An open beta may also serve as a
place of quality control. In certain embodiments, a partner must
meet certain program-specified performance and quality standards
before beta content is made generally available to system users,
for example. Thus, for example, a burden of quality is shifted to
the partner, and the program drives and enforces certain quality
standards that are made known to the partner.
[0100] From a music listener's perspective, facilitating easy
integration of new content into a library of music available to
customers helps to deliver an expanding world of music for their
enjoyment. Access to music services may be faster and better
facilitated via an open beta, for example. Using the platform and
process, content integration may be made easier for music partners
and more reliable for customers. Additionally, consumers are
becoming more comfortable with the concept of digital content,
cloud-based music services, and the overall idea and value in
"paying" for access to content/music. Using open beta and eventual
general availability of new content, customers may discover,
browse, and play an effectively unlimited selection of music via
controllers and playback devices described above.
[0101] Certain embodiments provide a self-service model for content
partners to manage customer feedback. For example, web-based forms
may be provided for customer feedback. A discussion forum may be
set up for each partner's music service. Via the forum, both
customers and partners may view and post feedback. An issue
tracking tool (e.g., Bugzilla.TM.) may be used to report errors,
flaws, failures, etc., in the service (commonly referred to as
"bugs"), for example.
[0102] Social media may be leveraged to facilitate and monitor
feedback and advertisement, for example. In certain embodiments,
custom user experience widgets or features may be used as
interaction models for recommendation engines.
[0103] In certain embodiments, monitoring and measurement of
on-going performance is facilitated via automated, 24.times.7
monitoring and snapshot dashboard visibility. For example, an
on-going quality and performance dashboard may provide a real-time
snapshot of a music partner's overall health and availability,
based on a variety of real-time alerts and data. One such
measurement, for example, is the number of bugs filed against a
particular service. Another example measurement is the number of
audio dropouts reported. Yet another example measurement is the
total number of users using the music service. These measurements
may represent a total number of occurrences or the total number of
occurrences per twenty-four (24) hour period, for example.
[0104] a. Example Configuration
[0105] In an embodiment, one or more configuration parameters are
provided to the perspective content services to simplify the
integration with a playback network. For example, the audio sample
rates (e.g., 48 kHz, 44.1 kHz, 32 kHz, 24 kHz, 22.05 kHz, 16 kHz,
11.025 kHz, 8 kHz, and so on), codecs (e.g., WMA using HTTP, WMA
using MMS with HTTP-like streaming, WMA using RTSP, HE-AAC, PS and
SBR using HTTP, and so on), languages for localization (e.g.,
English, French, Italian, German, Spanish, Dutch, Japanese,
Chinese, Swedish, Danish, Norwegian, and so on), and security
(e.g., SSL TLS v1) supported are provided. Unlike many traditional
software development programs, in one embodiment, a special
developer key is not required to begin the process. Instead,
according to an embodiment, what is needed for a content service to
begin the process is to have a representative download the Web
Services Description Language (WSDL), read the documentation, and
implement the web service. This embodiment eliminates, or
substantially eliminates, the often lengthy process of certifying a
new service or developer before the process begins.
[0106] In addition to basic configuration parameters that can be
provided to the content services, a description of the playback
system architecture is provided. For example, music storage,
controller caching, playlist configuration, device limit, and so on
can be described. In one example embodiment, the playback devices
do not store music locally, but play music that is streamed from
content services directly. There may be some amount of internal
buffering in RAM on a player, for example, but the buffering is to
reduce or avoid music interruptions on an unreliable network. In
another embodiment, the controllers cache music metadata, album art
(e.g., in jpg or png format), and search results. The amount of
data that is cached, for example, varies between controller
application platform, and is subject to the amount of RAM present
in each device. In another embodiment, the content of a music queue
may be saved into a playlist that is stored on the playback system.
In one example embodiment, a playlist may contain an encoded
identifier the represents the service providing the track, the
track's MIME type, and track ID within that service. In another
example embodiment, a playlist may contain the actual audio content
for each track in the playlist and/or the actual streaming
identifier (e.g., uniform resource identifier (URI)) for each
track. In yet another embodiment, the maximum number of playback
devices in a playback system is provided. For example, in a Sonos
system, thirty-two (32) zones, each playing its own stream, are
supported.
[0107] b. Example Development Guide
[0108] In an embodiment, the music services API is based on the
Simple Object Access Protocol (SOAP); however if the back-end
services of the content provider are based on a different protocol,
then the service may act as a mediation layer that maps the
back-end protocol to SOAP commands. For example, if the back-end
services are based on the Representational State Transfer (REST)
protocol, then the API service can be used as a mediation layer
that maps SOAP API methods to the REST back-end protocol. In the
example system, all SOAP responses should use a common encoding.
For example, Unicode Transformation Format-8 (UTF-8) Extensible
Markup Language (XML) encoding can be used for most responses, and
GNU Zip (GZip) encoding can be used to compress longer
responses.
[0109] In an embodiment, search results can include thousands of
items, and preferably content services are not required to provide
all items at once. In one example embodiment, APIs that return
collections of items include parameters specifying a starting index
and a count. If the count is less than the total number of items,
then the playback system can request successive ranges of items to
get the entire results.
[0110] In an embodiment, a device ID is a unique ID of a playback
device in the playback system (e.g., a unique identifier of a zone
player in a household). This ID is established once when the
playback system is first set up and is not likely to change. In the
example system, content services can use this ID to designate a
single "instance" of a playback device. This is useful, for
example, to count simultaneous "instances" of a user accessing a
content service from multiple locations simultaneously. In some
situations, music licensing rules include limits on how many tracks
can be played simultaneously from the same account. In one example
embodiment, the API provides a specific SOAP fault code,
DeviceLimit, to identify that a limit is reached on the number of
locations simultaneously accessing content from a single user
account. If a playback device attempts to start playing a new
track, and the service returns DeviceLimit, for example, the player
will "blacklist" the service and skip over all tracks in the queue
from the service. In one example embodiment, the "blacklist" will
be lifted the next time the user attempts to play a track.
[0111] In an embodiment, the service provider can choose their own
programming language for the music service mediation layer. It is
suggested that the language is one that can ingest a WSDL language
and generate code. For example, C#, PHP, Ruby and Java can be
used.
[0112] In an embodiment, there are three ways to implement
authentication. In one example embodiment, authentication is
anonymous. In this mode, the user does not need to provide any
credentials, and the playback system will communicate with the
content service without any attempt to login or obtain any kind of
token (e.g., session token). In another example, authentication is
based on a session ID. In this mode, the playback system will pass
the username and password to the content service and expect a
session token to be returned to the playback system. For example,
the playback system may pass the username and password in the
getSesssionId call over a secure protocol such as HTTPS, and a
session token is returned. All subsequent calls to the content
service from the playback system will include the session token in
a custom SOAP header. In this example, sessions may expire using
business rules determined by the content service. When the playback
system gets a report of an expired session, then the playback
system will need to login again before playing content from that
content provider. In yet another example, authentication is based
on exchanging a username and password with every call to the
content service.
[0113] In an embodiment, the minimum functionality may be
implemented using only a few methods. For example, getSessionId,
getMetadata, getMediaMetadata, getStreamingURL, and getLastUpdate
may be used to provide basic services. In this example,
getSessionID adds the content service to the playback system,
including authentication information if necessary. getMetadata is
used to allow users to browse music in a container hierarchy. For
example, if a user wants to browse music by Artist, Track, Genre,
and so on, they would use this method to do so. getMediaMetadata is
used by the playback system to get metadata about a particular
track or stream. For example, the playback system may call this
method passing in a track or stream ID, and the content service may
reply with information describing the track or stream.
getStreamingURL is used by the playback system to play content from
a content service. For example, the track or stream ID can be
passed with this method to initiate the streaming content.
getLastUpdate is used by the playback device to refresh the content
catalog in a timely fashion.
[0114] In an embodiment, search functionality can be implemented
using the getMetadata method described above and a Search method
that accepts a category identifier (e.g., Track, Album, Artist,
Playlist, etc.), search term, and pagination parameters and
responds with the appropriate results. In the example system,
alphabetic scrolling (e.g., "power scroll") can be implemented
using the getScrollIndices method.
[0115] In an embodiment, skip-limits for programmed radio stations
can be supported to address business rules for content providers.
In one example embodiment, playback devices play programmed radio
stations by fetching small segments of tracks, getting the next
segment as the current segment is nearly complete. To prevent a
user from skipping tracks, the content provide can return
canSkip=false in the trackMetadata that is returned to the playback
system.
[0116] In an embodiment, a controller (e.g., controller 500) may be
enabled to display two lines for track, album, and artist
information. In one example embodiment, the controller inspects the
itemType of the music containers to determine whether or not a
two-line display for the item should be used.
[0117] In an embodiment, users can manage a personalized content
collection on a content service by implementing three methods:
createItem, deleteItem, and getLastUpdate. These methods can be
used to set up a custom service descriptor, for example, by
checking favorites or adding/removing tracks, albums, and artists
as appropriate. A polling interval (e.g., 300 seconds) can be used
to make sure the personalized content is up-to-date.
[0118] In an embodiment, errors can be reported from the content
service to the playback device, and subsequently to the user as
necessary, using a set of predefined SOAP error codes to indicate
error conditions. In addition to a set of standard error codes, for
example, the API allows a service to provide customized error
conditions for situations where the usual fault codes do not
apply.
[0119] c. Example Beta Program
[0120] In the example system, a Beta program is used to assist in
the quality control of new services before they are released to the
general population. In one example embodiment, the Beta process
lasts between two and four weeks, with a successful exit from Beta
being determined by the manufacturer of the playback system (e.g.,
the determination of a successful Beta is determined by Sonos, Inc.
for Sonos playback devices). Some factors that may play a role in
the successful exit from Beta include the number of users and
active engagement from the Beta pool, the performance of the
service during Beta, feedback from Beta participants, and the
resolution of open issues. In the example embodiment, all feedback
can be viewed on an open Beta feedback website. For example, the
open Beta feedback for the Sonos devices can be found at
http://publicbeta.sonos.com.
[0121] d. Example Process Flow
[0122] FIG. 7 shows a flow diagram 700 for an example process by
which a content partner may access, validate, test, and launch
content to users. At block 702, a content provider, such as a music
content developer, accesses a program website for content
validation and integration to a playback platform. At block 704,
the provider registers as a music developer. At block 706, after
registering, the developer may access one or more platform APIs and
technical documentation. The APIs and documentation may be used to
allow a content provider to integrate their content (e.g., on
demand music, a smart radio station, streaming radio, and so on)
with a delivery platform (e.g., a multi-room music system and so
on).
[0123] At block 708, after using the API and documentation, a
technical configuration for the developer's content is submitted to
the program. At block 710, a self-test may be executed by the
developer to evaluate and test the technical configuration for the
developer's content. For example, debugging, performance, and other
tools or simulations may be executed with respect to the
developer's arrangement of content.
[0124] At block 712, following a successful self-test, the
developer submits an application for its content to be accepted for
beta test. At block 714, the application is reviewed and approved
(or sent back for further modification). At block 716, integration
and validation testing is performed on approved content via the
program (e.g., via automated tools). At block 718, feedback may be
provided to the developer whether or not testing results are
satisfactory, for example.
[0125] At block 720, developer content in the technical
configuration is provided for open beta testing to delivery
platform users. For example, a new music streaming radio may be
provided to SONOS.TM. users via a SONOS.TM. Labs beta test menu,
accessible via a user's music library viewable through a SONOS.TM.
controller. At block 722, the beta access is monitored and
evaluated. For example, user access and interaction with the beta
content may be automatically monitored and parameters or metrics
may be quantified and stored for program and developer review.
[0126] At block 724, results of the open beta are evaluated against
general availability criteria. Criteria may be set by the program,
industry standard, and so on. Feedback may be provided to the
developer to make further modification for consideration against
the general availability criteria and before official release. At
block 726, after the program and the developer are satisfied, the
content is launched for general availability via the delivery
platform (e.g., via music library on a SONOS.TM. controller to a
network of zone playback devices).
[0127] FIG. 8 depicts a flow diagram 800 for an example integration
process between a multimedia content developer and a multimedia
content platform/service. At block 801, the integration process
begins (e.g., via a program website access). At block 802, it is
determined whether the developer is an existing partner. If not, at
block 803, registration information is collected. At block 804, the
registration information is evaluated to determine that all
required information has been provided. If not, registration
information is again requested (block 803). If so, then the
developer's codec is checked, at block 805, to determine whether it
is supported. A codec is a device or computer program capable of
encoding and/or decoding a digital stream or signal, such as a
digital audio stream, for example. If yes, then, at block 806, a
contract is agreed upon with the developer (e.g., the developer
agrees to the program terms). If a contract is not agree or a codec
is not supported, at block 807, a program representative is
contacted. At block 808, if the contract is accepted, the partner
is welcomed. For example, an email with the partner's login and
password is sent to the partner.
[0128] At block 809, the partner's login and password information
are entered (e.g., via a program web site, portal, application
interface, and so on). Using these credentials, the partner may
login and may return to the website to continue the integration
process. At block 810, the login and password information is
authenticated. At block 811, the partner tools and development area
(e.g., a self-service extranet) are accessed.
[0129] At block 812, a download area is provided for the developer.
Registered partners may have secure access to the portal, a
dedicated website for the partners and developers. This site
provides access to a wide variety of documents, technical
information, and support resources to help developers succeed in
their integration efforts. Some features of the portal include:
high-level white papers and getting started information, API
reference documentation and integration guides, technical notes and
sample code libraries to help solve specific integration tasks,
support resources including tips and tricks, frequently asked
question guide, trouble-shooting guides, issue tracking, and more.
For example, materials such as a developer's guide, API overview,
API reference, streaming standards and requirements, branding
guidelines, sample service implementation, user interface
guidelines, test plan, automation suite, testing scripts, and so
on, may be provided for developer access. At block 813, the
developer uses these tools and resources to provide an
implementation of their content. For example, after downloading
technical documentation, partners can start integrating their music
service functionality with the platform.
[0130] At block 814, a test plan is executed with respect to the
implementation. For example, an automation suite may be used to
simulate and test the developer's content implementation. In
certain examples, after integration is complete, partners may test
their services with an actual music system. In certain embodiments,
the portal provides partners with a "Self Service and Setup" page
to point music player components (e.g., a zone player and a
controller) to an end point supporting API Web Services. After
configuring their system on the "Self Service and Setup" page, the
partner will be able to see their music service in the Music Menu
of the Controller. At this point, the music service is visible only
to the partner for testing and not available to other users.
[0131] After configuring the music service, the partner is to
download the test plan, provided by the program, to execute one or
more test cases. The partner is expected to execute the complete
test plan to make sure all the functionality is performing within
specified quality and performance metrics. After successfully
testing their music service, the partner can submit its request to
enter the Open Beta program.
[0132] At block 815, an application for the developer's
implementation is submitted (or re-submitted following changes). At
block 816, the application is automatically evaluated against
program submission criteria.
[0133] At block 817, an evaluated and automatically approved
application is again reviewed, and, at block 818, either approved
or rejected. A partner application goes through a check point for
the review and approval process. In certain embodiments, review and
approval includes quality assurance (QA) validation, review of
screen shots, and review of open beta criteria. If the application
is approved, the partner enters Open Beta. At block 819, a
rejection report is provided back to the developer for a change in
implementation (block 813). For example, if the partner does not
meet performance and quality criteria, the application is rejected
and an email is sent with the reasons for rejection. After fixing
the problems, the partner can re-submit the application for
approval. At block 820, an approved application is enabled as a
service (e.g., a music service) in open beta (e.g., via a music
playback controller).
[0134] At block 821, an open beta begins. During the open beta,
users may access the service and its content (e.g., in an
experimental or beta area, in a regular music area with a beta
label, and so on). Error statistics, performance measurements, user
ratings, user discussion, other feedback, and so on may be
collected and reported, for example. This is designed to allow
partners to perform load testing and fine-tune their services while
in beta. In-product open beta testing tools may be provided.
[0135] In certain embodiments, a beta testing area (e.g., the SONOS
SOUND LAB.TM.) enables partners to crowd-source their testing
efforts. By offering a test playground for music services to demo
and stream their content in a live environment with actual
customers, partners may identify usability and performance issues
with their service more quickly and reduce overall time-to-market.
Customers may access the latest music services by participate
participating in the beta testing.
[0136] As shown in FIG. 9A, for example, a controller may provide a
"More Music" menu 920, in which a list of beta services available
to customers is shown. Once the service is selected by the customer
using a simple setup wizard, it will appear under the "Music Menu"
930. To differentiate beta services from those already generally
available, the music service logo is tagged with a "beta" badge
920, for example. As illustrated in the example of FIG. 9B, the
"beta" badge may be removed at the end of beta testing.
[0137] At block 822, open beta evaluation occurs. For example, an
evaluation of whether the open beta is ready for general
availability is performed. During beta testing, customers test the
service, provide feedback and submit any bugs they may find. The
partners and developers portal gives partners access to forums and
issue tracking software to monitor feedback and resolve any issues
users are experiencing. At block 823, outstanding bugs or issues
are identified. If yes, beta testing continues. If no, at block
824, performance criteria are evaluated (e.g., on a scale from one
to ten). At this stage, the partner service goes through another
check point to track any outstanding issues, to monitor performance
and to ensure all partner deliverables are ready for the general
availability of the service. After a period of beta testing, if the
service is performing within the specified performance guidelines
and there are no outstanding issues, beta testing ends and the
service is enabled for general availability (GA). If the
performance criteria have not been met, then beta testing
continues. If the criteria have been met, then, at block 825, user
ratings are evaluated for acceptability (e.g., on a scale from one
to five). If not, then beta testing continues. If yes, then, at
block 826, partner deliverables are checked for availability. If
no, then beta testing continues. If yes, then, at block 827, the
content/service is provided to users with general availability via
a content delivery platform 828. As shown in FIG. 9B, the beta
badge is removed upon GA launch and the service appears under in
the Music Menu on the controller.
[0138] FIG. 10 illustrates a flow diagram 1000 for an example
cross-functional workflow for development, integration, beta, and
launch of new content services. At block 1001, program information
is provided. For example, information for new partners and
developers regarding the integration program is provided via a
website or other portal. At block 1002, registration information is
obtained from a new partner and login information is provided by
newly registered and previously registered partners.
[0139] At block 1003, a partner dashboard or "home screen" is
provided via a partner website or other portal. At block 1004, via
the provider portal, a technical resources download area may be
accessed. Technical information, API resources, or other tools may
be accessed by a registered partner, for example.
[0140] At block 1005, the partner implements a desired content
(e.g., digital audio) service. At block 1006, partner service(s)
may be enabled for testing on a provided test system for partner
self-test. At block 1007, after self-testing has been completed, an
application is submitted to the program for the service(s). As part
of the application, the partner submits all final deliverables for
an implemented service.
[0141] At block 1008, the application for service is reviewed for
quality, compliance, and so on. Assuming criteria are met, the
application is approved. Otherwise, the application is sent back
for further development and testing.
[0142] At block 1009, an approved service is enabled for beta
testing. For example, the service is provided for open beta and
made available to customers for use and review. The service is
monitored and evaluated automatically and by user feedback during
beta testing, for example. Feedback is provided to the developer
for consideration and possible modification, for example.
[0143] At block 1010, a general availability checklist is reviewed,
and a service candidate satisfying the criteria is released. At
block 1011, documentation, frequently asked questions (FAQs),
training, and so on are updated for general release via the content
platform. At block 1012, the service is made generally available
outside the beta. Content and music services may be updated on a
controller or other interface based on the newly available service,
for example.
[0144] FIG. 11 illustrates an example integration testing system
and associated process flow 1100. As shown in FIG. 11, a partner
portal 1101 may be accessed to, at 1102, download test tools 1104
via the Internet 1103 or other network. The test tools 1104 may
include test plan, API functional test suite, and so on. Using the
test tools 1104, a test may be executed at 1105. The test may be
executed via a partner firewall 1106 at a partner test server 1107,
and/or a test may be executed, at 1108, using a zone
player/controller configuration 1109, with results provided to the
partner test server 1107. At block 1110, test results are
collected, and, at 1111, test results are submitted via the
Internet or other network 1103 to the partner portal 1101.
[0145] Alternatively or in addition, a test may be executed, at
block 1112, at a partner public test server 1113 (e.g., an open
beta). A test server 1115 may also be used to execute a test 1114,
such as an API functional test, an API load test, and so on.
[0146] At block 1116, test results are compared, and, at 1117, test
results are submitted to the partner portal 1101 for review (and
further action).
[0147] FIG. 12 provides an example infrastructure 1200 for open
beta testing of content services. One or more music services 1201,
such as music service partners 1, 2, and 3 shown in FIG. 12, may
access one or more households 1203, such as beta customers 1, 2, 3,
4, . . . N, via the Internet 1202 or other network. Each beta
customer 1203 sends data for validation to a data collection (e.g.,
a data warehouse) 1204.
[0148] The collected data is evaluated, at 1205, to determine
whether one or more performance criterion is met. If the one or
more performance criterion is not met, then the beta test continues
with the customers 1203. If the one or more performance criterion
is met, then, at 1206, the data is evaluated to determine whether
the beta received an acceptable user rating. If the beta did not
receive an acceptable user rating, then the beta continues. If an
acceptable user rating was obtained, then the candidate is sent to
a check point 1209. Additionally, beta feedback may be provided via
a partner extranet 1207, including one or more music partner
forums, error reporting, user rating, and so on. At 1208,
outstanding bugs or issues are identified based on the partner
extranet 1207 feedback. If outstanding bugs or issues have been
identified, then the beta testing continues. If no outstanding bugs
or issues have been identified, then the candidate is sent to the
check point 1209.
[0149] At the check point 1209, data collected during the for the
service candidate beta is evaluated to determine whether beta
testing should continue or the candidate should be released to
general availability.
[0150] FIG. 13 illustrates an example music service performance
feedback dashboard 1300. A partner may obtain information for one
or more services 1301 regarding performance rating 1302, user
rating 1303, and identified issues 1304. The feedback may be used
for further modification, testing, or approval of the service and
may update as beta testing continues, for example.
[0151] Using the systems and methods described above, content
services may be developed, validated, beta tested by real
customers, and integrated with a content delivery platform. Certain
embodiments offer an open web-services API that provides an easy
way for content to be delivered by web-based streaming music
services and consumed by a content delivery system, such as the
SONOS.TM. Multi-Room Music System. The API is designed to support a
range of content providers, including on-demand music services as
well as Internet radio streaming. In certain embodiments, the API
is not designed for downloading music and saving onto a local hard
drive or other storage; instead the API is designed with a focus on
streaming media across playback devices that do not contain large
amounts of internal storage, for example.
[0152] In certain embodiments the API web service specification is
built using the SOAP 1.2 specification and defines methods to
browse and play music from a music service. A SOAP message
including an envelope containing an optional header and a required
body. The header contains blocks of information relevant to how the
message is to be processed. This includes routing and delivery
settings, authentication or authorization assertions, and
transaction contexts. The body contains the actual message to be
delivered and processed. In the example API, the SOAP headers are
used for passing in user credentials.
[0153] Web Services Description Language (WSDL) is an XML grammar
for describing network services as collections of communication
endpoints capable of exchanging messages. In certain embodiments,
the physical specification for the API is given as a WSDL document
and an XML Schema Definition (XSD) document. The WSDL+XSD documents
provide an unambiguous definition for all methods and data types in
the API, and have an additional benefit of being machine-readable
by several popular code generation tools.
[0154] In certain embodiments, error handling in the API is done
via standard SOAP 1.1 faults, specifically via the SOAP
<faultcode> element. The API may define a set of predefined
fault codes, for example.
[0155] In certain embodiments, the API provides core services for
four areas of media consumption: 1) Authentication, 2) Browsing and
Search, 3) Audio Playback, and 4) User Customization. Certain
optional services may also be provided.
[0156] e. Example Authentication Service
[0157] FIG. 14 illustrates an example authentication service. Most
service providers require a username and password to access their
content hierarchy or streams. In certain embodiments, the services
API provides a way for devices to authenticate via
username/password. Furthermore, a unique device-specific identifier
(such as its Media Access Control (MAC) address) is passed between
the device and service, in case the service wants to enforce any
per-device business rules.
[0158] In order to avoid overhead associated with maintaining
server state, each API/SOAP request that requires user
authorization carries credential information. Each API/SOAP request
includes a SOAP header element with end-user credentials. Because
some service providers cannot resolve username and password
credentials efficiently, the API also supports a tokenized form for
credential information. A separate API/SOAP request is made to
translate a username/password pair into an opaque token called
"sessionId".
[0159] Authentication is implemented by the getSessionId method or,
alternatively, can be implemented by passing in credentials with
HTTP headers, for example.
[0160] Thus, authentication may be facilitated between a music
system 1410 including at least one controller 1412 and at least one
zone player 1414 and a music service 1430 via a SOAP request 1420,
a SOAP response 1422, getSessionId(Username, Password) 1424, and
getSessionIdResponse(sessionId) 1426 via a WSDL 1432 and API
endpoint (e.g., an API/SOAP Web Server) 1434 associated with a
music server 1436.
[0161] f. Example Browse and Search Services
[0162] Consumers like to explore content by artist, genre, etc. As
such, in certain embodiments, the API allows music services to
provide browsing based on metadata like artists, albums, composers,
playlists, genres, programmed stations, and tracks. Service
providers may add their own browse hierarchy to allow consumers to
explore the editorial content, such as Top 100s, and the like.
[0163] The web services API allows service providers to tailor and
dynamically change the content hierarchy that they present. This
capability allows the service provider, the partner, to present
different content based on business rules, geography or user
experience on the affected device, for example.
[0164] In certain embodiments, in the API, the service provider is
responsible for sorting elements within the hierarchy, e.g.,
alphabetically or by some computed relevance. However the service
chooses to sort elements, the sort order should be consistent and
understandable to the user of the streaming device.
[0165] In certain embodiments, browse and search calls may be
structured to allow incremental browsing. This is to better support
devices with low memory footprints. For example, when a device
performs a search for all albums containing the string "Hits", the
call also specifies a desired starting index and count for the
search results (e.g., "search all tracks for `hits` and return 20
results starting at the 100th result").
[0166] In certain embodiments, browsing is implemented by the
getMetadata, getMediaMetadata and getLastUpdate methods. The API
also supports optional search and alphabetical scrolling
functionality. Search is implemented by the search method and uses
letter by letter search. Alphabetical scrolling is implemented by
the getScrollIndices method.
[0167] In certain embodiments, a client device using the API
invokes the getMediaURI method to obtain the playback URL of a
track given a track identifier (ID). This method is called on a
secure endpoint using secure sockets layer (SSL), and returns a
secure hypertext transfer protocol (HTTPS) URL for the track.
[0168] In certain embodiments, the API does not constrain
implementers to use any particular protocol. In certain
embodiments, the only requirement is that getMediaURI provide
content that can be streamed in a form recognized by the device,
for example. The API implementations have been built with streaming
via HTTP and multimedia messaging service (MMS), for example.
[0169] In certain embodiments, the API is agnostic about the
transport used for delivering content, and about how the content is
encoded. Content may be delivered as MP3s using HTTP streaming, as
Microsoft WINDOWS.TM. Media Audio using MMS, etc.
[0170] Content providers may want to allow users to customize their
content, such as allowing the creation of custom playlists. In
certain embodiments, the API supports this with general "item"
management functions. Customization is implemented by the
createItem and deleteItem methods, for example.
[0171] In certain embodiments, optional services may include 1)
Favorites, 2) Alphabetical Scrolling, 3 Status Reporting, 4)
Extended Metadata, and 5) Track Ratings, for example.
[0172] In certain embodiments, a service provider may have some
mechanism for users to add artists, albums or tracks to a special
"favorites" collection. If a favorite's collection is exposed to
the device, the service provider must implement these methods.
Favorites are implemented by the createItem, and deleteItem
methods, for example.
[0173] In certain embodiments, alphabetical scrolling is a
technique that optimizes content enumeration for large collections
of metadata. It allows a user to scroll through the alphabet to
select a letter, which can then initiate a getMetadata request on a
collection at a particular index, for example. If a service
provider wishes to provide this capability for large lists of
items, it may implement these methods. Alphabetical Scrolling is
implemented by the getScrollIndices method, for example.
[0174] In certain embodiments, service providers may want to
collect statistics or improve quality of service by being notified
when streaming failures occur. A service provider may implement
these methods if they desire such feedback from devices. Status
Reporting is implemented by the reportStatus and setPlayedSeconds
methods, for example.
[0175] In certain embodiments, a service provider may expose
additional metadata about a track, artist, album, or station, which
can be used by the client to create a richer browsing experience
for the user. Extended Metadata is implemented by the
getExtendedMetadata and getExtendedMetadataText methods.
[0176] In certain embodiments, music services may decide what, if
any, extra information view items they wish to present. In general,
the information view items fall into three categories: 1) Text
information about an artist, album or track. Examples include album
reviews, artist biographies and tour dates. 2) Additional music
browsing within the music service taking the selected content as
the starting point. For example, the information may be provided to
find artists who are similar or have influenced the selected
artist. 3) Library actions based on the selected track, album or
artist. For example, information may be provided to "Add track to
Library" or "Delete Album from library".
[0177] In certain embodiments, a service provider may allow the
client to apply a rating to a track. The value of the rating is
represented via the API simply as an integer, which has no inherent
semantic meaning. It is up to the service and client to define and
agree upon the meaning of each particular "rating value", and
behave accordingly. Track Ratings is implemented by the rateItem
method, for example.
[0178] FIG. 15 illustrates an example integration 1500 of the
SONOS.TM. Multi-Room Music System 1510 with an ACME Music Service
(AMS) 1530, which provides an endpoint 1531 to a SOAP web server
1533 running Sonos API services 1537 as shown in FIG. 15. The
sequence diagram of FIG. 15 shows a SOAP API request 1522 and a
SOAP response message 1524 between the music system 1510 and the
AMS 1530 for various music operations.
[0179] The music system 1510 may invoke 1520 a web service 1537 at
the music service's 1530 web server 1533. Music system 1510
components (Zone Player 1514 and Controller 1512) call the AMS 1530
using SOAP over HTTP and HTTPS 1522. The API 1535 makes use of SOAP
header blocks to present user credentials when applicable. When
user credentials are required by an API, the HTTPS transport is
used, otherwise the HTTP transport is used. For example, browsing
of the entire content hierarchy from AMS does not require any user
login or authentication whereas enumeration of the user "favorites"
directory would require valid credentials.
[0180] FIG. 16 illustrates an example system and sequence diagram
for content playback. As shown in FIG. 16, a zone player 1610
receives a request to play an audio track. The player 1610 uses a
message (e.g., an HTTPS SOAP message) 1620 to get a uniform
resource indicator (UIR) for the media file via a WSDL 1630 and a
music service API endpoint 1640. The WSDL 1630 formats the request
for the API endpoint 1640, which communicates with one or more
service content servers 1650 to locate the media. The server 1650
provides a location for the track via a return message 1660.
[0181] As illustrated, for example, in FIG. 17, prior interaction
between music services 1710 and playback devices 1730 over a
network such as the Internet 1720 suffered from device 1730
incompatibility, resulting in the use of one API 1740-1748 to
provide content from each service 1710 to each device 1730.
[0182] As illustrated, for example, in FIG. 18, certain embodiments
facilitate interoperability through provided resources, guidelines,
APIs, and testing to facilitate better interaction between music
services 1810 and playback devices 1830 over a network such as the
Internet 1820. In the example of FIG. 18, a common music API 1840
is used to facilitate communication and interoperability among all
connected services 1810 and devices 1830 to provide and share
content.
[0183] Figures described above (such as at least FIGS. 7, 8, 10-12,
and 14-16) depict example flow diagrams representative of
process(es) that may be implemented using, for example, computer
readable instructions that may be used to develop, evaluate, beta
test, approve, and release new multimedia content for access and
playback via a zone player and/or other playback device. The
example process(es) may be performed using a processor, a
controller and/or any other suitable processing device. For
example, the example process(es) may be implemented using coded
instructions (e.g., computer readable instructions) stored on a
tangible computer readable medium such as a flash memory, a
read-only memory (ROM), and/or a random-access memory (RAM). As
used herein, the term tangible computer readable medium is
expressly defined to include any type of computer readable storage
and to exclude propagating signals. Additionally or alternatively,
the example process(es) may be implemented using coded instructions
(e.g., computer readable instructions) stored on a non-transitory
computer readable medium such as a flash memory, a read-only memory
(ROM), a random-access memory (RAM), a cache, or any other storage
media in which information is stored for any duration (e.g., for
extended time periods, permanently, brief instances, for
temporarily buffering, and/or for caching of the information). As
used herein, the term non-transitory computer readable medium is
expressly defined to include any type of computer readable medium
and to exclude propagating signals.
[0184] Alternatively, some or all of the example process(es) may be
implemented using any combination(s) of application specific
integrated circuit(s) (ASIC(s)), programmable logic device(s)
(PLD(s)), field programmable logic device(s) (FPLD(s)), discrete
logic, hardware, firmware, and so on. Also, some or all of the
example process(es) may be implemented manually or as any
combination(s) of any of the foregoing techniques, for example, any
combination of firmware, software, discrete logic and/or hardware.
Further, although the example process(es) are described with
reference to the flow diagrams of FIGS. 7, 8, 10-12, and 14-16,
other methods of implementing the process(es) may be employed. For
example, the order of execution of the blocks may be changed,
and/or some of the blocks described may be changed, eliminated,
sub-divided, or combined. Additionally, any or all of the example
process(es) may be performed sequentially and/or in parallel by,
for example, separate processing threads, processors, devices,
discrete logic, circuits, and so on.
VII. Example Processing System
[0185] FIG. 19 is a block diagram of an example processor system
1900 that may be used to implement the systems, apparatus, articles
of manufacture, and methods described herein. The processor system
1900 may be included in, be used to implement, be used to control,
and/or be used to provide information to one or more of the
processes, systems, and configurations described above. As shown in
FIG. 19, the processor system 1900 includes a processor 1902 that
is coupled to an interconnection bus 1904. The processor 1902 may
be any suitable processor, processing unit or microprocessor.
Although not shown in FIG. 19, the system 1900 may be a
multi-processor system and, thus, may include one or more
additional processors that are identical or similar to the
processor 1902 and that are communicatively coupled to the
interconnection bus 1904.
[0186] The processor 1902 of FIG. 19 is coupled to a chipset 1906,
which includes a memory controller 1908 and an input/output (I/O)
controller 1910. As is well known, a chipset typically provides
input/output (I/O) and memory management functions as well as a
plurality of general purpose and/or special purpose registers,
timers, etc. that are accessible or used by one or more processors
coupled to the chipset 1906. The memory controller 1908 performs
functions that enable the processor 1902 (or processors if there
are multiple processors) to access a system memory 1912 and a mass
storage memory 1914.
[0187] The system memory 1912 may include any desired type of
volatile and/or non-volatile memory such as, for example, static
random access memory (SRAM), dynamic random access memory (DRAM),
flash memory, read-only memory (ROM), etc. The mass storage memory
1914 may include any desired type of mass storage device including
hard disk drives, optical drives, tape storage devices, etc.
[0188] The I/O controller 1910 performs functions that enable the
processor 1902 to communicate with peripheral I/O devices 1916 and
1918 and a network interface 1920 via an I/O bus 1922. The I/O
devices 1916 and 1918 may be any desired type of I/O device such
as, for example, a keyboard, a video display or monitor, a mouse,
etc. The network interface 1920 may be, for example, an Ethernet
device, an asynchronous transfer mode (ATM) device, an 802.11
device, a DSL modem, a cable modem, a cellular modem, etc. that
enables the processor system 1900 to communicate with another
processor system.
[0189] While the memory controller 1908 and the I/O controller 1910
are depicted in FIG. 19 as separate blocks within the chipset 1906,
the functions performed by these blocks may be integrated within a
single semiconductor circuit or may be implemented using two or
more separate integrated circuits.
VIII. Conclusion
[0190] The example embodiments described herein provide for systems
and methods to integrate music provider services with platforms and
systems for content distribution and playback. Technology from the
example embodiments may be used in any application where accurately
reproduced sound is desired, such as in buildings, motorized
vehicles, boats, airplanes, and in outdoor locations.
[0191] Certain embodiments provide a system including a web-based
media content development platform and content delivery platform,
the platforms including a processor and a memory. The example
development platform is arranged to provide an interface to accept
media content from a provider for certification. The example
development platform is arranged to facilitate self-test of the
media content by the provider via the interface according to
testing tools and an application programming interface provided in
conjunction with the development platform. The example development
platform is arranged to process the media content for monitored
beta test by a group of users via the content delivery platform.
The example development platform is arranged to evaluate the
monitored beta test to determine suitability of the media content
for release. The example development platform is arranged to
facilitate release of the media content for general availability
via the content delivery platform.
[0192] Certain embodiments provide a computer-implemented method
including providing, via a web-based media content development
platform, an interface to accept media content from a provider for
certification. The example method includes facilitating self-test
of the media content by the provider via the interface according to
testing tools and an application programming interface provided in
conjunction with the development platform. The example method
includes processing the media content for monitored beta test by a
group of users via a content delivery platform. The example method
includes evaluating the monitored beta test to determine
suitability of the media content for release. The example method
includes facilitating release of the media content for general
availability via the content delivery platform.
[0193] Certain examples provide a computer readable storage medium
including instructions for execution by a processor, the
instructions, when executed by the processor, to implement a system
for web-based content development and deployment. The example
system includes a web-based media content development platform and
content delivery platform, the platforms including a processor and
a memory. The example development platform is arranged to provide
an interface to accept media content from a provider for
certification. The example development platform is arranged to
facilitate self-test of the media content by the provider via the
interface according to testing tools and an application programming
interface provided in conjunction with the development platform.
The example development platform is arranged to process the media
content for monitored beta test by a group of users via the content
delivery platform. The example development platform is arranged to
evaluate the monitored beta test to determine suitability of the
media content for release. The example development platform is
arranged to facilitate release of the media content for general
availability via the content delivery platform.
[0194] The components, elements, and/or functionality of the
systems discussed above may be implemented alone or in combination
in various forms in hardware, firmware, and/or as a set of
instructions in software, for example. Certain embodiments may be
provided as a set of instructions residing on a computer-readable
medium, such as a memory, hard disk, CD-ROM, DVD, and/or EPROM, for
execution on a processing device, such as a controller and/or
playback device.
[0195] Various inventions have been described in sufficient detail
with a certain degree of particularity. It is understood to those
skilled in the art that the present disclosure of embodiments has
been made by way of examples only and that numerous changes in the
arrangement and combination of parts may be resorted without
departing from the spirit and scope of the invention as claimed.
While the embodiments discussed herein may appear to include some
limitations as to the presentation of the information units, in
terms of the format and arrangement, the embodiments have
applicability well beyond such embodiment, which can be appreciated
by those skilled in the art. Accordingly, the scope of the present
invention is defined by the claims rather than the forgoing
description of embodiments.
* * * * *
References