Opinion
No. C 20-06754 WHA
2022-08-02
GOOGLE LLC, Plaintiff, v. SONOS, INC., Defendant.
Charles Kramer Verhoeven, Quinn Emanuel Urquhart & Sullivan, LLP, San Francisco, CA, Anne-Raphaelle Aubry, Pro Hac Vice, Quinn Emanuel Urquhart & Sullivan, Boston, MA, Clement S. Roberts, Orrick, Herrington & Sutcliffe LLP, San Francisco, CA, Jordan R. Jaffe, Wilson Sonsini Goodrich & Rosati, San Francisco, CA, Lana Robins, Melissa J. Baily, Sean S. Pak, Jocelyn, Ma, Lindsay Cooper, James DuBois Judah, Quinn Emanuel Urquhart & Sullivan LLP, San Francisco, CA, Jason C. Williams, Pro Hac Vice, Quinn Emanuel Urquhart & Sullivan, LLP, New York, NY, Marc Lawrence Kaplan, Pro Hac Vice, Quinn Emanuel Urquhart & Sullivan, LLP, Chicago, IL, Nima Hefazi, Quinn, Emanuel, Urquhart & Sullivan, LLP, Los Angeles, CA, for Plaintiff. Alyssa M. Caridis, Shane D. Anderson, Orrick, Herrington & Sutcliffe LLP, Los Angeles, CA, Bas de Blank, Orrick, Herrington & Sutcliffe LLP, Menlo Park, CA, Clement S. Roberts, Elizabeth R. Moulton, Orrick, Herrington & Sutcliffe LLP, San Francisco, CA, Cole Bradley Richter, Pro Hac Vice, David R. Grosby, Pro Hac Vice, George I. Lee, Pro Hac Vice, Jae Y. Pak, Pro Hac Vice, John Dan Smith, III, Pro Hac Vice, I Matthew J. Sampson, Pro Hac Vice, Michael P. Boyea, Pro Hac Vice, Rory Patrick Shea, Pro Hac Vice, Sean M. Sullivan, Pro Hac Vice, Lee Sullivan Shea Smith LLP, Chicago, IL, Evan David Brewer, Orrick, Herrington & Sutcliffe LLP, Seattle, WA, Joseph Raymond Kolker, Pro Hac Vice, Orrick, Herrington & Sutcliffe LLP, New York, NY, for Defendant.
Charles Kramer Verhoeven, Quinn Emanuel Urquhart & Sullivan, LLP, San Francisco, CA, Anne-Raphaelle Aubry, Pro Hac Vice, Quinn Emanuel Urquhart & Sullivan, Boston, MA, Clement S. Roberts, Orrick, Herrington & Sutcliffe LLP, San Francisco, CA, Jordan R. Jaffe, Wilson Sonsini Goodrich & Rosati, San Francisco, CA, Lana Robins, Melissa J. Baily, Sean S. Pak, Jocelyn, Ma, Lindsay Cooper, James DuBois Judah, Quinn Emanuel Urquhart & Sullivan LLP, San Francisco, CA, Jason C. Williams, Pro Hac Vice, Quinn Emanuel Urquhart & Sullivan, LLP, New York, NY, Marc Lawrence Kaplan, Pro Hac Vice, Quinn Emanuel Urquhart & Sullivan, LLP, Chicago, IL, Nima Hefazi, Quinn, Emanuel, Urquhart & Sullivan, LLP, Los Angeles, CA, for Plaintiff.
Alyssa M. Caridis, Shane D. Anderson, Orrick, Herrington & Sutcliffe LLP, Los Angeles, CA, Bas de Blank, Orrick, Herrington & Sutcliffe LLP, Menlo Park, CA, Clement S. Roberts, Elizabeth R. Moulton, Orrick, Herrington & Sutcliffe LLP, San Francisco, CA, Cole Bradley Richter, Pro Hac Vice, David R. Grosby, Pro Hac Vice, George I. Lee, Pro Hac Vice, Jae Y. Pak, Pro Hac Vice, John Dan Smith, III, Pro Hac Vice, I Matthew J. Sampson, Pro Hac Vice, Michael P. Boyea, Pro Hac Vice, Rory Patrick Shea, Pro Hac Vice, Sean M. Sullivan, Pro Hac Vice, Lee Sullivan Shea Smith LLP, Chicago, IL, Evan David Brewer, Orrick, Herrington & Sutcliffe LLP, Seattle, WA, Joseph Raymond Kolker, Pro Hac Vice, Orrick, Herrington & Sutcliffe LLP, New York, NY, for Defendant.
ORDER GRANTING MOTION FOR PARTIAL SUMMARY JUDGMENT AS TO ’615 PATENT
WILLIAM ALSUP, United States District Judge
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.
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, 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 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, 106 S.Ct. 2505, 91 L.Ed.2d 202 (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, 106 S.Ct. 2505.
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 | Google's Proposed Construction | Court's Construction |
|---|---|---|
| Plain and ordinary meaning | "An ordered list of multimedia items that is selected by the user for playback" | "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." 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:
The parties’ dispute over the term "resource locator" does not bear on this order's infringement and invalidity analysis.
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 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 "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 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).
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 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 Bhattacharjee 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 Bhattacharjee 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 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 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. 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.
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.
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.
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). 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 Vulcan Eng'g Co. v. Fata Aluminium, Inc. , 278 F.3d 1366, 1375 (Fed. Cir. 2002) ("It is irrelevant whether an element has capabilities in addition to that stated in the claim."). Accordingly, the YouTube Remote app system tracked limitation 13.2.
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).
B. LIMITATIONS 13.5–13.6
Next, Sonos briefly argues that the YouTube Remote system did not disclose limitation 13.5 because the app did not "caus[e] the playback at the control device to be stopped " (Opp. 18). Instead, Sonos contends, the smart phone in the 2010 video proffered by Google "appears to still be in a playback state (albeit paused) ...." (ibid. ). Sonos, however, does not elaborate as to the distinction between playback being "paused" and "stopped," and presents no evidence that there is any difference between the two. Absent such, this order concludes that they mean the same thing. Thus, the YouTube Remote app tracked limitation 13.5 to that extent.
Sonos goes on to argue that Google has failed to show disclosure as to both limitations 13.5 and 13.6 because Google's arguments as to those limitations rely on an " ‘API’ document and/or source code" that is dated July 12, 2010. The version of the YouTube Remote system that Google asserts as anticipating prior art is dated November 9, 2010. To link the API document with the later version of the YouTube Remote app, Google provided a declaration from an engineer who did not work at Google until July 2011, a year after the date ascribed to the API document (Reply Br. 18; Levai Decl. ¶¶ 2, 9). Sonos asserts that such "an uncorroborated 2022 declaration of an interested witness ... who did not even work at Google" at the time "is insufficient corroboration" (Opp. 18). Not so. The engineer, Janos Levai, worked on the prior art product shortly after the relevant time period and then worked on subsequent iterations of the product for five years (see Levai Decl. ¶¶ 2, 9). He can testify about how the app worked. Consequently, Sonos has failed to show a genuine dispute as to limitations 13.5 and 13.6.
C. LIMITATION 13.4
We now circle back to limitation 13.4, which is our only remaining disputed limitation. That limitation recites a "set of inputs" that comprise "(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." The YouTube Remote app offered the user the option to select a "Connect" button to transfer playback from the smart phone to the playback devices available for pairing (Br. 19; Opp. 16–17). Sonos does not dispute that a selection of "Connect" was "a selection of the selectable option for transferring playback from the control device" (Opp. 17). Sonos contends, however, that the app did not allow the selection of a "particular playback device from the identified playback devices connected to the local area network" (ibid. ). In other words, Sonos asserts that, in the event multiple devices were available for playback (e.g. , multiple televisions), the user had no ability to select a subset of those devices for playback. The user was instead forced to transfer playback to all available devices (Schmidt Decl. ¶ 154).
In reply, Google points to YouTube Remote source code dated December 1, 2011 — which pre-dates the ’615 patent ’s claimed priority date of December 30, 2011 — that it asserts allowed users to select particular devices (Reply Br. 11–12 (citing Bhattacharjee Decl. ¶ 170)). Sonos does not dispute the substance of the code, but contends that it is not prior art because its own asserted priority date is July 15, 2011 (see, e.g. , Opp. 18 n.8). Sonos further asserts that Google never contested this earlier invention date in its motion. Google replies that it stated in its invalidity contentions that it was Sonos's burden to show the earlier priority date, 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 motion (see Br. 19 n.8). Further, Google's motion only discusses the December 1, 2011, source code in the context of its obviousness argument (see Bhattacharjee Decl. ¶ 170). Taken together, this shows that Google treated July 15 as the applicable priority date. If Google wanted to rely on the December 1 source code for its anticipation argument, it should have made that clear in its opening motion. Instead, Google engaged in a bait-and-switch in its reply brief (compare Br. 19–20, with Reply Br. 11-12). Thus, Google cannot now rely on the December 1, 2011, source code for its anticipation case. The YouTube Remote system, consequently, did not disclose limitation 13.4 because Google has failed to show that it allowed users to select a "particular playback device."
Nevertheless, this order concludes that it would have been obvious to combine the YouTube Remote app system with disclosures in United States Patent No. 9,490,998 to allow the selection of individual devices.
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). 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" to disclose all the elements of a claim. Cohesive Techs. Inc. v. Waters Corp. , 543 F.3d 1351, 1364 (Fed. Cir. 2008).
The ’998 patent is prior art. It was filed on March 7, 2011, and claims priority to an earlier provision 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. The ’998 patent disclosed that
[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.
(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.
Sonos raises three objections to this conclusion. First , Sonos argues that the passage is ambiguous insofar as it could be read to refer to
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
(see Schmidt Decl. ¶ 173). Put differently, Sonos does not read the passage to teach the selection of a particular device when multiple devices are connected in a session. This contorted interpretation does not convince. The most straightforward reading of the passage is that it disclosed the ability to "select one or more" devices among the "previously-paired devices."
Second , Sonos argues that the passage does not "mention or even suggest[ ] transferring playback from a ‘remote control’ to a ‘controlled device’ " and "[c]onsequently ... does not teach the selection of a particular ‘controlled device’ to transfer playback to" (Opp. 19). This is missing the forest for the trees. As described above, the YouTube Remote app system, which is prior art, disclosed the transfer of playback. The passage from the ’998 patent disclosed the selection of a particular device. They achieve the claim together.
Third , Sonos argues that it would not have been obvious to combine the ’998 patent ’s disclosure with the YouTube Remote system. Specifically, Sonos argues that the YouTube Remote "system architecture" both "teaches away from Google's proposed modifications and also renders such modifications more complicated than Google posits" (Opp. 21–22). Sonos further argues that there would have been no motivation to integrate the modification because it "was not even a prominent feature" of the YouTube Remote app (id. at 22). The problem with these assertions is that Google produced source code achieving the proposed modification just a few months after Sonos's asserted priority date, and Google then released the functionality to the public a year later (see Reply Br. 14). This adequately demonstrates that a person of skill in art would have been motivated to add the feature.
Sonos's remaining snippets of argument are conclusory and without merit. In sum, this order finds that it would have been obvious to combine the teachings of the ’998 patent with the YouTube Remote system to achieve the claimed invention. Google's motion for summary judgment of invalidity of claim 13 of the ’615 patent is accordingly GRANTED .
CONCLUSION
To the foregoing extent, Google's motion for summary judgment is GRANTED .