`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`
`
`
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
