Opinion
C 20-06754 WHA
04-13-2023
SONOS, INC., Plaintiff, v. GOOGLE LLC, Defendant.
ORDER RE MOTIONS FOR SUMMARY JUDGMENT
WILLIAM ALSUP, UNITED STATES DISTRICT JUDGE
INTRODUCTION
With trial looming in this patent infringement action, both sides again move for summary judgment. Alleged infringer now moves for summary judgment of invalidity and no willful or indirect infringement of the three remaining patents, as well as non-infringement of two of those patents based on a purported design-around. Meanwhile, patent owner now moves for summary judgment on alleged infringer's contract-based claims. For the following reasons, alleged infringer's motion is GRANTED IN PART, DENIED IN PART, and DEFERRED IN PART, whereas patent owner's motion is DENIED AS MOOT.
STATEMENT
The relevant facts are described at length elsewhere. See Sonos, Inc. v. Google LLC, 591 F.Supp.3d 638, 641 (N.D. Cal. 2022), leave to appeal denied, 2022 WL 1486359 (Fed. Cir. May 11, 2022). In brief, we have two related civil actions involving Sonos, Inc.'s patents and Google LLC's alleged infringement: Google's declaratory judgment action filed in the Northern District of California, and Sonos's affirmative infringement action filed (one day before) in the Western District of Texas and transferred (one year later) at the direction of the Federal Circuit (No. C 21-07559 WHA).
The operative pleadings focus on U.S. Patent Nos. 9,967,615; 10,779,033; 10,848,885; and 10,469,966. These patents generally concern multi-room “smart” speaker technology. Whereas the '615 and '033 patents cover technology related to transferring playback between devices, i.e., “casting,” the '885 and '966 patents cover technology related to managing groups of smart speakers.
Pursuant to “patent showdown” procedure, each side has already moved for summary judgment on a single claim. Separate orders granted summary judgment in favor of Google on invalidity of claim 13 of the '615 patent and in favor of Sonos on infringement of claim 1 of the '885 patent. Sonos has since withdrawn its remaining claims based on the '615 patent, and Google has since begun developing and deploying a purported design-around for the '885 and '966 patents. Claims and defenses related to the '033, '885, and '966 patents are now set for trial starting May 8, 2023 (SAC ¶¶ 49-84; see also No. C 21-07559 WHA, TAC ¶¶ 134-233). So are Google's claims for breach of contract and conversion, which are based on prior collaborations with Sonos (SAC ¶¶ 85-97).
In the lead-up to trial, both parties have filed motions to strike portions of each other's expert reports (Dkt. Nos. 464, 469), as well as new motions for summary judgment (Dkt. Nos. 478, 483). Sonos also filed a renewed motion to realign the parties (Dkt. No. 477), which the undersigned granted at the hearing after Google withdrew its opposition (Dkt. No. 557). A companion order considered the motions to strike (Dkt. No. 565). This order considers the motions for summary judgment.
Google moves for summary judgment of invalidity of the asserted claims of the '033, '885, and '966 patents; no willful or indirect infringement of the asserted claims of the '033, '885, and '966 patents; and non-infringement of the asserted claims of the '885 and '966 patents based on a purported design-around. Sonos moves for summary judgment on Google's breach of contract and conversion claims. This order follows full briefing and oral argument.
ANALYSIS
Under Rule 56 of the Federal Rules of Civil Procedure, summary judgment is proper when there is no genuine dispute of material fact and the movant is entitled to judgment as a matter of law. A dispute of material fact is genuine “if the evidence is such that a reasonable jury could return a verdict for the nonmoving party.” Anderson v. Liberty Lobby, Inc., 477 U.S. 242, 248 (1986). In deciding a motion for summary judgment, the district court must accept the non-movant's non-conclusory evidence and draw all justifiable inferences in the non-movant's favor. Id. at 255.
1. Google'S Motion: Invalidity of the '033 Patent.
Let's begin with the '033 patent. Our analysis of the '033 patent (“Systems and Methods for Networked Music Playback”) starts with our earlier analysis of the '615 patent (“Networked Music Playback”) during the patent showdown. Google LLC v. Sonos, Inc., 2022 WL 3046752 (N.D. Cal. Aug. 2, 2022). They have identical specifications. Like the '615 patent, the '033 patent is directed toward the act of transferring playback of media content from one device (e.g., a phone) to another (e.g., a television), an act Google calls “casting.” And, like claim 13 of the '615 patent covered in the prior order, the asserted claims of the '033 patent covered here are directed toward transferring playback of a queue of media content (e.g., a video playlist).
This order refers the reader to the prior order for a more in-depth introduction to cast technology and the accused applications, which include YouTube, YouTube Kids, YouTube TV, YouTube Music, and Google Play Music. Suffice to say, YouTube was and remains owned by Google, and the accused applications employ technology that enables a “control device” to transfer playback of a queue of media content to a Google cast-enabled “playback device,” wherein the control device controls the application and the playback device plays the content. By way of example, a user can activate a feature on the accused YouTube application to cast a video playlist (queue of media content) from a phone (control device) to a television (playback device). The analysis of the '615 patent in the prior order, and the analysis of the '033 patent in this order, hinge on the queue of media content that is cast. Because both parties find support in the prior order's analysis of non-infringement and invalidity, this order will provide a summary.
First, the prior order found Google's accused products did not infringe claim 13 of the '615 patent because they did not employ a “local playback queue on the particular playback device,” as required by limitation 13.5 ('615 patent 20:8-9). That order construed “playback queue” as “a list of multimedia content selected for playback.” It then determined that the information in the accused applications that was stored locally on Google cast-enabled playback devices to play casted content (i.e., last, current, and next media item) was not a playback queue. Rather, that information was a subset of the list of multimedia content selected for playback and merely provided the local means to process it. For the accused products, the list of multimedia content selected for playback was stored on a remote cloud server. The parties and the prior order referred to it as a “cloud queue,” and all agreed that it was not a local playback queue because it was not stored locally on a playback device in the accused applications. The parties only disputed whether the information received by a Google cast-enabled playback device from the cloud queue was itself a local playback queue. The prior order found it was not. “In short, the cloud queue r[an] the show.” Google, 2022 WL 3046752, at *6; see generally id. at *3-6.
Second, that order found claim 13 of the '615 patent invalid over prior art. Specifically, it determined that Google's YouTube Remote application anticipated claim 13 of the '615 patent for all but one limitation. This was limitation 13.4, which required “selection of [a] particular playback device” ('615 patent 19:61-67). But the prior order nevertheless concluded it would have been obvious to combine the YouTube Remote application with disclosures in a Google patent to allow for such selection (U.S. Patent No. 9,490,998). Note that the order did not discuss the local playback queue from limitation 13.5 in the context of invalidity; it only discussed it in the context of non-infringement, as set out above. By implication, however, the prior order found the YouTube Remote application employed a local playback queue because it found the YouTube Remote application disclosed limitation 13.5. Google, 2022 WL 3046752, at *6-10.
Whereas claim 13 of the '615 patent recited a “local playback queue on the particular playback device,” the corresponding claims of the '033 patent recite a “remote playback queue provided by a cloud-based computing system.” The parties agree that this is the central distinction between the two patents, but they disagree on the significance of this distinction.
A. No Judicial Estoppel.
As a threshold matter, this order will consider (and reject) Sonos's argument that Google is judicially estopped from asserting the YouTube Remote prior art disclosed the '033 patent's remote playback queue. According to Sonos, Google previously represented that the YouTube Remote system “used a local playback queue, and further argued that there can only be one playback queue in a system” (Sonos Opp. 2) (emphasis in original). It insists that the undersigned relied on these representations in finding claim 13 of the '615 patent invalid. According to Google, however, neither it nor the undersigned ever suggested that there could only be one playback queue in the YouTube Remote system (Google Reply Br. 1-3). This order agrees with Google.
“[W]here a party assumes a certain position in a legal proceeding, and succeeds in maintaining that position, he may not thereafter, simply because his interests have changed, assume a contrary position, especially if it be to prejudice the party who has acquiesced in the position formerly taken by him.” New Hampshire v. Maine, 532 U.S. 742, 749 (2001) (citation omitted). Google has not assumed a contrary position here. The language Sonos seizes upon from Google's prior motion for summary judgment stated:
[T]he YouTube Remote prior art product is a direct ancestor of the YouTube product Sonos accuses of infringement .... The key difference is that where the accused YouTube applications use . . . a cloud queue, the prior art YouTube Remote used . . . a local queue.(Sonos Opp. 2 (quoting Google Showdown Br. 2)) (emphasis omitted). Just because the accused applications use a cloud queue where the YouTube Remote prior art used a local queue does not mean that the YouTube Remote prior art could not also use a remote playback queue. Google's expert expressly rejected that position in his patent showdown rebuttal report, observing “[a] system might store the playback queue both at the local playback device and remotely,” but “[t]his [was] not the case with the accused products” (Bhattacharjee Showdown Rebuttal Rpt. ¶ 320) (emphasis added). Google's expert did not rule out this possibility for the prior art.
Neither did the prior order, which stated:
Sonos objects that multiple playback queues can exist simultaneously (Opp. 8). In support, Sonos points out that the specification teaches that there can be “two-way communication” between the local playback queue and a separate queue, “such as keeping a local playback queue synchronized with a queue that the user is editing/managing in the third party application” ('615 patent at 16:22-31). But there is no such “two-way communication” here. Rather, the cloud queue delivers information to the playback device on a one-way street. The cloud queue provides information about the queue . . . and never vice-versa, because there is no locally-stored queue that would allow “two-way” synchronization.Google, 2022 WL 3046752, at *6. In other words, that order only found the “two-way” playback queue of one embodiment did not exist in the accused products. It never concluded that multiple playback queues could not exist simultaneously or could not have existed simultaneously in the prior art.
Moreover, Google now argues that a feature in YouTube Remote version 2 (“YTR2”) disclosed a remote playback queue, whereas it was YouTube Remote version 1 (“YTR1”) that disclosed a local playback queue previously. This alone suggests that the prior order should not foreclose an invalidity analysis here. Whereas YTR1 was released on November 9, 2010, YTR2.03 and YTR2.07 were released on July 29, 2011, and August 10, 2011, respectively. The '033 patent application claims priority through a chain of applications dating back to December 30, 2011. Because the YTR2 system was released prior to the '033 patent priority date and could invalidate the asserted claims, this order proceeds to analysis of those claims.
B. Overview of Asserted Claims.
Sonos asserts claims 1-2, 4, 9, 11-13, and 16 of the '033 patent. Claims 1 and 12 are independent claims, and claims 2, 4, 9, 11, 13, and 16 are dependent claims. Whereas claim 1 is directed to a “computing device” (corresponding to a control device discussed above), claim 12 is directed to a “computer-readable medium” (with instructions for that control device). Both parties focus their analysis on claim 1.
Using Google's paragraph numbering, claim 1 of the '033 patent recites:
[1.0] A computing device comprising:
[1.1] at least one processor;
[1.2] a non-transitory computer-readable medium; and
[1.3] program instructions stored on the non-transitory computer-readable medium that, when executed by the at least one processor, cause the computing device to perform functions comprising:
[1.4] operating in a first mode in which the computing device is configured for playback of a remote playback queue provided by a cloud-based computing system associated with a cloud-based media service;
[1.5] while operating in the first mode, displaying a representation of one or more playback devices in a media playback system that are each i) communicatively coupled to the computing device over a data network and ii) available to accept playback responsibility for the remote playback queue;
[1.6] while displaying the representation of the one or more playback devices, receiving user input indicating a selection of at least one given playback device from the one or more playback devices;
[1.7] based on receiving the user input,
[1.7(a)] transmitting an instruction for the at least one given playback device to take over responsibility for playback of the remote playback queue from the computing device,
[1.7(b)] wherein the instruction configures the at least one given playback device to (i) communicate with the cloud-based computing system in order to obtain data identifying a next one or more media items that are in the remote playback queue, (ii) use the obtained data to retrieve at least one media item in the remote playback queue from the cloud-based media service; and (iii) play back the retrieved at least one media item;
[1.8] detecting an indication that playback responsibility for the remote playback queue has been successfully transferred from the computing device to the at least one given playback device; and
[1.9] after detecting the indication, transitioning from i) the first mode in which the computing device is configured for playback of the remote playback queue to ii) a second mode in which the computing device is configured to control the at least one given playback device's playback of the remote playback queue and the computing device is no longer configured for playback of the remote playback queue.('033 patent 17:32-18:10). Recall the parties agree that the primary difference between invalid claim 13 of the '615 patent and the asserted claims of the '033 patent is that the former recited a local playback queue and the latter recite a remote playback queue, italicized above.
Google now argues that claim 1 of the '033 patent and the other asserted claims are invalid as obvious over two prior art references: (1) Google's YTR2 system, which disclosed a remote playback queue on account of its “party mode” feature; and (2) Google's '998 patent, which (again) taught the selection of playback devices (Google Br. 5-15). Sonos contends that these prior art references did not satisfy limitations 1.4-1.9 of the '033 patent (Sonos Opp. 3 10). According to Sonos, the YTR2 system did not disclose a remote playback queue, as required by limitations 1.4, 1.7, 1.8, and 1.9, whereas the '998 patent did not teach the selection of playback devices, as required by limitations 1.5 and 1.6.
Google also argues that the YouTube Remote prior art disclosed a remote playback queue when a YTR1 or YTR2 user selected a list of service-recommended videos for playback (Google Br. 911). Because this order finds that YTR2 party mode disclosed a remote playback queue, however, it does not reach this argument.
A claimed invention is obvious if “the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art.” 35 U.S.C. § 103(a) (pre-AIA). Obviousness is a question of law based on underlying questions of fact. ABT Sys., LLC v. Emerson Elec. Co., 797 F.3d 1350, 1354 (Fed. Cir. 2015). Unlike anticipation, which “requires all elements of a claim to be disclosed within a single reference,” “[o]bviousness can be proven by combining existing prior art references.” Cohesive Techs. Inc. v. Waters Corp., 543 F.3d 1351, 1364 (Fed. Cir. 2008). “A party seeking to invalidate a patent based on obviousness must demonstrate by clear and convincing evidence that a skilled artisan would have been motivated to combine the teachings of the prior art references to achieve the claimed invention, and that the skilled artisan would have had a reasonable expectation of success in doing so.” Procter & Gamble Co. v. Teva Pharms. USA, Inc., 566 F.3d 989, 994 (Fed. Cir. 2009) (internal quotation marks and citation omitted). The first step in an obviousness analysis is proper construction of the claim to determine its scope and meaning, and the second step is comparison of the properly construed claim to the prior art. Medichem, S.A. v. Rolabo, S.L., 353 F.3d 928, 933 (Fed. Cir. 2003).
Here, the parties agree on the construction of the central claim term: a “remote playback queue” is a “playback queue,” as construed in the prior order, that is also “remote” (Dkt. Nos. 560-61). And, they interpret “remote” almost identically. Sonos explains that “the term ‘remote' refers to a location different from (i.e., not local to) the ‘computing device' or the ‘playback device,'” whereas Google proposes it means “geographically distant from the claimed computing and playback devices” (compare Dkt. No. 560 at 2, with Dkt. No. 561 at 1). For the purpose of evaluating movant Google's invalidity arguments, this order adopts nonmovant Sonos's phrasing and construes “remote” as “not local to the claimed computing device or playback device.” As such, a “remote playback queue” is a “playback queue” that is “not local to the claimed computing device or playback device.” Applying the construction of “playback queue” from the prior order, a “remote playback queue” is “a list of multimedia content selected for playback that is not local to the claimed computing device or playback device.”
With this agreed-upon construction, does claim 1 of the '033 patent read on the prior art? For the reasons that follow, this order concludes that it does.
C. Overview of Prior Art.
Let's start with the prior art. The YouTube Remote application allowed a user to display YouTube videos on one or more screens (e.g., televisions) and control playback of those YouTube videos from one or more mobile devices (e.g., phone and tablet). First released in November 2010 and later discontinued, it functioned like casting, but the YouTube Remote application required a user to separately navigate to an intermediary website on each of the devices and log in to the same YouTube account to pair them.
Party mode was a feature that Google developed after releasing YTR1, reducing it to practice on July 12, 2011, and releasing it in YTR2. Whereas YTR1 allowed for one user to manage a queue of YouTube videos and transfer playback from one or more mobile devices to one or more screens, YTR2 party mode allowed for two or more users to manage a queue of YouTube videos and transfer playback from two or more mobile devices to one or more screens. To reiterate, YTR2 predated the '033 patent priority date of December 30, 2011, with YTR2.03 and YTR2.07 released on July 29, 2011, and August 10, 2011, respectively.
To initiate party mode, a host user would select a queue of YouTube videos for playback on a mobile device running YTR2 and invite one or more guest users with a mobile device running YTR2. If the guest user(s) accepted the host user's invitation, the host user's mobile device would send a message to a cloud server (called the “MDx server”) with the list of identifiers for the queue of videos selected for playback (called “videoIds”). The cloud server would store this list of identifiers in the “party queue” and then send a message with the list of identifiers to the mobile device(s) of the guest user(s), where it would be stored locally (Bhattacharjee Rpt. ¶¶ 171-75; Schmidt Rebuttal Rpt. ¶¶ 207-08).
In party mode, the host user and guest user(s) managed the same queue of videos, which was stored in the party queue on the cloud server and on each of their mobile devices. If the host user or guest user(s) made a change to the queue of videos (e.g., removing the last video), her mobile device would send an update message to the cloud server, which would store the updated list of identifiers in the party queue. The cloud server would then send a message with the updated list of identifiers to the mobile devices of the host user and guest user(s), which was again stored locally. If playback was transferred to one or more of the host user's screens, the queue of videos was stored on the screen(s) as well, and the message with the updated list of identifiers would also go to the screen(s) to be stored locally (Bhattacharjee Rpt. ¶¶ 176-77; Schmidt Rebuttal Rpt. ¶¶ 213-14).
To transfer playback to a screen in party mode, the host or guest user(s) would press a “Connect” button in the application and the cloud server would send a message to the screen identifying one or more videos for playback. For each video, that screen would send a corresponding identifier it had stored locally to another cloud server (called “Player Service”) to obtain a URL (called a “Bandaid URL”). That URL would enable the screen to retrieve the media content (audio and video content) corresponding to the identifier from yet another cloud server in Google's Content Delivery Network (called “Bandaid”), which would then be played back (Bhattacharjee Rpt. ¶¶ 327-29, 340; Schmidt Rpt. ¶¶ 162-66; Schmidt Rebuttal Rpt. ¶¶ 174-76). Sonos's expert provides a helpful diagram of this process, which is based on a Google diagram produced in discovery:
(Image Omitted)
(Schmidt Rpt. ¶ 166).
As for the '998 patent, the prior order stated, in pertinent part:
The '998 patent is prior art. It was filed on March 7, 2011, and claims priority to an earlier provision[al] application filed in November 2010. The patent's inventors were involved with the development of the YouTube Remote system, and the patent relates to controlling playback on a playback device through a control device ....
[T]he patent disclosed that a “user interface” of a “remote control” (e.g., a smart phone) can display “previously paired controlled devices” (e.g., a television) so that a user may select and control “one or more paired controlled devices.”Google, 2022 WL 3046752, at *9. This user interface was called the “device-picker,” which was added to source code for the YouTube Remote application dated December 1, 2011 - again, before the priority date of the '033 patent, December 30, 2011. The device-picker was released with YouTube Remote version 3 (“YTR3”) in January 2012.
This order will first consider Google's arguments as to the “remote playback queue” limitations allegedly disclosed by the YTR2 system (1.4, 1.7, 1.8, and 1.9), and then circle back to the “selection of playback devices” limitations allegedly taught by the '998 patent (1.5 and 1.6).
D. Limitation 1.4.
Limitation 1.4 requires a “computing device” that is “configured for playback of a remote playback queue provided by a cloud-based computing system associated with a cloud-based media service” ('033 patent 17:40-42). The “computing device” corresponds to the control device discussed above, which is itself configured for playback at this stage. In other words, the playback captured by limitation 1.4 is taking place on a control device (e.g., a phone) and has not yet been transferred to a playback device (e.g., a television).
According to Google, YTR2 party mode disclosed limitation 1.4. Because the party queue was a playback queue, and the cloud server provided the party queue to the geographically distant mobile devices of the host and guest user(s), those mobile devices were ostensibly configured for playback of a remote playback queue provided by a cloud-based computing system (Google Br. 6-7). According to Sonos, however, party mode was “simply a mode that allow[ed] multiple YouTube accounts to add songs to the same queue” and that “d[id] not change anything about the location of the playback queue” (Sonos Opp. 3). Sonos emphasizes that in party mode and non-party mode alike, the mobile devices of host and guest user(s) and the host user's screen(s) all had and relied on their own local playback queues (Sonos Opp. 7).
True, the mobile devices of host and guest user(s) and the host user's screen(s) all had and relied on their own local playback queues. Google expressly acknowledges that the party queue was “copied to a device for the purposes of facilitating local playback” and that it did not “eliminate[] the playback queue on the playback device in favor of a cloud queue” until 2014 (Dkt. No. 561 at 1; Google Reply Br. 1). In other words, it is undisputed that the mobile devices of the host and guest user(s) stored the list of identifiers for the queue of videos selected for playback locally. But it is also undisputed that the cloud server stored the list of identifiers for the queue of videos selected for playback in the party queue (Google Br. 3 (citing Bhattacharjee Rpt. ¶¶ 171-73); Sonos Opp. 5 (citing Schmidt Rebuttal Rpt. ¶ 207); see also Schmidt Rebuttal Rpt. ¶ 204). That list was a playback queue (“a list of multimedia content selected for playback”) and that server was remote (“not local to the claimed computing device or playback device”). Putting it all together, the party queue was a list of multimedia content selected for playback that was not local to the claimed computing or playback device. The party queue was a remote playback queue. And, when playback had not yet been transferred to a screen, the mobile device in YTR2 party mode was configured for playback of a remote playback queue.
That mobile devices and screens also had local playback queues did not mean that the party queue was not a remote playback queue. The reader will recall that Google did not rule out the possibility that the YouTube Remote prior art could have employed both, which YTR2 party mode did. What we have here is the situation described by the Google expert in which “the system might store the playback queue both at the local playback device and remotely” (Bhattacharjee Showdown Rebuttal Rpt. ¶ 320). Indeed, the YouTube Remote prior art was strikingly similar to the embodiment that the prior order distinguished ('033 patent 16:16-27). This “third party application not only t[old] the local playback system what to play, but also maintain[ed] two-way communication with the local playback . . . system” (id. at 16:18-21). And “[t]wo way communication help[ed] enable features such as keeping a local playback queue synchronized with a queue that the user [was] editing/managing in the third party application” (id. at 16:21-24).
In YTR1 and YTR2 non-party mode, the queue that the user was editing/managing to which the local playback queue was synchronized was the local playback queue on the user's mobile device. There were no other users, and there was no queue saved on a cloud server. In YTR2 party mode, however, the queue that the user was editing/managing to which the local playback queue was synchronized was the remote playback queue. Only this queue, the party queue saved on the cloud server, reflected changes made by both this user and other user(s) in the party. “In short, the cloud queue r[an] the show” in YTR2 party mode as well. Google, 2022 WL 3046752, at *6.
Because YTR2 party mode disclosed a computing device that was configured for playback of a remote playback queue provided by a cloud-based computing system, the YTR2 system satisfied limitation 1.4.
E. Limitation 1.7.
The parties take up limitation 1.7 in parts, so this order will do the same.
Limitation 1.7(a) requires that the computing device, “based on receiving [] user input,” “transmit[] an instruction for the at least one given playback device to take over responsibility for playback of the remote playback queue from the computing device” ('033 patent 17:5356). Both sides agree that a mobile device running YTR2 party mode (computing device) transmitted a message (instruction) for a screen (playback device) to take over responsibility for playback once a user pressed (user input) the Connect button (Google Reply Br. 5; Sonos Opp. 9; see also Bhattacharjee Rpt. ¶ 332; Schmidt Rpt. ¶ 164). According to Google, because this computing device was configured for playback of a remote playback queue, this instruction was for taking over playback responsibility of a remote playback queue (Google Reply Br. 5). According to Sonos, however, the instruction was for taking over playback of a local playback queue, not a remote playback queue, because the playback devices were only configured for playback of a local playback queue (Sonos Opp. 8). This order has already explained why that is not the case. As such, it is apparent that a computing device running YTR2 party mode transmitted an instruction for a playback device to take over playback responsibility of a remote playback queue from a computing device.
Limitation 1.7(b) provides that the instruction to take over responsibility for playback configures the playback device to “(i) communicate with the cloud-based computing system in order to obtain data identifying a next one or more media items that are in the remote playback queue, (ii) use the obtained data to retrieve at least one media item in the remote playback queue from the cloud-based media service; and (iii) play back the retrieved at least one media item ('033 patent 17:58-65). The specification teaches that the data identifying a next one or more media items can take different forms, including “song identifier” or “URL” (id. at 12:37, 56). What's more, it specifically teaches that a URL “can be passed to a playback device to fetch content from a cloud,” and “[s]ongs and/or other multi-media can be retrieved from the Internet rather than a local device” (id. at 12:52-53, 57-58).
Recall once playback was transferred to a screen in YTR2 party mode, that screen would receive a message from the cloud server identifying one or more videos for playback. For each video, the screen would send a corresponding identifier it had stored locally to another cloud server (Player Service) to obtain a URL (Bandaid URL), which would enable it to retrieve the media content (audio and video content) corresponding to the identifier from yet another cloud server in Google's Content Delivery Network (Bandaid) for playback. YTR2 party mode disclosed limitation 7(b) because once the screen received an instruction to take over responsibility for playback, it sent a message to the Player Service to obtain a Bandaid URL that was used to retrieve media content from the Bandaid server and play back that retrieved content. As such, the playback device running YTR2 party mode was configured to “communicate with [the] cloud-based computing system” (Player Service) to “obtain data identifying a next one or more media items” (Bandaid URLs) and “use the obtained data to retrieve at least one media item in the remote playback queue” (audio and video content) to “playback the retrieved at least one media item,” as required (Google Br. 11).
Sonos disagrees that YTR2 party mode disclosed this limitation for three reasons (Sonos Opp. 8-10). None is availing.
First, Sonos argues that the identifiers (videoIds), not the URLs (Bandaid URLs), constituted “data identifying a next one or more media items that are in the remote playback queue” (Sonos Opp. 8) (emphasis in original). According to Sonos, because those identifiers were stored locally on the screen in a local playback queue in YTR2 party mode, they were not “in the remote playback queue,” as required by limitation 1.7(b). Although Sonos suggests that “the parties dispute whether ‘data identifying a next one or more media items' has to be a URL or could be another type of identifier,” both sides acknowledge that such data could be identifiers or URLs, consistent with the language in the specification (Sonos Opp. 8; Google Reply Br. 6 n.5; see '033 patent 12:37, 56). And, as discussed, devices configured for playback in YTR2 party mode had identifiers and URLs. Irrespective of whether the identifiers constituted “data identifying a next one or more media items,” the URLs clearly did.
The playback device in limitation 1.7(b) “obtain[s] data identifying a next one or more media items that are in the remote playback queue” as well as “use[s] the obtained data to retrieve at least one media item” and “play back the retrieved at least one media item.” It is undisputed that screens used URLs to retrieve and play back media content in YTR2 party mode (Schmidt Rpt. ¶ 164 (recognizing playback device “use[d] the one or more [Bandaid] URLs to retrieve the media item from one or more ‘Bandaid' servers . . . and then render[ed] [i.e., played back] the retrieved media item”); see also Schmidt Dep. 147:6-148:10; Bhattacharjee Rpt. ¶¶ 328-29).
Second, Sonos argues that limitation 1.7(b) requires that the “data identify[] a next one or more media items,” whereas “[t]he Bandaid URLs Google points to only identif[ied] the current media item for playback, not the next media item” (Sonos Opp. 9 (citing Schmidt Rebuttal Rpt. ¶¶ 176, 212)) (emphasis in original). In other words, “Google's argument thus equates the claim term ‘next' with ‘current'” when the patent specification distinguishes those terms elsewhere (Sonos Opp. 9 (citing '033 patent 16:49-67)).
Not so. The parties do not dispute that the screen in YTR2 party mode carried out the process of: (i) receiving a message from the (MDx) cloud server identifying a video for playback; (ii) sending a corresponding (videoId) identifier to another (Player Service) cloud server to receive a (Bandaid) URL; (iii) sending that (Bandaid) URL to yet another (Bandaid) cloud server to retrieve media (audio and video) content; (iv) and playing back that media content (Google Br. 11; Sonos Opp. 9). Nor do they dispute that this happened for each video in the party queue (ibid.; see also Schmidt Rpt. ¶ 164; Bhattacharjee Rpt. ¶ 328). Thus, the screen clearly “communicate[d] with the cloud-based computing system in order to obtain data identifying a next one or more media items that are in the remote playback queue.” That there might have only been one video in that queue is accounted for when the limitation describes “us[ing] the obtained data to retrieve at least one media item” and “play[ing] back the retrieved at least one media item.” Read in context, “next” must include - but is not limited to - “current” here.
Third, Sonos argues that in YTR2 party mode, the screen did not “obtain data identifying a next one or more items that are in the remote playback queue” because it played items from its local playback queue (Sonos Opp. 9-10) (emphasis in original). After all, according to Sonos, “[s]creens in YTR[2] party mode d[id] not ‘ask[] the MDx [cloud] server for which video to play next when the current [video] ended'” and they instead “simply play[ed] the next video in their local playback queue” (ibid.).
But, as Google notes, limitation 1.7(b) does not require the playback device to “fetch ‘data identifying . . . media items' directly ‘from [the] remote playback queue'” (Google Reply Br. 7 (quoting Sonos Opp. 9-10)). Rather, it requires that the playback device “obtain[] data identifying a next one or more media items that are in the remote playback queue,” and “use[] the obtained data to retrieve” and “play back the retrieved at least one media item.” That is what the screen in YTR2 party mode did. It received a message from the (MDx) cloud server identifying a video for playback before it sent the corresponding identifier to the Player Service and the corresponding URL to the Bandaid server. In sum, YTR2 party mode tracked limitation 1.7.
F. Limitations 1.8-1.9.
Limitation 1.8 requires that the computing device “detect[] an indication that playback responsibility for the remote playback queue has been successfully transferred from the computing device to the at least one given playback device” ('033 patent 17:66-18:2). Limitation 1.9 requires that, after detecting this indication, the computing device “control the at least one given playback device's playback of the remote playback queue” and is itself “no longer configured for playback of the remote playback queue” (id. at 18:3-10). According to Google, the YTR2 system disclosed these limitations because the application displayed a “Connected to [] screen” dialogue box once a host or guest user transferred playback to a screen, as demonstrated in the video from Google's invalidity contentions showing how the YouTube Remote application worked (Google Br. 13). Sonos does not address these limitations in its opposition and did not address them at the hearing, so this order incorporates its general argument that the YTR2 system used a local playback queue, not a remote playback queue, which it already rejected.
Citing https://www.youtube.com/watch?v=EGdsOslqG2s (last visited April 11, 2023).
This order observes that the video discussed by Google was uploaded on November 14, 2010 - shortly after the release of YTR1 on November 9, 2010, and well-before the release of YTR2.03 on July 29, 2011. Even so, there is no evidence on this record that this dialogue box was removed or changed in YTR2. To the contrary, Google's arguments at the patent showdown appear to have relied on both YTR1 and YTR2 systems, just without discussing party mode (Bhattacharjee Showdown Rpt. ¶¶ 169-71). This order therefore agrees with Google that the dialogue box demonstrated that the mobile device in the YTR2 system detected an indication playback responsibility had been successfully transferred, that it was configured to control a screen's playback of a remote playback queue, and that it was itself no longer configured for playback of a remote playback queue. As such, the YTR2 system satisfied limitations 1.8 and 1.9.
G. Limitations 1.5-1.6.
Having found that the YTR2 system disclosed all of the “remote playback queue” limitations, this order turns to the “selection of playback devices” limitations allegedly taught by the '998 patent.
Limitation 1.5 requires that the computing device “display[] a representation of one or more playback devices in a media playback system” available to accept playback responsibility for the remote playback queue ('033 patent 17:43-48). Limitation 1.6 requires that the computing device “receiv[e] user input indicating a selection of at least one given playback device from the one or more playback devices” (id. at 17:49-52). As Google observes, the prior order addressed a very similar limitation in claim 13 of the '615 patent, which required the computing device to “display[] . . . playback devices connected to the local area network” and receive user input indicating “a selection of [a] particular playback device from the identified playback devices” (Google Br. 14). Google, 2022 WL 3046752, at *9-10 (citing '998 patent 10:62-11:6). It found the YouTube Remote prior art's Connect button did not allow a user to select a subset of available playback devices, but the '998 patent disclosed the device-picker and taught the selection of playback devices, as contemplated by the '615 patent. Absent countervailing evidence, that Google produced YouTube Remote application source code incorporating the device-picker (December 1, 2011,) mere months after Sonos's claimed priority date for the '615 patent (July 15, 2011,) and released the functionality to the public with YTR3 (January 2012) clearly and convincingly demonstrated that a person of ordinary skill in the art would have been motivated to incorporate the teachings of the '998 patent. Her reasonable expectation of success was also self-evident. Accordingly, the prior order concluded that it would have been obvious to combine the prior art references and invalidated the asserted claim of the '615 patent.
Sonos raises no new evidence that demands a different outcome here. It did not address these limitations in its opposition, but it included language from its expert's rebuttal report on this point in its slides for the hearing. The only new argument is that “there would be no need to use a device-picker to select a particular [screen] for playback” in YTR2 party mode “when the desire [was] to have multiple [screens] for playback” (Schmidt Rebuttal Rpt. ¶ 351). It does not persuade. Even in party mode, a user might have considered it desirable to play back media on some screens (e.g., in the living room and kitchen) and not others (e.g., in the den). No evidence on this record suggests otherwise.
The '998 patent taught the selection of playback devices, as contemplated by limitations 1.5 and 1.6. That Google produced YouTube Remote application source code achieving the proposed modification roughly one month before Sonos's claimed priority date for the '033 patent (December 30, 2011,) clearly and convincingly demonstrates that a person of ordinary skill in art would have been motivated to incorporate the teachings of the '998 patent and would have had a reasonable expectation of success in doing so. Indeed, as Google observes, motivation and reasonable expectation of success are even stronger for the '033 patent, with Sonos having claimed an earlier priority date (July 15, 2011,) for the '615 patent (Google Br. 14 n.3).
Accordingly, this order finds the YTR2 system, combined with the '998 patent, rendered claim 1 of the '033 patent obvious.
H. Remaining Independent and Dependent Claims.
Having found claim 1 invalid as obvious, this order considers the remaining asserted claims of the '033 patent. Because claim 12 of the '033 patent is nearly identical to claim 1, just directed to a computer-readable medium instead of a computing device, this order finds that independent claim obvious over the YTR2 system and the '998 patent as well. The same logic applies to dependent claims 2, 9, 11, 13, and 16, for which Sonos simply incorporates its validity arguments for the independent claims (Bhattacharjee Rpt. ¶¶ 338-61).
As Google observes, the only dependent claim for which Sonos raises additional argument is claim 4, though this argument was not briefed by Sonos in its opposition (Google Br. 14). Claim 4 of the '033 patent recites that the representation of one or more playback devices in limitation 1.5 is for a “group of playback devices . . . that are to be configured for synchronous playback” ('033 patent 18:23-32). But this order agrees with Google's expert that “[b]ecause the YTR system already disclosed the ability to detect, display and transfer playback to multiple devices, allowing multiple devices to be represented by a single icon (rather than two separate icons) would have been an obvious design choice requiring only minor modification to the user interface display” based on the device-picker disclosed in the '998 patent and absent evidence to the contrary (Bhattacharjee Rpt. ¶ 646).
In sum, this order concludes that YTR2 party mode disclosed a remote playback queue, and it would have been obvious to combine the YTR2 system and the '998 patent to achieve the claimed invention. Google's motion as to the invalidity of the asserted claims of the '033 patent is GRANTED.
2. Google'S Motion: Invalidity of the '885 and '966 Patents.
Now we turn from casting to “zone scene management” and the '885 and '966 patents. Once more, our analysis starts with our analysis of the '885 patent at the patent showdown. Google LLC v. Sonos, Inc., 2022 WL 2870527 (N.D. Cal. July 21, 2022). The '885 and '966 patents have identical specifications. Both are directed toward a “method and apparatus for controlling or manipulating a plurality of multimedia players in a multi-zone system” ('885 and '966 patents 1:32-34). The asserted claims teach a user to customize and save multiple groups of smart speakers or other players, each according to a “theme or scene,” and then “activate” a customized group, called a “zone scene,” on demand (id. at 2:46-51).
Once more, this order refers the reader to the prior order for an in-depth introduction to the underlying technology and the accused products. By way of review, in a multi-zone system, a “player” is a speaker, television, or similar device that can play content. The patents refer to the player's location, such as a bedroom, as a “zone,” and the player therein as a “zone player” (see, e.g., Id. at 2:36-41; 3:13-23). According to the specifications, prior to 2006, it was difficult for users to dynamically control speaker groups. Audio sources were “hardwired” or “controlled by a pre-configured and pre-programmed controller,” which ostensibly made it cumbersome to “dynamically manag[e] the ad hoc creation and deletion of groups,” particularly when desired groups overlapped (id. at 1:62-2:2:25). Put another way, someone who enjoyed “listen[ing] to broadcast news from his/her favorite radio station in a bedroom, a bathroom, and a den while preparing to go to work in the morning” but also preferred to “listen in the den and the living room to music . . . in the evening” would not have been able to easily configure a traditional audio system to accommodate those preferences on account of then-existing technological and physical hurdles (ibid.).
The '885 and '966 patents ostensibly solved this problem by providing a “mechanism” to “allow a user to group” multimedia players “according to a theme or scene, where each of the players is located in a zone” (id. at 2:36-41). Then, “[w]hen the scene [was] activated, the players in the scene react[ed] in a synchronized manner” (id. at 2:41-42). This allowed a user to customize and save multiple groups of speakers or other players, each according to a “theme or scene,” and then later “activate” a customized group, called a “zone scene,” on demand (id. at 2:46-51). Thus, the person who enjoyed listening to broadcast news in the morning could form a “zone scene” called “Morning” that consisted of speakers in the bedroom, bathroom, and den, and activate that group on demand using an application on the controller device (e.g., a phone). And, that same person, who also enjoyed listening to music in the evening, could form and activate on demand another “zone scene” called “Evening” that consisted of speakers in the den and living room.
The prior order ruled that Google infringed claim 1 of the '885 patent. Specifically, assuming arguendo that Google's definition of zone scene as “a previously saved grouping of zone players according to a common theme” was correct, that order found Google's accused products infringed claim 1 because a user's ability to name speaker groups meant a user could group speakers according to a common theme. Google, 2022 WL 2870527, at *4. It also rejected two invalidity arguments: that claim 1 of the '885 patent was directed toward unpatentable subject matter, and that the '885 patent lacked written description support. Id. at *6-9. This order evaluates a different invalidity argument: that the asserted claim of the '885 patent (and, by extension, the asserted claims of the '966 patent,) are invalid as obvious over prior art.
After rejecting Google's invalidity arguments, the undersigned ordered Google to show cause as to why summary judgment in favor of Sonos on validity should not be entered (Dkt. No. 339). Another order declined to consider the new invalidity argument Google raised in response and entered summary judgment in favor of Sonos on validity of claim 1 of the '885 patent (Dkt. No. 382). Google then moved for reconsideration based on Mikkelsen Graphic Engineering, Inc. v. Zund America, Inc., 541 Fed.Appx. 964 (Fed. Cir. 2013). Upon reconsideration, a subsequent order agreed that Mikkelsen “caution[ed] against entering summary judgment against non-movants in like circumstances” and withdrew the ruling on validity (Dkt. No. 539). Google now raises that new argument as a movant.
A. Overview of Asserted Claims.
Sonos asserts claim 1 of the '885 patent and claims 1-2, 4, 6, 8-10, 12, 14, and 16 of the '966 patent. Claim 1 of the '885 patent and claims 1 and 9 of the '966 patent are independent claims, whereas claims 2, 4, 6, 8, 10, 12, 14, and 16 of the '966 patent are dependent claims. Note the '966 patent is drafted from the perspective of the controller device that controls zone players and makes groups (e.g., a phone), whereas the '885 patent is drafted from the perspective of a zone player itself (e.g., a speaker). Sonos filed the applications that led to the '885 and '966 patents on April 12, 2019, but the applications claim priority through a long chain of continuation applications dating back to a provisional application filed on September 12, 2006. Sonos claims an earlier conception date of December 2005.
Like the briefing and the parties at the hearing, this order focuses on claim 1 of the '885 patent. Using Google's paragraph numbering, claim 1 of the '885 patent recites:
[1.0] A first zone player comprising:
[1.1] a network interface that is configured to communicatively couple the first zone player to at least one data network;
[1.2] one or more processors;
[1.3] a non-transitory computer-readable medium; and
[1.4] program instructions stored on the non-transitory computer-readable medium that, when executed by the one or more processors, cause the first zone player to perform functions comprising:
[1.5] while operating in a standalone mode in which the first zone player is configured to play back media individually in a networked media playback system comprising the first zone player and at least two other zone players:
[1.6] (i) receiving, from a network device over a data network, a first indication that the first zone player has been added to a first zone scene comprising a first predefined grouping of zone players including at least the first zone player and a second zone player that are to be configured for synchronous playback of media when the first zone scene is invoked; and
[1.7] (ii) receiving, from the network device over the data network, a second indication that the first zone player has been added to a second zone scene comprising a second predefined grouping of zone players including at least the first zone player and a third zone player that are to be configured for synchronous playback of media when the second zone scene is invoked, wherein the second zone player is different than the third zone player;
[1.8] after receiving the first and second indications, continuing to operate in the standalone mode until a given one of the first and second zone scenes has been selected for invocation;
[1.9] after the given one of the first and second zone scenes has been selected for invocation, receiving, from the network device over the data network, an instruction to operate in accordance with a given one of the first and second zone scenes respectively comprising a given one of the first and second predefined groupings of zone players; and [1.10] based on the instruction, transitioning from operating in the standalone mode to operating in accordance with the given one of the first and second predefined groupings of zone players such that the first zone player is configured to coordinate with at least one other zone player in the given one of the first and second predefined groupings of zone players over a data network in order to output media in synchrony with output of media by the at least one other zone player in the given one of the first and second predefined groupings of zone players.('885 patent 11:37-12:23). “Zone scene,” in play here, is italicized above. Google asserts that claim 1 of the '885 patent and all asserted claims of the '966 patent are invalid as obvious over two prior art references: Sonos's prior art speaker system from 2005 and “modifications suggested to Sonos by users of that system” in customer posts on Sonos online forums (Google Br. 15). Sonos disagrees and contends that the prior art did not disclose zone scene technology as required by limitations 1.5-1.10 and the corresponding limitations of the '966 patent (Sonos Opp. 10-19; Dkt. No. 468-7 at 41-43, 85-88).
B. Overview of Prior Art.
As for prior art, the Sonos 2005 system was the initial version of Sonos's wireless multizone system. It launched no later than January 2005, well before both Sonos's claimed conception date of December 2005 and the provisional filing date of September 12, 2006 (see Almeroth Rebuttal Rpt. ¶ 265). The parties agree that the Sonos 2005 system disclosed “smart” speakers that could be grouped for synchronous playback, and they generally agree on how that grouping worked (Google Br. 16 (citing Almeroth Rebuttal Rpt. ¶ 266); Sonos Opp. 11 (citing Millington Decl. ¶ 5)). In essence, speakers in the Sonos 2005 system could be added to a temporary group individually, and that temporary group would be activated for playback immediately. Once a user no longer wished to use that temporary group for playback, it ceased to exist. The only saved group was (yet another) “party mode,” which allowed a user to immediately commence synchronous playback of a group of all speakers in her system (Schonfeld Rpt. ¶¶ 107, 114; Millington Decl. ¶ 7).
Although the parties dispute the extent to which the Sonos 2005 system disclosed the zone scene requirements of the asserted limitations, they generally agree that this system did not allow for speaker groups that could be named, saved, and later activated on-demand (Google Br. 15-16 (citing Schonfeld Reply Br. 1 ¶ 18; Dkt. No. 484-8 (Lambourn Emails)); Sonos Opp. 11-12 (citing Lambourn Decl. ¶¶ 8-11)).
This is where the forum posts come in. According to Google, “[t]o the extent not disclosed in the Sonos 2005 prior art system itself, customer comments on the Sonos forums disclose[d] the ‘zone scene' elements of claim 1 of the '885 patent” (Google Br. 18). It focuses on two illustrative posts from two threads on those forums:
In the first [thread], “Virtual Zones and Zone Grouping,” “theboyg” stated that the way the Sonos 2005 system permitted users to create groups - by linking and unlinking speakers in real time - was “cumbersome.” He suggested adding to the prior art system “a virtual zone - ie a zone called ‘Downstairs' that would allow a user to ‘group all [his] downstairs zones' and avoid the necessity to ‘keep manually linking and unlinking multiple zones everytime'” ....
The second relevant Sonos forum thread is titled “Macro/Presets.” In that thread, “JeffT” suggested that the Sonos 2005 system “save Zone links [i.e., speakers linked into a group] as favorites” so that, for example, he could set up “2 party modes, Summer and Winter,” where the “Summer mode” would include “the deck speakers and the Winter mode would not.”(Google Br. 16-17). Again, the forum posts of “theboyg” and “JeffT” were created and publicly available prior to both Sonos's claimed conception date, December 2005, and the provisional filing date, September 12, 2006. For reference, this order reproduces the posts below:
(Image Omitted)
Just got the Intro bundle, and I am impressed I did a search and did not find this suggested, but I would save Zone inks as favorites With only 2 ZPs it is not a problem yet but when I add more it maybe. I would ike to setup say Morrwig mode for the units I want in the morning and a preset volume between the units Another example I would have 2 party modes. Summer and Winter The Simmer mode would include the deck speakers and the Winter mode would not. Also it would be nice to have playlists or radio station associated with each mode So when I get up I press Morning the DI Chill radio station plays.(Google Br. 16-17). Did the Sonos 2005 system and the forum posts together render obvious the “zone scene” limitations? This order finds that genuine disputes of material fact preclude summary judgment of invalidity for obviousness over these two references.
C. Limitation 1.7.
By way of example, consider limitation 1.7. It recites a “zone player” that “receiv[es] . . . an indication that [it] has been added to a second zone scene comprising a second predefined grouping of zone players” ('885 patent 11:59-67). Note this second zone scene is different than the first zone scene to which the zone player is added in limitation 1.6 because it does not include at least one zone player in that first zone scene (id. at 11:53-58, 61-67).
Clearly limitation 1.7 was not satisfied by the Sonos 2005 system. A speaker in that system could not be added to two different predefined groupings of zone players. Even assuming arguendo that the party mode grouping of all speakers was a zone scene, a speaker could not be added to a second zone scene because no other groupings could be predefined. In other words, the Sonos 2005 system did not provide for saving additional, overlapping groups.
Google argues that the forum posts fill this gap. It emphasizes that “JeffT” expressly suggested adding functionality to include, inter alia, “2 party modes, Summer and Winter,” where the Summer mode “would include the deck speakers and the Winter mode would not” (Google. Br. 19 (citing Almeroth Rebuttal Rpt. ¶ 192)). Mapping the forum post onto the language of limitation 1.7, it discloses a “zone player” that is “added to a second zone scene [Winter mode] comprising a second predefined grouping of zone players” (that is different than the first zone scene because Summer mode does not include the deck speakers). Although Sonos does not directly dispute that this forum post disclosed saving additional, overlapping groups, it takes issue with the fact that the forum post did not disclose the “indication,” the “claimed communications between the zone players and controllers necessary for setting up and invoking zone scenes,” among other specific terms in other specific limitations (Sonos Opp. 13-14). Yet such rigid adherence to the language of the claims is not required to show obviousness. Indeed, the Supreme Court has expressly cautioned against a “narrow conception of the obviousness inquiry” in favor of “an expansive and flexible approach.” KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 402, 415 (2007).
But Google is not out of the woods yet. After all, “[a] party seeking to invalidate a patent based on obviousness must demonstrate by clear and convincing evidence that a skilled artisan would have been motivated to combine the teachings of the prior art references to achieve the claimed invention, and that the skilled artisan would have had a reasonable expectation of success in doing so.” Procter & Gamble, 566 F.3d at 994. The Federal Circuit has recently emphasized the “clear distinction in [its] case law between a patent challenger's burden to prove that a skilled artisan would have been motivated to combine prior art references and the additional requirement that the patent challenger also prove that the skilled artisan would have had a reasonable expectation of successfully achieving the claimed invention from the combination.” Eli Lilly & Co. v. Teva Pharms. Int'l GmbH, 8 F.4th 1331, 1344 (Fed. Cir. 2021). In other words, these are separate requirements. A finding that an alleged infringer has demonstrated a motivation to combine prior art references does not necessarily mean that the alleged infringer has also demonstrated a reasonable expectation of success in achieving the claimed invention by doing so. Ibid.
According to Google, “[b]ecause the Sonos forum posts expressly discuss modifying the Sonos 2005 system, there is a clear motivation to combine the prior art system and the users' suggested modifications to that system” (Google Br. 18). As Sonos observes, however, Google makes an analytical leap here, assuming that the existence of forum posts expressing motivation to combine prior art references means that a person of ordinary skill in the art would have had motivation to combine prior art references (Sonos Opp. 15). Worse, Google fails to address whether that person of ordinary skill in the art would have had a reasonable expectation of success in achieving the claimed invention. Indeed, it does not speak to reasonable expectation of success at all, even after Sonos pointed this out in its opposition (ibid.). Google has failed to meet its burden.
Recall, Sonos filed its provisional patent application directed to zone scene technology on September 12, 2006, and claims an earlier conception date of December 2005. The Sonos 2005 system was launched no later than January 2005 (Google Br. 16 (citing Almeroth Rebuttal Rpt. ¶ 265)). Users “theboyg” and “JeffT” weighed in later that year, on February 27, 2005, and September 22, 2005, respectively (Google Br. 16-17 (citing Almeroth Rebuttal Rpt. ¶ 193)). So did Sonos engineer Robert Lambourn, inventor of the '885 and '966 patents and Sonos's director of user experience design at the time. He sent an email to a colleague on April 11, 2005, suggesting two new approaches to grouping speakers, one of which “would allow a user with one click to put their Zones into predefined groups,” like “downstairs,” “upstairs,” and “morning” (Lambourn Emails at 1). Lambourn then “began to design and develop [the] new technology” (Lambourn Decl. ¶ 13). But Sonos did not file the application that led to the '885 and '966 patents until April 12, 2019, and it did not release the zone scenes feature (as “room groups”) until 2020. What's more, Sonos points to a dozen articles from the likes of CNN and Engadget praising the introduction of this feature upon release (Sonos Opp. 19 (citing Almeroth Rebuttal Rpt. ¶¶ 1613-40)).
The Federal Circuit has “consistently pronounced that all evidence pertaining to the objective indicia of nonobviousness must be considered before reaching an obviousness conclusion.” Plantronics, Inc. v. Aliph, Inc., 724 F.3d 1343, 1355 (Fed. Cir. 2013). And “[s]econdary considerations evidence can establish that an invention appearing to have been obvious in light of the prior art was not and may be the most probative and cogent evidence in the record.” Apple Inc. v. Int'l Trade Comm'n, 725 F.3d 1356, 1366 (Fed. Cir. 2013). Here, a reasonable jury could find that the gap in time and substantial praise demonstrate a person of ordinary skill in the art would not have had a reasonable expectation of success in achieving the claimed invention - even assuming that person would have been motivated to combine the teachings of the Sonos 2005 system with those of “theboyg” and “JeffT.” Google will have to make its best case in front of a jury. A genuine dispute of material fact remains that precludes finding the asserted claim of the '885 patent invalid.
Google focuses its analysis on the '885 patent but attaches a “comprehensive chart identifying how the prior art that renders obvious the asserted claim of the '885 patent also renders obvious the asserted claims of the '966 patent” (Google Br. 20). Because this order has not found that prior art renders obvious the asserted claim of the '885 patent, it declines to reach the asserted claims of the '966 patent (or the acceptability of this chart). Google's motion as to the invalidity of the asserted claims of the '885 and '966 patents is DENIED.
3. Google'S Motion: No Willful or Indirect Infringement.
Next, this order considers willful and indirect infringement. Google moves for summary judgment of no willful or indirect infringement of the '033, '885, and '966 patents. Because this order finds the asserted claims of the '033 patent invalid, it only considers this motion as to the '885 and '966 patents. Google's motion as to the '033 patent is DENIED AS MOOT.
According to Google, Sonos is no closer to providing evidence that Google had the required “knowledge of the patent,” “knowledge of infringement,” and “specific intent to infringe at the time of the challenged conduct” than it was when an order dismissed Sonos's claims for willful and indirect infringement last March (Google Br. 24). See Sonos, 591 F.Supp.3d at 643. As Google recognizes, however, a subsequent order allowed Sonos amend its pleadings in light of the “special twist” in this case: Google had commenced its own declaratory judgment action before Sonos filed its affirmative infringement action (Google Br. 24 (quoting Sonos, 591 F.Supp.3d at 647)). Sonos argues that there remains a genuine dispute of material fact as to whether Google was at least willfully blind to its infringement.
Upon review, this order agrees with Sonos with respect to the '966 patent, which was asserted in Sonos's original complaint. Knowledge of infringement and specific intent may be inferred from circumstantial evidence. Warsaw Orthopedic, Inc. v. NuVasive, Inc., 824 F.3d 1344, 1347 (Fed. Cir. 2016) (citing Glob.-Tech Appliances, Inc. v. SEB S.A., 563 U.S. 754, 770-71 (2011)). Google had enough notice of this patent to file its own complaint for declaratory relief based on non-infringement and invalidity, and that would go a long way in supplying the knowledge and intent necessary for willful and indirect infringement - or so a jury could reasonably find based on the evidence in this record.
Such reasoning, however, has no bearing on the '885 patent, which issued roughly two months after all of this litigation began and was subsequently added. The undersigned previously allowed Sonos to amend its complaint to plead willful and indirect infringement of this patent as well based in large part on the “forty-day notice” between when Sonos allegedly provided Google a draft of its amended complaint during a meet-and-confer and when Sonos allegedly filed that amended complaint. Sonos, Inc. v. Google LLC, 2022 WL 2046828, at *3 (N.D. Cal. June 7, 2022). As pointed out by Google in its present motion, however, Sonos actually filed that amended complaint with its motion to amend a mere three days after the meet-and-confer (Google Reply Br. 15 (citing No. C 21-07559 WHA, Dkt. No. 39-1)). With that in mind - and without a showing of countervailing support drawing upon the more complete record - it can no longer be said that Google had a meaningful opportunity to investigate allegations of infringement of the '885 patent with the notice provided.
Because a genuine dispute of material fact remains as to whether Google committed willful or indirect infringement of the '966 patent, Google's motion as to willful and indirect infringement of the '966 patent is DENIED. Because Google has shown that there are no genuine disputes of material fact as to whether it committed willful or indirect infringement of the '885 patent, however, Google's motion as to willful and indirect infringement of the '885 patent is GRANTED.
4. Sonos'S Motion: Breach of Contract and Conversion.
This order now turns to Sonos's motion for summary judgment on Google's claims of breach of contract and conversion, which derive from a 2013 collaboration agreement between the parties (SAC ¶¶ 85-97). According to Google, Sonos claimed as its own Google's intellectual property rights arising from Google's development work in integrating Google Play Music with Sonos speakers, even though their agreement gave Google intellectual property rights “‘arising from or related' to ‘any and all development work done by or on behalf of Google in creating the integrated offering'” (Google Opp. 1 (quoting Dkt. No. 479-4 § 3.4)). According to Sonos, however, it invented the “direct control” technology underlying that development work in 2011 when it filed the application (specification only) that led to the '033 patent, and Sonos never assigned intellectual property rights ostensibly arising from that application to Google in the 2013 agreement (Sonos Br. 1, 10-15). Sonos further argues that even if such development work was Google's intellectual property under the 2013 agreement - and Sonos would have breached that agreement and committed conversion when it filed the claims for the '033 patent in 2019 - the 2013 agreement had by then been superseded by another agreement such that there could be no breach (Sonos Br. 2, 15-16).
Google offered to “withdraw [these] claims without prejudice” to “streamline the issues for summary judgment and trial” if this order decided the asserted claims of the '033 patent are invalid, which it has (Dkt. No. 552). This order finds Google's suggested resolution appropriate to keep trial focused on what has always been the fulcrum of this dispute: patent infringement and associated defenses. Sonos's motion for summary judgment is therefore DENIED AS MOOT, with the understanding that the breach of contract and conversion claims are out of the case.
5. Google'S Motion: Non-Infringement of the '885 and '966 Patents Based on Purported Design-Around.
Lastly, this order circles back to Google's motion. After the prior order granted summary judgment of infringement of claim 1 of the '885 patent, Google apparently began changing its products and introducing a redesigned speaker that it disclosed to Sonos during discovery (Google Br. 20). Google contends that its redesigned speaker no longer infringes the asserted claim of the '885 patent - and cannot infringe the asserted claims of the '966 patent - because the redesigned speaker no longer operates in “standalone mode” after it is added to a new speaker group before that group is invoked (Google Br. 22). In brief, a speaker operating in standalone mode “is configured to playback media individually,” and Google has added a new function to its source code (“StopCurrentApp()”) that requires a redesigned speaker to stop playback before being added to a group ('885 patent 11:47-48; Google Br. 22). Sonos counters that the redesigned speaker continues to operate in standalone mode even under such circumstances and thereby continues to infringe the asserted claims of the '885 and '966 patents (Sonos Opp. 21, 23).
This order will not allow Google to cut to the front of the line in order to vet its purported design-around when so many questions of fact (and law) involving the original accused products remain. Experience teaches that the evaluation of redesigned products is aided by analysis of the main issues at trial, which will include the original speakers' infringement of the asserted claims of the '966 patent. Google will have to wait its turn. The redesigned speaker will be vetted in due course. Google's motion as to non-infringement of the asserted claims of the '885 and '966 patents based on its purported design-around is DEFERRED.
CONCLUSION
For the foregoing reasons, Google's motion for summary judgment is GRANTED IN PART, DENIED IN PART, and DEFERRED IN PART. Specifically, Google's motion as to invalidity of the '033 patent and no willful or indirect infringement of the '885 patent is GRANTED. Google's motion as to invalidity of the '885 and '966 patents, and no willful or indirect infringement of the '966 patent is DENIED, whereas Google's motion as to no willful or indirect infringement of the '033 patent is DENIED AS MOOT. Google's motion as to non-infringement of the '885 and '966 patents based on a purported design-around is DEFERRED. Meanwhile, Sonos's motion for summary judgment as to Google's breach of contract and conversion claims is DENIED AS MOOT.
The issues now set for trial are: (i) Sonos's claim for infringement (direct, willful, and indirect) of the asserted claims of the '966 patent; (ii) Google's counterclaim for non-infringement of the asserted claims of the '966 patent; (iii) Google's counterclaims for invalidity of the asserted claims of the '885 and '966 patents; (iv) damages for infringement of the asserted claim of the '885 patent; and (v) any and all remaining issues in the entire case, except the undersigned will consider Google's purported design-around in a bench trial after the rest of the issues are tried before the jury.
This order hereby CONSOLIDATES this action and the related affirmative infringement action (No. C 21-07559 WHA) for the purpose of taking them to trial. If the parties object, they are ordered to show cause by TUESDAY, APRIL 18, 2023, at 5:00 P.M.
IT IS SO ORDERED.