throbber
IPR2022-01433
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket