DCT

3:21-cv-07559

Sonos Inc v. Google LLC

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 3:21-cv-07559, N.D. Cal., 02/23/21 (Note: Complaint was originally filed in W.D. Tex. as 6:20-cv-00881 and later transferred).
  • Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Google has committed acts of infringement and has regular and established places of business in the district.
  • Core Dispute: Plaintiff alleges that Defendant’s Google Wireless Audio System, including its Chromecast, Nest, and Google Home smart speakers and associated software applications, infringes five patents related to networked audio playback and multi-device control.
  • Technical Context: The lawsuit concerns the technology of wireless multi-room audio systems, a market where smart speakers stream audio from cloud-based services and can be grouped for synchronized playback.
  • Key Procedural History: The complaint states that this is the second patent infringement suit by Sonos against Google, following a January 2020 complaint at the International Trade Commission (ITC) involving a different set of patents. The complaint also alleges that Sonos put Google on notice of infringement of a portfolio of patents on multiple occasions dating back to August 2016, and provided a pre-filing copy of the complaint to Google, which may be relevant to allegations of willful infringement.

Case Timeline

Date Event
2011-12-30 Earliest Priority Date for ’615 and ’033 Patents
2013-05-17 Earliest Priority Date for ’206, ’966, and ’885 Patents
2015-01-01 Chromecast Audio, an accused product, is launched
2016-05-17 U.S. Patent No. 9,344,206 Issues
2016-10-01 Sonos allegedly puts Google on notice of infringement, including of the ’206 Patent
2017-01-01 Google Home Max and Mini, accused products, are launched
2018-05-08 U.S. Patent No. 9,967,615 Issues
2019-02-01 Sonos allegedly puts Google on notice of infringement, including of the ’615 Patent
2019-11-05 U.S. Patent No. 10,469,966 Issues
2020-09-15 U.S. Patent No. 10,779,033 Issues
2020-11-24 U.S. Patent No. 10,848,885 Issues
2021-02-23 Complaint Filing Date

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 9,967,615 - “Networked Music Playback”

  • Patent Identification: U.S. Patent No. 9967615, "Networked Music Playback," issued May 8, 2018.

The Invention Explained

  • Problem Addressed: The patent addresses the challenge of creating a seamless listening experience when a user transitions from listening to media on a personal device (like a smartphone) to a home audio system (’615 Patent, col. 12:44-53). The goal is to allow a user's home "playback system" to "pick[] up from the same spot on the selected channel that was on her phone" without tight technical coupling between the third-party application and the playback system (’615 Patent, col. 12:44-67).
  • The Patented Solution: The invention describes a method where a user's "control device" (e.g., a smartphone running a third-party music app) can transfer playback responsibility to a separate "playback device" (e.g., a smart speaker) on a local network (’615 Patent, col. 12:53-63). This is achieved by passing data for retrieving the media, such as a Uniform Resource Locator (URI), to the playback device, which then "run[s] on its own to fetch the content" directly from the cloud (’615 Patent, col. 12:53-63). After the transfer, the control device's interface is modified to control the playback now occurring on the separate playback device (’615 Patent, col. 16:20-25).
  • Technical Importance: This "casting" or "handoff" model allows third-party applications to integrate with dedicated home audio hardware without needing complex, tightly-coupled software, thereby creating a more open and flexible ecosystem for streaming media (’615 Patent, col. 15:47-16:19).

Key Claims at a Glance

  • The complaint asserts at least independent claim 13 (’615 Patent, claim 13; Compl. ¶79).
  • Claim 13 recites a non-transitory computer-readable storage medium with instructions for a control device to implement a method comprising:
    • causing a graphical interface to display a control interface with transport controls for playback by the control device;
    • identifying playback devices connected to a local area network;
    • causing the graphical interface to display a selectable option for transferring playback;
    • detecting inputs selecting the transfer option and a particular playback device;
    • causing playback to be transferred by: (a) causing a cloud server to add multimedia content (via resource locators) to a local playback queue on the playback device, (b) stopping playback on the control device, and (c) modifying the transport controls to control the playback device; and
    • causing the playback device to retrieve and play the multimedia content from the cloud.
  • The complaint reserves the right to assert additional claims (Compl. ¶78).

U.S. Patent No. 10,779,033 - “Systems And Methods For Networked Music Playback”

  • Patent Identification: U.S. Patent No. 10779033, "Systems And Methods For Networked Music Playback," issued September 15, 2020.

The Invention Explained

  • Problem Addressed: This patent, which shares a specification with the ’615 Patent, addresses the same general problem of seamlessly transferring playback from a user's device to a dedicated media playback system (Compl. ¶59).
  • The Patented Solution: The invention claims a computing device that operates in two distinct modes. In a "first mode," it plays back a "remote playback queue" from a cloud service while also displaying representations of other available playback devices on the network (’033 Patent, claim 1). Upon user input selecting one of these other devices, it transmits an instruction for that device to take over playback responsibility. After confirming a successful transfer, the computing device transitions to a "second mode" where it is no longer configured for playback itself but is instead configured to control the other device's playback of the remote queue (’033 Patent, claim 1).
  • Technical Importance: This technology defines the transition of a single device (e.g., a smartphone) from being a self-contained media player to being a remote control for a separate, more capable playback system, a core interaction paradigm in modern streaming audio systems (’615 Patent, col. 17:5-20).

Key Claims at a Glance

  • The complaint asserts at least independent claim 1 (’033 Patent, claim 1; Compl. ¶91).
  • Claim 1 recites a computing device that operates in a "first mode" for playback of a remote queue and is operable to:
    • display a representation of one or more available playback devices;
    • receive user input selecting a given playback device;
    • transmit an instruction for the given playback device to take over responsibility for playback of the remote queue;
    • detect an indication that the transfer was successful; and
    • after detection, transition from the first mode to a "second mode" where the computing device is configured to control the given playback device's playback and is no longer configured for its own playback of the queue.
  • The complaint reserves the right to assert additional claims (Compl. ¶90).

U.S. Patent No. 9,344,206 - “Method And Apparatus For Updating Zone Configurations In A Multi-Zone System”

  • Patent Identification: U.S. Patent No. 9344206, "Method And Apparatus For Updating Zone Configurations In A Multi-Zone System," issued May 17, 2016.
  • Technology Synopsis: The patent addresses the inconvenience of dynamically grouping and controlling multiple audio players in a multi-zone system, which previously required adjusting players one at a time (’206 Patent, col. 2:13-16). The solution is a "zone scene," a predefined grouping of players that can be saved and later invoked with a single command to cause synchronous playback, overcoming the limitations of ad hoc, manual grouping (’206 Patent, col. 2:30-53).
  • Asserted Claims: At least independent claim 1 is asserted (’206 Patent, claim 1; Compl. ¶103).
  • Accused Features: The complaint alleges that Google's "speaker group" functionality, created and managed through the Google Home app, infringes by allowing users to create, save, and invoke predefined groups of speakers for synchronous playback (Compl. ¶103).

U.S. Patent No. 10,469,966 - “Zone Scene Management”

  • Patent Identification: U.S. Patent No. 10469966, "Zone Scene Management," issued November 5, 2019.
  • Technology Synopsis: This patent, related to the ’206 Patent, focuses on the creation and management of multiple "zone scenes" from a computing device (’966 Patent, Abstract). The invention describes a controller receiving requests to create different predefined groupings of zone players (zone scenes), storing them, and later allowing a user to invoke one of the scenes, causing a player to transition from standalone operation to synchronous playback with its assigned group (’966 Patent, col. 10:46-67).
  • Asserted Claims: At least independent claim 1 is asserted (’966 Patent, claim 1; Compl. ¶116).
  • Accused Features: The complaint accuses Google's system of infringing by allowing a controller (e.g., a smartphone with the Google Home app) to create and store multiple distinct "speaker groups" (the alleged "zone scenes") and later invoke one of them to initiate synchronous playback (Compl. ¶116).

U.S. Patent No. 10,848,885 - “Zone Scene Management”

  • Patent Identification: U.S. Patent No. 10848885, "Zone Scene Management," issued November 24, 2020.
  • Technology Synopsis: This patent, also related to the ’206 Patent, claims the invention from the perspective of the individual zone player rather than the controller (’885 Patent, Abstract). It describes a player operating in a standalone mode that receives indications that it has been added to multiple different "zone scenes." The player continues in standalone mode until one of the scenes is selected for invocation, at which point it receives an instruction and transitions to operate in synchrony with the other players in the invoked group (’885 Patent, claim 1).
  • Asserted Claims: At least independent claim 1 is asserted (’885 Patent, claim 1; Compl. ¶129).
  • Accused Features: The complaint alleges that individual Google speakers infringe by being capable of being added to multiple "speaker groups" while operating independently, and then transitioning to synchronous group playback only upon receiving an instruction that a specific group has been invoked (Compl. ¶129).

III. The Accused Instrumentality

Product Identification

  • The "Google Wireless Audio System," which collectively refers to Google Audio Players, Google Pixel Devices, and Google Apps (Compl. ¶25).
    • Google Audio Players: Products including Chromecast, Nest Mini, Nest Hub, Google Home, and Nest Audio (Compl. ¶23).
    • Google Pixel Devices: Hardware controllers such as Pixel phones, tablets, and laptops (Compl. ¶24).
    • Google Apps: Software controllers including the YouTube Music app, Google Play Music app, and Google Home app (Compl. ¶23).

Functionality and Market Context

  • The accused system allows users to stream audio content from cloud-based services (e.g., YouTube Music) to one or more smart speakers (Google Audio Players) distributed throughout a home (Compl. ¶32-33). Control is exercised through software on a user device (Google Apps on a Google Pixel Device), which can initiate playback on the user device itself or "cast" the playback to one or more speakers on the local Wi-Fi network (Compl. ¶79). The complaint provides a screenshot from a Chromecast-enabled device that shows a "Cast button," which, when selected, displays a list of available playback devices (Compl. ¶79, p. 30).
  • The system also allows users to create persistent "speaker groups" via the Google Home app, which enables multiple speakers to play the same audio in synchrony when the group is selected for playback (Compl. ¶103). The complaint alleges that Google's infringement has allowed it to sell tens of millions of devices and generate billions of dollars in revenue, positioning these products as "loss leaders" to entrench its advertising and data collection platforms (Compl. ¶36, ¶38).

IV. Analysis of Infringement Allegations

’615 Patent Infringement Allegations

Claim Element (from Independent Claim 13) Alleged Infringing Functionality Complaint Citation Patent Citation
causing a graphical interface to display a control interface including one or more transport controls to control playback by the control device; A Chromecast-enabled computing device, such as a smartphone running the YouTube Music app, displays a control interface with transport controls (e.g., play, pause) for local playback. This is illustrated in a screenshot showing the YouTube Music app interface (Compl. ¶79, p. 25). ¶79 col. 15:58-62
identifying playback devices connected to the local area network; After connecting to a Wi-Fi network, the Chromecast-enabled computing device is configured to identify one or more Chromecast-enabled media players connected to the same LAN. ¶79 col. 9:14-18
causing the graphical interface to display a selectable option for transferring playback from the control device; The graphical interface on the Chromecast-enabled computing device displays a selectable “Cast button” for transferring playback. This is shown in a screenshot with the "Cast" icon highlighted (Compl. ¶79, p. 28). ¶79 col. 12:48-53
detecting a set of inputs to transfer playback from the control device to a particular playback device... The system detects a user’s selection of the “Cast button” followed by the selection of a particular Chromecast-enabled media player from a displayed list of available devices on the network. ¶79 col. 16:1-12
causing one or more first cloud servers to add multimedia content to a local playback queue on the particular playback device... The control device causes a first Google cloud server to add resource locators for the selected media to a local queue on the chosen Chromecast media player, which correspond to the media's location on a second Google cloud server. ¶79 col. 12:53-63
causing playback at the control device to be stopped; and modifying the one or more transport controls... to control playback by the playback device. The control device stops its own playback and modifies its interface so that the transport controls now control the playback occurring on the selected Chromecast media player. Screenshots show the interface after casting, controlling playback on a "Nest Mini" (Compl. ¶79, p. 35). ¶79 col. 16:20-25
  • Identified Points of Contention:
    • Scope Questions: A potential issue is whether Google's architecture involves "one or more first cloud servers" adding content to a "local playback queue" on a "particular playback device" as recited in the claim, or if the control is managed through a different server-side or device-side mechanism that does not map directly onto the claim's specific multi-server architecture.
    • Technical Questions: The complaint alleges on "information and belief" that the transfer process involves adding resource locators to a local queue (Compl. ¶79, p. 33-34). The factual question will be whether Google's system technically operates in this manner, specifically whether a "local playback queue" exists on the playback device and is populated by a "first cloud server" as distinct from the "second cloud server" hosting the content.

’033 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
operating in a first mode in which the computing device is configured for playback of a remote playback queue provided by a cloud-based computing system... A Chromecast-enabled computing device (e.g., a Pixel phone) operates in a first mode where it plays back a remote queue from a cloud service like Google Play Music. Screenshots show local playback on a Hub media player (Compl. ¶91, p. 43). ¶91 col. 12:44-48
while operating in the first mode, displaying a representation of one or more playback devices... available to accept playback responsibility... While playing locally, the device displays a "Cast" icon which, when tapped, reveals a list of available Chromecast-enabled media players on the network that can accept playback responsibility. Screenshots show this list of devices (Compl. ¶91, p. 44). ¶91 col. 9:14-18
based on receiving the user input, transmitting an instruction for the at least one given playback device to take over responsibility for playback... Based on the user selecting a specific device from the list, the computing device transmits an instruction for that selected media player to take over playback of the remote queue from the cloud-based service. ¶91 col. 12:53-63
detecting an indication that playback responsibility... has been successfully transferred... The computing device detects a successful transfer, indicated visually by the "Cast button" changing from a light to dark grey or "filled in" appearance. Screenshots show the "Cast" icon in its post-transfer state (Compl. ¶91, p. 51). ¶91 col. 16:20-25
transitioning from... the first mode... to... a second mode in which the computing device is configured to control the at least one given playback device's playback... and... is no longer configured for playback... The computing device transitions from playing the media itself to becoming a remote control for the selected media player, while its own local playback ceases. Screenshots show the device's interface controlling playback on a "Nest Mini" (Compl. ¶91, p. 53). ¶91 col. 17:5-20
  • Identified Points of Contention:
    • Scope Questions: The dispute may center on whether the accused functionality constitutes two distinct and separate "modes" of operation as required by the claim, or if it is a single, continuous mode with shifting targets for audio output and control commands. The definition of "configured for playback" versus "configured to control" will be critical.
    • Technical Questions: A key factual question is how the system "detect[s] an indication that playback responsibility... has been successfully transferred." The complaint points to a visual change in the Cast icon, but the claim requires detection of the transfer itself, not just a UI update. The evidence required will need to show what technical signal or confirmation the control device receives to trigger its transition to the "second mode."

V. Key Claim Terms for Construction

  • The Term: "local playback queue" (’615 Patent, claim 13)

    • Context and Importance: This term is central to the infringement theory for the '615 patent. Whether Google's system uses a "queue" that is "local" to the playback device and populated by a "cloud server" is a specific architectural requirement. Practitioners may focus on this term because Google could argue its system uses a server-side queue or a streaming pointer that does not constitute a "local playback queue" in the manner described by the patent.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The patent describes various embodiments for "queue management," including a "shared queue... between the local playback system and the third party application to keep the local system and the application synchronized," which could suggest that the queue is a logical construct, not necessarily a file stored exclusively on the device (’615 Patent, col. 16:53-17:4).
      • Evidence for a Narrower Interpretation: The claim language recites adding content "to a local playback queue on the particular playback device," which suggests the queue physically resides on the speaker hardware itself, potentially narrowing the scope to exclude purely cloud-based queue management systems (’615 Patent, claim 13).

  • The Term: "zone scene" (’206, ’966, ’885 Patents, claim 1)

    • Context and Importance: This term is the core of the inventions in the second family of patents. The infringement case depends on equating Google's "speaker group" feature with the patented "zone scene." Practitioners may focus on this term because its definition will determine whether a simple user-created group of speakers meets the requirements of a "scene," which the patent describes as being part of a "theme" and having various associated parameters (’206 Patent, col. 8:19-55; ’966 Patent, col. 2:28-29).
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The patent abstract and claims define a "zone scene" simply as a "preconfigured grouping of zones" or a "group configuration," which may support the view that any saved user-defined speaker group is a "zone scene" (’966 Patent, Abstract; ’206 Patent, claim 1).
      • Evidence for a Narrower Interpretation: The specification describes a "zone scene" in the context of a "theme" (e.g., a "Morning" scene) that can be "activated," and discusses benefits such as allowing a predefined group to be invoked "without requiring the zone players in the group to be separated from other groups beforehand," which could imply a more complex state-management function than merely creating a speaker group (’206 Patent, col. 8:19-10:45).

VI. Other Allegations

  • Indirect Infringement: The complaint alleges both induced and contributory infringement for all five patents. Inducement is based on Google allegedly promoting, advertising, and instructing customers on how to use the infringing features of the Google Wireless Audio System (e.g., via product literature and user guides) (Compl. ¶81, ¶93, ¶105, ¶118, ¶131). Contributory infringement is based on Google supplying the Google Apps (e.g., YouTube Music, Google Home), which are alleged to be material components especially made for use in an infringing manner and not staple articles of commerce (Compl. ¶82, ¶94, ¶106, ¶119, ¶132).
  • Willful Infringement: Willfulness is alleged for all five patents. The basis includes alleged pre-suit knowledge of the patents or willful blindness, citing specific notice letters sent to Google in October 2016 (for the ’206 Patent) and February 2019 (for the ’615 Patent), as well as Sonos providing Google with a draft of the complaint prior to filing, which provided notice for all patents-in-suit (Compl. ¶83, ¶95, ¶107, ¶120, ¶133).

VII. Analyst’s Conclusion: Key Questions for the Case

  • A core issue will be one of technical implementation: Do the accused Google products operate according to the specific architectural steps laid out in the claims? For the '615 and '033 patents, this will focus on whether Google's "casting" function technically involves a "local playback queue" and a distinct transition between two "modes" of operation, or if it achieves a similar result through a non-infringing method.
  • A second central question will be one of definitional scope: Can the term "zone scene," described in the patents with contextual language about "themes" and complex configurations, be construed broadly enough to read on the "speaker group" feature in Google's products, which users create for simple synchronous playback?
  • A key evidentiary question will concern willfulness: The complaint alleges multiple instances of pre-suit notice over several years. The case may turn on what Google knew about the patents-in-suit and when, and whether its continued sale of the accused products after receiving notice constituted objectively reckless behavior.