`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`______________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________________________________
`
`
`
`THE WALT DISNEY COMPANY, DISNEY STREAMING SERVICES LLC,
`HULU LLC, AND NETFLIX INC.,
`
`Petitioners
`
`v.
`
`WAG ACQUISITION, LLC
`
`Patent Owner
`
`U.S. Pat. No. 9,762,636
`
`
`
`_______________________________________
`
`Inter Partes Review Case No. IPR2022-01227
`
`_______________________________________
`
`
`
`PATENT OWNER’S SUR-REPLY
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`TABLE OF CONTENTS
`
`
`
`I.
`
`INTRODUCTION ............................................................................................. 1
`
`II. POSITA DEFINITION ...................................................................................... 3
`
`III. CLAIM CONSTRUCTION ISSUES ................................................................ 3
`
`A. Construction: Program (Reply, 3) ................................................................. 3
`
`B. Construction: Connection data rate limitation [h] (Reply, 4-5) .................... 5
`
`C. Construction: No server dependency limitation [j] (Reply, 6) ...................... 6
`
`IV. Argument ............................................................................................................ 8
`
`A. Connection rate limitation [h] (Reply, 7) ...................................................... 8
`
`1. No collateral estoppel on connection rate limitation ................................. 8
`
`2. Carmel does not meet the connection rate limitation [h] ........................... 9
`
`B. Limitation [j] (no server dependency on record of last element sent) ........13
`
`C. Limitation [k] ..............................................................................................18
`
`1. Alleged collateral estoppel .......................................................................18
`
`1. Carmel does not limitation [k] (each element sent is responsive to request
`by serial ID) .....................................................................................................19
`
`D.
`
`Inherency .....................................................................................................22
`
`E. No motivation to modify Carmel ................................................................25
`
`F.
`
`Shteyn ..........................................................................................................25
`
`V. CONCLUSION ................................................................................................26
`
`
`
`
`
`
`
`–ii–
`
`

`

`
`
`
`Case IPR2022-01227
`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
`
`Declaration of Henry Houh, Ph.D. Regarding Claims 1-17 of U.S.
`Patent No. 9,729,594, IPR2022-01346, Exhibit 1002
`
`2004
`
`IETF RFC 2068
`
`2005
`
`April 10, 2023, Remote Deposition of Henry Houh, IPR2022-
`01227-28
`
`2006
`
`Declaration of W. Leo Hoarty
`
`2007
`
`IETF RFC 1738
`
`2008
`
`Redline comparison of claims of ’824 and ’636 patents
`
`2009
`
`2010
`
`April 10, 2023, (First) Remote Deposition of Henry Houh,
`IPR2022—01227-28
`
`August 21, 2023, (Second) Remote Deposition of Henry Houh,
`IPR2022—1227-28
`
`
`
`
`
`
`
`
`
`
`
`
`–iii–
`
`

`

`
`
`
`I.
`
`INTRODUCTION
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`As noted in the POR, Petitioner has not shown where Carmel (EX1004), on
`
`which it principally relies, discloses a client that makes successive individual
`
`requests to the server for each of the media data elements that comprise a program
`
`stream. Nor does the Reply point to any such identified evidence it claims the POR
`
`overlooked. In short, the record herein points to no express disclosure in Carmel of
`
`any such individual requests.
`
`In instituting review, the Board cited the fact that Petitioner’s expert said that
`
`such individual requests were “inherent when using the HTTP protocol to
`
`download each of the slice files,” noting that “[a]t this stage of the proceeding,
`
`Patent Owner does not introduce rebuttal testimony.” Inst. Dec. at 44.
`
`That situation has now changed. Patent Owner’s expert has appeared and
`
`rebutted the assertion of inherency.
`
`The Reply (e.g., Reply-1:16-18) refers over and over again to what it asserts is
`
`“Carmel’s repeated disclosure of the client requesting each slice by identifier,” yet
`
`never cites anything in Carmel that says this. The most Petitioner ever does is
`
`merely to characterize what is shown in Figs. 6A and 6B of Carmel and then, as
`
`illustrated on page 19 of the Reply, segue into referring to this as “express
`
`disclosure.” It is a piecewise bootstrap argument, which leaps from an insufficient
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`disclosure to a characterization, which then labels the characterization as “express
`
`disclosure” for the remainder of the submission.
`
`Nowhere in Carmel, from beginning to end, is there express disclosure of
`
`individual element requests that Petitioner has attributed to it. Rather, the case here
`
`rests entirely on alleged inherent disclosure.
`
`Inherency fails as well because inherency implies necessity. Persion
`
`Pharmaceuticals v. Alvogen Malta Oper., 945 F.3d 1184, 1191 (Fed. Cir. 2019).
`
`Under the evidence of record, Petitioner fails to make a showing, as to any
`
`embodiment disclosed in Carmel, that Carmel must, as a matter of technical
`
`necessity, implement streaming by means of successive individual requests for
`
`each of the stream elements.
`
`The above-noted lack of individual element requests in Carmel is an
`
`overarching shortcoming of the Petition. Numerous other shortcomings of Carmel
`
`will be addressed herein as well.
`
`Reply-1:19-20 asserts that, as to the secondary reference, Shteyn, PO argues
`
`contrary to Shteyn’s “express disclosure.” However, all the Petition seeks to rely
`
`on Shteyn for is the server’s selection of elements to send, allegedly without
`
`depending on its own record of what it has previously sent. Petitioner claims there
`
`is express disclosure for this, but as discussed below, has failed to substantiate any
`
`such disclosure.
`
`–2–
`
`

`

`
`
`
`II.
`
`POSITA DEFINITION
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`Petitioner argues for a “POSITA” who lacks familiarity with basic internet
`
`protocols and tools for working with dynamic content and creating interactive web
`
`sites—a person who lacks the skill to see through its flawed inherency arguments.
`
`It is clear from the argument at page 2 of the Reply that Petitioner would prefer a
`
`POSITA that wasn’t aware of the practice of scripting applications for a streaming
`
`media server.
`
`Yet, Dr. Houh himself confirmed that a POSITA would know the basics of TCP
`
`and HTML. EX2009-38:11-39:16 (TCP), 43:3-44:5 (HTTP). It is curious to see
`
`Disney trying to argue against this, to get by with a POSITA who doesn’t even
`
`meet those minimal qualifications and wouldn’t recognize the use of then currently
`
`improved protocol standards by Carmel.
`
`III. CLAIM CONSTRUCTION ISSUES
`
`A. Construction: Program (Reply, 3)
`
`(Reply-3:5-7) (“Program”) Disney does not offer its own construction. It
`
`appears from its argument that a connection’s ability to send any single media data
`
`element during the course of transmission, faster than the playback rate, would
`
`meet this limitation. This extreme construction does not square with the claim
`
`language and other intrinsic as well as extrinsic evidence.
`
`–3–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`The specification addresses a process of streaming a program as a result of a
`
`series of individual element requests. It describes that “the user computer …
`
`continues with additional data requests for the duration of playing the audio/video
`
`material.” EX1001-14:56-58. Reducing the requirements for a connection that can
`
`accommodate those continued requests, so that they are satisfied by the sending of
`
`merely a single element, results in a claimed feature (the connection) that is not
`
`capable of performing as described in the specification and fails to address the
`
`stated object of performing “without disruption.” EX1001-3:49-50.
`
`(Reply-3:16:19) (“all of the media data elements that are sent”). The Reply
`
`argues that only “one or more” elements must be sent, but argues as if “one or
`
`more” reduces to one element. But the claim recites “one or more,” and if more
`
`than one element is sent, then, by the literal claim language, the rate requirement
`
`must apply to all of the “more” elements. The Reply repeatedly fails to address
`
`this.
`
`(Reply-4:1-15) (“delivering a program to the extent you wish to consume it”) It
`
`is hard to see how Disney finds breathing room in the fact that a server need not
`
`continue streaming a program after a user leaves. The claim addresses the steps the
`
`server must perform to stream a program. Disney does not show how the fact that a
`
`user may leave in mid-stream alters the substance of the claimed method.
`
`–4–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`(Reply-4:1-15) (“program” in the ’141 patent) Disney is still arguing here
`
`against claim 10 of the ’141 patent, which is different, as addressed below.
`
`B. Construction: Connection data rate limitation [h] (Reply, 4-5)
`
`(Reply-5:1-5) Significantly, Disney does not dispute that in order for it not to
`
`fail during transmission, the “connection” in this claim must be capable of sending
`
`the elements comprising the program to be transmitted, more rapidly than the
`
`playback rate. EX2006 ¶¶ 20, 24-25, 46.
`
`Disney argues here that the limitation is satisfied where the connection can meet
`
`the playback rate instantaneously, for any one element. The Reply includes the
`
`words “or more” in its quote but fails to give effect to the words “or more” where a
`
`response comprises more than one element.
`
`Disney’s argument is more directed at claim 10 of the ’141 patent than the claim
`
`here. The prior claim recited “[a] server for distributing streaming media” as
`
`opposed to the claims here, e.g., for “[a] method for distributing a program,”
`
`further reciting steps including without limitation a plurality of requests, moreover
`
`successive requests (referencing the “last media data element sent”), and a
`
`connection that possesses a specified rate characteristic for “the one or more media
`
`data elements sent via that connection” – clearly not satisfied by the rate at which
`
`the connection might send a single element. It would be perverse (and legally
`
`incorrect) to disregard all of this further language, as well as the specification
`
`–5–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`disclosure of the object of continuous delivery and how the invention meets it, to
`
`interpret this claim as having the same scope the Board previously attributed to the
`
`differently worded claims in the ’141 patent.
`
`(Reply-5:6-10) Petitioner is ascribing an instantaneous inference to “data
`
`connection,” implying that “data connection” is a transient operating characteristic
`
`rather than referring to physical hardware. The physical characteristics of the “data
`
`connection” are unchanging, even though the operating characteristics vary—as
`
`explicitly contemplated by the ’636 patent. E.g., EX1001-2:34-40.
`
`(Reply-5:11-18) The transfer is over the internet, which the Patent states (and
`
`POSITAs appreciate) simply does not guarantee locked-in transmission rates. But
`
`specified connections (such as, in the specification, the user’s connection with a
`
`56K modem) are understood. The Reply’s argument at 5 seems to argue that the
`
`variability of the internet supports its “instantaneous” construction, where if
`
`anything it is to the contrary. The variability of the internet is the very reason why
`
`a mere instantaneous rate is not sufficient.
`
`C. Construction: No server dependency limitation [j] (Reply, 6)
`
`(Reply-6:2-6) Petitioner did not initially, and does not in its Reply, dispute that
`
`limitation [j] literally applies to where more than one element is selected, and that
`
`in that case, per limitation [j], the elements in excess of one must each be selected
`
`by the server without the specified dependency. The Reply seeks to shift the
`
`–6–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`discussion here to its “entire program” arguments, which do not address the
`
`construction of limitation [j]. Disney has not articulated any actual dispute with
`
`PO’s position on construction of limitation [j].
`
`(Reply-6:7-12) The Reply seeks to argue “client-side control” which is not a
`
`claim term, and which Petitioner doesn’t define.
`
`(Reply-6:14-17) (Limitation [k]: “all” and “each”) Disney takes issue with PO’s
`
`construction, but does not state its own. PO raised this construction in its POR to
`
`address the Board’s suggestion in a later Google institution decision (IPR2022-
`
`01412), that the word “all” in limitation [k] did not imply “each.” The difference at
`
`stake in these constructions of limitation [k] may be illustrated as follows:
`
`Assume the prior art discloses (as PO asserts Carmel does) one request, which
`
`specified only ID-1 (as a starting slice), and not any other IDs, which then spawns
`
`a response of elements with IDs ID-1 .. ID-100.
`
`Construction A: “all” including “each” –
`
`Prior art fails, because ID-2 .. ID-100 were not specified in “the request.”
`
`Construction B: “all” but not necessarily “each” –
`
`Since all slices sent were “requested” (though not necessarily by individual
`
`ID), the prior art would be asserted to apply.
`
`–7–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`However, to be consistent with the ’636 specification (EX1001-14:42-62) and
`
`surrounding claim language, interpretation “B” (push a stream of elements from a
`
`specified starting point) must be incorrect.
`
`(Reply-6:18-20) To the extent the Reply can be taken as in favor of the Board’s
`
`suggestion in the separate Google IPR, the words “or more” in limitation [k] is the
`
`problem for Disney, not the separate question that Disney again presses in this
`
`context, of whether the entire program must be sent.
`
`PO does not discern any argument by Disney that disputes that where a
`
`response does comprise more than one media data element, per limitation [k], each
`
`of the “more” data elements in the response must have been sent responsive to “the
`
`requests,” the antecedent for which is “requests … each received request
`
`specifying one or more serial identifiers of the requested one or more media data
`
`elements.”
`
`IV. Argument
`
`A. Connection rate limitation [h] (Reply, 7)
`
`1.
`
`No collateral estoppel on connection rate limitation
`
`(Reply-7:12-17) (Alleged collateral estoppel on the connection rate limitation
`
`[h]) This assertion assumes the connection rate limitation is met by the ability to
`
`make an instantaneous transfer of one element faster than the playback rate,
`
`contrary to the proper construction.
`
`–8–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`(Reply-7:18-8:5) (comparing ’636 and ’141 claims) The ’636 claims go to a
`
`characteristic of the connection that applies over the elements sent via the
`
`connection, while the prior case (’141 patent) addressed the step of “sending” an
`
`element.
`
`The claims have different wording and thus presumptively have different scope.
`
`(Reply-8:6-9) (issue preclusion) The “issue” litigated here is different, since, as
`
`noted above, the issue concerns a physical characteristic of a data connection with
`
`respect to a program (’636 patent), sent over the connection in tranches of “one or
`
`more” media data elements, versus how, at instantaneous points in time, a stream
`
`element may be sent.
`
`2.
`
`Carmel does not meet the connection rate limitation [h]
`
`(Reply-8:17-20) (Alleged previous finding) The Board previously found only
`
`that Carmel discloses that during normal operation the “data rate” may be
`
`sometimes faster than the playback rate.
`
`However, the claims here all go to the “data rate” of the “connection between
`
`the server system and each requesting user system.”
`
`(Reply-8:19-20) (No “concession”) To the extent the POR at 31 can be read to
`
`attribute to Carmel that the data connection “generally should be equal to or faster”
`
`than the playback rate, this was an error and not intended. The related disclosure
`
`–9–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`from Carmel is that “the data rate [without stating of what] should be generally
`
`equal to or faster than the [playback] rate.” EX1004-2:56-59.
`
`(Reply-9:1-4) (“data rate should be generally equal to or faster”) Carmel’s
`
`disclosure of a mere “data rate” that should be equal to or faster than the playback
`
`rate does not disclose that “the data connection” between the server and each client
`
`should have a data rate that is generally equal to or faster than the playback rate.
`
`Carmel’s reference at 2:56-59 addresses a rate of data transfer but does not tie it
`
`to a single connection.
`
`The very next paragraph in Carmel (EX1004-1:60-67) spells out that such a
`
`“data rate” may be met, for example, by aggregated connections, even though no
`
`single connection meets this limitation. The Federal Circuit in fact reversed in the
`
`prior case when the Board found the corresponding limitation could be met by
`
`aggregating connections. EX2001 at 9-10. The Board here cannot rest its reliance
`
`on this language, with regard to limitation [h].1
`
`(Reply-9:7-19) (client “chooses … quality level appropriate to the bandwidth”)
`
`Choosing a quality level to meet a currently observed bandwidth is not the same as
`
`choosing a connection with a data rate more rapid than the playback rate, which the
`
`
`1 Carmel also teaches that the data rate can also be accommodated by changing the
`
`data to a lower encoding (EX1004-3:5-13).
`
`–10–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`client can expect the server to sustain. The cited disclosure is yet another example
`
`of Carmel seeking to match the playback rate, with no expectation that any
`
`connection will actually sustain performance at greater than the playback rate. The
`
`words “appropriate to” do not necessarily mean less than and do not teach
`
`choosing a connection faster than the playback rate. The concept of matching the
`
`data and transmission bandwidth pervades Carmel and does not teach a connection
`
`having a data rate in excess of the playback rate.2
`
`(Reply-10:11-19) The mere existence of other applications that specified fast
`
`connections does not address motivation to combine. Petitioner’s urging the Board
`
`to dispense with any showing of motivation to combine to support a challenge to
`
`patentability under § 103 courts error. The Reply also seeks to invoke Mr. Hoarty’s
`
`testimony, but this does not stand up. Mr. Hoarty is simply misquoted here. He was
`
`clearly commenting on the requirements of the claims, not the disclosure of
`
`Carmel. EX1029-62:2-15.
`
`It would be error to infer that merely because a POSITA would have known that
`
`connections of various specified speeds could have been procured, at increasing
`
`
`2 The Reply at 10 cites TCP. However, the mere use of TCP says nothing about the
`
`“data rate” of the “connection” that TCP is used over. The Reply here conflates
`
`limitations [h] and [i].
`
`–11–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`cost, the POSITA would therefore have known, without more, to have specified
`
`such a connection for using a certain method of streaming. The POSITA, in
`
`addition to devising the new streaming method based on individual element
`
`requests by serial identifier, would also have had to have realized a method based
`
`on individual element requests would technically require such a connection. The
`
`Petition fails to address this.
`
`The Reply also fails to dispute Mr. Hoarty’s testimony that consistently sending
`
`faster than the playback rate in Carmel would cause Carmel to fail, since Carmel
`
`has no disclosure of a buffer. EX2006 ¶¶ 18, 106; POR at 32. The same can be seen
`
`in Figs. 6A and 6B, in which Petitioner points to no mechanism in the loop to
`
`regulate how rapidly the assumed “requests” would be made.
`
`(Reply-11:1-3) (Petition’s failure to provide a motivation to combine) The
`
`Reply cites the Petition at 35, but neither that page in the Petition, nor ¶¶ 102-107
`
`of the expert declaration that the Petition would (improperly) seek to incorporate
`
`by reference, address any motivation to combine the different examples cited with
`
`Carmel.
`
`(Reply-11:4-12) Petitioner cannot rely on limitation (i) to satisfy limitation (h).
`
`Limitations (h) and (i) are separate limitations and it would be error to conflate
`
`them. What the connection will allow is a separate fact from the data rate of the
`
`connection.
`
`–12–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`B.
`
`Limitation [j] (no server dependency on record of last element
`sent)
`
`(Reply-11:17-21) (collateral estoppel) The term “pointer” is narrower than
`
`“record” – there are records that are not pointers. This being a negative limitation,
`
`the broader negative limitation (“record”) makes the present claim of narrower
`
`scope in this respect. There is thus no collateral estoppel.
`
`(Reply-12:1-9) (“client-side control) Disney repeats the words “client-side
`
`control” (which it does not define) throughout its Reply as if they were part of the
`
`claim language, which they are not. All the client in Carmel “controls” is to request
`
`a program stream and a starting slice for the server’s transmission of that stream.
`
`General terms such as “client-side control” cannot substitute for pointing to where
`
`the prior art discloses the actual claim limitations at issue, which require individual
`
`requests of each of the media data elements comprising the stream, by their serial
`
`IDs. When the server autonomously streams a continuing sequence of such
`
`elements in response to a request that identified only a single starting ID, the server
`
`must maintain a record of what it sent in order to determine the next element to
`
`send. The Reply does not dispute this basic point, but tries to evade it with words
`
`such as “client-side control.”
`
`(Reply-12:18-20) (limitation [j] allegedly follows from client-side control) The
`
`general phrase “client-side control” is not helpful without the ability to distinguish
`
`individual requests by a client from a single client request that starts a stream from
`
`–13–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`a starting point designated by the client, as Carmel does. Nor does mere “lack of
`
`specialized server software,” as what is involved is only software that makes use of
`
`open standards, such as HTTP 1.1.
`
`(Reply-12:18-20) (downloads over one or two HTTP links) What is missing
`
`here is any disclosure of individual requests as required by the claims. Disney
`
`needs to show individual requests by serial ID in order to negate the otherwise
`
`certain conclusion that the server must be determining the elements to send. But it
`
`does not point to any such disclosure. The fact that a client downloads slices over a
`
`link, or over two links “in successive alternation,” does not show that the client is
`
`requesting the slices over the link(s). As pointed out in the POR (at 38, 40), the
`
`server could equally well determine which elements to send and send them over
`
`the link(s), either on an individual link, or on a plurality of links that have been
`
`opened, in successive alternation, which will equally well result in the client
`
`“downloading” the slices. The disclosure simply does not reflect any client
`
`requests to the server for individual slices by slice ID, other than the single request
`
`that starts the stream of slices.
`
`(Reply-13:6-10) (“push” reading of Carmel is “wrong”). This argument fails to
`
`point to disclosure in Carmel of other than a push system.
`
`Dr. Houh insists that Fig. 6B represents the same “individual request” behavior
`
`he reads into Fig. 6A. In Fig. 6A, he interprets the words “one or two links, over
`
`–14–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`which files … are downloaded” as if it said “one or two links, over which the client
`
`requests files”—which Carmel does not disclose.3
`
`When he gets to Fig. 6B and is asked about “[r]esponsive to the [client’s]
`
`selection, server 36 begins to transmit data slices,” he maintains that the words
`
`“server … begins to transmit” actually means that the client is making individual
`
`requests for what the server is transmitting. See EX2010-38:25-40:24.
`
`Neither passage actually states that the client “requests” anything, let alone
`
`successive slices, individually.
`
`Dr. Houh dismisses the even more clear statement in Carmel with regard to Fig.
`
`6B attributing the successive “transmit” action to the server as “high level”
`
`(EX2010-38:25-39:17), as if Carmel at this point in its disclosure was merely
`
`glossing over critical details.
`
`It is Dr. Houh that is glossing over details, by writing off express disclosure in
`
`the reference that is contrary to his hypothesis, as “high level.”
`
`
`3 Dr. Houh also confirmed that even if serving over multiple links the server-side
`
`process would have information identifying a user’s links and the slices sent to the
`
`user. EX2010-90:10-98:25.
`
`–15–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`The Fig. 6B embodiment is expressly preferably over a single HTTP link. Dr.
`
`Houh did not dispute that HTTP could in fact “push” over a single link. EX2010-
`
`71:23-25.
`
`Dr. Houh does not even contend, and could not plausibly explain, why two
`
`illustrative figures illustrating alternate embodiments would operate by two
`
`completely different mechanisms, which would impact the bandwidth requirements
`
`if they indeed differed, with no mention of any such difference.
`
`The fact is also that Carmel claimed these two alternatives in one series of
`
`claims of diminishing scope—totally consistent with the alternatives having a
`
`common base mechanism (and difficult to explain if otherwise). Dr. Houh indeed
`
`maintains that the Fig. 6B embodiment is an enhancement of the Fig. 6A
`
`embodiment that works by the same underlying mechanism. EX2010-42:11-43:7.
`
`But he wants to read “download,” which simply reflects a transfer of data, as
`
`implying an unstated “request” for the data from the receiving end, and then
`
`disregard “server 36 begins to transmit” as “high-level” gloss that doesn’t really
`
`mean what it says.
`
`By maintaining these disclosures are fundamentally the same, Dr. Houh must
`
`not only address the word “download,” which he appears to find easier to bend to
`
`his preferred reading, he must also address the more difficult (for him) “server
`
`begins to transmit,” but he fails to do so.
`
`–16–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`Carmel also has approximately two dozen disclosures, each of which states that
`
`the data rate may be “equal to” the playback rate. E.g., EX1004 Abstract, 4:2, 3:39,
`
`3:59, 4:2, 4:24, 4:62 etc. (numerous like disclosures). Petitioner does not dispute
`
`Mr. Hoarty’s testimony (EX2006 ¶ 25) that a data rate merely “equal to” the
`
`playback rate will not work for a sliced, individual request streaming mechanism.
`
`By failing to take any issue with this, and yet arguing that both Figs. 6A and 6B
`
`(i.e., the entirety of Carmel) represent individual slice request implementations,
`
`Disney could only say that the repeated “equal to” disclosures of Carmel would be
`
`inoperable. Of course, streaming successive slices from a specified starting point
`
`can work with a data rate generally equal to the playback rate.
`
`Dr. Houh also cannot claim that both the single and multi-level Carmel
`
`embodiments operate on the same principle and claim that it is “inherent” that that
`
`principle is an individual request mechanism in both cases, and yet argue for
`
`“necessity” to support inherency with respect to only one of the implementations
`
`(Fig. 6A). If “individual requests” are inherent in the operating principle of the
`
`one, it must be inherent in the principle of the other, where he claims the
`
`–17–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`underlying mechanisms of the two to be equivalent. He cannot just ignore the
`
`embodiment he finds troublesome.4
`
`(Reply-13:11-18) (again pursuing “client-side control”) The client in Carmel
`
`controls where to start the stream, and how to synchronize playback after the
`
`stream is received. But reading the claim to cover this would make the claim much
`
`broader than its terms.
`
`Merely repeating the mantra “client-side control” does not satisfy the need for
`
`actual citations. It begs the question of client control of what? It is not a substitute
`
`for finding disclosure of the actual claimed features.
`
`C. Limitation [k]
`
`1.
`
`Alleged collateral estoppel
`
`(Reply-14:2-19) The heading here as well as the argument that follows glosses
`
`the limitations of the prior and present claims to argue that they are identical,
`
`where they are not.
`
`
`4 Dr. Houh says both embodiments are allegedly pull by reason of inherency yet
`
`does not dispute that there is no inherency on the preferred (one link) form of the
`
`6B embodiment. The only interpretation that is fully consistent is “push” streaming
`
`from a specified starting point—it accounts for every disclosure, even multicast
`
`(EX1004-8:9-11). Pull by individual slice requests is not inherent in any disclosed
`
`embodiment.
`
`–18–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`The Reply at 14-20 glosses over the (k) limitation, the actual effect of which is
`
`to add a further “wherein” limitation that the server sends no elements other than
`
`those requested by serial ID.
`
`The claim at issue with respect to the ’141 patent did not recite this. With such
`
`differences, there can be no collateral estoppel on Carmel meeting this limitation of
`
`the ’636 or ’824 patents.
`
`1.
`Carmel does not limitation [k] (each element sent is
`responsive to request by serial ID)
`
`(Reply-15:1-15) (alleged “clear” teaching of individual requests). The argument
`
`ties this to “an” HTTP link as well as “two” HTTP links, and claims “clear”
`
`disclosure that the client is making individual slice requests, without citing one
`
`statement to that effect.
`
`(Reply-15:16-20) (client opens links allegedly means it is making requests over
`
`the links) The fact that the client opens the link is irrelevant to the issue of how the
`
`link is used; in either case the client or server could stage alternation over a link
`
`initially opened by the client. The client opened the first link as well, and this is
`
`clearly immaterial. The argument still begs the question posed in the POR.
`
`(Reply-16:1-4) (Fig. 6A) The Reply fails to point out where this flow chart
`
`shows “requests” for the individual elements, and it does not.
`
`–19–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`On each loop traversal there may be a singular slice, but this does not reflect
`
`whether the slice got there because it was individually requested or simply because
`
`the server sent it as part of a series.
`
`(Reply-17:3-8) (HTTP FROM SERVER) As the Reply notes, the client receives
`
`the HTTP elements from the server. There is nothing disclosed here about requests
`
`to the server.
`
`(Reply-17:9-15) (Fig. 6B) Carmel’s disclosure at EX1004-11:9-18 is that the
`
`embodiment corresponding to Fig. 6B can select a new encoding rate. All this
`
`means is that the client, by doing so, is asking the server to push elements with a
`
`different encoding than the server is currently pushing. No individual element
`
`request is shown.
`
`(Reply-17:16-20) (re: “Yes” loop) This is mere attorney argument trying to
`
`interpret the figure where its expert failed to do so.
`
`It is also incorrect by presupposing that “HTTP FROM SERVER” means
`
`“HTTP Request to server.” Of course, the loop must go to the second box “HTTP
`
`FROM SERVER” since the client must receive the data that is being decoded.
`
`Furthermore, the Reply’s explanation provides no way for the supposed
`
`individual “requests” to be redirected to another quality level without revising the
`
`disclosed scheme of element numbering. EX2006 ¶¶ 111, 125. The Reply is
`
`–20–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`completely silent with regard to pages 42-43 of the POR and EX2006 ¶ 125, which
`
`point out Dr. Houh’s error.
`
`(Reply-18:2-6) (cit