Case 3:20-cv-06754-WHA Document 316 Filed 08/02/22 Page 1 of 17
`
`
`
`
`
`
`
`
`
`
`
`UNITED STATES DISTRICT COURT
`
`
`NORTHERN DISTRICT OF CALIFORNIA
`
`GOOGLE LLC,
`
`
`
`Plaintiff,
`
`v.
`
`SONOS, INC.,
`
`Defendant.
`
`
`No. C 20-06754 WHA
`
`
`
`ORDER GRANTING
`MOTION FOR PARTIAL
`SUMMARY JUDGMENT
`AS TO ‘615 PATENT
`
`
`
`INTRODUCTION
`
`In this patent infringement action, the accused infringer moves for summary judgment of
`
`non-infringement and invalidity of claim 13 of U.S. Patent No. 9,967,615. To the extent stated
`
`below, the motion is GRANTED.
`
`STATEMENT
`
`Patent owner Sonos, Inc. alleges that Google LLC’s products infringe its patents,
`
`including United States Patent Nos. 10,848,885 and 9,967,615. Pursuant to our “patent
`
`showdown” procedure (Dkt. Nos. 68, 206), each side moves for summary judgment on one
`
`particular claim-in-suit. A separate order granted Sonos’s motion for summary judgment of
`
`infringement as to claim 1 of the ’885 patent and denied Google’s corresponding motion of
`
`non-infringement (Dkt. No. 309). This order considers Google’s motion for summary
`
`judgment of non-infringement and invalidity as to claim 13 of the ’615 patent.
`
`
`
`
`
`
`
`
`
`
`
`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 316 Filed 08/02/22 Page 2 of 17
`
`
`
`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
`
`The technology at issue in this case generally concerns multi-room “smart” speaker
`
`technology. Whereas the ’885 patent covers technology related to managing groups of smart
`
`speakers, the ’615 patent relates to the act of transferring playback of music or other media
`
`content from one device (e.g., a smart phone) to another (e.g., a smart speaker). In particular,
`
`claim 13 of the ’615 patent is directed towards transferring playback of a queue of media
`
`content (e.g., a song playlist) from one device to another.
`
`Some knowledge of pertinent terminology is helpful. Sonos accuses Google of infringing
`
`by equipping “control devices” with certain apps that are capable of transferring media
`
`playback to a “playback device.” Control devices are devices such as smart phones or tablets
`
`that can install and control apps. Playback devices are devices such a smart speakers or
`
`televisions that can play content. Google refers to the act of transferring playback from the
`
`control device to the playback device as “casting.” The accused apps employ “cast”
`
`technology that enables control devices to transfer media playback to a “cast-enabled”
`
`playback device (Opp. 2).
`
`The ability to transfer playback is useful because control devices are not necessarily ideal
`
`for media playback. Smart phones, for example, have small screens and produce
`
`unexceptional audio. Cast technology solves this problem by allowing users to transfer video
`
`to external, larger screens and audio to external, higher-quality speakers.
`
`Google Play Music, one of the accused apps, is illustrative. The app offers users a library
`
`of songs to play. The details are disputed, but, generally, the app has access to information
`
`about a song track currently being played, the tracks that were played previously, and the
`
`tracks that are scheduled to play in the future. Such an arrangement of songs (or other content)
`
`is commonly referred to as a “queue.” Among other purposes, the app’s access to the queue
`
`allows users to skip forward to the next song or skip backward to the previous song.
`
`If a Google Play Music user is disgruntled by the smart phone’s speaker and wants to
`
`transfer audio playback to a smart speaker, the user can activate a feature on the app to cast
`
`from the former to the latter. In addition to transferring playback of the current song, the smart
`
`phone also transfers access to the queue of songs. Then, once playback has been transferred,
`
`2
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 316 Filed 08/02/22 Page 3 of 17
`
`
`
`our user can control playback through the smart phone. Our user can, for example, skip to the
`
`next song in the queue, go back to the previous song in the queue, or shuffle the music in the
`
`queue, all while the music is playing on the smart speaker.
`
`Sonos also accuses various of Google’s YouTube apps of infringing, including YouTube,
`
`YouTube Music, YouTube Kids, and YouTube TV. The YouTube apps work similarly to
`
`Google Play Music, except those apps allow videos (and accompanying audio) to be cast to
`
`another device such as a smart television. A user can, for example, install the YouTube app on
`
`a smart phone, play a YouTube video on the phone, and then cast the video, even midstream,
`
`to a cast-enabled television. The video would then play on the television, the television would
`
`have access to the queue of videos, and the user would be able to control playback through the
`
`phone.
`
`Claim 13 of the ’615 patent is directed toward “systems, methods, apparatus, and articles
`
`of manufacture” to facilitate the transfer of playback from a “control device” to a “playback
`
`device” (’615 patent at Abstract). Using Google’s paragraph numbering, claim 13 of the ’615
`
`patent recites:
`
`13[pre]. A tangible, non-transitory computer readable storage
`medium including instructions for execution by a processor, the
`instructions, when executed, cause a control device to implement a
`method comprising:
`
`13.1 causing a graphical interface to display a control interface
`including one or more transport controls to control playback by the
`control device;
`
`13.2 after connecting to a local area network via a network interface,
`identifying playback devices connected to the local area network;
`
`13.3 causing the graphical interface to display a selectable option for
`transferring playback from the control device;
`
`13.4 detecting a set of inputs to transfer playback from the control
`device to a particular playback device, wherein the set of inputs
`comprises: (i) a selection of the selectable option for transferring
`playback from the control device and (ii) a selection of the particular
`playback device from the identified playback devices connected to the
`local area network:
`
`13.5 after detecting the set of inputs to transfer playback from the
`control device to the particular playback device, causing playback to
`be transferred from the control device to the particular playback
`
`3
`
`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 316 Filed 08/02/22 Page 4 of 17
`
`
`
`device, wherein transferring playback from the control device to the
`particular playback device comprises:
`
`(a) causing one or more first cloud servers to add multimedia
`content to a local playback queue on the particular playback
`device, wherein adding the multimedia content to the local
`playback queue comprises the one or more first cloud servers
`adding, to the local playback queue, one or more resource
`locators corresponding to respective locations of the
`multimedia content at one or more second cloud servers of a
`streaming content service;
`
`(b) causing playback at the control device to be stopped; and
`
`(c) modifying the one or more transport controls of the control
`interface to control playback by the playback device; and
`
`13.6 causing the particular playback device to play back the
`multimedia content, wherein the particular playback device playing
`back the multimedia content comprises the particular playback device
`retrieving the multimedia content from one or more second cloud
`servers of a streaming content service and playing back the retrieved
`multimedia content.
`
`The most contested terms are italicized. Sonos filed the application that led to the ’615 patent
`
`in 2018, but the patent application claims priority through a chain of applications dating back
`
`to December 30, 2011. As detailed further below, the parties dispute the date of conception.
`
`Sonos asserts July 15, 2011, as the invention date.
`
`
`
`Google argues that its products do not infringe element 13.5(a) because the accused apps
`
`employ a remote playback queue as opposed to a local playback queue. Google further
`
`contends that a 2010 version of the YouTube Remote app either anticipated claim 13 or, when
`
`combined with other references, rendered it obvious. This order follows full briefing and oral
`
`argument.
`
`ANALYSIS
`
`Summary judgment is proper when there is no genuine dispute of material fact and the
`
`moving party is entitled to judgment as a matter of law. FRCP 56(a). A genuine dispute of
`
`material fact is one that “might affect the outcome of the suit under the governing law.”
`
`Anderson v. Liberty Lobby, Inc., 477 U.S. 242, 247–48 (1986). In deciding a motion for
`
`summary judgment, the court must accept the non-movant’s non-conclusory evidence and
`
`draw all justifiable inferences in its favor. Id. at 255.
`
`4
`
`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 316 Filed 08/02/22 Page 5 of 17
`
`
`
`1.
`
`NON-INFRINGEMENT.
`
`This order starts with Google’s non-infringement arguments. Analysis of patent
`
`infringement requires a claim to be properly construed to determine its scope and meaning,
`
`which is then compared to the accused device or process. See Tessera, Inc. v. Int'l Trade
`
`Comm’n, 646 F.3d 1357, 1364 (Fed. Cir. 2011); Carroll Touch, Inc. v. Electro Mech. Sys., Inc.,
`
`15 F.3d 1573, 1576 (Fed. Cir. 1993). Accordingly, this order will first construe the disputed
`
`term to determine claim 13’s scope and then proceed to assess whether the properly construed
`
`claim reads on Google’s accused products.
`
`A.
`
`CONSTRUCTION OF “PLAYBACK QUEUE”
`
`
`
`Sonos’s Proposed
`Construction
`Plain and ordinary meaning
`
`Google’s Proposed
`Construction
`“An ordered list of
`multimedia items that is
`selected by the user for
`playback”
`
`Court’s Construction
`
`“A list of multimedia
`content selected for
`playback”
`
`Claim terms generally take “their ordinary and customary meaning,” that is “the meaning
`
`that the term would have to a person of ordinary skill in the art in question at the time of the
`
`invention.” Phillips v. AWH Corp., 415 F.3d 1303, 1312–13 (Fed. Cir. 2005) (en banc).
`
`Although construction begins with the claim language itself, “the specification is the single
`
`best” — and usually dispositive — “guide to the meaning of a disputed term.” Network-1
`
`Techs., Inc. v. Hewlett-Packard Co., 981 F.3d 1015, 1022 (Fed. Cir. 2020) (quoting Phillips,
`
`415 F.3d at 1314–15) (emphasis added).
`
`Here, the only pertinent term in dispute is “playback queue.”1 As explained above, part
`
`of claim 13 relates to transferring a queue of content from one device to another. The relevant
`
`portion of limitation 13.5 recites:
`
`after detecting the set of inputs to transfer playback from the control
`device to the particular playback device, causing playback to be
`transferred from the control device to the particular playback device,
`wherein transferring playback from the control device to the
`
`
`1 The parties’ dispute over the term “resource locator” does not bear on this order’s infringement
`and invalidity analysis.
`
`5
`
`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 316 Filed 08/02/22 Page 6 of 17
`
`
`
`particular playback device comprises:
`
`(a) causing one or more first cloud servers to add multimedia
`content to a local playback queue on the particular playback
`device. . .
`
`(emphasis added). The parties fiercely dispute whether the accused products use a “local
`
`playback queue.” As detailed further below, Google’s cast technology currently manages
`
`content queues, broadly speaking, by storing such a queue on a remote cloud server on the
`
`internet. The parties refer to this remote queue as a cloud queue (see, e.g., Br. 1). The parties
`
`agree that the cloud queue is not a “local playback queue,” as required by limitation 13.5(a),
`
`because it’s stored remotely on the internet as opposed to being stored locally on the playback
`
`device.
`
`In order to play music or other content, however, a Google cast-enabled playback device
`
`receives some information from a cloud queue, which it subsequently stores locally. The
`
`details are disputed, but, as an example, a cast-enabled smart speaker might receive
`
`information from the cloud queue about the current song being played, the next song scheduled
`
`to play (in case the user wants to skip the next song), and the song that was played before (in
`
`case the user wants to go back to the previous song). This is the extent of what the smart
`
`speaker knows. The smart speaker won’t, for example, know about the next ten songs
`
`scheduled to play, or the ten songs that played before. That more extensive information is only
`
`stored in the cloud queue.
`
`At stake here is whether the locally-stored information about the previous, current, and
`
`next song might also be a playback queue. If it is, then it could be the kind of “local playback
`
`queue” necessary to infringe. Sonos accordingly advocates against associating the term
`
`“playback queue” with any specific requirements, while Google wants a more definite
`
`construction to serve as the foundation for its non-infringement arguments. In particular, the
`
`parties dispute whether the term “playback queue” requires: (1) an “ordered list”; (2) plural
`
`“multimedia items”; and (3) user-selected media.
`
`First, Sonos asserts that a “playback queue” need not be a list, but this argument does not
`
`conform with the intrinsic evidence. The patent repeatedly associates a queue with a “list” or
`
`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 316 Filed 08/02/22 Page 7 of 17
`
`
`
`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
`
`“playlist.” See, e.g., ’615 patent at 15:57–67 (playback device may have information about “a
`
`current play position within a list to enable near-seamless ‘handoff’ of music from a portable
`
`device to a local playback system” (emphasis added)); 16:32–35 (devices may share “a current
`
`point of playback (e.g., now playing a third song in a playlist, fourth song in the playlist, and
`
`so on)”).
`
`Sonos objects that “the ’615 Patent teaches embodiments where a ‘playback device’
`
`queues a single resource locator, such as a URL. . . .” (Claim Constr. Br. 12). But a list of one
`
`is still a list. The patent cites a publication that states, for instance, that a “media listing can
`
`include . . . one or more additional items of media content.” See U.S. Patent App. Publ.
`
`2012/0089910 A1 at ¶ 52 (emphasis added); see also FitBit Inc. v. AliphCom, 2017 WL
`
`386257, at *14 (N.D. Cal. Jan. 27, 2017) (Judge Edward J. Davila) (“The ordinary meaning of
`
`‘list’ also supports the idea that the ‘list’ at issue can contain one . . . item[]. Lists often . . .
`
`contain only one item.”).
`
`Second, Sonos argues that nothing requires a “playback queue” to contain plural
`
`multimedia items. This order agrees on that point. The plain language of the claim recites:
`
`“adding the multimedia content to the local playback queue comprises . . . adding, to the local
`
`playback queue, one or more resource locators” (see limitation 13.5(a) (emphasis added)).
`
`Google objects that a queue must include a “next” media item in case the user wants to skip
`
`forward, and accordingly argues that a queue logically must include at least two items (Br. 9
`
`(citing Bhattacharjee Decl. ¶¶ 71–73)). But the patent does not have such a restrictive view of
`
`a queue. In addition to the claim language cited above, the specification repeatedly describes
`
`embodiments where a queue only contains a single audio track. See, e.g., ’615 patent at 11:62–
`
`12:3 (a smart speaker “may contain a uniform resource locator . . . that specifies an address to
`
`a particular audio track in the cloud” (emphasis added)); see also id. at 10:42–46; 12:49–63;
`
`13:36–40. These citations suggest that the list must contain at least one item, but not
`
`necessarily more than one.
`
`Third, Sonos asserts that the content in the queue need not be selected directly by a user.
`
`Google’s position, by contrast, is that a user must directly populate and manage the queue (CC
`
`7
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 316 Filed 08/02/22 Page 8 of 17
`
`
`
`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
`
`Opp. 11). Google’s argument does not persuade. True, the specification discusses scenarios
`
`where a user adds or deletes content from the queue and suggests that a user can edit a queue
`
`(see, e.g., ’615 patent at 16:25–31 (describing a “queue that the user is editing/managing. . . .”).
`
`However, the specification also repeatedly describes embodiments in which the third-party
`
`application (such as Google Play Music) dictates what media content is in the queue. See, e.g.,
`
`’615 patent at 13:1–10; 15:59–62. Moreover, as Sonos points out, nothing in the claim itself
`
`refers to a user.
`
`In sum, this order agrees with Google that a “playback queue” requires a “list” of content
`
`selected for playback, but agrees with Sonos that the list does not necessarily require more than
`
`one item of content or require users to select content directly. This order further rejects
`
`Google’s proposal to include the term “multimedia item” in the construction. The claim uses
`
`the term “multimedia content,” and there is no need to introduce additional ambiguity by
`
`importing a new term. Accordingly, this order construes the term “playback queue” as “a list
`
`of multimedia content selected for playback.”
`
`B.
`
`THE ACCUSED APPS DO NOT USE A “LOCAL PLAYBACK QUEUE”
`
`Having construed “playback queue,” we now turn to Google’s non-infringement
`
`arguments. To prove infringement, Sonos must show that Google’s accused products meet
`
`each properly construed limitation of claim 13 either literally or under the doctrine of
`
`equivalents. See Deering Precision Instruments, LLC v. Vector Distribution Sys., Inc., 347
`
`F.3d 1314, 1324 (Fed. Cir. 2003). Here, Sonos asserts both. To establish literal infringement,
`
`all of the elements of the claim, as correctly construed, must be present in the accused
`
`products. TechSearch, LLC v. Intel Corp., 286 F.3d 1360, 1371 (Fed. Cir. 2002). Sonos may
`
`also establish infringement under the doctrine of equivalents by “showing that the difference
`
`between the claimed invention and the accused product [is] insubstantial,” including “by
`
`showing on a limitation by limitation basis that the accused product performs substantially the
`
`same function in substantially the same way with substantially the same result as each claim
`
`limitation of the patented product.” Crown Packaging Tech., Inc. v. Rexam Beverage Can Co.,
`
`559 F.3d 1308, 1312 (Fed. Cir. 2009).
`
`8
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 316 Filed 08/02/22 Page 9 of 17
`
`
`
`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
`
`As stated above, Google’s primary non-infringement theory is that both its Google Play
`
`Music app and YouTube app products do not use a “local playback queue” (see limitation
`
`13.5). The two categories of accused apps operate in slightly different ways. In plain Greek,
`
`Sonos asserts that using the cast feature on the YouTube apps on a control device causes a
`
`“WatchNext” server to transmit a “WatchNextResponse” to a cast-enabled playback device.
`
`The WatchNextResponse is then stored by the playback device. According to Sonos, the
`
`WatchNextResponse “often” includes a string of characters called a “videoId” that corresponds
`
`to the item set to currently playback, the item set to playback next, and the item that came
`
`before the current item (Opp. 3–5). Similarly, casting from the Google Play Music app on the
`
`control device creates an ItemWindowResponse that stores a link to the previous, current, and
`
`next media items set for playback (Opp. 7-8). The apps receive this information from a cloud
`
`queue, and neither of the apps store any additional media content beyond those three items.
`
`Google quibbles about some of the details. Google asserts, for example, that a playback
`
`device only “request[s] cloud queue items one-by-one” (Br. 7). Google further states that the
`
`“upNextVideoID” variable (i.e., the variable corresponding to the item set to play next) only
`
`appears when “the cloud queue has been exhausted,” and that this variable “only exists for a
`
`few milliseconds” (Br. 9).
`
`At bottom, though, neither side appears to dispute that Google’s products operate by
`
`“retrieving” information from the cloud queue about the current, next, and previous media item
`
`(Br. 9; Opp. 3). Nor do the parties dispute that these three items are only a subset of a separate
`
`cloud queue. The focus of the dispute is instead on whether this information stored locally in
`
`the playback device is a playback queue at all.
`
`The parties dedicated the bulk of their briefing and their time at oral argument to this
`
`issue. Upon review, this order concludes that neither the information stored by the
`
`WatchNextResponse (in the YouTube apps) nor the information stored by the
`
`ItemWindowResponse (in the Google Play Music app) qualify as a playback queue. The
`
`groups of three items stored by the respective apps are not lists of multimedia content selected
`
`for playback. In each app, the cloud queue stores the list, and the locally-stored information is
`
`9
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 316 Filed 08/02/22 Page 10 of 17
`
`
`
`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
`
`merely a mirror reflecting a subset of what is happening in the cloud queue. The songs set to
`
`play on Google Play Music, for example, are all dictated by the cloud queue. If the user adds
`
`or edits a playlist, the cloud queue changes. If the app creates a playlist, the cloud queue
`
`adapts. It is only after the cloud queue changes that anything can happen to the information
`
`stored locally on the playback device (see Bhattarcharjee Decl. ¶¶ 81–84). This demonstrates
`
`that the groups of three items stored in each app are not lists of content selected for playback,
`
`but rather merely provide the means to process the lists for playback. In short, the cloud queue
`
`runs the show.
`
`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 to the WatchNextResponse and
`
`ItemWindowResponse, and never vice-versa, because there is no locally-stored queue that
`
`would allow “two-way” synchronization.
`
`Sonos further objects that the specification teaches that “the local playback system” can
`
`“periodically fetch[] a short list of tracks to play list” from a “third-party application” (id. at
`
`16:63–66). This passage, however, explains that the third-party application can “override a
`
`local playback queue” with the “short list of tracks to play next” (ibid.). The passage thus
`
`distinguishes a local playback queue from the “short list of tracks.” Moreover, the passage
`
`suggests that there must be something to override, and, here, the locally-stored information can
`
`never be populated by anything other than the “short list of tracks.” Instead,
`
`WatchNextResponse and ItemWindowResponse can never store additional or different items,
`
`and never more than three total items (see Bhatarcharjee Decl. ¶¶ 21, 73, 119).
`
`Sonos has accordingly failed to raise a genuine dispute that Google’s products employ a
`
`“local playback queue” as contemplated by claim 13 of the ’615 patent. Thus, Google’s
`
`10
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 316 Filed 08/02/22 Page 11 of 17
`
`
`
`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
`
`products do not infringe the claim, and this order need not address Google’s additional non-
`
`infringement arguments.
`
`2.
`
`ANTICIPATION AND OBVIOUSNESS.
`
`This order now turns to Google’s invalidity arguments. Before we move forward,
`
`however, a procedural note. After Google filed its motion, Sonos moved to strike some of the
`
`motion for improperly asserting new invalidity theories and prior art references. A prior order
`
`granted Sonos’s motion in part, striking paragraphs 133 and 138–41 of Dr. Bhattacharjee’s
`
`expert report in their entirety (Dkt. No. 315). That material is accordingly not considered here.
`
`With this in mind, we now turn to Google’s surviving arguments. Google asserts that
`
`one of its previous apps, the YouTube Remote app, anticipated claim 13 of the ’615 patent.
`
`Alternatively, Google argues that it would have been obvious to combine the YouTube Remote
`
`app with other prior art references to achieve Sonos’s claimed invention.
`
`The YouTube Remote app was released in November 2010 (see Bobohalma Decl. ¶ 3).
`
`The purpose of the app was to allow a smart phone to connect to another device, such as a
`
`television or computer, so that a YouTube video being played on the smart phone would
`
`appear on a larger screen (Br. 16). For example, a user could mirror a YouTube video onto a
`
`television and control playback of the video through the app. In short, the app functioned
`
`similarly to what Google now calls casting, as described above. The old process was more
`
`cumbersome, however, because it involved an intermediary website to which both devices
`
`separately had to connect to enable pairing. Specifically, each device needed to separately
`
`navigate to the intermediary website and log in to the same YouTube account. Once the
`
`devices were logged in to the same account, they could then pair with each other through the
`
`YouTube Remote app (see Opp. 14–15).
`
`Google now asserts that the app disclosed each and every limitation of claim 13.
`
`“Anticipation requires that a single prior art reference disclose each and every limitation of the
`
`claimed invention, either expressly or inherently.” SRI Int’l Inc. v. Cisco Sys., Inc., 930 F.3d
`
`1295, 1306 (Fed. Cir. 2019). “Anticipation is a question of fact.” Atlas Powder Co. v. Ireco,
`
`Inc., 190 F.3d 1342, 1346 (Fed. Cir. 1999). Because a patent is presumed valid, the party
`
`11
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 316 Filed 08/02/22 Page 12 of 17
`
`
`
`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
`
`asserting invalidity has the burden of proof to show anticipation by clear and convincing
`
`evidence. Core Wireless Licensing S.A.R.L. v. LG Elecs., Inc., 880 F.3d 1356, 1364 (Fed. Cir.
`
`2018).
`
`Sonos replies that the YouTube remote app did not disclose claim limitations 13.2, 13.4,
`
`13.5, and 13.6.2 This order will first consider Sonos’s arguments as to 13.2, 13.5, and 13.6,
`
`and then circle back to 13.4. For the reasons that follow, this order concludes that the app did
`
`not disclose limitation 13.4, but that modifying the app the satisfy the limitation would have
`
`been obvious in light of the prior art.
`
`A.
`
`LIMITATION 13.2
`
`Claim limitation 13.2 recites “after connecting to a local area network via a network
`
`interface, identifying playback devices connected to the local area network.” For our purposes,
`
`a “local area network,” or LAN, refers to a “local” home Wi-Fi network. This is in contrast to
`
`a “wide area network,” or WAN, which refers to network that can be accessed more widely,
`
`e.g., a 3G cellular network. The important point is that a LAN and a WAN provide different
`
`means to connect a device to the internet.
`
`Sonos reads limitation 13.2 to require that the control device affirmatively identify that
`
`the playback device is connected to the same LAN as the control device, as opposed to a WAN
`
`or a different LAN (Opp. 15). Google admits that its system did not do this. Instead, the
`
`system allowed the control device and the playback device to separately log in to the
`
`intermediary website. As such, it didn’t matter whether the smart phone and television were
`
`connected to the internet in different ways. For example, the smart phone could have used a
`
`3G network (a WAN) to navigate to the intermediary website, while the television could have
`
`used a home Wi-Fi network (a LAN) to navigate to the intermediary website. Thus, the
`
`YouTube Remote system did not require the control device to know whether the television was
`
`connected to a LAN at all. Sonos insists that this precludes anticipation.
`
`
`2 Sonos briefly argues that Google has not met its burden to show anticipation as to limitations
`13.1 and 13.3 (Opp. 14). But Google stated in its motion that, according to Sonos’s validity
`contentions, there was no dispute as those limitations (see Br. 17–18). Sonos said nothing to the
`contrary in its opposition brief.
`
`12
`
`Northern District of California
`
`United States District Court
`
`

`

`Case 3:20-cv-06754-WHA Document 316 Filed 08/02/22 Page 13 of 17
`
`
`
`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 objects that the plain language of the claim does not require any such identifying
`
`of the LAN. This order agrees. The claim only requires the control device to “identify[]
`
`playback devices connected to the local area network” (see limitation 13.2). The phrase
`
`“connected to the local area network” modifies “playback devices.” Accordingly, the claim
`
`does not require affirmatively identifying the LAN. Nor does it require identifying that the
`
`television is connected to the LAN. All that is required is that the system allowed (i) playback
`
`devices to be identified and (ii) such identified devices to be connected to the same LAN as the
`
`control device.
`
`The YouTube Remote system allowed both. It is undisputed that a television, for
`
`example, could have been connected to the same home Wi-Fi network as the smart phone, and
`
`that the smart phone could have transferred playback to that television. Indeed, Google has
`
`provided a 2010 video demonstrating just that (see Reply Br. 10).3 In such circumstances, the
`
`control device is “identifying playback devices connected to the [LAN]” (see limitation 13.2).
`
`True, as Google acknowledges, the phone and the television could have been connected to the
`
`internet in different ways, but that Google’s system could identify devices connected to the
`
`LAN in some circumstances and devices not connected to the LAN in others does not preclude
`
`anticipation. Rather, it shows that Google’s system was flexible and had capabilities in
`
`addition to those recited by the claim. See