`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`______________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________________________________
`
`
`
`GOOGLE LLC,
`
`Petitioner
`
`v.
`
`WAG ACQUISITION, LLC
`
`Patent Owner
`
`U.S. Pat. No. 9,762,636
`
`
`
`_______________________________________
`
`Inter Partes Review Case No. IPR2022-01413
`
`_______________________________________
`
`
`
`PATENT OWNER’S SUR-REPLY
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`TABLE OF CONTENTS
`
`
`
`INTRODUCTION ..................................................................................................... 1
`
`CLAIM CONSTRUCTION ....................................................................................... 3
`
`A. Preambles .......................................................................................................... 3
`
`B. “Requests” Limitations ..................................................................................... 4
`
`C. “Data Rate of the Data Connection” Limitation ............................................... 6
`
`D. “Without Depending on the Server System Maintaining a Record” Limitation
`
`8
`
`CARMEL GROUNDS (1-4) ...................................................................................... 8
`
`A. Alleged Carmel Disclosure of “Client Control” ............................................... 8
`
`1. Carmel’s alleged “express disclosure” Contention that Carmel discloses
`“Pull” ................................................................................................................10
`
`B. Google’s Arguments as to Specific Limitations .............................................20
`
`1.
`
`2.
`
`“Supplying” Limitation ............................................................................20
`
`“Requests” Limitations ............................................................................21
`
`3. Connection Data Rate Limitation ............................................................22
`
`4. Dependency on record of the last media data element sent .....................25
`
`C. Grounds 2 and 3 ..............................................................................................25
`
`CONCLUSION ........................................................................................................26
`
`
`
`
`
`
`
`
`
`
`
`–ii–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`LIST OF PATENT OWNER’S EXHIBITS
`
`Exhibit
`
`Description
`
`2001
`
`WAG Acquisition, LLC v. WebPower, Inc., 781 F. App’x 1007
`(Fed. Cir. 2019)
`
`2002
`
`Declaration of W. Leo Hoarty
`
`2003
`
`Declaration of Henry Houh (Ex. 1002 of IPR2022-01228)
`
`2004
`
`May 23, 2023, Deposition of Dr. Kevin Jeffay
`
`2005
`
`IETF RFC 2068
`
`2006
`
`May 25, 2023, Deposition of Dr. Nathaniel Polish
`
`2007
`
`2008
`
`2009
`
`2010
`
`2011
`
`Declaration of Dr. Nathaniel Polish, Emblaze Ltd. v. Apple Inc.,
`case no. 11-CV-01079 (N.D. Ca. Feb. 14, 2014)
`
`In re Certain Fitness Devices, Streaming Components Thereof,
`and System Containing Same, Inv. No. 337-TA-1265, Initial
`Determination (ITC, Sept. 9, 2022) (CALJ Clark S. Cheney)
`
`In re Certain Fitness Devices, Streaming Components Thereof,
`and System Containing Same, Inv. No. 337-TA-1265, Evidentiary
`Hearing – Volume III (ITC, March 14, 2022)
`
`Final Written Decision, WebPower v. WAG Acquisition, LLC,
`IPR2016-01238, Paper No. 22 (Dec. 26, 2017)
`
`Final Written Decision on Remand, WebPower v. WAG
`Acquisition, LLC, IPR2016-01238, Paper No. 28 (July 16, 2020)
`
`2012
`
`Microsoft Computer Dictionary, Fifth ed. (excerpts)
`
`2013
`
`Redline comparison of claims of ’824 and ’636 patents
`
`2014
`
`Claim term concordance table
`
`2015
`
`IETF RFC 1945
`
`2016
`
`October 4, 2023, Deposition of Dr. Nathaniel Polish
`
`–iii–
`
`
`
`
`
`
`INTRODUCTION
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`Goggle’s Reply (as did the Petition) focuses nearly entirely on Carmel. The
`
`evidence reflects that Carmel works by a different mechanism than asserted by
`
`Google. The facts are inconsistent with Google’s theories throughout (including
`
`improper new theories as well as the original theories).
`
`Pivoting, Google now seeks to turn Carmel on its head. Google refers several
`
`times to language near the end of Carmel referencing upload from source computer
`
`34 to server 36, stating “similar methods are applicable, mutatis mutandis, to the
`
`method of downloading the files from server 36 to clients 30, as shown in FIG.
`
`6A.” EX1003-13:32-35. Google, at Reply-10-11, relies on its expert, EX2011
`
`¶¶ 74-78, pointing to source computer 34’s control of slices it puts on respective
`
`links for upload to server 36 and seeking to project those operations onto the
`
`download process. But this clearly cuts against Google. In fact, it was Patent
`
`Owner’s argument (POR-56) that server 36, in its transmissions to clients 30, was
`
`doing the same thing—what source 34 did via ftp (concededly a push), server 36
`
`did relative to client 30 (i.e., a push).
`
`At Reply 24, however, Google takes this further, with an entirely new theory,
`
`which not only projects the source 34-server 36 interaction “mutatis mutandis”
`
`onto the server 36-client 30 interaction, but further, based on no written disclosure
`
`anywhere, reverses the interaction as well, imagining it as a client 30-server 36
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`interaction, with the client now in control. But this is still not even an attempt to
`
`explain how a disclosed continuous push transmission of successive elements can
`
`be transformed into individually “as required” requests to send identified elements.
`
`The Board cannot adopt an interpretation of the prior art based on such inversions
`
`and then reinversions of the evidence, which fail to complete the required
`
`connections between the elements.
`
`(Reply-2) Google’s Reply tellingly leads not on the merits but rather by
`
`appealing to a prior decision addressing different claim terms. Neither the Petition
`
`nor the Reply use the words “collateral estoppel” (and it isn’t). The prior decision
`
`is also not evidence. The Board must base its decision on the evidence in this case.
`
`(Reply-2, “Client-side control”) The Petition did not invoke “client-side
`
`control” and did not mention the Federal Circuit decision referenced here. Yet
`
`Google’s mantra throughout its Reply is that “Carmel emphasizes client-control.”
`
`Carmel does not use the words “client-side control,” and what the client does
`
`control in Carmel is limited to bulk interactions, such as where streaming begins,
`
`the number of links to the server, and compression levels. Google would imply
`
`from this that Carmel also discloses individual element requests, but this does not
`
`follow. The words “client-side control” are being used by Goole to gloss over lack
`
`of actual evidence for individual element requests.
`
`–2–
`
`
`
`
`
`
`CLAIM CONSTRUCTION
`
`A.
`
`Preambles
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`(Reply-3-4, addressing Patent Owner’s argument that additional
`
`limitations make clear that the preambles and claims address a continuous
`
`process that continues for the duration of playback) Google’s arguments
`
`concerning the preambles, and indeed each of the claims as a whole, falter when
`
`viewed together with limitations that apply by their terms to “all” of the media data
`
`elements or “each” sending. In view of the preamble’s reference to a method (or
`
`system, or recorded medium) “for distributing a live audio or video program,” and
`
`in view of the specification’s disclosure that the user computer “continues with
`
`additional data requests for the duration of playing the audio/video material”—and
`
`that these are the same “requests” referenced in the claim as being correspondingly
`
`received by the server over the same duration—it is clear that the claim addresses a
`
`process structured to be sustainable over the duration of the corresponding client’s
`
`playback, and that the server must therefore be implemented so that the limitations
`
`will be met for a transmission of that duration.
`
`Google argues that the fact that a user could stop watching a video in mid-
`
`stream limits what “the program” means in the preamble. All this argument does is
`
`highlight the continuing nature of the claim limitations, without disputing that the
`
`limitation requirements continue but simply quibbling over how long they
`
`–3–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`continue. Google does not point to any structural operational difference that results
`
`from the fact that a user may leave early.
`
`(Reply-5, Mr. Hoarty’s testimony) Additionally, Google omits testimony from
`
`Mr. Hoarty it does not like: “I would read that as the duration that the user was
`
`viewing the program.” EX1103-25:10-12. Contrary to Google’s assertions, Mr.
`
`Hoarty’s position is consistent with Patent Owner’s.
`
`(Reply-5, streaming of live programs) Google’s argument with regard to a
`
`live program is even more strained. Users inherently join and leave ongoing live
`
`streams, for example a live streaming of a radio or TV station. Google points to
`
`nothing in the structural characteristics and operational capabilities of a server that
`
`can receive a live feed from a source and redistribute it over the internet, that
`
`would change as a consequence of when users enter or leave the transmission
`
`stream.
`
`B.
`
`“Requests” Limitations
`
`(Reply-6-7, that “PO’s sole evidence [for individually identified requests] is
`
`a sentence in the specification”) Google’s assertion here is incorrect, as Patent
`
`Owner first argued the claim limitations must be read together. POR-13 argued that
`
`“[t]he plain and ordinary meaning of [limitation d] is that if the request responded
`
`to is for more than one element, then each of the elements in the response must
`
`have been specified as part of the request by its respective serial ID.” Patent
`
`–4–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`Owner argued that “read in light of limitation d … the only reasonable
`
`interpretation of limitations c-c(ii)” is that “even if the ‘received request’ is for
`
`more than one element, each such requested element is identified in the request by
`
`the respective serial identifier of that media data element.” POR-11-12. The Reply
`
`does not address or dispute Patent Owner’s arguments that the claims read as a
`
`whole mandate Patent Owner’s construction. Google ducks the issue, focusing only
`
`on the specification.
`
`When it turns to the specification (falsely characterizing it as “PO’s sole
`
`evidence”), Googe gets that wrong as well, bowling over the words:
`
`the user computer transmits a request to the server to send one or
`
`more data elements, specifying the serial numbers of the data
`
`elements.
`
`EX1001-14:51-53 (emphasis added). This disclosure is unmistakable and contrary
`
`to Google’s argument that the specification does not recite requests specifying each
`
`serial number of the requested elements. Google argues for a construction contrary
`
`to any disclosed embodiment. Even Google’s expert agrees, contrary to the Reply,
`
`that this specification language “would not include a data element that is not
`
`–5–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`identified by—identified in the request by a serial number.” See EX2016-42:2-
`
`43:11.
`
`C.
`
`“Data Rate of the Data Connection” Limitation
`
`(Reply-7-8, that “data rate” is only tied to an unspecified number of
`
`elements, implicitly as little as a single element) Google’s Reply on this point
`
`does not address Patent Owner’s actual argument. The connection data rate
`
`limitation is not an instantaneous rate, e.g., transfer rate for a single element (POR-
`
`15) (EX2016 45:4-46:9 (a “single observation wouldn’t really be necessarily
`
`dispositive”)), nor is it a rate over some unspecified number of elements that could
`
`be as little as a single element. Furthermore, Google’s dichotomy, of a single
`
`element vs. each and every element (“must always”), is a false one.
`
`Google’s false dichotomy is: “Under PO’s interpretation, each-and-every
`
`element must be transferred faster than the playback rate, but a ‘live’ program
`
`cannot be continuously transferred at a rate faster than the playback rate since it is
`
`impossible to get ahead for a ‘live’ program.” Reply-8 (Emphasis added). This
`
`Google argument reveals a failure to appreciate the disclosure.
`
`It is the transmission that causes media data to be collected ahead of the
`
`playback, by virtue of filling a client-side store or buffer. The requested serially
`
`identified elements exist on the server when they are requested. They are each
`
`“transmitted to the user computer as fast as the data connection between the user
`
`–6–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`computer and the server will allow” (EX1001-14:61-62), necessarily implying that
`
`there is extra time between the elements. The user computer “incorporate[es] a user
`
`buffer and comprises means for receiving and storing a predetermined number of
`
`media data elements.” EX1001-15:10-12. The player thus starts playback from the
`
`buffer, which stores elements ahead of what is needed for continued playback, and
`
`it stays ahead, because “as data is played out, the next sequential data elements are
`
`requested from the server in such a fashion as to approximately maintain the
`
`predetermined number of data elements in the user’s buffer.” EX1001-15:15-18.
`
`Contrary to Google’s assertion, this does not necessarily require that “each-and-
`
`every element must be transferred faster than the playback rate.” But it does
`
`require a connection having a data rate such that, when measured over at least “the
`
`predetermined number” of sequential elements, the transmission time of those
`
`elements will be less than their back-to-back playback duration. That is the
`
`minimum required to render the combined limitations, in accordance with the
`
`literal claim language, operable, so as to maintain approximately a predetermined
`
`number of media data elements in the user buffer as data is constantly being played
`
`out at the playback rate. EX2002 ¶¶ 26-27, 47.
`
`(Reply-8-9, comparing prior Federal Circuit decision) Patent Owner agrees
`
`that the Federal Circuit decision concerned a transmission rate for individual
`
`elements.
`
`–7–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`D.
`“Without Depending on the Server System Maintaining a
`Record” Limitation
`
`(Reply-9, “PO does not advance any specific construction for this limitation
`
`[d(iii)]”) This is a misstatement. POR-19 pointed out that it was “[t]he Petition
`
`[that] does not argue any particular construction for this term” (emphasis added)
`
`and the POR expressly set forth Patent Owner’s interpretation, to which the Reply
`
`has no response, obliquely inserting cross-references to its discussion of other
`
`limitations. Patent Owner cannot discern here an actual argument against its
`
`construction of limitation d(iii).
`
`CARMEL GROUNDS (1-4)
`
`(Reply-9, “All four grounds in the Petition rely on Carmel as a primary
`
`reference”) Correct (and the Petition’s downfall).
`
`A. Alleged Carmel Disclosure of “Client Control”
`
`(Reply-10, “Carmel discloses client control”) As addressed above, Carmel
`
`discloses that the client can control the starting slice from which the server will
`
`push successive elements, can open HTTP connections, and can send commands to
`
`ask the server to change which available encoding level of the streaming data to
`
`send, none of which get to individual element requests. The catch-phrase “client
`
`control” is insufficient.
`
`(Reply-10, “‘[C]lient 30’ selects and downloads a slice”) This is a
`
`manufactured quote and so misleading it should be stricken. Nor does the
`
`–8–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`disclosure tie the “SELECT SLICE” box in any way to “downloads a slice.” The
`
`disclosure as to the word “select” is that “graphic 56 (FIG. 3C) is displayed by the
`
`client, so that a user can decide and indicate at which slice of data stream 40 to
`
`begin downloading. Responsive to a user input, client 30 selects an appropriate
`
`starting slice.” EX1003-10:43-46 (emphasis added).
`
`(Reply-11, “By teaching that ‘client 30’ monitors links, establishes links,
`
`and controls the slices allocated to each link, Carmel teaches a client-driven
`
`and ‘pull’-based approach”) “Pull” does not follow from “monitors links” and
`
`“establishes links.” The only thing Google cites (in footnote 3) for “controls the
`
`slices allocated to each link” is Carmel’s disclosure of what source computer 34
`
`does. Google repeatedly over-relies on imputing details of the upload process from
`
`source 34 to server 36, to apply in every respect to server 36’s transmission to
`
`clients 30. But here, Google actually argues against itself, because computer 34 is
`
`the media source relative to server 36—the reverse of what Google seeks to
`
`establish. Google’s argument here appears to agree with Patent Owner.
`
`(Reply-11, “‘client 30’ decides whether to break a link”) Carmel does not
`
`suggest that any of clients 30 controls whether to retransmit over a broken link.
`
`The cited disclosure from Carmel’s col. 10 once again references source computer
`
`34. The mere words “mutatis mutandis” (from EX1003-13:30-35) are insufficient
`
`to overcome the specific evidence (or substitute for it), and in any case, the
`
`–9–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`“control” in the upload scenario is being applied from the data source side
`
`(computer 34), again, the opposite of what Google seeks to argue. Google again
`
`argues in favor of Patent Owner’s position.
`
`Moreover, the “mutatis mutandis” reasoning raises the issue that upload is
`
`preferably via ftp, which the experts both agree is a push protocol. POR-45;
`
`EX2006- 114:1-18 (Polish); EX2002 ¶ 63 (Hoarty).
`
`1.
`Carmel’s alleged “express disclosure”
`Contention that Carmel discloses “Pull”
`
`(Reply-12, “only ‘client 30’ can decide when to proceed with the next slice
`
`[to DECODE/OUTPUT]”) Nothing here even suggests a “request” to the server,
`
`as opposed to processing slices already received via push. See POR-51-52.
`
`Nothing in Carmel suggests that the checking link function is coordinated with
`
`any “request” for a slice. The consequence of detecting significant lag is to open a
`
`new link. EX1003-10:55-63. There is no basis to read anything more into this.
`
`There is also nothing that says a “request” to the server for a slice is made
`
`anywhere in the loop iteration.
`
`DECODE and OUTPUT DATA are also not definitive since in any formulation,
`
`push or pull, the client will need to decode and output the media data.
`
`(Reply-12, “even in HTTP1.1 each file must be individually requested—
`
`something Patent Owner’s expert admits”) This argument is fraught. First, it
`
`–10–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`was not in the Petition, second, it blatantly misrepresents the underlying testimony,
`
`and third, it is contrary to the HTTP 1.1 specification in evidence.1
`
`First, in a related case, Disney asserted in its (earlier filed) Petition that
`
`individual file requests are inherent in HTTP, and Patent Owner addressed this at
`
`length in that case. Google did not make that assertion in the Petition herein,
`
`raising it now for the first time in its Reply.
`
`Second, Google’s statement that its argument is “something PO’s expert
`
`admits” is a total fabrication. Mr. Hoarty testified that “a POSITA would not
`
`understand Carmel to disclose an individual request (pull) form of streaming”
`
`(EX2002 ¶ 62), and that HTTP 1.1 supported responses “comprising an open-
`
`ended sequence of data elements, so that, in response to a single invocation, the
`
`server could send sequential portions of the content,” citing and explaining
`
`referenced detailed testimony by Dr. Jeffay (Amazon’s expert). EX2002 ¶ 53-54.
`
`Testimony that Mr. Hoarty cites (EX2009-637:10-639-7) obliterates any
`
`“inherency” assertion:
`
`
`1 Patent Owner recognizes these are harsh words, but intends them, as it believes
`
`the Reply here and in several other places crosses well over the line of zealous
`
`advocacy.
`
`–11–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`• Disagrees that, “if Carmel … is transmitting a request via HTTP, then that
`
`request necessarily identifies the requested file stored by the video server.”
`
`EX2009-637:10-16.
`
`• Explains that, “HTTP is famously the best example of a giant Swiss Army
`
`knife protocol that we have on the Internet.… There are many ways to get
`
`content sent to you by HTTP.” EX2009-637:18-22.
`
`• Confirms that mere reference to HTTP doesn’t inherently mean a request for
`
`a file but instead that “there are many other ways that you can get content
`
`via HTTP without making a GET request and without having to request a
`
`file, for example, by name.” EX2009637:24-638:8.
`
`• That HTTP supports “a GET request that does not use a file name.… [but] to
`
`identify a stream…. not request a file; instead request a higher level object
`
`like a stream. And HTTP supports a mode of content delivery that is called
`
`chunked transfer encoding, where … in each HTTP response, you send a
`
`sequential portion of the content that’s being requested. And this is described
`
`in Carmel in column 2.” EX2009:638:12-639:5.
`
`• Further, a POSITA “would understand that a perfectly viable way to
`
`implement that would be … [to] generate a post request to the server,
`
`sending the data that … the user had input via the client app, and with that
`
`data having been received at the server, the server would then start sending
`
`–12–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`media down to the client, for example, using chunked encoding.” EX2009-
`
`639:18-24.
`
`Google grossly misrepresents Mr. Hoarty’s deposition testimony—from another
`
`case. See EX1111 ¶ 68, quoting EX1101 (Disney deposition of Hoarty) 66:11-67:1.
`
`In the Disney deposition, Mr. Hoarty was specifically asked about “a request for
`
`File A” (EX1101-66:11), to which he replied, answering a following question that
`
`was explicitly “based on that scenario” (EX1101-66:17-18), that the server would
`
`not send File B if the request “didn’t ask for it.” EX1101-66:20. The suggestion
`
`that this answer constitutes an “admission” that “in HTTP 1.1 each file must be
`
`individually requested” is not commensurate with the question and is outright
`
`false.
`
`Google’s belated argument would assume an HTTP request has to be for a file.
`
`However, just the same as Mr. Hoarty and Dr. Jeffay, Google’s expert himself
`
`confirmed the contrary in his most recent deposition, that HTTP 1.1 specifies
`
`requests more broadly, for “entities.” EX2016-88:3-6 (“Q. a GET request is for an
`
`entity? A. “Yeah, I guess that’s the way they refer to it.”); EX2016-90:16-25 (Q.
`
`“chunked encoding here it refers to an entity that is generated dynamically?” A.
`
`–13–
`
`
`
`Case IPR2022-01413
`
`
`Patent 9,762,636
`
`
`Yeah … they’re being if you will, dynamically generated.”).2 There is nothing left
`
`to back Google’s incorrect assertion that an HTTP request must be for an
`
`individual file.
`
`POR-33, 35, 50 noted the lack of evidence of any Carmel disclosure of an
`
`HTTP request for an individual file. Google’s response is its misstatement of Mr.
`
`Hoarty’s testimony, and a new (to this case) and likewise manufactured assertion
`
`that anything else would not have been technically possible. At Reply-12, Google
`
`throws in a string of bare cites, purporting to evidence individually identified
`
`requests, but each of those citations falls flat on inspection.
`
`(Reply 12-13, HTTP cannot support sending unrequested files) It is
`
`uncontested that HTTP does not support the sending of unrequested files. Google’s
`
`argument, however, is a strawman assuming the conclusion that Carmel’s requests
`
`are for files, when Carmel does not disclose that, and nothing technically requires
`
`it. In Carmel, there is one request to send a stream (which is comprised from the
`
`
`2 Dr. Polish, at EX1111 ¶ 68, cites Swaminathan (EX1104-3-4), but later
`
`acknowledged that Swaminathan chunked stream fragments (each corresponding
`
`to a Carmel “slice”). EX2016-28:24-30:5. Here, the larger structure, the stream, is
`
`being chunked. That a file itself may be chunked for delivery does not show that
`
`HTTP 1.1 “requires” that HTTP requests be files or slices.
`
`–14–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`contents of sequential slices) starting from a specified slice. No one says the file
`
`contents included in the resulting stream are “unrequested.” But that does not
`
`imply the included content is “individually requested” for each slice. Indeed, as
`
`evidenced above, a POSITA would recognize that it is not.
`
`(Reply-13, “specialized software”) Google still does not respond to POR-26-
`
`27, as to what would take software that implements an open specification outside
`
`the scope of Carmel, which specifically invokes that specification. EX1003-2:22-
`
`28.
`
`(Reply-12, n.4, “‘chunked transfer encoding’ is used when the file size is
`
`undefined or unknown.”) The HTTP 1.1 standard (EX2005) actually says that
`
`“chunked encoding … allows dynamically-produced content to be transferred”
`
`(EX2005-21/140 (emphasis added))—a permissive statement—not that chunked
`
`transfer encoding “is” used “when the file size is undefined or unknown,” as
`
`Google suggests.
`
`Carmel uses a live feed as its base example, a prime example of dynamically-
`
`produced content. While allowing for such content, the RFC states no requirement
`
`that the content must not be complete, requiring only that the “entity-body” consist
`
`of “OCTETS” (bytes). See EX2005-36/140.
`
`(Reply-13, “HTTP1.1 … require[s] that each file must be individually
`
`requested”) Google finesses even its own expert’s testimony, which did not say
`
`–15–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`“individually” requested. Cf. Ex. 1111 ¶ 69 (“specifically” requested). Google’s
`
`Reply argues that something sent as an internal part of a continuous stream, and
`
`therefore “requested” in that sense, morphs into “individually” requested, a
`
`conclusion that does not follow. The expert himself stretches the argument by
`
`saying “specifically” requested, and while the word “specifically” can perhaps be
`
`justified under a very inclusive view of “specifically,” it is not sufficient to meet
`
`the claim limitations. To take this over the line, Google’s Reply takes “specifically”
`
`requested (the best it could get from the evidence) and expressly represents it as if
`
`the evidence had said “individually” requested, which it does not.
`
`(Reply-13, SELECT SLICE is included in every continue loop) Fig. 6A
`
`reflects a loop in which the client repeatedly receives elements via HTTP. EX2002
`
`¶ 68. Google would infer from Carmel’s Fig. 6A that SELECT SLICE is executed
`
`on every loop iteration and represents a request. Google points to nothing in the
`
`written disclosure to support this. Google dodges the issue of why SELECT SLICE
`
`follows rather than precedes HTTP FROM SERVER raised in the POR. POR-34-
`
`35.
`
`Dr. Polish acknowledged that Fig. 6B represented the same underlying
`
`approach as Fig. 6A. EX2006-105:13-106:1 (“So in 6B it’s adjusting the level. In
`
`6A it’s just checking whether the link is broken”). That being the case, Google does
`
`not explain why Fig. 6B says READ SLICE and not SELECT SLICE as in Fig.
`
`–16–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`6A. The simple explanation for this is because SELECT SLICE only means select
`
`a slice responsive to human input (POR-34), and that, as reflected in the
`
`corresponding descriptions at EX1003-10:42-47 and EX1003-10:64-11:8
`
`respectively for Figs. 6A and 6B, the graphical user interface feature of Carmel that
`
`supports such selection is only addressed in connection with Fig. 6A.
`
`(Reply-13-14, HTTP FROM SERVER means “PULL”) As to Google’s
`
`contentions that Figs. 6A and 6B of Carmel are cast as steps performed by client 30
`
`and so should be understood as a “pull” from the server, the actual underlying step
`
`in each case that is performed by the client is receiving data from the server. This
`
`does not require “pull.”
`
`Google’s citation at Reply-14 to Mr. Hoarty’s deposition is off-base, as this
`
`testimony concerned practicing the ’594 patent, not Carmel.
`
`(Reply-14, “client … reads an index file to identify, select, and request the
`
`next-needed slice”) Google fails to identify any disclosure that Carmel repeats a
`
`process of reading the index file to select and request each successive slice. Merely
`
`glossing over fifteen lines of disclosure in this way when the disclosure itself
`
`actually says nothing of the sort is insufficient.
`
`(Reply-14, “only ‘client 30’ would know when the “DECODE” and
`
`“OUTPUT DATA” steps are complete, so only ‘client 30’ can decide when to
`
`proceed with the next slice) Regardless of a push or pull implementation, it is
`
`–17–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`obviously always the client that decodes and outputs the media data. This thus has
`
`no bearing on “pull.”
`
`(Reply-14-15, ITC ruling) Regardless of the underlying claims in the ITC
`
`case, the ALJ made various factual findings as to Carmel after trial on the merits
`
`that included testimony from various experts. The Board should be aware of the
`
`ITC ruling and factual conclusions therein regarding Carmel.
`
`(Reply-15, Claim constructions in N.D. Cal.) Google’s citation from N.D.
`
`Cal. is construction of a limitation in Carmel’s claims concerning the rate that a
`
`client “can download the sequence” of uploaded files. The claims in question are
`
`broad, and do not recite requests. It is not a ruling that Carmel discloses successive
`
`individual requests.
`
`(Reply-15-16, Download implies a request) Carmel uses the word
`
`“download” with respect to both Figs. 6A and 6B. In the context of Fig. 6B,
`
`Carmel recites “downloading” at 10:65, which it relates to the action of “the client
`
`selects one of the available quality levels in the stream. Responsive to the selection,
`
`server 36 begins to transmit data slices at the chosen quality level.” EX1003-11:4-
`
`7 (emphasis added). The “download” here is unmistakably the result of receiving
`
`the successive slices that the server transmits. Google does not explain why
`
`“download” has a narrower meaning when used earlier in col. 10 of Carmel.
`
`–18–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`Patent Owner does not dispute that there is a “request,” insofar as the client
`
`requests transmission of the stream. The client requests the stream and downloads
`
`its elements as they are sent. However, the mere word “download,” under either
`
`side’s preferred definition, does not address whether there are individual requests
`
`for the constituent elements that comprise the stream that the client has requested.
`
`(Reply-16-17, Expert “poll”) In a case of multiple challengers, a headcount of
`
`their experts is not probative. The notable development is that one of the experts
`
`that Google purports to count in this tally actually waffled. Google quibbles about
`
`this (yet seems concerned enough to raise it (in footnote 5)), but the other expert’s
`
`prior testimony that neither the Figs. 6A nor 6B embodiments disclose slices being
`
`independently requestable is a major inconsistency on the challengers’ side.
`
`(Reply-17, “lacking server-side software for similar functions, a POSITA
`
`would overall understand this disclosure to be consistent with ‘pull.’”) It does
`
`not follow that a client is making individual pull requests simply because it asks
`
`the server to switch to a different encoding level. The POR at 32-33 addressed this,
`
`and merely repeating a contrary conclusion does not advance Google’s case.
`
`(Reply-17-18 and n.6, that the “heart” of the Carmel invention is pull, to
`
`which the inventor later added push) If Google is now joining the camp that
`
`distinguishes the underlying principle of the Fig. 6A and 6B embodiments, its
`
`position on the word “download” is even further nullified, because “downloading”
`
`–19–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`at 10:65 of Carmel would be concededly tied to push. Moreover, Google cannot
`
`take this tack now, as its expert testified to the contrary. EX2006-106:2-7. Finally,
`
`the assertion that the Carmel inventors, without comment, tacked on an
`
`enhancement that required a completely different underlying implementation
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
