`Petitioner Reply to Patent Owner Response
`Filed on behalf of Amazon.com, Inc., Amazon Web Services, Inc.,
`and Amazon.com Services LLC
`
`By:
`J. DAVID HADDEN (Reg. No. 40,629)
`SAINA SHAMILOV (Reg. No. 48,266)
`BRIAN HOFFMAN (Reg. No. 39,713)
`JOHNATHAN CHAI (Reg. No. 75,690)
`JOHNSON KUNCHERIA (Reg. No. 69,093)
`KEVIN MCGANN (Reg. No. 48,793)
`FENWICK & WEST LLP
`801 California Street
`Mountain View, CA 94041
`Telephone: 650.988.8500
`Facsimile: 650.938.5200
`
`
`
`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,
`Petitioner,
`
`v.
`
`WAG ACQUISITION, LLC,
`Patent Owner.
`
`
`Case No. IPR2022-01433
`Patent 9,762,636
`_____________
`PETITIONER REPLY TO PATENT OWNER RESPONSE
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`V.
`
`Page
`INTRODUCTION .......................................................................................... 1
`I.
`II. MOTIVATIONS TO COMBINE THE REFERENCES ................................ 1
`III. CARMEL DISCLOSES A “PULL” SYSTEM .............................................. 2
`IV. THE PETITION RELIES ON CARMEL’S SINGLE QUALITY
`LEVEL EMBODIMENT ................................................................................ 6
`CARMEL AND FEIG DISCLOSE THE “RATE” OF
`LIMITATION H ............................................................................................. 8
`VI. CARMEL AND FEIG DISCLOSE THAT THE ELEMENTS
`ARE SENT WITHOUT DEPENDING ON THE SERVER
`SYSTEM TO MAINTAIN A RECORD OF THE LAST
`ELEMENT SENT PER LIMITATION J ..................................................... 14
`VII. CARMEL AND FEIG DISCLOSE THAT ALL OF THE
`ELEMENTS ARE SENT IN RESPONSE TO THE REQUESTS
`PER LIMITATION K ................................................................................... 18
`VIII. DR. JEFFAY’S TESTIMONY IS CONSISTENT ....................................... 21
`
`
`
`
`
`
`i
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`TABLE OF AUTHORITIES
`
`Page(s)
`
`CASES
`B & B Hardware, Inc. v. Hargis Indus., Inc.,
`575 U.S. 138 (2015) ............................................................................................ 10
`OTHER AUTHORITIES
`Restatement (Second) of Judgments ........................................................................ 10
`
`
`
`
`
`
`ii
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`EXHIBIT LIST (37 C.F.R. § 42.63(e))
`
`Exhibit
`
`1001
`
`1002
`
`1003
`
`1004
`
`1005
`
`Description
`
`U.S. Patent No. 9,762,636
`
`Declaration of Kevin Jeffay, Ph.D.
`
`Curriculum vitae of Kevin Jeffay, Ph.D.
`
`File History of U.S. Patent No. 9,762,636 (Abridged)
`
`U.S. Patent No. 6,389,473
`
`1006 Willebeek-LeMair et al. “Bamba—Audio and video streaming over the
`Internet,” published in 1998
`
`1007
`
`1008
`
`1009
`
`1010
`
`Declaration of Rachel Watters re Willebeek
`
`Defendants’ Opening Claim Construction Brief (Dkt. 37), No. 6:21-cv-
`00815-ADA (W.D. Tex.)
`
`Declaration of Dan Schonfeld (Dkt. 37.1), No. 6:21-cv-00815-ADA
`(W.D. Tex.)
`
`Plaintiff’s Responsive Claim Construction Brief (Dkt. 38), No. 6:21-cv-
`00815-ADA (W.D. Tex.)
`
`1011
`
`Declaration of Keith J. Teruya (Dkt. 38.1), No. 6:21-cv-00815-ADA
`(W.D. Tex.)
`
`1012
`
`1013
`
`1014
`
`1015
`
`1016
`
`Defendants’ Reply Claim Construction Brief (Dkt. 42), No.
`6:21-cv-00815-ADA (W.D. Tex.)
`
`Plaintiff’s Sur-Reply Claim Construction Brief (Dkt. 47), No. 6:21-cv-
`00815-ADA (W.D. Tex.)
`
`PCT Publication No. WO 1997/044942
`
`U.S. Patent No. 8,122,141
`
`U.S. Patent No. 6,668,088
`
`iii
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`
`Exhibit
`
`Description
`
`1017
`
`1018
`
`1019
`
`1020
`
`1021
`
`1022
`
`1023
`
`1024
`
`1025
`
`1026
`
`1027
`
`1028
`
`1029
`
`1030
`
`U.S. Patent No. 5,533,138
`
`U.S. Patent No. 5,469,212
`
`U.S. Patent No. 6,314,137
`
`U.S. Patent No. 6,848,004
`
`U.S. Patent No. 6,728,763
`
`Scheduling Order (Dkt. 35), No. 6:21-cv-00815-ADA (W.D. Tex.)
`
`Defendants’ Motion to Transfer Venue (Dkt. 30), No. 6:21-cv-00815-
`ADA (W.D. Tex.)
`
`United States District Courts Statistics
`
`Plaintiff’s Responsive Claim Construction Brief (Dkt. 39), No. 6:21-cv-
`00816-ADA (W.D. Tex.)
`
`Declaration of Keith J. Teruya (Dkt. 39.1), No. 6:21-cv-00816-ADA
`(W.D. Tex.)
`
`Defendants’ Reply Claim Construction Brief (Dkt. 43), No. 6:21-cv-
`00816-ADA (W.D. Tex.)
`
`Plaintiff’s Sur-Reply Claim Construction Brief (Dkt. 45), No. 6:21-cv-
`00816-ADA (W.D. Tex.)
`
`“Transmission Control Protocol,” IETF RFC793, published in
`September 1981
`
`TCP/IP Illustrated, Vol. 1, The Protocols, W. Richard Stevens,
`published in 1994
`
`1031
`
`U.S. Patent No. 6,175,862
`
`1032 Microsoft Computer Dictionary. Fifth ed. (additional excerpt)
`
`1033
`
`August 3, 2023, Deposition of W. Leo Hoarty
`
`
`
`iv
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`I.
`INTRODUCTION
`Patent Owner does not contest that the combination of Carmel, Feig, and
`
`Willebeek discloses challenged claims 1-12. Patent Owner instead mischaracterizes
`
`Carmel as disclosing a “push” system that a POSITA would not have combined with
`
`the other references. But Patent Owner’s arguments rely on a misreading of Carmel,
`
`conflate separate embodiments disclosed in Carmel, and contradict a final decision
`
`of the Board with respect to disclosures related to data connections and rates.
`
`II. MOTIVATIONS TO COMBINE THE REFERENCES
`Patent Owner attacks the specific motivations to combine Carmel and Feig
`
`provided by the Petition with respect to limitations h, j, and k. See, e.g., POR, 41-
`
`51 (h), 53-54 (j), 58-61 (k). Petitioner addresses each of these arguments below
`
`when discussing the respective limitation.
`
`Stepping back, it is important to keep in mind that Patent Owner fails to
`
`dispute all of the motivations to combine the references provided in the Petition,
`
`including motivations the Board listed and discussed in the Institution Decision at
`
`pages 60-61. Patent Owner also does not dispute motivations the Petition provides
`
`at page 17 and interspersed throughout the remainder of the document. See, e.g.,
`
`Pet., 33 (using serial identifiers to simplify the operation of the combined system),
`
`34 (maintaining slices in a data structure to more readily respond to requests from
`
`clients).
`
`1
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`For example, the Petition demonstrates that the combination would “expand
`
`the types of servers that could be used within Carmel’s system by inducing
`
`‘a non-streaming server to simulate a streaming server.” Pet., 39 (citing EX1031,
`
`1:9-10). The Board was preliminarily persuaded by this motivation and flags it in
`
`the Institution Decision at pages 62-63 as a reason to combine the references. Patent
`
`Owner does not address this motivation.
`
`Similarly, the Petition demonstrates that a POSITA would have been
`
`motivated to combine Carmel, Feig, and Willebeek “to quickly move data slices
`
`from the server to the client to support playback with a minimum of dropouts.” Pet.,
`
`49-50. The Institution Decision specifically calls out this motivation on page 61.
`
`Patent Owner does not address this motivation.
`
`For these reasons alone, Patent Owner fails to rebut that claims 1-12 of U.S.
`
`Patent No. 9,762,636 are invalid.
`
`III. CARMEL DISCLOSES A “PULL” SYSTEM
`Patent Owner’s position rests on whether Carmel discloses a push or pull
`
`system. The Petition demonstrates that Carmel discloses a system in which clients
`
`“read an index file” identifying slices of a multimedia program “and request or pull
`
`the sequential slices by identifier.” Pet., 14 (citing EX1005, 10:25-48, FIG. 6A,
`
`2
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`7:39-8:5, 2:51-59, 11:9-22; EX1002, ¶68).1 Specifically, a POSITA in possession
`
`of Carmel “would have recognized that each slice file may be requested individually
`
`using an HTTP GET request, and the server would send each requested slice to the
`
`user system in response,” i.e., Carmel is a pull system. Pet., 54.
`
`Patent Owner took issue with this assertion in its Preliminary Response,
`
`arguing that “Carmel is fundamentally a ‘push’ system in which the server paces
`
`delivery of slices to the client with relatively little feedback from the client, rather
`
`than a “pull” system . . . in which the client specifically requests each media data
`
`element from the server.” POPR, 31; see POR, 3 fn.1 (providing similar definitions
`
`of “push” and “pull”). In its Institution Decision, the Board recognized that “Carmel
`
`does not explain details about HTTP” and found based on the preliminary record
`
`that “HTTP downloading in Carmel using an HTTP GET request for each slice file
`
`demonstrates what was well known in the art.” Institution Decision, 58. The Board
`
`invited Patent Owner to rebut this finding at trial. Id.
`
`Patent Owner does not rebut or deny that downloading files using HTTP GET
`
`requests was well-known in the art. Patent Owner’s expert, Mr. Hoarty, agreed in
`
`
`1 The parties agree that Feig discloses a pull system. See, e.g., Pet., 41 (demonstrating
`
`that Feig teaches a pull system in which the server system sends requested media
`
`data elements to user systems); POR, 60 (confirming same).
`
`3
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`his deposition that using HTTP GET requests in this manner was commonplace.
`
`See, e.g., EX1033, 12:25-13:3 (a POSITA would have had a background with the
`
`HTTP protocol and its evolution), 18:2-4 (GET request is most common request in
`
`HTTP 1.1), 18:15-20 (GET request is way for a client to retrieve content from a
`
`server), 18:21-19:5 (client must first make GET request to obtain content from a
`
`server), 26:25-27:7 (when a client receives data from a server, it is implied that the
`
`client is making at least one request), 48:7-19 (individual files are requested using
`
`individual requests).
`
`Indeed, other experts confirm that Carmel teaches a POSITA to use HTTP
`
`GET requests to retrieve individual files. EX2010, 111:2-5 (Dr. Jeffay: “because
`
`GET requests are so common and ubiquitous, Carmel teaches to a [POSITA] a
`
`download can occur over a GET request”); EX2021, 81:10-83:21 (Dr. Houh: Carmel
`
`teaches to a POSITA that “the client is asking for each of the files” using HTTP GET
`
`requests).
`
`Patent Owner instead advances a different argument in its Response. Patent
`
`Owner argues that Carmel teaches use of a data transfer technique new to HTTP 1.1
`
`called “chunked transfer encoding,” which is purportedly a “push.” POR, 58
`
`(“HTTP itself evolved during the period in question to support push forms of
`
`streaming, and it is exactly this capability that is reflected in Carmel.”), 60 (“Carmel
`
`actually teaches use of the then-new push-type streaming features of HTTP 1.1
`
`4
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`(EX1005-2:26-28)”); see EX2007, ¶51 (referring to this technique as “chunked
`
`transfer encoding”); EX2013, 639:1-5 (same).
`
`This argument is based on a single passage in Carmel referring to two different
`
`embodiments:
`
`Preferably, each segment or slice is contained in a separate, respective
`file. Alternatively, the segments or slices may all be contained in a
`single indexed file, which is streamed to the client in a series of packets,
`each covering a range of one or more indices. HTTP version 1.1
`supports this sort of file streaming. Other protocols may also be used
`for this purpose.
`
`EX1005, 2:22-28 (emphasis added); see POR, 21-22, 31, 60 (citing to portions of
`
`this passage). Patent Owner relies on the third sentence in this passage as disclosing
`
`the “chunked transfer encoding.” POR, 21; EX2007, ¶51.
`
`Carmel is clear, however, that chunked transfer encoding is an alternative to
`
`the preferred embodiment. The quoted passage explicitly states that each segment
`
`or slice is preferably “contained in a separate, respective file.” EX1005, 2:22-23. It
`
`goes on to explain that in an alternative embodiment, “the segments or slices may
`
`all be contained in a single indexed file, which is streamed to the client in a series of
`
`packets.” EX1005, 2:23-25. When Carmel says “HTTP version 1.1 supports this
`
`sort of file streaming” (EX1005, 2:26-27 (emphasis added)), it is referring to the
`
`“stream[ing]” mentioned in the previous sentence, in which the segments or slices
`
`are “contained in a single indexed file.” EX1005, 2:24-25.
`
`5
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`Thus, Carmel at most discloses the use of chunked transfer encoding in a
`
`non-preferred single-file embodiment. Mr. Hoarty agreed in his deposition that this
`
`encoding is more suited to larger files than smaller files. EX1033, 36:23-37:22
`
`(“chunked transfer uses an indexed file as a means of sending a larger . . . message.”).
`
`Dr. Houh said much the same thing. EX2021, 118:20-119:5 (“I’ve heard [chunked
`
`transfer encoding] referred to cases where portions of a very large file may be
`
`transmitted in chunks.” It “doesn’t apply in a case where the file is broken up into a
`
`series of slice files as disclosed in Carmel.”).
`
`Accordingly, Carmel discloses to a POSITA a preferred embodiment in which
`
`clients use HTTP GET requests to retrieve segments or slices contained in separate,
`
`respective files. This is a pull system under Patent Owner’s own definition. POR,
`
`3 fn.1 (“Pull is understood to mean the client actively retrieves data from the server
`
`and thus itself paces delivery.”). Carmel is similar in this respect to Feig, which
`
`Patent Owner agrees is a pull system. POR, 60; see EX1031, 5:16-18 (describing
`
`HTTP GET requests for files); EX1002, ¶73 (discussing Feig); Institution Decision,
`
`59 (same).
`
`IV. THE PETITION RELIES ON CARMEL’S SINGLE QUALITY LEVEL
`EMBODIMENT
`Both parties agree that Carmel discloses two embodiments: a single quality
`
`level embodiment illustrated by data stream 40 of FIG. 3A and the method of
`
`FIG. 6A, and a multiple quality level embodiment illustrated by data stream 41 of
`
`6
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`FIG. 3D and the method of FIG. 6B. See, e.g., EX1005, 7:18-58 (description of FIG.
`
`3A), 10:24-63 (description of FIG. 6A), 8:42-9:9 (description of FIG. 3D), 10:64-
`
`11:22 (description of FIG. 6B); EX2010, 146:3-11 (Dr. Jeffay distinguishing data
`
`streams 40 and 41 as two “separate and quite distinct embodiments”); EX2007, ¶52
`
`(Mr. Hoarty referring to “different embodiments”); EX1033, 43:4-8 (Mr. Hoarty
`
`confirming data streams 40 and 41 are different embodiments).
`
`The Petition focuses on data stream 40 and the method of FIG. 6A, i.e., the
`
`single quality level embodiment. See, e.g., Pet., 13-14 (overview of Carmel). For
`
`example, the Petition explains that Carmel supplies media data elements per
`
`limitation c with reference to the slices of FIG. 6A. Pet., 29-30. Likewise, the
`
`Petition demonstrates that Carmel discloses serially identifying the media data
`
`elements per limitation d with reference to data stream 40 and FIG. 3A. Pet., 31.
`
`The Petition consistently refers to Carmel’s single quality level embodiment for
`
`contested limitations h, j, and k as well. See Pet., 45 (citing to the description of
`
`FIG. 3A for limitation h), 50-51 (citing to the description of FIG. 6A for limitation j),
`
`54 (referring to FIG. 6A for limitation k).
`
`Many of Patent Owner’s arguments, however, depend on Carmel’s slices
`
`having multiple quality levels—Carmel’s embodiment on which the Petition does
`
`not rely. See, e.g., POR, 25-28 (describing multiple quality levels). For example,
`
`Patent Owner asserts that Carmel’s description of the server transmitting data at a
`
`7
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`chosen quality level “reflects a push.” POR, 26. Patent Owner attempts to resolve
`
`this disconnect between the arguments in its Response and the grounds raised in the
`
`Petition by asserting that “Figure 6A of Carmel is a base embodiment upon which
`
`Figure 6B adds additional features.” POR, 28. Patent Owner also points to a few
`
`places where Dr. Jeffay cited to portions of Carmel from both embodiments to make
`
`unrelated points. POR, 34-35. But it is undisputed that Carmel’s two embodiments
`
`are different. EX2010, 60:1-6 (Dr. Jeffay: Figure 6B “is talking about a different
`
`data stream embodiment” than Figure 6A); EX1033, 43:8 (Mr. Hoarty: “I agree.
`
`They’re different.”). Accordingly, Patent Owner’s arguments for the individual
`
`claim limitations fail for the reasons provided below.
`
`V. CARMEL AND FEIG DISCLOSE THE “RATE” OF LIMITATION H
`Limitation h recites that “the data connection between the server system and
`
`each requesting user system has a data rate more rapid than the playback rate . . . .”2
`
`Patent Owner does not dispute that limitation h is met by Feig. See POR, 37, 42
`
`(mentioning Feig only in passing); Pet. 45 (explaining why Feig discloses limitation
`
`h); EX1002, ¶132 (same). Patent Owner instead argues that Carmel fails to disclose
`
`
`2 Patent Owner’s construction of “data rate” at pages 10-14 of its Response is
`
`inconsistent with Mr. Hoarty’s testimony and contradicts the finding of the Board in
`
`IPR2016-01238 for the reasons provided below.
`
`8
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`this limitation and attacks the combination of Carmel with Feig. POR, 38-51. In
`
`essence, Patent Owner argues that a POSITA would not have modified Carmel in
`
`view of Feig because using a suitably fast data connection with Carmel’s system
`
`would be problematic.
`
`Carmel explicitly states that “the data rate should be generally equal to or
`
`faster than the rate at which the data are generated at the transmitting computer.”
`
`EX1005, 2:51-29; Pet., 44; POR, 37. The Board made a preliminary finding in the
`
`Institution Decision that “Carmel’s disclosure of an ‘equal to or faster’ data rate
`
`teaches a ‘faster’ data rate.” Institution Decision, 45. This finding is consistent with
`
`the final decision in IPR2016-01238, in which the Board recognized that “Patent
`
`Owner did not specifically dispute that Carmel teaches transmission faster than the
`
`playback rate.” IPR2016-01238, Paper No. 28, 18; Pet., 43. Carmel thus discloses
`
`limitation h because Carmel’s data connection between the server and user systems
`
`may have “a data rate more rapid than the playback rate of the one or more media
`
`data elements sent via that connection.”
`
`Patent Owner argues that Carmel’s “generally equal to or faster than”
`
`disclosure is not referring to the data rate of the connection but may instead be
`
`referring to an aggregate link. POR, 38. This argument contradicts the finding of
`
`the Board in IPR2016-01238, which recognized that “this passage is describing the
`
`‘sufficient rate’ during normal streaming operation (uploading and downloading of
`
`9
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`data to and from the server), not the later-described embodiments using multiple
`
`links as one way to compensate for lag or slow connections.” IPR2016-01238
`
`(EX2017), Paper No. 28, 18 (favorably quoting Petitioner in that IPR); Institution
`
`Decision, 44. Furthermore, Patent Owner is precluded from challenging the Board’s
`
`final decision in IPR2016-01238. B & B Hardware, Inc. v. Hargis Indus., Inc., 575
`
`U.S. 138, 148 (2015) (according to the Restatement (Second) of Judgments, issue
`
`preclusion applies “[w]hen an issue of fact or law is actually litigated and determined
`
`by a valid and final judgment, and the determination is essential to the judgment, the
`
`determination is conclusive in a subsequent action between the parties, whether on
`
`the same or a different claim”) (citation omitted).
`
`The remainder of Patent Owner’s argument for limitation h is devoted to
`
`explaining why a POSITA would not have modified Carmel alone or in view of Feig.
`
`POR, 41-51. To the extent modification is necessary, it would have been obvious to
`
`a POSITA in view of Feig for the reasons provided in the Petition, namely “to ensure
`
`that the transmission or reception is ‘keeping up’ with the input of the data” to the
`
`client. Pet., 45 (citing EX1005, 7:36-40); EX1002, ¶133.
`
`Patent Owner’s specifically argues that a POSITA would not have found a
`
`suitably fast data connection obvious because the Internet “does not guarantee timely
`
`delivery” and is “subject to irregular transmission.” POR, 42. Patent Owner is
`
`apparently arguing that a fast data connection would not have been obvious because
`
`10
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`a faster connection may not always be faster. POR, 42-44. This argument is
`
`inconsistent with Mr. Hoarty’s testimony. He said that the server need only attempt
`
`to send at faster than the playback rate to meet the claim. EX1033, 104:14-17
`
`(“I would say the server needs to attempt to send -- well, the server will transmit
`
`faster than playback rate, but some of the -- some of the data sent will be lost.”).
`
`Patent Owner does not dispute that Carmel’s server sends the slices as fast as the
`
`data connection between the server system and each requesting user system allows.
`
`See POR, 18 (not contesting limitation i). Dr. Jeffay also testified, and Mr. Hoarty
`
`confirmed, that such fast data connections were well-known in the art. EX1002,
`
`¶134; EX1033, 90:2-8. Moreover, the challenged patent does not describe any new
`
`network technology that guarantees a suitably fast data rate while accounting for
`
`network congestion. EX1033, 94:1-7.
`
`Patent Owner next argues that Carmel teaches away from using a suitably fast
`
`data connection because it will absorb the increase in data rate by increasing the data
`
`quality level. POR, 44-47. The gist of Patent Owner’s position is that “the client
`
`must be able to adapt the data encoding to use the additional bandwidth” of a faster
`
`data connection “in order to avoid overrunning the client with data.” POR, 45. This
`
`argument is not applicable to Carmel’s single quality level embodiment. Mr. Hoarty
`
`confirmed that Carmel’s description of stream 40 and FIG. 3A, on which Petition
`
`11
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`relies, does not describe changing stream quality levels during transmission at all.
`
`EX1033, 53:25-54:4.
`
`To the extent overrunning the client with data is a problem, 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. Pet., 55; EX1002, ¶159. In other
`
`words, a POSITA would have resolved this issue by allowing the client to precisely
`
`control and select which elements it receives from the server. EX1002, ¶160.
`
`Patent Owner also argues there is no reasonable expectation of success. POR,
`
`47-49. Patent Owner asserts that a POSITA could not “ensure that the data
`
`transmission rate is always faster than the playback rate” because “a POSITA would
`
`have had no reason to believe that this could even be done.” POR, 47-48; see also
`
`id., 42 (discussing related issue). This is because “the connection speed could
`
`transiently dip below the playback rate, even if an apparently adequate connection
`
`speed was specified.” POR, 49.
`
`This argument is inconsistent with Mr. Hoarty’s testimony. He interprets the
`
`claimed “data rate” to be the “average rate that accounts for congestion in the . . .
`
`internet.” EX1033, 92:19-93:3. As he puts it, “[o]n average, the data to the client
`
`needs to be faster than playback rate.” EX1033, 98:9-10. He says “it’s obvious and
`
`clear [in limitation h] that the . . . data rate is filling a cache in a receiver system to
`
`stay ahead of congestion and playback rate combined.” EX1033, 98:24-99:9.
`
`12
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`Further, Mr. Hoarty says that in this situation the data “will always arrive faster than
`
`the playback rate.” EX1033, 101:3-5; see also id. 95:2-4 (client uses pull to always
`
`stay ahead of congestion), 102:5-14 (server meets claim when it always tries to send
`
`data faster than the playback rate), 103:20-24 (system compensates for network
`
`delay by always sending to the client faster than the playback rate), 107:3 (“The data
`
`rate is going to always be faster.”).
`
`This is what Feig discloses. EX1031, 6:21-31; see EX1002, ¶132.
`
`Specifically, Feig discloses a pull system in which one minute of video is delivered
`
`over a network in 30 seconds. Id.; Institution Decision, 45-47. Patent Owner fails
`
`to explain why a POSITA would “have had no reason to believe that this could even
`
`be done” (POR, 48) when Feig teaches how to do it.
`
`Patent Owner’s next argument is that “[m]erely supplying a faster connection”
`
`will compromise the reliability of Carmel’s system. POR, 49. This is purportedly
`
`because using a faster data connection with Carmel’s system “will overflow the
`
`memory of the player.” POR, 50. This argument incorrectly assumes that Carmel’s
`
`single quality level embodiment is a push system, and it is not as described above.
`
`Moreover, to the extent overrunning the client with data is a problem, 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. Pet., 55; EX1002,
`
`¶¶159, 160.
`
`13
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`Patent Owner’s final argument is that Carmel will degrade the presentation
`
`due to network lag, even if a suitable data connection is used. POR, 50-51; EX2007,
`
`¶87. While neither Patent Owner nor its expert explains why or how Carmel’s
`
`presentation will degrade, they appear to be improperly relying on Carmel’s multiple
`
`quality level embodiment. They fail to relate this argument to Carmel’s single
`
`quality level embodiment referenced in and relied upon by the Petition.
`
`VI. CARMEL AND FEIG DISCLOSE THAT THE ELEMENTS ARE
`SENT WITHOUT DEPENDING ON THE SERVER SYSTEM TO
`MAINTAIN A RECORD OF THE LAST ELEMENT SENT PER
`LIMITATION J
`Limitation j recites that the “media data element[s] sent are selected without
`
`depending on the server system maintaining a record of the last media data element
`
`sent . . . .” Carmel discloses a client downloading the data stream starting from an
`
`identified point. Pet., 50-51; EX1005, 10:36-54. The client displays a graphic slider
`
`allowing the user to indicate the starting point. Id. Carmel thus provides a client-
`
`side control for requesting sequential media data elements. Pet., 51-52; IPR2016-
`
`01238, Paper No. 22 at 26. This client-side control does not depend on the server
`
`system maintaining a record of the last media data element sent to the requesting
`
`user systems as recited in limitation j. EX1002, ¶151.
`
`Patent Owner argues there is no evidence Carmel discloses “individual
`
`requests for slices by serial ID such that the server need not make its own
`
`determination of the identification of any slice to send.” POR, 52. But Patent Owner
`
`14
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`does not contest that Carmel discloses limitation f, which involves the server
`
`“receiving requests . . . for one or more of the media data elements . . . each received
`
`request specifying one or more serial identifiers . . . .” Pet., 35-38. Thus, there is
`
`ample unrebutted evidence in the Petition that Carmel contains such disclosure.
`
`Patent Owner also asserts that Carmel’s server “responses send more than one
`
`slice (indeed send[] the entire stream after the first slice is selected).” POR, 52.
`
`Mr. Hoarty expands on this argument in his declaration, saying “Carmel’s server
`
`must maintain a record of the last slice it sent to the user system in order to determine
`
`which slice to send next.” EX2007, ¶66. However, Mr. Hoarty admitted in his
`
`deposition that the client issues a HTTP GET request for the initial slice at the
`
`starting point. EX1033, 51:24-52:11. He also confirmed that Carmel discloses
`
`slices being stored in separate files and admitted that the client would need to issue
`
`additional HTTP GET requests when the slice files are separate, which Carmel
`
`identifies as the preferred embodiment. EX1033, 63:7-19. Thus, in Carmel there is
`
`no need for the server to maintain a record of the last slice sent. EX1002, ¶151
`
`(“Since . . . playback occurs by requesting sequential segments, it is unnecessary for
`
`the server to track the segment state.”).
`
`Further, Patent Owner does not dispute that Feig alone and in combination
`
`with Carmel teaches limitation j. See POR, 53-54. Instead, Patent Owner asserts
`
`15
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`that the Petition failed to provide sufficient rationale for combining the references.
`
`POR, 54-55.
`
`The crux of Patent Owner’s argument is that Carmel’s single quality level
`
`embodiment is a push system, Feig is a pull system, and the combination of the two
`
`references would change the operating principle of Carmel. POR, 53. But this
`
`premise is incorrect, as both the single quality level embodiment of Carmel and Feig
`
`are pull systems, as described above. Even if Carmel’s single quality level
`
`embodiment was a push system, and it is not, the combination would not change the
`
`principle of operation as both Carmel and Feig rely on client-server interactions
`
`involving HTTP GET requests for media data elements to provide streaming
`
`services.
`
`Patent Owner also challenges motivations for the combination stated in the
`
`Petition, that 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.’”
`
`POR, 54; Pet. 53; EX1002, ¶¶154-155. According to Patent Owner, Carmel already
`
`supports the ability of the user to decide and indicate where to begin downloading,
`
`and there is no need to combine Carmel and Feig to meet this goal. POR, 54.
`
`But Patent Owner is misinterpreting the motivations. A POSITA would have
`
`been motivated to make this combination because the client making requests for
`
`16
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`media data elements per Feig allows the client to precisely control and select which
`
`segments it receives. EX1002, ¶¶154-155. The Board recognized this aspect as a
`
`separate motivation. Institution Decision, p. 61.
`
`Allowing the client to precisely control and select the segments it receives
`
`enables the combined Carmel-Feig system to operate without depending on the
`
`server maintaining a record of the last media data element sent, which is beneficial
`
`given that HTTP is a stateless protocol and Carmel uses a standard network server.
`
`Pet. 52; EX1002, ¶¶153-155; EX1033, 39:24-40:1; EX1005, 2:17-21. Allowing the
`
`client to precisely control and select the segments it receives also addresses an
`
`alleged defect in Carmel raised by Patent Owner – the risk of client buffer overruns.
`
`Pet., 54-55; EX1002, ¶159; POR, 46; EX2007, ¶¶84-85; EX1033, 138:2-15
`
`(Mr. Hoarty explaining that buffer overflow can be addressed by monitoring buffer
`
`fullness and making client requests).
`
`Feig’s solution complements Carmel’s goal of allowing a user to decide and
`
`indicate at which slice to begin downloading. In other words, a POSITA would have
`
`recognized that Carmel and Feig work well together. EX1002, ¶155 (the
`
`“combination is no more than using a known technique in Feig to improve . . .
`
`Carmel in the same way”). Moreover, to the extent “Carmel does not explain details
`
`about HTTP” (Institution Decision, 58), Feig provides the missing explanation for
`
`17
`
`
`
`IPR2022-01433
`Petitioner Reply to Patent Owner Response
`how a client can use HTTP to precisely control and select which segments it receives
`
`and thereby indicate at which slice to begin downloading. EX1031, 5:16-18.
`
`VII. CARMEL AND FEIG DISCLOSE THAT ALL OF THE ELEMENTS
`ARE SENT IN RESPONSE TO THE REQUESTS PER LIMITATION K
`Limitation k recites that “all of the media data elements . . . are sent in response
`
`to the requests.”3 Carmel indisputably discloses a preferred embodiment in which
`
`each slice is stored as a separate file. EX1005, 2:22-23; EX1033, 63:7-19. In
`
`addition, the client may indisputably retrieve such slices by making HTTP GET
`
`requests for each respective slice file. EX10