`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`______________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________________________________
`
`
`
`AMAZON.COM, INC., AMAZON WEB SERVICES, INC.,
`AND AMAZON.COM SERVICES LLC.,
`
`Petitioners
`
`v.
`
`WAG ACQUISITION, LLC
`
`Patent Owner
`
`U.S. Pat. No. 9,762,636
`
`
`
`_______________________________________
`
`Inter Partes Review Case No. IPR2022-01433
`
`_______________________________________
`
`
`
`PATENT OWNER’S SUR-REPLY
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`TABLE OF CONTENTS
`
`
`
`I.
`
`INTRODUCTION ............................................................................................. 1
`
`II. NO MOTIVATIONS TO COMBINE THE REFERENCES ............................. 3
`
`III. CARMEL DOES NOT DISCLOSE A “PULL” SYSTEM ............................... 6
`
`IV. CARMEL’S SINGLE QUALITY LEVEL EMBODIMENT (FIG. 6A) ........... 9
`
`V. LIMITATION h .................................................................................................. 9
`
`VI. LIMITATION j .................................................................................................12
`
`VII. LIMITATION k ................................................................................................14
`
`VIII. DR. JEFFAY’S TESTIMONY .........................................................................18
`
`IX. CONCLUSION ................................................................................................19
`
`
`
`
`
`
`
`
`
`
`
`–ii–
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`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
`
`IETF RFC 1945
`
`2003
`
`CV of Kevin Jeffay, Ph.D.
`
`2004
`
`2005
`
`2006
`
`Longhorn HD LLC v. Netscout Systems, Inc., Case No. 2:20-CV-
`00349, Memorandum Opinion (E.D. Tex., March 31, 2022)
`
`3G Licensing, S.A. v. HTC Corp., Case No. 17-83, Memorandum
`Order (D. Del. March 30, 2022)
`
`SEVEN Networks, LLC v. Google LLC, Case No. 2:17-cv-442,
`Pretrial Conference (E.D. Tex., Dec. 12, 2018)
`
`2007
`
`Declaration of W. Leo Hoarty
`
`2008
`
`Declaration of Henry Houh (Ex. 1002 of IPR2022-01228)
`
`2009
`
`Redline comparing declaration of Kevin Jeffay (Ex. 2824) with
`Declaration of Henry Houh (Ex. 2008)
`
`2010
`
`May 23, 2023, Deposition of Dr. Kevin Jeffay
`
`2011
`
`May 25, 2023, Deposition of Dr. Nathaniel Polish
`
`2012
`
`2013
`
`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)
`
`–iii–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`2014
`
`In re Certain Fitness Devices, Streaming Components Thereof,
`and System Containing Same, Inv. No. 337-TA-1265, Document
`Filing Report
`
`2015
`
`Redline comparison of claims of ’824 and ’636 patents
`
`2016
`
`2017
`
`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)
`
`2018
`
`IETF RFC 2068
`
`2019
`
`Microsoft Computer Dictionary, Fifth ed. (excerpts)
`
`2020
`
`Avi Networks, Inc. v. Citrix Systems, Inc., IPR2019-00845, Ex.
`1007
`
`2021
`
`April 10, 2023 Deposition of Dr. Henry Houh
`
`2636
`
`Declaration of Kevin Jeffay (Ex. 1002 of IPR2022-01433)
`
`2824
`
`Declaration of Kevin Jeffay (Ex. 1002 of IPR2022-01430)
`
`–iv–
`
`
`
`
`
`
`I.
`
`INTRODUCTION
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`Amazon did not even submit a Reply declaration from its expert, Dr. Kevin
`
`Jeffay, who, as it developed during his deposition, had given prior inconsistent
`
`testimony with regard to Amazon’s primary reference, Carmel, which he did not
`
`disclose in his declaration.
`
`Instead, while going through the motions of trying to salvage its position on
`
`Carmel, Amazon now seeks at every turn to pivot to principal reliance on another
`
`reference, Feig, instead of Carmel.
`
`However, the Petition failed to point to Feig in the first instance to support five
`
`of the twelve limitations at issue, limitations a, b, c, e, and l. Amazon asserts
`
`nothing as to any of those points with regards to Feig, and it would have been too
`
`late to have done so in its Reply.
`
`The Petition was based on Carmel in view of Feig, not on Feig alone, or Feig in
`
`view of Carmel. Even if read as the reverse of how it was presented, the Petition
`
`did not provide evidence to support such a reversed § 103 position as to all
`
`limitations.
`
`The Petition also provided the most cursory alleged motivations to combine,
`
`which, as the POR and Patent Owner’s (“PO’s”) expert, W. Leo Hoarty (EX2007),
`
`pointed out, were all inadequate. Amazon tries to reword and reargue these alleged
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`motivations in its Reply, but this effort comes too late and in any case is
`
`ineffective.
`
`In instituting this case, the Board stated:
`
`At this stage of the proceeding, Patent Owner does not introduce
`rebuttal testimony. Nor does Patent Owner criticize Dr. Jeffay’s
`testimony about HTTP downloading in Carmel using an HTTP
`GET request for each slice file as technically incorrect.
`
`Institution Decision 57-58. Patent Owner has now submitted rebuttal testimony,
`
`which stands unrebutted. In particular, Mr. Hoarty thoroughly rebutted Dr. Jeffay’s
`
`testimony regarding HTTP, and indeed Dr. Jeffay himself, confronted with his prior
`
`testimony concerning Carmel, conceded that the version of HTTP specifically
`
`referenced in Carmel supports streaming without requiring an HTTP GET request
`
`for each slice file. EX2010-121:22-124:12. Dr. Jeffay has nothing further to say, as
`
`evidenced by his complete silence when the opportunity was provided for a reply.
`
`At the very end of its Reply, purporting to limit Dr. Jeffay’s most damaging
`
`testimony to one disclosed embodiment in Carmel, Amazon claims now to address
`
`only that one embodiment, which it insists differs from the other in its underlying
`
`implementation. Dr. Jeffay’s prior testimony speaks for itself, however, and it is
`
`clear on its face that his prior testimony is not so limited. As will be addressed,
`
`Amazon’s positions on the supposed “differences” between the two embodiments,
`
`which it uses in its effort to rehabilitate Dr. Jeffay (without any further submission
`
`from him) are also inconsistent with each other, and for that additional reason have
`
`–2–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`no merit, either in themselves or as a basis to explain away Dr. Jeffay’s
`
`contradictions.
`
`II. NO MOTIVATIONS TO COMBINE THE REFERENCES
`
`(Reply-1) The Petition exclusively relied on Carmel for limitations a, b, c, e,
`
`and l. The Petition did not present any grounds that would modify Feig and/or
`
`Willebeek in view of Carmel to meet these limitations. The Petition fails to provide
`
`support for Amazon to proceed on the basis of Feig or Willebeek alone. Therefore,
`
`all that Amazon can do is rely on modifying Carmel with regard to limitations h, j,
`
`and k, in view of Feig (and to the very limited extent invoked by Amazon,
`
`Willebeek).
`
`All of Amazon’s arguments as to motivation are based on faulty assumptions as
`
`to the nature of operation of Carmel, and therefore fail.
`
`Furthermore, regardless of lack of motivation, the Petition cites no evidence
`
`that either Carmel or Feig teach limitation j.
`
`(Reply-2—using non-streaming server to simulate a streaming server) This
`
`alleged motivation was asserted in the Petition specifically with regard to
`
`limitation f. Pet.-39. The textual antecedent for “the combination” referred to there
`
`was “to combine the teachings of Feig related to reciting receiving requests at the
`
`server system with Carmel.” Amazon’s Reply now morphs this into a general
`
`motivation to “combine” the references wholesale (not just to combine the
`
`–3–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`specified single feature the Petition identified) by adding the second entire
`
`disclosure as a separate additional parallel mechanism. This is no longer
`
`“simulating” by the manner that Carmel receives requests, as originally argued
`
`(which would be a modification, as addressed at POR-53-54, 59-60).
`
`Carmel itself was based on adaptation of a commodity server to perform
`
`streaming, and thereby replace costly specialized prior art facilities. EX2007 ¶ 48.
`
`The Petition presumes, on top of that, that Carmel did so by simply iterating file-
`
`by-file requests as might be made to a static HTTP server. As further addressed
`
`herein, this premise has not held up. The actual disclosed mechanisms of Carmel
`
`do not support Amazon’s invalidity arguments. The Petition addressed the
`
`limitations individually. At page 39 (as noted above), it proposed modifying
`
`Carmel to incorporate a “receiving requests” feature to address limitation f.
`
`PO argued that such a modification would be at war with the mechanism
`
`Carmel actually recites and would completely change the principle of operation of
`
`Carmel with disclosures from another reference. Amazon gets no traction with
`
`such an argument, as it clearly goes too far. In view of the clear insufficiency of
`
`that argument, Amazon seeks to shift here to a new approach, that instead of
`
`modifying the operation of Carmel, it would make a broader “combination”
`
`(broader than the one suggested in the original Petition), which would now just add
`
`an alternate capability on top of unmodified Carmel—to “expand” Carmel.
`
`–4–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`Amazon does not point to where Carmel or anything else ever suggested
`
`deploying completely different types of servers in the same system, nor does it
`
`address why a POSITA would want to create such a hybrid system.
`
`Carmel, whose title is “Network streaming server,” already discloses a
`
`streaming server, just one that operates by a different principle, i.e., push. The
`
`server has to work with a client. The Petition does not address why, where Carmel
`
`also presumes control over the design of the client, it would make sense to provide
`
`two alternate methods of streaming, each requiring a different type of client. PO
`
`addressed this at page 61 of the POR.
`
`Further, Carmel’s server already performs as “a streaming server,” and Amazon
`
`does not explain why, in view of the existing disclosure of a streaming server, a
`
`POSITA would see a need to “simulate” one. As shown by the evidence in this case
`
`(again reviewed below), Carmel’s disclosed server (36) does so by continuously
`
`streaming media slices from a specified starting slice. Carmel’s system requires a
`
`client (implemented in a Java Applet in the case of Carmel) with corresponding
`
`functionality, in order to make use of such a server. Feig requires a different type of
`
`client. Whether Carmel’s push server mechanism is modified (i.e., entirely
`
`replaced) by a different type of mechanism, or the different server mechanism is
`
`simply added as a second alternative, a different, or additional (but still different)
`
`–5–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`client mechanism must also be provided, along with functionality to choose which
`
`alternative to use, none of which is addressed by Amazon.
`
`Amazon also does not explain how just bolting on a second mechanism from
`
`another reference makes Carmel itself anything other than irrelevant extra baggage.
`
`It fails to point out how, under its proposal, there would be any continued relevance
`
`of Carmel itself. The “benefit” of such an approach is thus completely rhetorical,
`
`not technical, to give Amazon a segue to its secondary reference, after the technical
`
`relevance of its primary reference has been rebutted.
`
`(Reply-2—claim that “Patent Owner does not address” motivation to
`
`combine faster data connection with Carmel) This assertion is simply incorrect,
`
`as PO did address exactly this proposed modification, based on Feig and
`
`Willebeek, at length, at pages 42-43 of the POR.
`
`III. CARMEL DOES NOT DISCLOSE A “PULL” SYSTEM
`
`(Reply-2) Amazon’s assertions that HTTP GET requests for a file “were
`
`commonplace” does not address the issue of whether Carmel discloses such
`
`requests in the first instance. Amazon points to no such disclosure and there is
`
`none. (The quoted words “request or pull the sequential slices by identifier” are
`
`Amazon’s (from the Petition), not any quote from Carmel.)
`
`The evidence establishes that Carmel streams via a different mechanism, that of
`
`autonomously pushing files from a specified starting point, POR 30-31, and
`
`–6–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`provides no reason why a POSITA would modify a server implemented in such a
`
`manner to change to a system whereby it waited for a specific HTTP GET request
`
`for each file before sending that file.
`
`(Reply-4) What Amazon seeks to cite from Dr. Houh’s testimony is hearsay
`
`from a different case. Dr. Houh’s deposition is PO’s Exhibit filed herein, but was
`
`not submitted for the truth of his testimony, but to note the positions he took. In
`
`fact, EX2021 was not even cited in the POR.1
`
`(Reply-4—disparaging Carmel’s disclosure of HTTP 1.1) Amazon relies
`
`here 100% on attorney argument. Its own expert himself identified “chunked
`
`transfer encoding” as disclosed in col. 2 of Carmel. EX2010-121:22-123-18. That
`
`
`1 In addition to being wrong (as PO argues in the other case), his deposition makes
`
`clear that Dr. Houh had never considered and was completely unaware when he
`
`wrote his declaration, or sat for his first deposition, of applicable new provisions of
`
`the HTTP 1.1 specification regarding serving over persistent connections, such as
`
`by chunked transfer encoding (EX2021-128:24-132-23). Dr. Houh’s declaration
`
`(EX2008) was cited in the POR, but only to show, with EX1002 (Jeffay Dec.) and
`
`EX2009 (redline) that more than half of Dr. Jeffay’s declaration was clearly cut and
`
`pasted from Dr. Houh’s declaration. See EX2010-97:26-101:24; EX2009 (redline
`
`comparison of Jeffay vs. Houh declarations); POR-32.
`
`–7–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`testimony completely corroborates PO’s expert (EX2007 ¶¶ 51-55). Now that PO
`
`has argued this in its POR, Amazon has dropped its expert, hopes the Board will
`
`overlook what he testified, and simply resorts to disparagement.
`
`Amazon argues that somehow chunked transfer encoding doesn’t work with
`
`individual files, which is pure attorney argument, incorrect, contrary to the cited
`
`RFC, RFC 2068 (EX2018-21-22, defining “chunk-data” as data that can be any
`
`OCTETs (bytes), stating no requirement where the OCTETS must come from),
`
`contrary to its expert’s testimony, and contrary to PO’s expert (EX2007 ¶¶ 51-55).
`
`It is undisputed that chunked transfer encoding can be used to programmatically
`
`generate a stream comprised of individual files, of the server’s selection. PO’s
`
`expert and Amazon’s expert (in his prior testimony) both explained how to do it.
`
`EX2007 ¶ 55; EX2010-122:22-123:5.
`
`(Reply-6) As to chunked transfer encoding allegedly being “more suited to
`
`larger files than smaller files” (emphasis added), Mr. Hoarty testified that chunked
`
`transfer encoding addressed “the need for moving … large message bodies.”
`
`EX1033-37:9-10 (emphasis added). Any suggestion that “large message bodies”
`
`are limited to large “files” is incorrect. As in Carmel, a large message body is
`
`created (by the server) from individual files.
`
`Amazon makes such strained and plainly flawed arguments, then gives up,
`
`seeking again to take refuge in Feig.
`
`–8–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`IV. CARMEL’S SINGLE QUALITY LEVEL EMBODIMENT (FIG. 6A)
`
`(Reply-8 “Patent Owner also points to a few places where Dr. Jeffay cited
`
`to portions of Carmel from both embodiments to make unrelated points.”)
`
`Amazon seeks here to distance itself to no avail from its expert’s prior testimony,
`
`which, despite Amazon’s revisionism, was directly on the Fig 6A and 6B
`
`embodiments in Carmel. POR-33-34 (quoting EX2013-641:24-642:9 (addressing
`
`“independent requests” not being disclosed in Carmel: “Certainly in the context of
`
`the multi-level data stream embodiment, it’s also my opinion that it’s not disclosed
`
`in terms of the single level embodiment”) (emphasis added)).
`
`V. LIMITATION h
`
`Reply-8-9 concerns an alleged motivation to provide Carmel with a faster data
`
`connection. This argument fails to address the fact that Carmel discloses no buffer
`
`control. The disclosure of “generally” equal to or faster means that transmissions
`
`between server and client will sometimes to be slower, as indeed they must be to
`
`prevent Carmel’s system from overflowing. EX2007 ¶¶ 74, 82. In the multi-level
`
`embodiment, Carmel can adapt on the fly to keep the transmission matched to the
`
`available bandwidth. In the single-level embodiment, it may choose an appropriate
`
`level to start (EX1005-9:6-8), and all it can then do is open and close connections
`
`(EX1005-10:55-63), which still does not help if the client does not have adequate
`
`internet bandwidth. EX2007 ¶ 83.
`
`–9–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`(Reply-10 citing prior IPR) The prior decision in IPR2016-01238 was
`
`reversed on the point for which it is cited. EX2001-11.
`
`(Reply-11, that it would have been obvious for Carmel to utilize a faster
`
`connection) The argument for unlimited speed assumes the client has unbounded
`
`capacity to store incoming data. Amazon does not address the fact that Carmel
`
`provides no disclosure of how a client is supposed to handle this. Indeed, there is
`
`no disclosure at all of a client-side buffer in Carmel, a fact that the Petition fails to
`
`address. The Reply brings up the challenged patent, but that works because the
`
`challenged patent discloses a buffer, and because the requests are explicitly
`
`calibrated to maintain a predetermined number of media data elements in the
`
`buffer. EX1001-15:9-18. Carmel has no corresponding disclosure.
`
`(Reply-11—overrunning buffer not applicable to single-level embodiment)
`
`This argument does not follow, as Carmel’s single-level embodiment also does not
`
`disclose a buffer (certainly not one of any given size) and would suffer from the
`
`same infirmity (of losing what the client system cannot receive) in the event of the
`
`proposed modification.
`
`(Reply-12—“a POSITA would have been motivated to use Feig’s solution in
`
`which the client avoids overflow by selectively pulling data elements from the
`
`server.”) This is a new theory. The argument actually made (Pet.-55) was directed
`
`–10–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`at a proposed modification that “supports Carmel’s goal of allowing a user to
`
`‘decide and indicate at which slice of data stream 40 to begin downloading.’”
`
`Now, Amazon proposes a wholesale change from Carmel’s push to an alleged
`
`pull (with the alleged motivation now morphed to “selectively pulling elements”),
`
`to address the problem of overflow (as well as underflow). This comes back once
`
`again to a modified argument, which now becomes simply to replace Carmel with
`
`Feig.
`
`(Reply-12—reasonable expectation of success) Amazon seeks to get away
`
`from the fact that the Petition was addressing:
`
`“a data rate more rapid than the playback rate” for all of the media
`data elements sent…. A POSITA would have found it obvious in
`view of Feig to modify Carmel to ensure that the data transmission
`rate is always faster than the playback rate of the requested slice.
`
`Pet.-44-45 (emphasis in original). The Reply now seeks to argue in terms of
`
`“average” rates, which is different from what the Petition had argued.
`
`(Reply-13—characterizing Mr. Hoarty’s testimony) Mr. Hoarty testified to
`
`the opposite of how his testimony is represented here. The cited testimony that a
`
`source transmission “will always arrive faster than the playback rate” was clearly
`
`addressing the rate averaged over time (EX1033-98:9-17) and distinguishing it
`
`from an instantaneous rate. Over a connection having a data rate faster than the
`
`playback rate (as claimed), the elements, on average over the course of a
`
`transmission, will arrive faster than they need to play back. As Mr. Hoarty said,
`
`–11–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`this is the reason for having a buffer for a connection over which the instantaneous
`
`rate may vary. EX1033-94:1-12.
`
`(Reply-14—PO “improperly relying on Carmel’s multiple quality level
`
`embodiment”) The only way to understand Amazon’s argument at Reply-14 is
`
`that (as a consequence of distancing itself from the Fig. 6B embodiment) it is an
`
`express disclaimer of any argument that Carmel’s downshifting the quality level
`
`meets the connection rate limitation.
`
`Furthermore, it is a fiction that the Petition only relied on the “single-level”/Fig.
`
`6A embodiment. For example, on the connection data rate limitation (h), the
`
`Petition argued Carmel’s disclosures about “keeping up” and that “[i]n the event
`
`that a lag is detected,” Carmel will “increase the data transmission or reception
`
`rate” (Pet.-44), citing EX1005-7:36-42. The cited disclosures depend on Carmel’s
`
`disclosures of changing the slices themselves (EX1005-7:42-49), which is only a
`
`feature of the multi-level embodiment, not the single-level embodiment of Fig. 6A.
`
`VI. LIMITATION j
`
`As discussed above, Carmel’s implementation is for the server to push slices
`
`from a specified starting point. Carmel’s server thus must maintain a running
`
`record as to its place in the stream. EX2007 ¶ 66.
`
`To the extent Amazon seeks to rely on Feig for limitation j, it is Amazon’s
`
`burden to point to where Feig makes this disclosure.
`
`–12–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`Amazon’s argument, on pages 50-51 of the Petition, points to alleged “client-
`
`side control” that “does not depend on the server system maintaining a record of
`
`the last media data element sent to the requesting user systems.” The alleged
`
`“client-side control” is addressed on page 50 of the Petition, and points to
`
`“segments from a video stream” as being the media data elements. However,
`
`Amazon does not point to any disclosure in Feig that the segments are the claimed
`
`media data elements, each having its own serial identifier, and there is no such
`
`disclosure. The Petition does not carry Amazon’s burden to the extent Amazon
`
`seeks to rely on Feig for disclosure of limitation j.
`
`As to motivation, there is no reason for Carmel to incorporate this limitation,
`
`and if it did, its own disclosed mechanism would not work. EX2007 ¶ 66.
`
`(Reply-16) The Reply purports to address Carmel here as a push but goes on to
`
`state that its “the principle of operation … rel[ies] on client-server interactions
`
`involving HTTP GET requests for media data elements to provide streaming
`
`services.” This ignores that the push response in Carmel operates by streaming
`
`multiple slices in response to one request, which flatly contradicts Amazon’s
`
`assumption as to limitation j.
`
`(Reply-17) Amazon again misrepresents what was presented in the Petition, in
`
`order to pivot to Feig. The Petition had not stated a general ability to control what
`
`–13–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`was received, but one more specifically tailored to starting the stream. According
`
`to the Petition:
`
`it would allow the client to precisely control and select which
`segments it receives from the server, which supports Carmel’s goal
`of allowing a user to ‘decide and indicate at which slice of data
`stream 40 to begin downloading.’
`
`Pet.-53 (emphasis added). Amazon now changes its alleged motivation as one that
`
`is more generally “[a]llowing the client to precisely control and select the
`
`segments,” when it had made no such argument in the Petition.
`
`(Reply-17, alleged “control” addresses “overruns”) This is a new argument
`
`as to limitation j, which was stated only with regard to limitation k. Pet.-55. The
`
`remainder of the argument again presumes wholesale replacement of Carmel by
`
`Feig.
`
`VII. LIMITATION k
`
`(Reply-18) The Reply addresses what “a” client “may” do with an HTTP
`
`server, which fails to address that the cited reference, Carmel, does not disclose a
`
`client that works that way.
`
`(Reply-19) Amazon argues that if a client seeks individual files, it has to make
`
`individual GET requests. This does not address the fact that Carmel does not
`
`disclose that this is how it streams the data in its files. Amazon does not point to
`
`–14–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`any disclosure in Carmel for individual file requests, and its expert had testified to
`
`the contrary.
`
`Further, Amazon completely misrepresents Mr. Hoarty’s testimony on this issue.
`
`Mr. Hoarty was very clear that Carmel disclosed only pushing slices from a
`
`specified starting point and did not testify as Amazon states.
`
`At EX1033-64, with regard to Carmel, Mr. Hoarty was referring to “at least the
`
`starting point of that … stream,” not one-by-one transmissions. He simply
`
`acknowledged that one-by-one transmissions were possible (EX1033-42:6-15,
`
`“that is one way to retrieve -- by definition, that is one way to retrieve -- retrieve
`
`elements from a server or files from a server, of course.”; EX1033-48:8-49:15,
`
`addressing “the basi[c] framework of the GET request.”; EX1033-63:7-19, stating
`
`only that a request “for a single file” will not return multiple files.)
`
`Amazon’s argument studiously overlooks the fact that HTTP requests are not
`
`limited to “files” and that in HTTP 1.1 (as disclosed in Carmel), a server can
`
`respond to a request with a sequential portion of the content that is being requested.
`
`EX2007 ¶¶ 51, 55.
`
`(Reply-19) Amazon’s argument that Carmel’s use of the word “download”
`
`necessarily reflects individual requests for every element referenced is based on a
`
`selective reading of Carmel.
`
`–15–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`To begin with, Amazon, in a concession nowhere hinted at in its Petition, now
`
`maintains (Reply-7) that it “does not rely” on the Carmel Fig. 6B embodiment. It
`
`is no surprise that Amazon would now try to take this position, as its expert
`
`admitted straight up (as he had to, due to his own prior testimony, referenced
`
`above) that at least the embodiment in Fig. 6B is a push. But there is a further
`
`inconvenient consequence of this (for Amazon), which is that Carmel also uses the
`
`word “downloading” to describe what clients 30 do in that Fig. 6B (push)
`
`embodiment:
`
`FIG. 6B is a flow chart illustrating the operation of clients 30 in
`downloading and playing back multi-level data stream 41 (FIG.
`3D) transmitted from server 36, in accordance with another
`preferred embodiment of the present invention. As in the method of
`FIG. 6A, each client 30 connects to the server, generally using a
`single HTTP link. After reading header 43 and, preferably, making,
`an initial assessment of the link bandwidth, 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.
`
`EX1005-10:64-11:7 (emphasis added). Amazon wisely concedes this disclosure
`
`concerns a push. Note in particular, the italicized words “downloading” and “as in
`
`the method of Fig. 6A” in the above quote. The quote, describing the multi-level
`
`embodiment, certainly does not reflect the “individual requests” that Amazon
`
`claims are tied to the word “download.” Amazon’s argument, then, is that
`
`“downloading” at EX1005-10:65 means something different when used elsewhere
`
`–16–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`in Carmel (even a few lines up in the same column, col. 10, e.g., line 25), which
`
`cannot be correct. The contention that there is some undisclosed but basic
`
`difference in implementation between these embodiments is also implausible. See
`
`EX2007 ¶ 64-65. Amazon’s position is not believable.2
`
`(Reply-19-20, characterizing PO’s argument as “download … refers to
`
`sending files”) PO actually argued (at POR-55-56) “a POSITA understands that
`
`client 30 ‘begins to download’ the sequence of slices because server 36 is sending
`
`them.”
`
`No one disputes that the server in Carmel sends a stream in the first instance in
`
`response to a user request. Once that is done, characterizing as “downloading”
`
`receipt of the stream of elements sent in response does not stretch any definition,
`
`including Amazon’s EX1032. Amazon wants to read in a further requirement for
`
`individual one-by-one requests for each constituent element, but this goes too far.3
`
`
`2 The Board cannot fail to notice that every other expert in the related cases
`
`currently before the Board agrees that Fig. 6B represents a variation upon the base
`
`embodiment in Fig. 6A.
`
`3 (Reply-20, n.4—that Mr. Hoarty “strains credibility [sic]”) Mr. Hoarty’s
`
`testimony does not strain credulity at all. The dictionary Amazon’s counsel showed
`
`him defined “download” as “to send a block of data … to a dependent device.” The
`
`
`
`–17–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`Furthermore, if the client is requesting each file by serial ID, why would it
`
`dispense with an index file for multicast? Clearly, because multicast (EX1005-8:9-
`
`11) serves all clients in lock step with no ability to seek earlier in the stream,
`
`further reflecting that such seeking of a starting point is what the index file is for.
`
`There is no disclosure in Carmel that the index file is needed to stream.4
`
`(Reply-21) Amazon’s argument is in substance simply an argument to
`
`reengineer Carmel as a pull. This again is simply seeking to change the grounds of
`
`this Petition to Feig in view of Carmel.
`
`VIII. DR. JEFFAY’S TESTIMONY
`
`(Reply-21-24) Dr. Jeffay’s prior testimony, collected in the POR (POR-29-30)
`
`speaks for itself.
`
`
`
`
`word can be used either way. A sender can be said to download data to a recipient,
`
`and a recipient can be said to download data from a sender. The latter is even more
`
`clear where, as here, there is no question that the recipient initiates the process
`
`(e.g., by Carmel’s graphical slider, setting a starting point for downloading). The
`
`fact that it has done so in itself teaches nothing about the transfer mechanism.
`
`4 Carmel also uses the term “download” in connection with RTP (a protocol used to
`
`transport data via push). EX1005-2:11-15, 5:25-28, 7:4-8, and twice in the claims.
`
`–18–
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`IX. CONCLUSION
`
`The Board should find all challenged claims not unpatentable.
`
`Dated: October 9, 2023
`
`
`Respectfully submitted,
`
`/Ronald Abramson/
`Ronald Abramson
`(Attorney for Patent Owner)
`Reg. No. 34,762
`212-257-1630
`
`–19–
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`CERTIFICATION UNDER 37 CFR § 42.24(d)
`
`Pursuant to 37 CFR §42.24(d), the undersigned hereby certifies that the
`
`word count for the foregoing Patent Owner Preliminary Response totals 4,107
`
`words, which is less than the 5,600 allowed under 37 CFR §42.24(a)(c)(4).
`
`Dated: October 9, 2023
`
`
`Respectfully submitted,
`
`/Ronald Abramson/
`Ronald Abramson
`(Attorney for Patent Owner)
`Reg. No. 34,762
`212-257-1630
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 CFR § 42.205(b), the undersigned certifies that on October 9,
`
`2023, a complete and entire copy of this Patent Owner Response was provided to
`
`the Petitioner by filing through the Patent Trial and Appeal Case Tracking System
`
`and via email, as authorized in Petitioner’s mandatory notices, by serving the
`
`following email address:
`
`
`
`Dated: October 9, 2023
`
`
`WAG-IPR@fenwick.com
`
`Respectfully submitted,
`
`/Ronald Abramson/
`Ronald Abramson
`(Attorney for Patent Owner)
`Reg. No. 34,762
`212-257-1630
`
`
`
`
`
`
`
`
`
`
`
`