Google LLC v. Sonos, Inc.

Filing 316

ORDER GRANTING 222 MOTION FOR PARTIAL SUMMARY JUDGMENT AS TO 615 PATENT. SIGNED BY JUDGE ALSUP. (whalc5, COURT STAFF) (Filed on 8/2/2022)

Download PDF
1 2 3 4 5 UNITED STATES DISTRICT COURT 6 7 NORTHERN DISTRICT OF CALIFORNIA 8 9 10 GOOGLE LLC, Plaintiff, United States District Court Northern District of California 11 12 13 14 No. C 20-06754 WHA v. SONOS, INC., Defendant. 15 ORDER GRANTING MOTION FOR PARTIAL SUMMARY JUDGMENT AS TO ‘615 PATENT 16 INTRODUCTION 17 18 In this patent infringement action, the accused infringer moves for summary judgment of 19 non-infringement and invalidity of claim 13 of U.S. Patent No. 9,967,615. To the extent stated 20 below, the motion is GRANTED. 21 STATEMENT 22 Patent owner Sonos, Inc. alleges that Google LLC’s products infringe its patents, 23 including United States Patent Nos. 10,848,885 and 9,967,615. Pursuant to our “patent 24 showdown” procedure (Dkt. Nos. 68, 206), each side moves for summary judgment on one 25 particular claim-in-suit. A separate order granted Sonos’s motion for summary judgment of 26 infringement as to claim 1 of the ’885 patent and denied Google’s corresponding motion of 27 non-infringement (Dkt. No. 309). This order considers Google’s motion for summary 28 judgment of non-infringement and invalidity as to claim 13 of the ’615 patent. 1 2 technology. Whereas the ’885 patent covers technology related to managing groups of smart 3 speakers, the ’615 patent relates to the act of transferring playback of music or other media 4 content from one device (e.g., a smart phone) to another (e.g., a smart speaker). In particular, 5 claim 13 of the ’615 patent is directed towards transferring playback of a queue of media 6 content (e.g., a song playlist) from one device to another. 7 United States District Court Northern District of California The technology at issue in this case generally concerns multi-room “smart” speaker Some knowledge of pertinent terminology is helpful. Sonos accuses Google of infringing 8 by equipping “control devices” with certain apps that are capable of transferring media 9 playback to a “playback device.” Control devices are devices such as smart phones or tablets 10 that can install and control apps. Playback devices are devices such a smart speakers or 11 televisions that can play content. Google refers to the act of transferring playback from the 12 control device to the playback device as “casting.” The accused apps employ “cast” 13 technology that enables control devices to transfer media playback to a “cast-enabled” 14 playback device (Opp. 2). 15 The ability to transfer playback is useful because control devices are not necessarily ideal 16 for media playback. Smart phones, for example, have small screens and produce 17 unexceptional audio. Cast technology solves this problem by allowing users to transfer video 18 to external, larger screens and audio to external, higher-quality speakers. 19 Google Play Music, one of the accused apps, is illustrative. The app offers users a library 20 of songs to play. The details are disputed, but, generally, the app has access to information 21 about a song track currently being played, the tracks that were played previously, and the 22 tracks that are scheduled to play in the future. Such an arrangement of songs (or other content) 23 is commonly referred to as a “queue.” Among other purposes, the app’s access to the queue 24 allows users to skip forward to the next song or skip backward to the previous song. 25 If a Google Play Music user is disgruntled by the smart phone’s speaker and wants to 26 transfer audio playback to a smart speaker, the user can activate a feature on the app to cast 27 from the former to the latter. In addition to transferring playback of the current song, the smart 28 phone also transfers access to the queue of songs. Then, once playback has been transferred, 2 1 our user can control playback through the smart phone. Our user can, for example, skip to the 2 next song in the queue, go back to the previous song in the queue, or shuffle the music in the 3 queue, all while the music is playing on the smart speaker. United States District Court Northern District of California 4 Sonos also accuses various of Google’s YouTube apps of infringing, including YouTube, 5 YouTube Music, YouTube Kids, and YouTube TV. The YouTube apps work similarly to 6 Google Play Music, except those apps allow videos (and accompanying audio) to be cast to 7 another device such as a smart television. A user can, for example, install the YouTube app on 8 a smart phone, play a YouTube video on the phone, and then cast the video, even midstream, 9 to a cast-enabled television. The video would then play on the television, the television would 10 have access to the queue of videos, and the user would be able to control playback through the 11 phone. 12 Claim 13 of the ’615 patent is directed toward “systems, methods, apparatus, and articles 13 of manufacture” to facilitate the transfer of playback from a “control device” to a “playback 14 device” (’615 patent at Abstract). Using Google’s paragraph numbering, claim 13 of the ’615 15 patent recites: 16 17 18 19 20 21 22 23 24 25 26 27 28 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 device, wherein transferring playback from the control device to the particular playback device comprises: 1 2 (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; 3 4 5 6 (b) causing playback at the control device to be stopped; and 7 (c) modifying the one or more transport controls of the control interface to control playback by the playback device; and 8 9 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. 10 United States District Court Northern District of California 11 12 The most contested terms are italicized. Sonos filed the application that led to the ’615 patent 13 in 2018, but the patent application claims priority through a chain of applications dating back 14 to December 30, 2011. As detailed further below, the parties dispute the date of conception. 15 Sonos asserts July 15, 2011, as the invention date. 16 Google argues that its products do not infringe element 13.5(a) because the accused apps 17 employ a remote playback queue as opposed to a local playback queue. Google further 18 contends that a 2010 version of the YouTube Remote app either anticipated claim 13 or, when 19 combined with other references, rendered it obvious. This order follows full briefing and oral 20 argument. 21 ANALYSIS 22 Summary judgment is proper when there is no genuine dispute of material fact and the 23 moving party is entitled to judgment as a matter of law. FRCP 56(a). A genuine dispute of 24 material fact is one that “might affect the outcome of the suit under the governing law.” 25 Anderson v. Liberty Lobby, Inc., 477 U.S. 242, 247–48 (1986). In deciding a motion for 26 summary judgment, the court must accept the non-movant’s non-conclusory evidence and 27 draw all justifiable inferences in its favor. Id. at 255. 28 4 1. 1 NON-INFRINGEMENT. This order starts with Google’s non-infringement arguments. Analysis of patent 2 infringement requires a claim to be properly construed to determine its scope and meaning, 3 which is then compared to the accused device or process. See Tessera, Inc. v. Int'l Trade 4 Comm’n, 646 F.3d 1357, 1364 (Fed. Cir. 2011); Carroll Touch, Inc. v. Electro Mech. Sys., Inc., 5 15 F.3d 1573, 1576 (Fed. Cir. 1993). Accordingly, this order will first construe the disputed 6 term to determine claim 13’s scope and then proceed to assess whether the properly construed 7 claim reads on Google’s accused products. 8 A. 9 10 Sonos’s Proposed Construction Plain and ordinary meaning 11 United States District Court Northern District of California CONSTRUCTION OF “PLAYBACK QUEUE” 12 13 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 14 15 that the term would have to a person of ordinary skill in the art in question at the time of the 16 invention.” Phillips v. AWH Corp., 415 F.3d 1303, 1312–13 (Fed. Cir. 2005) (en banc). 17 Although construction begins with the claim language itself, “the specification is the single 18 best” — and usually dispositive — “guide to the meaning of a disputed term.” Network-1 19 Techs., Inc. v. Hewlett-Packard Co., 981 F.3d 1015, 1022 (Fed. Cir. 2020) (quoting Phillips, 20 415 F.3d at 1314–15) (emphasis added). Here, the only pertinent term in dispute is “playback queue.”1 As explained above, part 21 22 of claim 13 relates to transferring a queue of content from one device to another. The relevant 23 portion of limitation 13.5 recites: 24 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 25 26 27 28 The parties’ dispute over the term “resource locator” does not bear on this order’s infringement and invalidity analysis. 5 1 particular playback device comprises: 1 (a) causing one or more first cloud servers to add multimedia content to a local playback queue on the particular playback device. . . 2 3 4 (emphasis added). The parties fiercely dispute whether the accused products use a “local 5 playback queue.” As detailed further below, Google’s cast technology currently manages 6 content queues, broadly speaking, by storing such a queue on a remote cloud server on the 7 internet. The parties refer to this remote queue as a cloud queue (see, e.g., Br. 1). The parties 8 agree that the cloud queue is not a “local playback queue,” as required by limitation 13.5(a), 9 because it’s stored remotely on the internet as opposed to being stored locally on the playback 10 United States District Court Northern District of California 11 device. In order to play music or other content, however, a Google cast-enabled playback device 12 receives some information from a cloud queue, which it subsequently stores locally. The 13 details are disputed, but, as an example, a cast-enabled smart speaker might receive 14 information from the cloud queue about the current song being played, the next song scheduled 15 to play (in case the user wants to skip the next song), and the song that was played before (in 16 case the user wants to go back to the previous song). This is the extent of what the smart 17 speaker knows. The smart speaker won’t, for example, know about the next ten songs 18 scheduled to play, or the ten songs that played before. That more extensive information is only 19 stored in the cloud queue. 20 At stake here is whether the locally-stored information about the previous, current, and 21 next song might also be a playback queue. If it is, then it could be the kind of “local playback 22 queue” necessary to infringe. Sonos accordingly advocates against associating the term 23 “playback queue” with any specific requirements, while Google wants a more definite 24 construction to serve as the foundation for its non-infringement arguments. In particular, the 25 parties dispute whether the term “playback queue” requires: (1) an “ordered list”; (2) plural 26 “multimedia items”; and (3) user-selected media. 27 28 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 United States District Court Northern District of California 1 “playlist.” See, e.g., ’615 patent at 15:57–67 (playback device may have information about “a 2 current play position within a list to enable near-seamless ‘handoff’ of music from a portable 3 device to a local playback system” (emphasis added)); 16:32–35 (devices may share “a current 4 point of playback (e.g., now playing a third song in a playlist, fourth song in the playlist, and 5 so on)”). 6 Sonos objects that “the ’615 Patent teaches embodiments where a ‘playback device’ 7 queues a single resource locator, such as a URL. . . .” (Claim Constr. Br. 12). But a list of one 8 is still a list. The patent cites a publication that states, for instance, that a “media listing can 9 include . . . one or more additional items of media content.” See U.S. Patent App. Publ. 10 2012/0089910 A1 at ¶ 52 (emphasis added); see also FitBit Inc. v. AliphCom, 2017 WL 11 386257, at *14 (N.D. Cal. Jan. 27, 2017) (Judge Edward J. Davila) (“The ordinary meaning of 12 ‘list’ also supports the idea that the ‘list’ at issue can contain one . . . item[]. Lists often . . . 13 contain only one item.”). 14 Second, Sonos argues that nothing requires a “playback queue” to contain plural 15 multimedia items. This order agrees on that point. The plain language of the claim recites: 16 “adding the multimedia content to the local playback queue comprises . . . adding, to the local 17 playback queue, one or more resource locators” (see limitation 13.5(a) (emphasis added)). 18 Google objects that a queue must include a “next” media item in case the user wants to skip 19 forward, and accordingly argues that a queue logically must include at least two items (Br. 9 20 (citing Bhattacharjee Decl. ¶¶ 71–73)). But the patent does not have such a restrictive view of 21 a queue. In addition to the claim language cited above, the specification repeatedly describes 22 embodiments where a queue only contains a single audio track. See, e.g., ’615 patent at 11:62– 23 12:3 (a smart speaker “may contain a uniform resource locator . . . that specifies an address to 24 a particular audio track in the cloud” (emphasis added)); see also id. at 10:42–46; 12:49–63; 25 13:36–40. These citations suggest that the list must contain at least one item, but not 26 necessarily more than one. 27 Third, Sonos asserts that the content in the queue need not be selected directly by a user. 28 Google’s position, by contrast, is that a user must directly populate and manage the queue (CC 7 United States District Court Northern District of California 1 Opp. 11). Google’s argument does not persuade. True, the specification discusses scenarios 2 where a user adds or deletes content from the queue and suggests that a user can edit a queue 3 (see, e.g., ’615 patent at 16:25–31 (describing a “queue that the user is editing/managing. . . .”). 4 However, the specification also repeatedly describes embodiments in which the third-party 5 application (such as Google Play Music) dictates what media content is in the queue. See, e.g., 6 ’615 patent at 13:1–10; 15:59–62. Moreover, as Sonos points out, nothing in the claim itself 7 refers to a user. 8 In sum, this order agrees with Google that a “playback queue” requires a “list” of content 9 selected for playback, but agrees with Sonos that the list does not necessarily require more than 10 one item of content or require users to select content directly. This order further rejects 11 Google’s proposal to include the term “multimedia item” in the construction. The claim uses 12 the term “multimedia content,” and there is no need to introduce additional ambiguity by 13 importing a new term. Accordingly, this order construes the term “playback queue” as “a list 14 of multimedia content selected for playback.” 15 B. THE ACCUSED APPS DO NOT USE A “LOCAL PLAYBACK QUEUE” 16 Having construed “playback queue,” we now turn to Google’s non-infringement 17 arguments. To prove infringement, Sonos must show that Google’s accused products meet 18 each properly construed limitation of claim 13 either literally or under the doctrine of 19 equivalents. See Deering Precision Instruments, LLC v. Vector Distribution Sys., Inc., 347 20 F.3d 1314, 1324 (Fed. Cir. 2003). Here, Sonos asserts both. To establish literal infringement, 21 all of the elements of the claim, as correctly construed, must be present in the accused 22 products. TechSearch, LLC v. Intel Corp., 286 F.3d 1360, 1371 (Fed. Cir. 2002). Sonos may 23 also establish infringement under the doctrine of equivalents by “showing that the difference 24 between the claimed invention and the accused product [is] insubstantial,” including “by 25 showing on a limitation by limitation basis that the accused product performs substantially the 26 same function in substantially the same way with substantially the same result as each claim 27 limitation of the patented product.” Crown Packaging Tech., Inc. v. Rexam Beverage Can Co., 28 559 F.3d 1308, 1312 (Fed. Cir. 2009). 8 United States District Court Northern District of California 1 As stated above, Google’s primary non-infringement theory is that both its Google Play 2 Music app and YouTube app products do not use a “local playback queue” (see limitation 3 13.5). The two categories of accused apps operate in slightly different ways. In plain Greek, 4 Sonos asserts that using the cast feature on the YouTube apps on a control device causes a 5 “WatchNext” server to transmit a “WatchNextResponse” to a cast-enabled playback device. 6 The WatchNextResponse is then stored by the playback device. According to Sonos, the 7 WatchNextResponse “often” includes a string of characters called a “videoId” that corresponds 8 to the item set to currently playback, the item set to playback next, and the item that came 9 before the current item (Opp. 3–5). Similarly, casting from the Google Play Music app on the 10 control device creates an ItemWindowResponse that stores a link to the previous, current, and 11 next media items set for playback (Opp. 7-8). The apps receive this information from a cloud 12 queue, and neither of the apps store any additional media content beyond those three items. 13 Google quibbles about some of the details. Google asserts, for example, that a playback 14 device only “request[s] cloud queue items one-by-one” (Br. 7). Google further states that the 15 “upNextVideoID” variable (i.e., the variable corresponding to the item set to play next) only 16 appears when “the cloud queue has been exhausted,” and that this variable “only exists for a 17 few milliseconds” (Br. 9). 18 At bottom, though, neither side appears to dispute that Google’s products operate by 19 “retrieving” information from the cloud queue about the current, next, and previous media item 20 (Br. 9; Opp. 3). Nor do the parties dispute that these three items are only a subset of a separate 21 cloud queue. The focus of the dispute is instead on whether this information stored locally in 22 the playback device is a playback queue at all. 23 The parties dedicated the bulk of their briefing and their time at oral argument to this 24 issue. Upon review, this order concludes that neither the information stored by the 25 WatchNextResponse (in the YouTube apps) nor the information stored by the 26 ItemWindowResponse (in the Google Play Music app) qualify as a playback queue. The 27 groups of three items stored by the respective apps are not lists of multimedia content selected 28 for playback. In each app, the cloud queue stores the list, and the locally-stored information is 9 1 merely a mirror reflecting a subset of what is happening in the cloud queue. The songs set to 2 play on Google Play Music, for example, are all dictated by the cloud queue. If the user adds 3 or edits a playlist, the cloud queue changes. If the app creates a playlist, the cloud queue 4 adapts. It is only after the cloud queue changes that anything can happen to the information 5 stored locally on the playback device (see Bhattarcharjee Decl. ¶¶ 81–84). This demonstrates 6 that the groups of three items stored in each app are not lists of content selected for playback, 7 but rather merely provide the means to process the lists for playback. In short, the cloud queue 8 runs the show. United States District Court Northern District of California 9 Sonos objects that multiple playback queues can exist simultaneously (Opp. 8). In 10 support, Sonos points out that the specification teaches that there can be “two-way 11 communication” between the local playback queue and a separate queue, “such as keeping a 12 local playback queue synchronized with a queue that the user is editing/managing in the third 13 party application” (’615 patent at 16:22–31). But there is no such “two-way communication” 14 here. Rather, the cloud queue delivers information to the playback device on a one-way street. 15 The cloud queue provides information about the queue to the WatchNextResponse and 16 ItemWindowResponse, and never vice-versa, because there is no locally-stored queue that 17 would allow “two-way” synchronization. 18 Sonos further objects that the specification teaches that “the local playback system” can 19 “periodically fetch[] a short list of tracks to play list” from a “third-party application” (id. at 20 16:63–66). This passage, however, explains that the third-party application can “override a 21 local playback queue” with the “short list of tracks to play next” (ibid.). The passage thus 22 distinguishes a local playback queue from the “short list of tracks.” Moreover, the passage 23 suggests that there must be something to override, and, here, the locally-stored information can 24 never be populated by anything other than the “short list of tracks.” Instead, 25 WatchNextResponse and ItemWindowResponse can never store additional or different items, 26 and never more than three total items (see Bhatarcharjee Decl. ¶¶ 21, 73, 119). 27 28 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 United States District Court Northern District of California 1 products do not infringe the claim, and this order need not address Google’s additional non- 2 infringement arguments. 3 2. 4 This order now turns to Google’s invalidity arguments. Before we move forward, 5 however, a procedural note. After Google filed its motion, Sonos moved to strike some of the 6 motion for improperly asserting new invalidity theories and prior art references. A prior order 7 granted Sonos’s motion in part, striking paragraphs 133 and 138–41 of Dr. Bhattacharjee’s 8 expert report in their entirety (Dkt. No. 315). That material is accordingly not considered here. ANTICIPATION AND OBVIOUSNESS. 9 With this in mind, we now turn to Google’s surviving arguments. Google asserts that 10 one of its previous apps, the YouTube Remote app, anticipated claim 13 of the ’615 patent. 11 Alternatively, Google argues that it would have been obvious to combine the YouTube Remote 12 app with other prior art references to achieve Sonos’s claimed invention. 13 The YouTube Remote app was released in November 2010 (see Bobohalma Decl. ¶ 3). 14 The purpose of the app was to allow a smart phone to connect to another device, such as a 15 television or computer, so that a YouTube video being played on the smart phone would 16 appear on a larger screen (Br. 16). For example, a user could mirror a YouTube video onto a 17 television and control playback of the video through the app. In short, the app functioned 18 similarly to what Google now calls casting, as described above. The old process was more 19 cumbersome, however, because it involved an intermediary website to which both devices 20 separately had to connect to enable pairing. Specifically, each device needed to separately 21 navigate to the intermediary website and log in to the same YouTube account. Once the 22 devices were logged in to the same account, they could then pair with each other through the 23 YouTube Remote app (see Opp. 14–15). 24 Google now asserts that the app disclosed each and every limitation of claim 13. 25 “Anticipation requires that a single prior art reference disclose each and every limitation of the 26 claimed invention, either expressly or inherently.” SRI Int’l Inc. v. Cisco Sys., Inc., 930 F.3d 27 1295, 1306 (Fed. Cir. 2019). “Anticipation is a question of fact.” Atlas Powder Co. v. Ireco, 28 Inc., 190 F.3d 1342, 1346 (Fed. Cir. 1999). Because a patent is presumed valid, the party 11 1 asserting invalidity has the burden of proof to show anticipation by clear and convincing 2 evidence. Core Wireless Licensing S.A.R.L. v. LG Elecs., Inc., 880 F.3d 1356, 1364 (Fed. Cir. 3 2018). Sonos replies that the YouTube remote app did not disclose claim limitations 13.2, 13.4, 4 5 13.5, and 13.6.2 This order will first consider Sonos’s arguments as to 13.2, 13.5, and 13.6, 6 and then circle back to 13.4. For the reasons that follow, this order concludes that the app did 7 not disclose limitation 13.4, but that modifying the app the satisfy the limitation would have 8 been obvious in light of the prior art. United States District Court Northern District of California 9 A. LIMITATION 13.2 10 Claim limitation 13.2 recites “after connecting to a local area network via a network 11 interface, identifying playback devices connected to the local area network.” For our purposes, 12 a “local area network,” or LAN, refers to a “local” home Wi-Fi network. This is in contrast to 13 a “wide area network,” or WAN, which refers to network that can be accessed more widely, 14 e.g., a 3G cellular network. The important point is that a LAN and a WAN provide different 15 means to connect a device to the internet. Sonos reads limitation 13.2 to require that the control device affirmatively identify that 16 17 the playback device is connected to the same LAN as the control device, as opposed to a WAN 18 or a different LAN (Opp. 15). Google admits that its system did not do this. Instead, the 19 system allowed the control device and the playback device to separately log in to the 20 intermediary website. As such, it didn’t matter whether the smart phone and television were 21 connected to the internet in different ways. For example, the smart phone could have used a 22 3G network (a WAN) to navigate to the intermediary website, while the television could have 23 used a home Wi-Fi network (a LAN) to navigate to the intermediary website. Thus, the 24 YouTube Remote system did not require the control device to know whether the television was 25 connected to a LAN at all. Sonos insists that this precludes anticipation. 26 27 28 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 Google objects that the plain language of the claim does not require any such identifying 1 2 of the LAN. This order agrees. The claim only requires the control device to “identify[] 3 playback devices connected to the local area network” (see limitation 13.2). The phrase 4 “connected to the local area network” modifies “playback devices.” Accordingly, the claim 5 does not require affirmatively identifying the LAN. Nor does it require identifying that the 6 television is connected to the LAN. All that is required is that the system allowed (i) playback 7 devices to be identified and (ii) such identified devices to be connected to the same LAN as the 8 control device. The YouTube Remote system allowed both. It is undisputed that a television, for United States District Court Northern District of California 9 10 example, could have been connected to the same home Wi-Fi network as the smart phone, and 11 that the smart phone could have transferred playback to that television. Indeed, Google has 12 provided a 2010 video demonstrating just that (see Reply Br. 10).3 In such circumstances, the 13 control device is “identifying playback devices connected to the [LAN]” (see limitation 13.2). 14 True, as Google acknowledges, the phone and the television could have been connected to the 15 internet in different ways, but that Google’s system could identify devices connected to the 16 LAN in some circumstances and devices not connected to the LAN in others does not preclude 17 anticipation. Rather, it shows that Google’s system was flexible and had capabilities in 18 addition to those recited by the claim. See Vulcan Eng'g Co. v. Fata Aluminium, Inc., 278 F.3d 19 1366, 1375 (Fed. Cir. 2002) (“It is irrelevant whether an element has capabilities in addition to 20 that stated in the claim.”). Accordingly, the YouTube Remote app system tracked limitation 21 13.2. 22 B. LIMITATIONS 13.5–13.6 23 Next, Sonos briefly argues that the YouTube Remote system did not disclose limitation 24 13.5 because the app did not “caus[e] the playback at the control device to be stopped” (Opp. 25 18). Instead, Sonos contends, the smart phone in the 2010 video proffered by Google “appears 26 to still be in a playback state (albeit paused). . . .” (ibid.). Sonos, however, does not elaborate 27 28 3 Citing How to Control Google TV or YouTube Leanback with YouTube Remote, YouTube (Nov. 14, 2010), available at https://youtu.be/EGdsOslqG2s?t=56 (last visited July 29, 2022). 13 1 as to the distinction between playback being “paused” and “stopped,” and presents no evidence 2 that there is any difference between the two. Absent such, this order concludes that they mean 3 the same thing. Thus, the YouTube Remote app tracked limitation 13.5 to that extent. United States District Court Northern District of California 4 Sonos goes on to argue that Google has failed to show disclosure as to both limitations 5 13.5 and 13.6 because Google’s arguments as to those limitations rely on an “‘API’ document 6 and/or source code” that is dated July 12, 2010. The version of the YouTube Remote system 7 that Google asserts as anticipating prior art is dated November 9, 2010. To link the API 8 document with the later version of the YouTube Remote app, Google provided a declaration 9 from an engineer who did not work at Google until July 2011, a year after the date ascribed to 10 the API document (Reply Br. 18; Levai Decl. ¶¶ 2, 9). Sonos asserts that such “an 11 uncorroborated 2022 declaration of an interested witness . . . who did not even work at 12 Google” at the time “is insufficient corroboration” (Opp. 18). Not so. The engineer, Janos 13 Levai, worked on the prior art product shortly after the relevant time period and then worked 14 on subsequent iterations of the product for five years (see Levai Decl. ¶¶ 2, 9). He can testify 15 about how the app worked. Consequently, Sonos has failed to show a genuine dispute as to 16 limitations 13.5 and 13.6. 17 18 C. LIMITATION 13.4 We now circle back to limitation 13.4, which is our only remaining disputed limitation. 19 That limitation recites a “set of inputs” that comprise “(i) a selection of the selectable option 20 for transferring playback from the control device and (ii) a selection of the particular playback 21 device from the identified playback devices connected to the local area network.” The 22 YouTube Remote app offered the user the option to select a “Connect” button to transfer 23 playback from the smart phone to the playback devices available for pairing (Br. 19; Opp. 16– 24 17). Sonos does not dispute that a selection of “Connect” was “a selection of the selectable 25 option for transferring playback from the control device” (Opp. 17). Sonos contends, however, 26 that the app did not allow the selection of a “particular playback device from the identified 27 playback devices connected to the local area network” (ibid.). In other words, Sonos asserts 28 that, in the event multiple devices were available for playback (e.g., multiple televisions), the 14 1 user had no ability to select a subset of those devices for playback. The user was instead 2 forced to transfer playback to all available devices (Schmidt Decl. ¶ 154). 3 4 which pre-dates the ’615 patent’s claimed priority date of December 30, 2011 — that it asserts 5 allowed users to select particular devices (Reply Br. 11–12 (citing Bhattarcharjee Decl. ¶ 6 170)). Sonos does not dispute the substance of the code, but contends that it is not prior art 7 because its own asserted priority date is July 15, 2011 (see, e.g., Opp. 18 n.8). Sonos further 8 asserts that Google never contested this earlier invention date in its motion. Google replies that 9 it stated in its invalidity contentions that it was Sonos’s burden to show the earlier priority date, 10 11 United States District Court Northern District of California In reply, Google points to YouTube Remote source code dated December 1, 2011 — and that it was only using the July 15 date to frame its arguments (Reply Br. 12). This order sides with Sonos here. Google acknowledged the July 15 date in its opening 12 motion (see Br. 19 n.8). Further, Google’s motion only discusses the December 1, 2011, 13 source code in the context of its obviousness argument (see Bhattacharjee Decl. ¶ 170). Taken 14 together, this shows that Google treated July 15 as the applicable priority date. If Google 15 wanted to rely on the December 1 source code for its anticipation argument, it should have 16 made that clear in its opening motion. Instead, Google engaged in a bait-and-switch in its 17 reply brief (compare Br. 19–20, with Reply Br. 11-12). Thus, Google cannot now rely on the 18 December 1, 2011, source code for its anticipation case. The YouTube Remote system, 19 consequently, did not disclose limitation 13.4 because Google has failed to show that it 20 allowed users to select a “particular playback device.” 21 Nevertheless, this order concludes that it would have been obvious to combine the 22 YouTube Remote app system with disclosures in United States Patent No. 9,490,998 to allow 23 the selection of individual devices. 24 A claimed invention is obvious if “the differences between the subject matter sought to 25 be patented and the prior art are such that the subject matter as a whole would have been 26 obvious at the time the invention was made to a person having ordinary skill in the art.” 35 27 U.S.C. § 103(a) (pre-AIA). Unlike anticipation, which “requires all elements of a claim to be 28 disclosed within a single reference,” “[o]bviousness can be proven by combining existing prior 15 1 art references” to disclose all the elements of a claim. Cohesive Techs. Inc. v. Waters Corp., 2 543 F.3d 1351, 1364 (Fed. Cir. 2008). 3 The ’998 patent is prior art. It was filed on March 7, 2011, and claims priority to an 4 earlier provision application filed in November 2010. The patent’s inventors were involved 5 with the development of the YouTube Remote system, and the patent relates to controlling 6 playback on a playback device through a control device. The ’998 patent disclosed that 7 [i]n some examples, the user may also utilize the remote control application of remote control 75 to select one or more previously paired controlled devices, and to send control messages to one or more paired controlled devices. For example, the user may interact with user interface 84 and/or display 88 to interact with and control any available controlled devices. 8 9 10 United States District Court Northern District of California 11 12 13 14 (see ’998 patent at 10:62–11:6 (emphasis added)). Thus, the 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” (ibid.) The patent, therefore, taught the “selection of the particular playback device from the identified playback devices” as contemplated by the ’615 patent. 15 Sonos raises three objections to this conclusion. First, Sonos argues that the passage is 16 ambiguous insofar as it could be read to refer to 17 the ability to control one “controlled device,” if that is the only “previously paired” “controlled device,” or the ability to control all “controlled devices” collectively, if multiple “controlled devices” have been “previously paired” with a “remote control” in a session 18 19 20 (see Schmidt Decl. ¶ 173). Put differently, Sonos does not read the passage to teach the 21 selection of a particular device when multiple devices are connected in a session. This 22 contorted interpretation does not convince. The most straightforward reading of the passage is 23 that it disclosed the ability to “select one or more” devices among the “previously-paired 24 devices.” 25 Second, Sonos argues that the passage does not “mention or even suggest[] transferring 26 playback from a ‘remote control’ to a ‘controlled device’” and “[c]onsequently . . . does not 27 teach the selection of a particular ‘controlled device’ to transfer playback to” (Opp. 19). This 28 is missing the forest for the trees. As described above, the YouTube Remote app system, 16 United States District Court Northern District of California 1 which is prior art, disclosed the transfer of playback. The passage from the ’998 patent 2 disclosed the selection of a particular device. They achieve the claim together. 3 Third, Sonos argues that it would not have been obvious to combine the ’998 patent’s 4 disclosure with the YouTube Remote system. Specifically, Sonos argues that the YouTube 5 Remote “system architecture” both “teaches away from Google’s proposed modifications and 6 also renders such modifications more complicated than Google posits” (Opp. 21–22). Sonos 7 further argues that there would have been no motivation to integrate the modification because 8 it “was not even a prominent feature” of the YouTube Remote app (id. at 22). The problem 9 with these assertions is that Google produced source code achieving the proposed modification 10 just a few months after Sonos’s asserted priority date, and Google then released the 11 functionality to the public a year later (see Reply Br. 14). This adequately demonstrates that a 12 person of skill in art would have been motivated to add the feature. 13 Sonos’s remaining snippets of argument are conclusory and without merit. In sum, this 14 order finds that it would have been obvious to combine the teachings of the ’998 patent with 15 the YouTube Remote system to achieve the claimed invention. Google’s motion for summary 16 judgment of invalidity of claim 13 of the ’615 patent is accordingly GRANTED. CONCLUSION 17 18 To the foregoing extent, Google’s motion for summary judgment is GRANTED. 19 IT IS SO ORDERED. 20 21 Dated: August 2, 2022. 22 23 WILLIAM ALSUP UNITED STATES DISTRICT JUDGE 24 25 26 27 28 17

Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.


Why Is My Information Online?