DOCKET NO.: 410797-000029
`Filed on behalf of The Walt Disney Company, Disney Streaming Services LLC,
`and Hulu LLC
`By: Larissa S. Bifano, Reg. No. 59,051
`Thomas Fuller, Reg. No. 74,439
`
`DLA Piper LLP (US)
`33 Arch Street, 26th Floor
`Boston, Massachusetts 02110-1447
`Email: larissa.bifano@us.dlapiper.com
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`The Walt Disney Company, Disney Streaming Services LLC, and Hulu LLC
`
`Petitioner
`
`v.
`
`WAG Acquisition LLC,
`
`Patent Owner
`
`IPR2022-01227
`Patent 9,762,636
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE TO
`
`PETITION
`
`
`Filed on behalf of The Walt Disney Company, Disney Streaming Services LLC,
`and Hulu LLC
`By: Larissa S. Bifano, Reg. No. 59,051
`Thomas Fuller, Reg. No. 74,439
`
`DLA Piper LLP (US)
`33 Arch Street, 26th Floor
`Boston, Massachusetts 02110-1447
`Email: larissa.bifano@us.dlapiper.com
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`The Walt Disney Company, Disney Streaming Services LLC, and Hulu LLC
`
`Petitioner
`
`v.
`
`WAG Acquisition LLC,
`
`Patent Owner
`
`IPR2022-01227
`Patent 9,762,636
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE TO
`
`PETITION
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`TABLE OF CONTENTS
`INTRODUCTION .......................................................................................... 1
`
`PATENT OWNER’S POSITA DEFINITION IS UNSUPPORTED ............ 2
`
`I.
`
`II.
`
`III. CLAIM CONSTRUCTIONS OFFERED BY PO ARE IMPROPER ........... 3
`
`A.
`
`B.
`
`C.
`
`D.
`
`Program ................................................................................................ 3
`
`Claim Limitations [1.h]/[5.h]/[9.h] [EX1001, 16:57-60] ..................... 4
`
`Claim Limitations [1.j], [5.j], [9.j] [EX 1001, 16:64–67] .................... 6
`
`Claim Limitations [1.k], [5.k], [9.k] [EX1001, 17:1–3] ...................... 6
`
`IV. CARMEL RENDERS OBVIOUS CLAIMS 1-12 OF THE ’636
`
`PATENT ......................................................................................................... 7
`
`A.
`
`Claim Limitations [1.h]/[5.h]/[9.h] ...................................................... 7
`
`1.
`
`PO is collaterally estopped on the issue of Carmel having
`
`a data connection with a data rate faster than the
`
`playback rate .............................................................................. 7
`
`2.
`
`Carmel teaches claim limitations [1.h]/[5.h]/[9.h] ..................... 8
`
`B.
`
`Claim Limitations [1.j]/[5.j]/[9.j] ....................................................... 11
`
`i
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`1.
`
`PO is collaterally estopped on the issue of Carmel
`
`disclosing that the media data elements are selected
`
`without the server maintaining a record .................................. 11
`
`2.
`
`Carmel teaches claim limitations [1.j], [5.j], [9.j] ................... 12
`
`C.
`
`Claim Limitations [1.k]/[5.k]/[9.k] .................................................... 14
`
`1.
`
`PO is collaterally estopped on the issue of that Carmel
`
`teaches that the server sends media data elements in
`
`response to requests from the client ......................................... 14
`
`Carmel teaches claim limitations [1.k]/[5.k]/[9.k] ................... 15
`
`Carmel Inherently Teaches a Client Request System .............. 20
`
`A POSITA Would Have Modified Carmel.............................. 23
`
`2.
`
`3.
`
`4.
`
`V.
`
`CARMEL AND SHTEYN RENDERS OBVIOUS CLAIMS 1-12 OF
`
`THE ’636 AND ’824 PATENTS.................................................................. 24
`
`A.
`
`Carmel and Shteyn Render Obvious Claim Limitation [1.j],
`
`[5.j], [9.j] ............................................................................................ 24
`
`B.
`
`A POSITA Would Have Combined Carmel and Shteyn ................... 26
`
`VI. NO SECONDARY CONSIDERATIONS; DEPENDENT CLAIMS ......... 27
`
`VII. CONCLUSION ............................................................................................. 27
`ii
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`TABLE OF AUTHORITIES
`
`Cases
`
` Page(s)
`
`Google LLC v. WAG Acquisition, L.L.C.,
`IPR2022-01412, Paper 8 (PTAB Mar. 23, 2023)…………………………4, 6
`
`M2M Sols. LLC v. Amazon.com, Inc.,
`2023 U.S. App. LEXIS 4053 (Fed. Cir. 2023)…………………………7, 8, 14
`
`Google LLC v. Hammond Dev. Int’l, Inc.,
`54 F.4th 1377 (Fed. Cir. 2022)……………………………………………….8
`
`Ariosa Diagnostics v. Verinata Health, Inc.,
`805 F.3d 1359 (Fed. Cir. 2015)……………………………………………..10
`
`Lyft, Inc. v. Agis Software Development LLC,
`IPR2022-00513, Paper 24 (PTAB May 25, 2023)…………………………..10
`
`Zynga Inc. v. IGT,
`IPR2022-00199, Paper 32 (PTAB June 8, 2023)……………………………10
`
`WebPower, Inc. v. WAG Acquisition,
`IPR2016-01238, EX2001 (PTAB Mar. 30, 2017)…………………………18
`
`Hospira, Inc. v. Fresenius Kabi USA, LLC,
`946 F.3d 1322 (Fed. Cir. 2020)…………………………………………….20
`
`Intel Corp. v. PACT XPP Schweiz AG,
`61 F.4th 1373 (Fed. Cir. 2023)……………………………………………..24
`
`iii
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`PETITIONER’S EXHIBIT LIST
`
`Exhibit
`
`Description
`
`1001
`
`1002
`
`1003
`
`1004
`
`1005
`
`1006
`
`1007
`
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`
`1014
`
`U.S. Patent No. 9,762,636
`
`Declaration of Dr. Henry Houh
`
`File History of U.S. Patent No. 9,762,636
`
`U.S. Patent No. 6,389,473 to Carmel et al.
`
`U.S. Patent No. 8,122,141 to Price
`
`Final Written Decision, WebPower v. WAG Acquisition, LLC,
`IPR2016-01238, Paper No. 22 (Dec. 26, 2017)
`
`Final Written Decision on Remand, WebPower v. WAG
`Acquisition, LLC, IPR2016-01238, Paper No. 28 (July 16, 2020)
`
`U.S. Patent No. 7,529,806 to Shteyn
`
`Order Setting Pretrial Deadlines, No. 2:21-cv-08230 JAK(EX),
`Dkt. No. 64 (CDCA)
`
`Joint Motion To Transfer To The Northern District Of
`California And To Vacate All Pending Deadlines, No. 6:21-cv-
`01083-ADA, Dkt. No. 48 (WDTX)
`
`“Positive COVID Tests Derail Intel Patent Trial In WDTX”,
`Ryan Davis, https://www.law360.com/ip/articles/1487451
`(April 26, 2022)
`
`Plaintiff’s Responsive Claim Construction Brief, No. 6-21-cv-
`00816, Dkt. No. 39 (WDTX)
`
`Declaration of Keith J. Teruya, No. 6-21-cv-00816, Dkt. No.
`39-1 (WDTX)
`
`Plaintiff’s Sur-Reply Claim Construction Brief, No. 6-21-cv-
`00816, Dkt. No. 45 (WDTX)
`
`iv
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`Plaintiff’s Responsive Claim Construction Brief, No. 6-21-cv-
`00815, Dkt. No. 38 (WDTX)
`
`Declaration of Keith J. Teruya, No. 6-21-cv-00815, Dkt. No.
`38-1 (WDTX)
`
`U.S. Patent No. 6,728,763 to Chen
`
`IETF RFC793 published in September 1981.
`
`TCP/IP Illustrated, Volume 1 by W. Richard Stevens published
`in 1994.
`
`U.S. Patent No. 6,848,004 to Chang
`
`WO1997044942 to Kliger
`
`U.S. Patent No. 6,668,088 to Werner et al.
`
`U.S. Patent No. 5,533,138 to Kim et al.
`
`U.S. Patent No. 5,469,212 to Lee
`
`U.S. Patent No. 6,314,137 to Ono et al.
`
`Defendants Google LLC and YouTube, LLC’s Reply Claim
`Construction Brief, No. 6-21-cv-00816, Dkt. No. 43 (WDTX)
`
`Stipulation Letter sent to Litigation Counsel for WAG
`Acquisition LLC. on July 13, 2022.
`
`U.S. Patent No. 6,557,041 to Mallart
`
`July 6, 2023, Remote Deposition of W. Leo Hoarty, IPR2022-
`01227-28
`
`Supplemental Declaration of Henry Houh, Ph.D. In Support of
`Petitioner’s Reply to Patent Owner Response
`
`1015
`
`1016
`
`1017
`
`1018
`
`1019
`
`1020
`
`1021
`
`1022
`
`1023
`
`1024
`
`1025
`
`1026
`
`1027
`
`1028
`
`1029
`
`1030
`
`v
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`I.
`
`INTRODUCTION
`
`The Walt Disney Company, Disney Streaming Services LLC, and Hulu
`
`LLC, (collectively “Petitioner”) established in its Petition that Carmel (and Carmel
`
`in combination with Shteyn) renders all claims of U.S. Pat. No. 9,762,636 (the
`
`’636 patent) invalid as obvious. The ’636 patent’s claims also materially overlap
`
`with the claims of related U.S. Pat. No. 8,122,141 (EX1005) (the ’141 patent) that
`
`the Board found unpatentable over Carmel. EX1006; EX1007. Thus, Patent
`
`Owner (“PO”) should be subject to collateral estoppel on the issues previously
`
`litigated as to Carmel.
`
`Nevertheless, PO’s arguments attempting to salvage its claims fail. PO, in
`
`its Patent Owner Response (Paper 15, “POR”), attempts to rewrite the claim
`
`language of the ’636 patent and the substance of Carmel itself. For instance, PO
`
`attempts to construe the claims without intrinsic evidence support as being limited
`
`to “distributing an entire program over the internet, and not merely some portion
`
`of a program.” (POR 11) (emphasis added).
`
`PO also seeks to characterize this IPR as push vs. pull to divert the Board’s
`
`attention away from the actual language in the claims and Carmel’s repeated
`
`disclosure of the client requesting each slice by identifier.
`
`Lastly, PO argument as to Carmel and Shteyn is contrary to Shteyn’s express
`
`disclosure.
`
`1
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`II.
`
`PATENT OWNER’S POSITA DEFINITION IS UNSUPPORTED
`
`Petitioner’s POSITA definition is similar to the one adopted in a prior
`
`proceeding against PO. EX1007, 12-13. Thus, Petitioner respectfully believes it
`
`likewise should be adopted here.
`
`While PO “largely agrees” with it (POR 9), PO contends that a POSITA
`
`should further have “some theoretical understanding . . with basic internet
`
`protocols and tools for working with dynamic content and creating interactive web
`
`sites . . . .” EX2006, ¶13.
`
`This should be rejected because PO cites no intrinsic evidence support, and
`
`such additions render the POSITA definition unbounded and confusing with “some
`
`theoretical understanding” and “tools for working with dynamic content,” as
`
`confirmed during the deposition of WAG’s expert W. Leo Hoarty (“Hoarty”).
`
`EX1029 (“Hoarty Tr.”) at 20:17-25:16; EX1030, ¶¶13-15.
`
`PO forced this definition because, without it, PO’s argument that Carmel is a
`
`server push system deteriorates as PO argues that a POSITA would write a script
`
`“for generating dynamic web content.” EX2006, ¶87; POR 47-48. This is illogical
`
`as discussed below.
`
`Regardless, Dr. Houh is a POSITA under either definition because of his
`
`PhD degree and significant research and work experience since the early 1990s in
`
`streaming media. EX1002, ¶¶6-20; EX1030, ¶16.
`2
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`III. CLAIM CONSTRUCTIONS OFFERED BY PO ARE IMPROPER
`
`Petitioner believes plain and ordinary meaning should apply (Pet., 9), and
`
`PO’s constructions are contradicted by the intrinsic record and even their expert.
`
`Program
`A.
`PO contends “program” recited in the claimed preambles should be
`
`construed as “entire program” because “steps, a-g” allegedly streams the entire
`
`program. POR 11-12. This is wrong for several reasons.
`
`First, the ’636 Patent only recites “program,” not an “entire program,” and
`
`the claims of the ’636 Patent never mention the word “entire.” EX1030, ¶¶8, 22
`
`Second, the claimed steps do not support PO’s argument. The instituted
`
`claims recite requesting and sending “one or more of the media data elements,” not
`
`the entire program. EX1001, claim 1 (“receiving requests . . . for one or more of
`
`the media data elements” and “sending, by the server system, the one or more
`
`media data elements”); POR 12-13, 18 (“regardless of whether what is being sent
`
`is one element or more than one element”); EX1030, ¶23.
`
`Likewise, the claim language, “all of the media data elements that are sent,”
`
`is unhelpful to PO as that refers to the previously recited “responsive to the
`
`requests, sending, by the server system, the one or more media data elements,” not
`
`that the entire program must be sent. EX1030, ¶24; see Google LLC v. WAG
`
`3
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`Acquisition, L.L.C., IPR2022-01412, Paper 8, at 38 (Mar. 23, 2023) (“limitation
`
`calls for ‘all’ . . . does not require every slice to be requested by slice number.”).
`
`Hoarty’s testimony further undermines PO’s proposed construction. He
`
`contends that the entire program means the system must be “capable of delivering
`
`a program to the extent you wish to consume it” which, according to Hoarty’s
`
`definition, would mean the construction of “program” depends on each user’s
`
`consumption at a point in time, e.g., consuming 5 minutes or some other duration
`
`of a two-hour movie. Hoarty Tr., 31:13-33:7 (emphasis added); EX1030, ¶25.
`
`Finally, the term “program” is recited multiple times in the ’141 Patent, and
`
`PO never sought a construction of the term “program” as “entire program.”
`
`EX1006, 9-10. This shows PO’s new construction is not credible, especially given
`
`“program” should have the same meaning in related family members.
`
`Thus, there is no support for PO rewriting the claims as streaming an “entire
`
`program . . . from beginning to end” (POR 16), and this flawed construction
`
`weakens several of PO’s other constructions which hinge on “entire program.”
`
`Claim Limitations [1.h]/[5.h]/[9.h] [EX1001, 16:57-60]
`B.
`PO argues that the limitation, “the data connection between the server
`
`system and each requesting user system has a data rate more rapid than the
`
`playback rate of the one or more media data elements sent via that connection,” is
`
`for the “data rate … over the entire streaming of the program.” POR 13-15.
`4
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`This construction rests on the incorrect construction of “program” as “entire
`
`program.” Accordingly, the plain and ordinary meaning of the term connotes that
`
`the data connection between the server system and each requesting user system is
`
`only required to be more rapid than the playback of the one or more media data
`
`elements. Pet., 9-10.
`
`PO’s construction is further deficient because there cannot be a “data
`
`connection more rapid than the playback rate, which is in effect during the entire
`
`program transmission, from beginning to end” (POR 16) while still having
`
`“interruptions with an internet connection” and other delays. POR 13; EX2006,
`
`¶25; EX1015, 15-16.
`
`PO attempts to cast this conflict as relating to an “instantaneous transfer
`
`rate” (POR 13), but PO provides no analysis for why this resolves such conflict.
`
`Indeed, the ’636 Patent never mentions “instantaneous transfer rate,” and confirms
`
`that there are “unanticipated transmission delays and losses that are inherent in
`
`many Internet protocols.” EX1001, 2:34-40. Hoarty admits the connection cannot
`
`always be faster “[b]ecause the internet can’t do that . . . But in general, it needs
`
`to be faster . . . [and] realizes there’s congestion that’s not controllable.” Hoarty
`
`Tr., 68:2-15 (emphasis added).
`
`Accordingly, PO’s construction should be rejected.
`
`5
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`Claim Limitations [1.j], [5.j], [9.j] [EX 1001, 16:64–67]
`C.
`PO requests construction for the limitation “the one or more media data
`
`elements sent are selected without depending on the server system maintaining a
`
`record of the last media data element sent to the requesting user systems,”
`
`(EX1001, 16:64–67) but it is unclear what construction PO is asserting other than
`
`the flawed “entire program.” POR 18.
`
`Further, PO did not request a construction on similar claim language in the
`
`’141 IPR (“server does not maintain a pointer into a buffer established within said
`
`server, for each said user”). EX2006, ¶43; POR 1. Thus, Petitioner believes the
`
`Board should follow its prior precedent for this limitation to determine if a
`
`reference has “client-side control” and “a lack of specialized server software.”
`
`EX1006, 26; EX1007; Pet., 44; Paper 11, 40.
`
`Claim Limitations [1.k], [5.k], [9.k] [EX1001, 17:1–3]
`D.
`PO appears to argue that the claim limitation “all of the media data elements
`
`that are sent by the server system to the plurality of user systems are sent in
`
`response to the requests” (EX1001, 17:1–3) applies to “each and every element” of
`
`the stream. POR 20.
`
`Yet, the claim only recites the “the one or more media data element[s]” that
`
`are sent in response to requests, not the entire program as discussed above.
`
`Google, IPR2022-01412, Paper 8, at 38; EX1001, claim 1.
`6
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`IV. CARMEL RENDERS OBVIOUS CLAIMS 1-12 OF THE ’636 PATENT
`
`A.
`
`Claim Limitations [1.h]/[5.h]/[9.h]
`1.
`PO is collaterally estopped on the issue of Carmel having a
`data connection with a data rate faster than the playback
`rate
`Collateral estoppel occurs when, “(1) the issue is identical to one decided in
`
`the first action; (2) the issue was actually litigated in the first action; (3) resolution
`
`of the issue was essential to a final judgment in the first action; and (4) had a full
`
`and fair opportunity to litigate the issue in the first action.” M2M Sols. LLC v.
`
`Amazon.com, Inc., Nos. 2022-1122, 2022-1124, 2023 U.S. App. LEXIS 4053, at
`
`*9 (Fed. Cir. Feb. 22, 2023).
`
`The issue of whether Carmel teaches “the data connection between the
`
`server system and each requesting user system has a data rate more rapid than the
`
`playback rate of the one or more media data elements sent via that connection” is
`
`the same as the Board found in the ’141 Patent. EX1007, 6 (’141 Patent: “send
`
`media data elements . . . at a rate more rapid than the rate at which said streaming
`
`media is played back by a user”), 16-23.
`
`There is no material difference between the rate limitations of the ’636 and
`
`’141 patents because both refer to transmitting media data elements more rapid
`
`than a playback rate, which the Board previously concluded Carmel teaches.
`
`Notably, PO requests the Board apply the Federal Circuit’s decision construing the
`7
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`same limitation above in the ’141 Patent to this case, which necessarily concedes
`
`common issues were previously litigated. POR 6-7. And, as discussed, the ’141
`
`Patent recites “program” just as in the ’636 Patent. M2M, at *10-11 (“M2M is
`
`collaterally estopped from arguing that Kloba failed to disclose ‘consumer usage
`
`information’”).
`
`PO argues that collateral estoppel does not apply because claim 1 of the ’636
`
`Patent differs from the ’141 Patent claims. POR 5. But, collateral estoppel applies
`
`to “issues” litigated, not entire claims. Google LLC v. Hammond Dev. Int’l, Inc.,
`
`54 F.4th 1377, 1381 (Fed. Cir. 2022); M2M, 2023 at *9.
`
`Lastly, this issue was litigated to final written decision and was critical to the
`
`remand decision. EX1007, 16-23. Accordingly, PO had a full and fair opportunity
`
`to litigate the issue. Id.
`
`Carmel teaches claim limitations [1.h]/[5.h]/[9.h]
`2.
`As discussed, the claim limitations do not require the entire program to be
`
`delivered at a rate more rapid than the playback rate and thus Carmel teaches these
`
`limitations.
`
`The Board previously found Carmel has a data connection that sends data
`
`faster than the playback rate in two ways. Pet., 36-39; Paper 11, 31-35; EX1007,
`
`18-23. Moreover, PO concedes that “Carmel discloses that the data connection
`
`may at times be more rapid than the playback rate, and that it ‘generally
`8
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`should be’ equal to or faster.” POR 31 (emphasis added). This concession meets
`
`its own expert’s requirement for these claim limitations that “in general, it needs
`
`to be faster.” Hoarty Tr., 68:2-15 (emphasis added). Accordingly, Carmel teaches
`
`claim limitations [1.h]/[5.h]/[9.h].
`
`Even if PO’s ambiguous construction of an “entire program” is adopted,
`
`Carmel teaches this claim limitation for three reasons.
`
`First, Carmel teaches that every segment (or slice) would be transmitted
`
`faster than the playback rate, because Carmel states “[e]ach of clients 30 chooses . .
`
`. the quality level appropriate to the bandwidth of its link on network 28 to server
`
`36.” Pet. 38; EX1004, 9:6-9, 4:43-47 (“downloading the sequence includes
`
`determining a data bandwidth of the network between the server and the client
`
`computer and selecting one of the quality levels responsive to the determined
`
`bandwidth.”), 1:50-53 (“object . . . to provide . . . high-bandwidth data streaming
`
`over a network”); EX1002, ¶109. This transmitting the quality level below the
`
`available bandwidth meets Hoarty’s understanding of these claim limitations.
`
`Hoarty Tr., 67:6-18 (“It means that the bandwidth location of that channel is at a
`
`higher rate than the bit rate of the program being transmitted.”). This also meets
`
`PO’s litigation understanding of the limitations as simply bandwidth capacity.
`
`EX1015, 15-17 (PO arguing “wrong” to state “data rate” is an actual rate).
`
`9
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`Relatedly, Carmel teaches TCP (EX1007, 24), which PO’s litigation expert
`
`stated maximizes the connection rate or would use the available bandwidth to
`
`transmit the media elements. EX1013, ¶30. Thus, Carmel’s TCP disclosure
`
`teaches these limitations.
`
`Second, “it was well known in the art that the data rate or bandwidth
`
`capacity can be more rapid than the encoding or playback rate.” Pet., 36 (citation,
`
`footnote omitted). Dr. Houh cites multiple prior art references detailing why it was
`
`known to a POSITA to transmit data faster than the playback rate. EX1002,
`
`¶¶102-107; Ariosa Diagnostics v. Verinata Health, Inc., 805 F.3d 1359, 1365 (Fed.
`
`Cir. 2015).
`
`Importantly, Hoarty does not dispute and in fact concedes this point,
`
`including that the references “utilize data connections more rapid than the playback
`
`rate for those implementations.” EX2006, ¶110; Paper 11, 34-35. Rather, PO
`
`argues that there is insufficient motivation to combine and reasonable expectation
`
`of success. POR 32-34. However, this is not required because a POSITA’s
`
`knowledge alone is sufficient. See Lyft, Inc. v. Agis Software Development LLC,
`
`IPR2022-00513, Paper 24, fn 13 (May 25, 2023) (“We disagree with Patent Owner
`
`that Petitioner was required to . . . demonstrate a reason or motivation to
`
`combine”); Zynga Inc. v. IGT, IPR2022-00199, Paper 32, at 36 (June 8, 2023).
`
`10
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`PO further contends that this argument was not provided in the Petition.
`
`POR 34. Not so. The Petition specifically identified this argument with Dr. Houh
`
`providing further basis for it. See Pet., 36.
`
`Third, PO has not challenged that Carmel teaches claim limitations
`
`[1.i]/[5.i]/[9.i] or “each sending is at a transmission rate as fast as the data
`
`connection between the server system and each requesting user system allow[s].”
`
`(emphasis added). Necessarily, if Carmel teaches [1.i] /[5.i]/[9.i], it must teach
`
`claim limitations [1.h]/[5.h]/[9.h] because if Carmel is sending each slice “as fast
`
`as the data connection . . . allows,” the data connection would be at its maximum
`
`or faster than the playback rate for the entire program. EX1015, 17 (PO asserting
`
`that “data rate” means “data elements . . . are always sent as fast as the connection
`
`will allow.”).
`
`B.
`
`Claim Limitations [1.j]/[5.j]/[9.j]
`1.
`PO is collaterally estopped on the issue of Carmel disclosing
`that the media data elements are selected without the server
`maintaining a record
`The issue of whether Carmel teaches “the one or more media data elements
`
`sent are selected without depending on the server system maintaining a record of
`
`the last media data element” is the same issue as the one the Board found taught by
`
`Carmel in the ’141 Patent. EX1006, 26 (’141 Patent, claim 15: “… server does not
`
`maintain a pointer into a buffer established within said server, for each said user”)
`11
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`PO contends in a footnote that the “claim language here is materially
`
`different,” but tellingly does not provide any explanation of these alleged
`
`differences. POR 37. This is because the Board’s finding that Carmel teaches
`
`claim 15 of the ’141 Patent with “client-side control” and “a lack of specialized
`
`server software” (EX1006, 26) applies equally to the ’636 Patent claim limitations
`
`[1.j]/[5.j]/[9.j]. Indeed, PO and Hoarty admit the “challenged claims are drawn to
`
`the pull embodiment . . . [where] the server in the pull embodiment ‘does not
`
`maintain a pointer’ marking the position of each user in the stream.” POR 1
`
`(citation omitted), 8, 15; EX2006, ¶¶21, 43.
`
`This issue was litigated to final written decision in the ’141 IPR, and PO had
`
`a full and fair opportunity to litigate the issue. EX1006, 25; EX1007.
`
`Carmel teaches claim limitations [1.j], [5.j], [9.j]
`2.
`Carmel teaches claim limitations [1.j], [5.j], [9.j] because Carmel describes
`
`“client-side control” and “a lack of specialized server software.” EX1006, 26; Pet.,
`
`44. PO never confronted such evidence, even though cited in the institution
`
`decision and Petition. Paper 11, 40 (citing EX1006); EX1006, 25, 26 (discussing
`
`Carmel at 2:17-21, 10:45-54, 8:32-41); Pet., 44.
`
`Petitioner outlined that the client controls the selecting of slices, not the
`
`server: “client 30 opens one or two HTTP links, over which files 42, 44, 46, etc.,
`
`are downloaded in successive alternation . . . ” by “read[ing] index file 50 (FIG.
`12
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`3B), and graphic 56 (FIG. 3C) is displayed by the client, so that a user can decide
`
`and indicate at which slice of data stream 40 to begin downloading. Responsive to
`
`a user input, client 30 selects an appropriate starting slice and begins to download
`
`and decode (decompress) files 42, 44, 46, etc.” EX1004, 10:36-54, 8:23-41;
`
`EX1002, ¶¶123-126; Pet. 43; Paper 11, 40.
`
`PO argues that the Petition only addressed selecting one element which
`
`causes other elements to be transmitted. POR 35-37. However, this is wrong and
`
`is indicative of PO’s characterization that Carmel is limited to a server “push”
`
`system (POR 38; EX2006, ¶¶117, 120), which is refuted below with respect to
`
`claim limitations [1.k]/[5.k]/[9.k].
`
`The client-side control described in Carmel is further reinforced given a
`
`“user . . . may choose to begin downloading data stream 40 from an earlier point in
`
`time than that indicated by ID 52” (EX1004, 8:7-9; EX1002, ¶125; Paper 11, 40)
`
`and “Carmel explains its client-side control by including slice indices in the data
`
`stream, which are ‘used by the clients in maintaining synchronization’ and which
`
`‘allows the broadcast to go on substantially in real time without the use of special-
`
`purpose hardware.’” Paper 11, 40 (quoting EX1004, 2:17–21); EX1006, 26;
`
`EX1002, ¶126.
`
`13
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`C.
`
`Claim Limitations [1.k]/[5.k]/[9.k]
`1.
`PO is collaterally estopped on the issue of that Carmel
`teaches that the server sends media data elements in
`response to requests from the client
`Carmel’s disclosure of this limitation was already litigated in the ’141 Patent
`
`with the Board stating, “[a]s Petitioner contends, Carmel describes causing the
`
`server to receive requests from the user system for such media data elements,
`
`specifying such identifiers” and send such requested media data elements.
`
`EX1006, 16 (citation omitted), 28, 5 (’141 Patent, claim 10: “server to receive
`
`requests from the user system for one or more media data elements specifying the
`
`identifiers of the requested data elements . . . cause the server to send media data
`
`elements to the user system responsive to said requests”), 6; EX1007, 16-23.
`
`Thus, Carmel teaches this limitation because the client requests each media
`
`data element by serial identifier from the server which sends such requested
`
`elements. M2M, at *10-11.
`
`PO’s expert reinforces this estoppel conclusion because he admits that the
`
`’141 Patent claims a client request system, like the ’636 Patent. EX2006, ¶29.
`
`Accordingly, PO had a full and fair opportunity to litigate this issue and should be
`
`collaterally estopped. EX1006, 16, 28; EX1007, 16-23.
`
`14
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`Carmel teaches claim limitations [1.k]/[5.k]/[9.k]
`2.
`Carmel discloses claim limitations [1.k]/[5.k]/[9.k]. Pet., 44-47; EX1002,
`
`¶¶127-131. PO, in contrast, asserts that Carmel’s server “send[s] a plurality of
`
`elements in response to a single user request.” POR 39, 38; EX2006, ¶69. This is
`
`wrong as outlined below.
`
`Carmel’s client opens an HTTP link in which slices “42, 44, 46, etc., are
`
`downloaded in successive alternation” from the server. EX1004, 10:36-50 (“client
`
`30 opens one or two HTTP links, over which files 42, 44, 46, etc., are
`
`downloaded in successive alternation . . . [r]esponsive to a user input, client 30
`
`selects an appropriate starting slice and begins to download and decode
`
`(decompress) files 42, 44, 46, etc.”) (emphasis added), 6:3-6 (“a method of
`
`downloading broadcast data from a server to a client . . . .”) (emphasis added);
`
`Pet., 31-36, 45 (referring to Section VII.A.2.g), 46-47; EX1002, ¶¶98, 128, 135.
`
`This clearly teaches that Carmel’s client requests each slice one after another by
`
`identifier from the server.
`
`Against this express disclosure, PO claims that the “successive alteration”
`
`disclosure “beg[] the question of whether the server or the client is staging the
`
`alternation.” POR 40 (citation omitted). There is no question: the above
`
`disclosure describes that the “client 30 opens” the HTTP link from which the client
`
`downloads slices 42, 44, 46, etc. EX1004, 10:36-50.
`15
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`Carmel’s client request system is further shown in Figure 6A below, where
`
`the client will “Read Index File” to “Select Slice”—singular, not plural—from the
`
`server, and the client will repeatedly loop requesting each time a single slice from
`
`the server. EX1004, Fig. 6A; EX1002, ¶128; EX2005, 60:7-61:6, 74:2-22.
`
`Loop
`
`EX1004, Fig. 6A (annotated).
`
`However, PO argues that Figure 6A shows an “HTTP read” request for a
`
`plurality of slices from which “Select Slice” obtains a slice from the downloaded
`
`16
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`plurality. POR 40; EX2006, ¶121. It also contends that “Read Index File” step is
`
`“pointless” based on this “HTTP read.” Id.
`
`PO’s attempt to rewrite Carmel’s figure fails. Figure 6A states “HTTP from
`
`Server” (not “HTTP read”), and there is no mention in the above Figure 6A of an
`
`already downloaded plurality of slices to “Select Slice” as PO contends. Rather, it
`
`shows “HTTP from Server” or an HTTP link to the server such that Carmel’s
`
`client “Read Index File” to “Select Slice” (singular) over a repeated loop, just as
`
`Figure 6A and the specification state. Pet., 45; EX1004, 10:38-40.
`
`Figure 6B below reinforces the conclusion that Carmel is a client request
`
`system. This shows the client “Read Slice” (singular) and then repeatedly looping
`
`to select a different slice encoding rate (audio/video level) if the rate is too high.
`
`EX1004, Fig. 6B, 6:7-10 (“downloading broadcast data from a server to a client.”);
`
`EX1002, ¶129; EX2005, 60:7-61:6; Pet., 45-46. Moreover, there is no way to tell
`
`the server in Carmel to switch to a new encoding rate without the client generating
`
`a request for it.
`
`Additionally, if the server only “send[s] a plurality of elements in response
`
`to a single user request” as PO contends, you would expect the “Yes” loop (“Rate
`
`Higher Than Need?” and “Rate Too Low?”) only to go up to “Decode” rather than
`
`all the way to top as shown in Figure 6B with the client requesting another element
`
`at “HTTP from Server.” Pet., 45-46; EX1004, Fig. 6B.
`17
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`Loop
`
`Loop
`
` EX1004, FIG. 6B (annotated).
`
`PO contends that Figure 6B does not show requesting a slice by identifier.
`
`POR 42-44. But, PO’s prior IPR expert admitted Carmel’s Figure 6B shows that a
`
`client requests different quality level “slices 42-48” from the server. WebPower,
`
`Inc. v. WAG Acquisition, IPR2016-01238, EX2001 (Prof. Mung Chiang Decl.), ¶14
`
`(“As shown in Figure 6B, while downloading the slices 42-48, the client 30 is
`18
`
`
`
`IPR2022-01227
`U.S. Pat. No. 9,762,636
`
`constantly evaluating each link and adjusting audio/video levels accordingly so
`
`that the slices 42-48 ‘fit’ within the available rate of that link.”) (emphasis added);
`
`id., Paper 11, at 8, 9 (similar).
`
`PO then attempts to replace Carmel’s express disclosure with speculation,
`
`contending a POSITA would write a “script” in, e.g., ASP, to request one slice
`
`resulting in the streaming of other slices. POR 44-47; EX2006, ¶¶82, 86-93. This
`
`is erroneous.
`
`It is not reasonable that a POSITA would ignore Carmel’s express disclosure
`
`of the simpler index file solution discussed in Figure 6A to request one slice after
`
`another and instead employ a manufactured solution of scriptwriting. Hoarty Tr.,
`
`65:2-15 (“Q. Does Carmel teach transfer of data, using these supervising scripts?
`
`A. I don’t believe so. Q. Okay. Does Carmel talk about ASP? A. I don’t recall that
`
`in Carmel. … and I don’t see a direct reference to a scripting language”); EX1030,
`
`¶¶38-40.
`
`PO further provides so-called “two . . . embodiments1” (POR 47-48) from
`
`the HTTP 1.1 Specification to argue that Carmel does not teach these claim
`
`limitations. But these mischaracterize HTTP as discussed below. Regardless,
`
`Carmel generally cites HTTP while citing (but not i
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
