Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 1 of 33
`
`
`
`
`
`
`
`
`
`UNITED STATES DISTRICT COURT
`
`
`NORTHERN DISTRICT OF CALIFORNIA
`
`SONOS, INC.,
`
`
`
`Plaintiff,
`
`v.
`
`GOOGLE LLC,
`
`Defendant.
`
`
`No. C 20-06754 WHA
`
`
`
`ORDER RE MOTIONS FOR
`SUMMARY JUDGMENT
`
`
`
`INTRODUCTION
`
`With trial looming in this patent infringement action, both sides again move for summary
`
`judgment. Alleged infringer now moves for summary judgment of invalidity and no willful or
`
`indirect infringement of the three remaining patents, as well as non-infringement of two of
`
`those patents based on a purported design-around. Meanwhile, patent owner now moves for
`
`summary judgment on alleged infringer’s contract-based claims. For the following reasons,
`
`alleged infringer’s motion is GRANTED IN PART, DENIED IN PART, and DEFERRED IN PART,
`
`whereas patent owner’s motion is DENIED AS MOOT.
`
`STATEMENT
`
`The relevant facts are described at length elsewhere. See Sonos, Inc. v. Google LLC,
`
`591 F. Supp. 3d 638, 641 (N.D. Cal. 2022), leave to appeal denied, 2022 WL 1486359 (Fed.
`
`Cir. May 11, 2022). In brief, we have two related civil actions involving Sonos, Inc.’s patents
`
`and Google LLC’s alleged infringement: Google’s declaratory judgment action filed in the
`
`
`
`
`
`
`
`
`
`
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 2 of 33
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California, and Sonos’s affirmative infringement action filed (one day
`
`before) in the Western District of Texas and transferred (one year later) at the direction of the
`
`Federal Circuit (No. C 21-07559 WHA).
`
`The operative pleadings focus on U.S. Patent Nos. 9,967,615; 10,779,033; 10,848,885;
`
`and 10,469,966. These patents generally concern multi-room “smart” speaker technology.
`
`Whereas the ’615 and ’033 patents cover technology related to transferring playback between
`
`devices, i.e., “casting,” the ’885 and ’966 patents cover technology related to managing groups
`
`of smart speakers.
`
`Pursuant to “patent showdown” procedure, each side has already moved for summary
`
`judgment on a single claim. Separate orders granted summary judgment in favor of Google on
`
`invalidity of claim 13 of the ’615 patent and in favor of Sonos on infringement of claim 1 of
`
`the ’885 patent. Sonos has since withdrawn its remaining claims based on the ’615 patent, and
`
`Google has since begun developing and deploying a purported design-around for the ’885 and
`
`’966 patents. Claims and defenses related to the ’033, ’885, and ’966 patents are now set for
`
`trial starting May 8, 2023 (SAC ¶¶ 49–84; see also No. C 21-07559 WHA, TAC ¶¶ 134–233).
`
`So are Google’s claims for breach of contract and conversion, which are based on prior
`
`collaborations with Sonos (SAC ¶¶ 85–97).
`
`In the lead-up to trial, both parties have filed motions to strike portions of each other’s
`
`expert reports (Dkt. Nos. 464, 469), as well as new motions for summary judgment (Dkt. Nos.
`
`478, 483). Sonos also filed a renewed motion to realign the parties (Dkt. No. 477), which the
`
`undersigned granted at the hearing after Google withdrew its opposition (Dkt. No. 557). A
`
`companion order considered the motions to strike (Dkt. No. 565). This order considers the
`
`motions for summary judgment.
`
`Google moves for summary judgment of invalidity of the asserted claims of the ’033,
`
`’885, and ’966 patents; no willful or indirect infringement of the asserted claims of the ’033,
`
`’885, and ’966 patents; and non-infringement of the asserted claims of the ’885 and ’966
`
`patents based on a purported design-around. Sonos moves for summary judgment on Google’s
`
`breach of contract and conversion claims. This order follows full briefing and oral argument.
`
`2
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 3 of 33
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`ANALYSIS
`
`Under Rule 56 of the Federal Rules of Civil Procedure, summary judgment is proper
`
`when there is no genuine dispute of material fact and the movant is entitled to judgment as a
`
`matter of law. A dispute of material fact is genuine “if the evidence is such that a reasonable
`
`jury could return a verdict for the nonmoving party.” Anderson v. Liberty Lobby, Inc.,
`
`477 U.S. 242, 248 (1986). In deciding a motion for summary judgment, the district court must
`
`accept the non-movant’s non-conclusory evidence and draw all justifiable inferences in the
`
`non-movant’s favor. Id. at 255.
`
`1.
`
`GOOGLE’S MOTION: INVALIDITY OF THE ’033 PATENT.
`
`Let’s begin with the ’033 patent. Our analysis of the ’033 patent (“Systems and Methods
`
`for Networked Music Playback”) starts with our earlier analysis of the ’615 patent
`
`(“Networked Music Playback”) during the patent showdown. Google LLC v. Sonos, Inc.,
`
`2022 WL 3046752 (N.D. Cal. Aug. 2, 2022). They have identical specifications. Like the
`
`’615 patent, the ’033 patent is directed toward the act of transferring playback of media content
`
`from one device (e.g., a phone) to another (e.g., a television), an act Google calls “casting.”
`
`And, like claim 13 of the ’615 patent covered in the prior order, the asserted claims of the ’033
`
`patent covered here are directed toward transferring playback of a queue of media content
`
`(e.g., a video playlist).
`
`This order refers the reader to the prior order for a more in-depth introduction to cast
`
`technology and the accused applications, which include YouTube, YouTube Kids, YouTube
`
`TV, YouTube Music, and Google Play Music. Suffice to say, YouTube was and remains
`
`owned by Google, and the accused applications employ technology that enables a “control
`
`device” to transfer playback of a queue of media content to a Google cast-enabled “playback
`
`device,” wherein the control device controls the application and the playback device plays the
`
`content. By way of example, a user can activate a feature on the accused YouTube application
`
`to cast a video playlist (queue of media content) from a phone (control device) to a television
`
`(playback device). The analysis of the ’615 patent in the prior order, and the analysis of the
`
`’033 patent in this order, hinge on the queue of media content that is cast. Because both parties
`
`3
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 4 of 33
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`find support in the prior order’s analysis of non-infringement and invalidity, this order will
`
`provide a summary.
`
`First, the prior order found Google’s accused products did not infringe claim 13 of the
`
`’615 patent because they did not employ a “local playback queue on the particular playback
`
`device,” as required by limitation 13.5 (’615 patent 20:8–9). That order construed “playback
`
`queue” as “a list of multimedia content selected for playback.” It then determined that the
`
`information in the accused applications that was stored locally on Google cast-enabled
`
`playback devices to play casted content (i.e., last, current, and next media item) was not a
`
`playback queue. Rather, that information was a subset of the list of multimedia content
`
`selected for playback and merely provided the local means to process it. For the accused
`
`products, the list of multimedia content selected for playback was stored on a remote cloud
`
`server. The parties and the prior order referred to it as a “cloud queue,” and all agreed that it
`
`was not a local playback queue because it was not stored locally on a playback device in the
`
`accused applications. The parties only disputed whether the information received by a Google
`
`cast-enabled playback device from the cloud queue was itself a local playback queue. The
`
`prior order found it was not. “In short, the cloud queue r[an] the show.” Google, 2022 WL
`
`3046752, at *6; see generally id. at *3–6.
`
`Second, that order found claim 13 of the ’615 patent invalid over prior art. Specifically,
`
`it determined that Google’s YouTube Remote application anticipated claim 13 of the ’615
`
`patent for all but one limitation. This was limitation 13.4, which required “selection of [a]
`
`particular playback device” (’615 patent 19:61–67). But the prior order nevertheless
`
`concluded it would have been obvious to combine the YouTube Remote application with
`
`disclosures in a Google patent to allow for such selection (U.S. Patent No. 9,490,998). Note
`
`that the order did not discuss the local playback queue from limitation 13.5 in the context of
`
`invalidity; it only discussed it in the context of non-infringement, as set out above. By
`
`implication, however, the prior order found the YouTube Remote application employed a local
`
`playback queue because it found the YouTube Remote application disclosed limitation 13.5.
`
`Google, 2022 WL 3046752, at *6–10.
`
`4
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 5 of 33
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Whereas claim 13 of the ’615 patent recited a “local playback queue on the particular
`
`playback device,” the corresponding claims of the ’033 patent recite a “remote playback queue
`
`provided by a cloud-based computing system.” The parties agree that this is the central
`
`distinction between the two patents, but they disagree on the significance of this distinction.
`
`A.
`
`NO JUDICIAL ESTOPPEL.
`
`As a threshold matter, this order will consider (and reject) Sonos’s argument that Google
`
`is judicially estopped from asserting the YouTube Remote prior art disclosed the ’033 patent’s
`
`remote playback queue. According to Sonos, Google previously represented that the YouTube
`
`Remote system “used a local playback queue, and further argued that there can only be one
`
`playback queue in a system” (Sonos Opp. 2) (emphasis in original). It insists that the
`
`undersigned relied on these representations in finding claim 13 of the ’615 patent invalid.
`
`According to Google, however, neither it nor the undersigned ever suggested that there could
`
`only be one playback queue in the YouTube Remote system (Google Reply Br. 1–3). This
`
`order agrees with Google.
`
`“[W]here a party assumes a certain position in a legal proceeding, and succeeds in
`
`maintaining that position, he may not thereafter, simply because his interests have changed,
`
`assume a contrary position, especially if it be to prejudice the party who has acquiesced in the
`
`position formerly taken by him.” New Hampshire v. Maine, 532 U.S. 742, 749 (2001) (citation
`
`omitted). Google has not assumed a contrary position here. The language Sonos seizes upon
`
`from Google’s prior motion for summary judgment stated:
`
`[T]he YouTube Remote prior art product is a direct ancestor of the
`YouTube product Sonos accuses of infringement . . . . The key
`difference is that where the accused YouTube applications use . . .
`a cloud queue, the prior art YouTube Remote used . . . a local
`queue.
`
`(Sonos Opp. 2 (quoting Google Showdown Br. 2)) (emphasis omitted). Just because the
`
`accused applications use a cloud queue where the YouTube Remote prior art used a local
`
`queue does not mean that the YouTube Remote prior art could not also use a remote playback
`
`queue. Google’s expert expressly rejected that position in his patent showdown rebuttal report,
`
`observing “[a] system might store the playback queue both at the local playback device and
`
`5
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 6 of 33
`
`
`
`remotely,” but “[t]his [was] not the case with the accused products” (Bhattacharjee Showdown
`
`Rebuttal Rpt. ¶ 320) (emphasis added). Google’s expert did not rule out this possibility for the
`
`prior art.
`
`Neither did the prior order, which stated:
`
`Sonos objects that multiple playback queues can exist
`simultaneously (Opp. 8). In support, Sonos points out that the
`specification teaches that there can be “two-way communication”
`between the local playback queue and a separate queue, “such as
`keeping a local playback queue synchronized with a queue that the
`user is editing/managing in the third party application” (’615
`patent at 16:22–31). But there is no such “two-way
`communication” here. Rather, the cloud queue delivers
`information to the playback device on a one-way street. The cloud
`queue provides information about the queue . . . and never vice-
`versa, because there is no locally-stored queue that would allow
`“two-way” synchronization.
`
`Google, 2022 WL 3046752, at *6. In other words, that order only found the “two-way”
`
`playback queue of one embodiment did not exist in the accused products. It never concluded
`
`that multiple playback queues could not exist simultaneously or could not have existed
`
`simultaneously in the prior art.
`
`Moreover, Google now argues that a feature in YouTube Remote version 2 (“YTR2”)
`
`disclosed a remote playback queue, whereas it was YouTube Remote version 1 (“YTR1”) that
`
`disclosed a local playback queue previously. This alone suggests that the prior order should
`
`not foreclose an invalidity analysis here. Whereas YTR1 was released on November 9, 2010,
`
`YTR2.03 and YTR2.07 were released on July 29, 2011, and August 10, 2011, respectively.
`
`The ’033 patent application claims priority through a chain of applications dating back to
`
`December 30, 2011. Because the YTR2 system was released prior to the ’033 patent priority
`
`date and could invalidate the asserted claims, this order proceeds to analysis of those claims.
`
`B.
`
`OVERVIEW OF ASSERTED CLAIMS.
`
`Sonos asserts claims 1–2, 4, 9, 11–13, and 16 of the ’033 patent. Claims 1 and 12 are
`
`independent claims, and claims 2, 4, 9, 11, 13, and 16 are dependent claims. Whereas claim 1
`
`is directed to a “computing device” (corresponding to a control device discussed above), claim
`
`6
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 7 of 33
`
`
`
`12 is directed to a “computer-readable medium” (with instructions for that control device).
`
`Both parties focus their analysis on claim 1.
`
`Using Google’s paragraph numbering, claim 1 of the ’033 patent recites:
`
`[1.0] A computing device comprising:
`
`[1.1] at least one processor;
`
`[1.2] a non-transitory computer-readable medium; and
`
`[1.3] program instructions stored on the non-transitory computer-
`readable medium that, when executed by the at least one processor,
`cause the computing device to perform functions comprising:
`
`[1.4] 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
`associated with a cloud-based media service;
`
`[1.5] while operating in the first mode, displaying a
`representation of one or more playback devices in a media
`playback system that are each i) communicatively coupled
`to the computing device over a data network and ii)
`available to accept playback responsibility for the remote
`playback queue;
`
`[1.6] while displaying the representation of the one or more
`playback devices, receiving user input indicating a
`selection of at least one given playback device from the one
`or more playback devices;
`
`[1.7] based on receiving the user input,
`
`
`[1.7(a)] transmitting an instruction for the at least
`one given playback device to take over
`responsibility for playback of the remote playback
`queue from the computing device,
`
`[1.7(b)] wherein the instruction configures the at
`least one given playback device to (i) communicate
`with the cloud-based computing system in order to
`obtain data identifying a next one or more media
`items that are in the remote playback queue, (ii) use
`the obtained data to retrieve at least one media item
`in the remote playback queue from the cloud-based
`media service; and (iii) play back the retrieved at
`least one media item;
`
`[1.8] detecting an indication that playback responsibility for
`the remote playback queue has been successfully
`transferred from the computing device to the at least one
`given playback device; and
`
`
`7
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 8 of 33
`
`
`
`[1.9] after detecting the indication, transitioning from i) the
`first mode in which the computing device is configured for
`playback of the remote playback queue to ii) a second
`mode in which the computing device is configured to
`control the at least one given playback device’s playback of
`the remote playback queue and the computing device is no
`longer configured for playback of the remote playback
`queue.
`
`(’033 patent 17:32–18:10). Recall the parties agree that the primary difference between invalid
`
`claim 13 of the ’615 patent and the asserted claims of the ’033 patent is that the former recited
`
`a local playback queue and the latter recite a remote playback queue, italicized above.
`
`Google now argues that claim 1 of the ’033 patent and the other asserted claims are
`
`invalid as obvious over two prior art references: (1) Google’s YTR2 system, which disclosed a
`
`remote playback queue on account of its “party mode” feature; and (2) Google’s ’998 patent,
`
`which (again) taught the selection of playback devices (Google Br. 5–15). Sonos contends that
`
`these prior art references did not satisfy limitations 1.4–1.9 of the ’033 patent (Sonos Opp. 3–
`
`10). According to Sonos, the YTR2 system did not disclose a remote playback queue, as
`
`required by limitations 1.4, 1.7, 1.8, and 1.9, whereas the ’998 patent did not teach the
`
`selection of playback devices, as required by limitations 1.5 and 1.6.1
`
`A claimed invention is obvious if “the differences between the subject matter sought to
`
`be patented and the prior art are such that the subject matter as a whole would have been
`
`obvious at the time the invention was made to a person having ordinary skill in the art.”
`
`35 U.S.C. § 103(a) (pre-AIA). Obviousness is a question of law based on underlying questions
`
`of fact. ABT Sys., LLC v. Emerson Elec. Co., 797 F.3d 1350, 1354 (Fed. Cir. 2015). Unlike
`
`anticipation, which “requires all elements of a claim to be disclosed within a single reference,”
`
`“[o]bviousness can be proven by combining existing prior art references.” Cohesive Techs.
`
`Inc. v. Waters Corp., 543 F.3d 1351, 1364 (Fed. Cir. 2008). “A party seeking to invalidate a
`
`patent based on obviousness must demonstrate by clear and convincing evidence that a skilled
`
`artisan would have been motivated to combine the teachings of the prior art references to
`
`
`1 Google also argues that the YouTube Remote prior art disclosed a remote playback queue when
`a YTR1 or YTR2 user selected a list of service-recommended videos for playback (Google Br. 9–
`11). Because this order finds that YTR2 party mode disclosed a remote playback queue, however,
`it does not reach this argument.
`
`8
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 9 of 33
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`achieve the claimed invention, and that the skilled artisan would have had a reasonable
`
`expectation of success in doing so.” Procter & Gamble Co. v. Teva Pharms. USA, Inc.,
`
`566 F.3d 989, 994 (Fed. Cir. 2009) (internal quotation marks and citation omitted). The first
`
`step in an obviousness analysis is proper construction of the claim to determine its scope and
`
`meaning, and the second step is comparison of the properly construed claim to the prior art.
`
`Medichem, S.A. v. Rolabo, S.L., 353 F.3d 928, 933 (Fed. Cir. 2003).
`
`Here, the parties agree on the construction of the central claim term: a “remote playback
`
`queue” is a “playback queue,” as construed in the prior order, that is also “remote” (Dkt. Nos.
`
`560–61). And, they interpret “remote” almost identically. Sonos explains that “the term
`
`‘remote’ refers to a location different from (i.e., not local to) the ‘computing device’ or the
`
`‘playback device,’” whereas Google proposes it means “geographically distant from the
`
`claimed computing and playback devices” (compare Dkt. No. 560 at 2, with Dkt. No. 561 at 1).
`
`For the purpose of evaluating movant Google’s invalidity arguments, this order adopts non-
`
`movant Sonos’s phrasing and construes “remote” as “not local to the claimed computing
`
`device or playback device.” As such, a “remote playback queue” is a “playback queue” that is
`
`“not local to the claimed computing device or playback device.” Applying the construction of
`
`“playback queue” from the prior order, a “remote playback queue” is “a list of multimedia
`
`content selected for playback that is not local to the claimed computing device or playback
`
`device.”
`
`With this agreed-upon construction, does claim 1 of the ’033 patent read on the prior art?
`
`For the reasons that follow, this order concludes that it does.
`
`C.
`
`OVERVIEW OF PRIOR ART.
`
`Let’s start with the prior art. The YouTube Remote application allowed a user to display
`
`YouTube videos on one or more screens (e.g., televisions) and control playback of those
`
`YouTube videos from one or more mobile devices (e.g., phone and tablet). First released in
`
`November 2010 and later discontinued, it functioned like casting, but the YouTube Remote
`
`application required a user to separately navigate to an intermediary website on each of the
`
`devices and log in to the same YouTube account to pair them.
`
`9
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 10 of 33
`
`
`
`Party mode was a feature that Google developed after releasing YTR1, reducing it to
`
`practice on July 12, 2011, and releasing it in YTR2. Whereas YTR1 allowed for one user to
`
`manage a queue of YouTube videos and transfer playback from one or more mobile devices to
`
`one or more screens, YTR2 party mode allowed for two or more users to manage a queue of
`
`YouTube videos and transfer playback from two or more mobile devices to one or more
`
`screens. To reiterate, YTR2 predated the ’033 patent priority date of December 30, 2011, with
`
`YTR2.03 and YTR2.07 released on July 29, 2011, and August 10, 2011, respectively.
`
`To initiate party mode, a host user would select a queue of YouTube videos for playback
`
`on a mobile device running YTR2 and invite one or more guest users with a mobile device
`
`running YTR2. If the guest user(s) accepted the host user’s invitation, the host user’s mobile
`
`device would send a message to a cloud server (called the “MDx server”) with the list of
`
`identifiers for the queue of videos selected for playback (called “videoIds”). The cloud server
`
`would store this list of identifiers in the “party queue” and then send a message with the list of
`
`identifiers to the mobile device(s) of the guest user(s), where it would be stored locally
`
`(Bhattacharjee Rpt. ¶¶ 171–75; Schmidt Rebuttal Rpt. ¶¶ 207–08).
`
`In party mode, the host user and guest user(s) managed the same queue of videos, which
`
`was stored in the party queue on the cloud server and on each of their mobile devices. If the
`
`host user or guest user(s) made a change to the queue of videos (e.g., removing the last video),
`
`her mobile device would send an update message to the cloud server, which would store the
`
`updated list of identifiers in the party queue. The cloud server would then send a message with
`
`the updated list of identifiers to the mobile devices of the host user and guest user(s), which
`
`was again stored locally. If playback was transferred to one or more of the host user’s screens,
`
`the queue of videos was stored on the screen(s) as well, and the message with the updated list
`
`of identifiers would also go to the screen(s) to be stored locally (Bhattacharjee Rpt. ¶¶ 176–77;
`
`Schmidt Rebuttal Rpt. ¶¶ 213–14).
`
`10
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 11 of 33
`
`
`
`To transfer playback to a screen in party mode, the host or guest user(s) would press a
`
`“Connect” button in the application and the cloud server would send a message to the screen
`
`identifying one or more videos for playback. For each video, that screen would send a
`
`corresponding identifier it had stored locally to another cloud server (called “Player Service”)
`
`to obtain a URL (called a “Bandaid URL”). That URL would enable the screen to retrieve the
`
`media content (audio and video content) corresponding to the identifier from yet another cloud
`
`server in Google’s Content Delivery Network (called “Bandaid”), which would then be played
`
`back (Bhattacharjee Rpt. ¶¶ 327–29, 340; Schmidt Rpt. ¶¶ 162–66; Schmidt Rebuttal Rpt.
`
`¶¶ 174–76). Sonos’s expert provides a helpful diagram of this process, which is based on a
`
`Google diagram produced in discovery:
`
`Transferring Playback in YTR2 Party Mode.
`
`
`
`(Schmidt Rpt. ¶ 166).
`
`As for the ’998 patent, the prior order stated, in pertinent part:
`
`The ’998 patent is prior art. It was filed on March 7, 2011, and
`claims priority to an earlier provision[al] application filed in
`November 2010. The patent’s inventors were involved with the
`development of the YouTube Remote system, and the patent
`relates to controlling playback on a playback device through a
`control device . . . .
`
`[T]he patent disclosed that a “user interface” of a “remote control”
`(e.g., a smart phone) can display “previously paired controlled
`devices” (e.g., a television) so that a user may select and control
`“one or more paired controlled devices.”
`
`11
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 12 of 33
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Google, 2022 WL 3046752, at *9. This user interface was called the “device-picker,” which
`
`was added to source code for the YouTube Remote application dated December 1, 2011 —
`
`again, before the priority date of the ’033 patent, December 30, 2011. The device-picker was
`
`released with YouTube Remote version 3 (“YTR3”) in January 2012.
`
`This order will first consider Google’s arguments as to the “remote playback queue”
`
`limitations allegedly disclosed by the YTR2 system (1.4, 1.7, 1.8, and 1.9), and then circle
`
`back to the “selection of playback devices” limitations allegedly taught by the ’998 patent (1.5
`
`and 1.6).
`
`D.
`
`LIMITATION 1.4.
`
`Limitation 1.4 requires a “computing device” that is “configured for playback of a remote
`
`playback queue provided by a cloud-based computing system associated with a cloud-based
`
`media service” (’033 patent 17:40–42). The “computing device” corresponds to the control
`
`device discussed above, which is itself configured for playback at this stage. In other words,
`
`the playback captured by limitation 1.4 is taking place on a control device (e.g., a phone) and
`
`has not yet been transferred to a playback device (e.g., a television).
`
`According to Google, YTR2 party mode disclosed limitation 1.4. Because the party
`
`queue was a playback queue, and the cloud server provided the party queue to the
`
`geographically distant mobile devices of the host and guest user(s), those mobile devices were
`
`ostensibly configured for playback of a remote playback queue provided by a cloud-based
`
`computing system (Google Br. 6–7). According to Sonos, however, party mode was “simply a
`
`mode that allow[ed] multiple YouTube accounts to add songs to the same queue” and that
`
`“d[id] not change anything about the location of the playback queue” (Sonos Opp. 3). Sonos
`
`emphasizes that in party mode and non-party mode alike, the mobile devices of host and guest
`
`user(s) and the host user’s screen(s) all had and relied on their own local playback queues
`
`(Sonos Opp. 7).
`
`True, the mobile devices of host and guest user(s) and the host user’s screen(s) all had
`
`and relied on their own local playback queues. Google expressly acknowledges that the party
`
`queue was “copied to a device for the purposes of facilitating local playback” and that it did
`
`12
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 566 Filed 04/13/23 Page 13 of 33
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`not “eliminate[] the playback queue on the playback device in favor of a cloud queue” until
`
`2014 (Dkt. No. 561 at 1; Google Reply Br. 1). In other words, it is undisputed that the mobile
`
`devices of the host and guest user(s) stored the list of identifiers for the queue of videos
`
`selected for playback locally. But it is also undisputed that the cloud server stored the list of
`
`identifiers for the queue of videos selected for playback in the party queue (Google Br. 3
`
`(citing Bhattacharjee Rpt. ¶¶ 171–73); Sonos Opp. 5 (citing Schmidt Rebuttal Rpt. ¶ 207); see
`
`also Schmidt Rebuttal Rpt. ¶ 204). That list was a playback queue (“a list of multimedia
`
`content selected for playback”) and that server was remote (“not local to the claimed
`
`computing device or playback device”). Putting it all together, the party queue was a list of
`
`multimedia content selected for playback that was not local to the claimed computing or
`
`playback device. The party queue was a remote playback queue. And, when playback had not
`
`yet been transferred to a screen, the mobile device in YTR2 party mode was configured for
`
`playback of a remote playback queue.
`
`That mobile devices and screens also had local playback queues did not mean that the
`
`party queue was not a remote playback queue. The reader will recall that Google did not rule
`
`out the possibility that the YouTube Remote prior art could have employed both, which YTR2
`
`party mode did. What we have here is the situation described by the Google expert in which
`
`“the system might store the playback queue both at the local playback device and remotely”
`
`(Bhattacharjee Showdown Rebuttal Rpt. ¶ 320). Indeed, the YouTube Remote prior art was
`
`strikingly similar to the embodiment that the prior order distinguished (’033 patent 16:16–27).
`
`This “third party application not only t[old] the local playback system what to play, but also
`
`maintain[ed] two-way communication with the local playback . . . system” (id. at 16:18–21).
`
`And “[t]wo way communication help[ed] enable features such as keeping a local playback
`
`queue synchronized with a queue that the user [was] editing/managing in the third party
`
`application” (id. at 16:21–24).
`
`In YTR1 and YTR2 non-party mode, the queue that the user was editing/managing to
`
`which the local playback queue was synchronized was the local playback queue on the user’s
`
`mobile device. There were no other users, and there was no queue saved on a cloud server. In
`
`13
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Documen