IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`Google LLC,
`Petitioner
`
`v.
`
`WAG Acquisition, L.L.C.
`Patent Owner.
`
`
`
`IPR2022-01413
`
`U.S. Patent No. 9,762,636 B2
`Issue Date: September 12, 2017
`
`Title: STREAMING MEDIA DELIVERY SYSTEM
`
`
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`
`
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`Table of Contents
`
`Page
`
` I.
`Introduction ..................................................................................................... 1
`POSITA .......................................................................................................... 2
`II.
`III. Claim Construction ......................................................................................... 3
`A.
`Preambles ............................................................................................. 3
`B.
`“Requests” Limitations ........................................................................ 5
`C.
`“Data Rate of the Data Connection” Limitation .................................. 7
`D.
`“Without Depending on the Server System Maintaining a
`Record” Limitation ............................................................................... 9
`IV. Carmel Grounds (1-4) ..................................................................................... 9
`A.
`Carmel Discloses Client Control and “Pull” ...................................... 10
`1.
`PO’s arguments and alleged evidence cannot overcome
`Carmel’s express disclosure ..................................................... 11
`Carmel Grounds Satisfy the Limitations Identified by PO ................ 18
`1.
`Carmel Grounds Satisfy the “Supplying” Limitation .............. 18
`2.
`Carmel Grounds Satisfy the “Requests” Limitations .............. 19
`3.
`Carmel Grounds Satisfy the “Data Rate of the Data
`Connection” Limitation ........................................................... 21
`Carmel Grounds Satisfy the “Without Depending on the
`Server System Maintaining A Record of the Last Media
`Data Element Sent” Limitation ................................................ 25
`Carmel Combinations (Grounds 2-4) Disclose the Challenged
`Claims ................................................................................................. 26
`No Secondary Considerations ...................................................................... 27
`V.
`VI. Conclusion .................................................................................................... 27
`CERTIFICATE OF SERVICE ............................................................................... 30
`
`B.
`
`C.
`
`4.
`
`-i-
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`
`List of Exhibits
`
`
`
` 
`
`
`
`Description of Document
`
`Exhibit
`No.
`1001 U.S. Patent No. 9,762,636 B2 to Harold Edward Price (filed October
`3, 2016, issued September 12, 2017)
`1002 Declaration of Dr. Nathaniel Polish (“Polish” or “Polish Decl.”)
`1003 U.S. Patent No. 6,389,473 to Sharon Carmel et al. (filed March 24,
`1999, issued May 14, 2002) (“Carmel”)
`1004 U.S. Patent No. 6,292,834 to Hemanth Srinivas Ravi et al. (filed March
`14, 1997, issued September 18, 2001) (“Ravi”)
`1005 U.S. Patent No. 6,008,853 to Ajai Narayan et al. (filed November 12,
`1997, issued December 28, 1999) (“Narayan”)
`1009 U.S. Patent No. 5,867,230 to Feng Chi Wang et al. (filed June 30, 1997,
`issued February 2, 1999)
`1010 U.S. Patent No. 6,637,031 to Phillip A. Chou (filed December 4, 1998,
`issued October 21, 2003)
`
`1011
`
`Shanwei Cen et al., Flow and Congestion Control for Internet Media
`Streaming Applications (1997)
`
`1012
`
`Jian Lu, Signal Processing for Internet Video Streaming: A Review
`(2000)
`1013 H. Schulzrinne et al., Network Working Group Request for Comments:
`2326, Real Time Streaming Protocol (RTSP) (1998)
`1014 U.S. Patent No. 7,529,806 to Yevgeniy Eugene Shteyn (filed November
`4, 1999, issued May 5, 2009)
`1015 U.S. Patent No. 5,721,878 to Hal Hjalmar Ottesen et al. (filed June 7,
`1995, issued February 24, 1998
`
`‐i‐ 
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`
`List of Exhibits
`
`
`
` 
`
`
`
`Description of Document
`
`Exhibit
`No.
`1016 R. Fielding et al., Hypertext Transfer Protocol -- HTTP/1.1 (1999)
`1017
`
`Sam Iren and Paul D. Amer, The Transport Layer: Tutorial and Survey
`(1999)
`1018 U.S. Patent No. 5,793,980 to Robert D. Glaser et al. (filed November
`30, 1994, issued August 11, 1998)
`1019 M.H. Willebeek-Lemair et al., Bamba – Audio and video streaming over
`the Internet (1998)
`1020 Excerpts from David Austerberry, The Technology of Video and Audio
`Streaming (2004)
`1021 Cannon DV Format,
`https://web.archive.org/web/19991013131445/http://canondv.com:80/s
`hared/dvinfo/dvinfo2.html (1999)
`1022 Alan T. Wetzel and Michael R. Schell, Consumer Applications of the
`IEEE 1394 Serial Bus, and a 1394/DV Video Editing System (1996)
`1023 U.S. Patent No. 5,568,192 to Eric C. Hannah (filed August 30, 1995,
`issued October 22, 1996)
`1024 U.S. Patent No. 5,402,170 to Kenneth A. Parulski et al. (filed August
`31, 1992, issued March 28, 1995)
`
`1025
`
`Jean-Phillipe Martin-Flatin, Push vs. Pull in Web-Based Network
`Management (1999)
`1026 Lixin Gao et al., Catching and Selective Catching: Efficient Latency
`Reduction Techniques for Delivering Continuous Multimedia Streams
`(1999)
`
`‐ii‐ 
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`
`List of Exhibits
`
`
`
` 
`
`
`
`Exhibit
`No.
`1027 U.S. Patent No. 5,822,524 to Huey-Shiang Chen et al. (filed July 21,
`1995, issued October 13, 1998)
`
`Description of Document
`
`1028
`
`Sriram S. Rao et al., Comparative Evaluation of Server-push and Client-
`pull Architectures for Multimedia Servers (1996)
`1029
`ʼ636 Patent Prosecution History File
`1032 U.S. Patent No. 7,237,254 B1 to Nosakhare D. Omoigui (filed March
`29, 2000, issued June 26, 2007)
`1033 WAG Acquisition, L.L.C.’s Proposed Claim Constructions from WAG
`Acquisition, L.L.C. v. Google LLC, No. 6:21-cv-00816-ADA (W.D.
`Tex.), dated February 18, 2022
`1034 U.S. Patent No. 5,488,433 to Kinya Washino et al. (filed March 1, 1995,
`issued January 30, 1996)
`
`1035
`
`Panasonic DV-PV910,
`https://web.archive.org/web/19990505044020/http://www.panasonic.c
`om:80/consumer_electronics/video/pv_dv910.htm (archived May 5,
`1999)
`1036 Canon Elura,
`https://web.archive.org/web/19990424171105/http://www.canondv.co
`m:80/elura/index.html (archived April 24, 1999)
`1037 Canon XL1,
`https://web.archive.org/web/19990420230845/http://canondv.com:80/
`xl1/index2.html (archived April 20, 1994)
`1038 Anthony D. Mercando, Multimedia Mania (1994)
`1039 Brad Hansen, The Dictionary of Multimedia (1997)
`
`‐iii‐ 
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`
`List of Exhibits
`
`
`
` 
`
`
`
`Description of Document
`
`Exhibit
`No.
`1040 Defendants Google LLC and YouTube, LLC’s Opening Claim
`Construction Brief from WAG Acquisition, L.L.C. v. Google LLC, No.
`6:21-cv-00816-ADA (W.D. Tex.), Dkt. No. 37, filed March 14, 2022
`1041 Declaration of Keith J. Teruya from WAG Acquisition, L.L.C. v. Google
`LLC, No. 6:21-cv-00816-ADA (W.D. Tex.), filed April 1, 2022
`
`1042
`1043
`
`Jonathan C. Soo, Live Multimedia over HTTP (1994)
`
`from WAG
`Plaintiff’s Responsive Claim Construction Brief
`Acquisition, L.L.C. v. Google LLC, No. 6:21-cv-00816-ADA (W.D.
`Tex.), filed April 1, 2022
`1044 Defendants Google LLC and YouTube, LLC’s Reply Claim
`Construction Brief from WAG Acquisition, L.L.C. v. Google LLC, No.
`6:21-cv-00816-ADA (W.D. Tex.), Dkt. No. 43, filed April 15, 2022
`
`1045
`
`Phil Karn and Craig Partridge, Improving Round-Trip Time Estimates
`in Reliable Transport Protocols (1988)
`1046 Hari Balakrishnan et al., Improving TCP/IP Performance over Wireless
`Networks (1995)
`1047 WAG Acquisition, L.L.C.’s Preliminary Infringement Contentions
`from WAG Acquisition, L.L.C. v. Google LLC, No. 6:21-cv-00816-ADA
`(W.D. Tex.), dated November 15, 2021
`1058 Opening Claim Construction Brief of Amazon.com, Inc., Amazon Web
`Services, Inc., and Amazon.com Services, LLC from WAG Acquisition,
`L.L.C. v. Amazon.com, Inc., No. 6:21-cv-00815-ADA (W.D. Tex.), Dkt.
`No. 37, filed March 11, 2022
`1060 List of Claims
`
`‐iv‐ 
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`
`List of Exhibits
`
`
`
` 
`
`
`
`Description of Document
`
`Exhibit
`No.
`1061 U.S. Patent No. 8,122,141 to Harold Edward Price (filed May 10, 2010,
`issued February 21, 2012)
`ʼ636 YouTube Amended Infringement Contentions from WAG
`Acquisition, L.L.C. v. Google LLC, No. 6:21-cv-00816-ADA (W.D.
`Tex.), served February 8, 2022
`
`1063
`
`1065
`
`Proof of Service – YouTube, Inc. from WAG Acquisition, L.L.C. v.
`Google LLC, No. 6:21-cv-00816-ADA (W.D. Tex.), Dkt. 13
`
`1066
`
`Proof of Service – Google LLC from WAG Acquisition, L.L.C. v.
`Google LLC, No. 6:21-cv-00816-ADA (W.D. Tex.), Dkt. 14
`1067 Curriculum Vitae of Dr. Nathaniel Polish
`1101
`
`July 6, 2023 Deposition of Patent Owner’s Expert W. Leo Hoarty for
`IPR2022-01227 and IPR2022-01228
`1102 August 3, 2023 Deposition of Patent Owner’s Expert W. Leo Hoarty for
`IPR2022-01430 and IPR2022-01433
`1103 August 21, 2023 Deposition of Patent Owner’s Expert W. Leo Hoarty
`for IPR2022-01411, IPR2022-01412, and IPR2022-01413
`
`1104
`
`Swaminathan, Viswanathan, and Sheng Wei, “Low latency live video
`streaming using HTTP chunked encoding,” 2011 IEEE 13th
`International Workshop on Multimedia Signal Processing, IEEE, 2011.
`1105 Orallo, E. Hernandez, and Joan Vila-Carbó, “A fast method to optimise
`network resources for Video-on-demand Transmission,” Proceedings of
`the 26th Euromicro Conference, EUROMICRO 2000, Informatics:
`Inventing the Future, Vol. 1., pp. 440-447, IEEE, Sep. 5, 2000.
`
`‐v‐ 
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`
`List of Exhibits
`
`
`
` 
`
`
`
`Description of Document
`
`Exhibit
`No.
`1106 Tierney, Brian, et al., “Distributed parallel data storage systems: A
`scalable approach to high speed image servers,” Proceedings of the
`second ACM international conference on Multimedia, pp. 399-405, Oct.
`15, 1994.
`1107 Bradley, Adam D., Azer Bestavros, and Assaf J. Kfoury, “A typed
`model for encoding-based protocol interoperability,” Proceedings of the
`12th IEEE International Conference on Network Protocols, 2004, ICNP
`2004, IEEE, Oct. 8, 2004.
`1108 Claim Construction Order, Emblaze Ltd. v. Apple Inc., Case No. 5:11-
`cv-01079-PSG (N.D. Cal. Oct. 9, 2014)
`1109 WAG Acquisition’s May 15, 2023 Reply Brief, Reexam Control No.
`90/014,833 (U.S. Patent No. 8,327,011)
`1110 Claim Construction Order, Emblaze Ltd. v. Microsoft Corp., Case No.
`12-cv-05422-JST (N.D. Cal. July 29, 2014)
`1111 Reply Declaration of Dr. Nathaniel Polish (“Polish Reply”)
`1112
`
`In re Certain Fitness Devices, Streaming Components Thereof, and
`System Containing Same, Inv. No. 337-TA-1265, Evidentiary Hearing
`– Volume II (ITC, March 10, 2022)
`
`1113
`Israeli Patent Application No. 123819
`1114 Microsoft Computer Dictionary, 5th Ed. © 2002 (excerpts)
`
`‐vi‐ 
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`I.
`INTRODUCTION
`Patent Owner’s (PO) Response (POR) raises arguments predicated on
`
`undefined and previously undisclosed claim constructions, as well as a fundamental
`
`mischaracterization of Carmel (EX1003) as a server-controlled system that only
`
`discloses “push.”
`
`The Challenged Claims of U.S. Patent No. 9,762,636 (EX1001 (“ʼ636” or
`
`“ʼ636 patent”)) pertain to the distribution of “live” content from a server system, in
`
`which the server system “receiv[es] requests” for “one or more of the media data
`
`elements” from a “requesting user system,” and “responsive to the requests, send[s]”
`
`the “one or more media data elements having the one or more specified serial
`
`identifiers, to the requesting user systems[.]” (E.g., ʼ636, cl. 1.) While the claims
`
`recite a client-driven process, the claims do not use the words “push” or “pull,” nor
`
`does the specification characterize the purported invention as such.
`
`Carmel discloses the invention recited by the Challenged Claims, as well as
`
`“pull,” to the extent the Board adopts the “push”/“pull” categorization. Carmel’s
`
`preferred embodiments disclose a client-controlled design for downloading separate
`
`files that teaches repeated HTTP requests for each file. Moreover, in discussing a
`
`Board decision relying on Carmel as prior art to U.S. Patent No. 8,122,141 (“ʼ141
`
`patent”), which is related to the ʼ636 patent, the Federal Circuit held:
`
` 
`
`
`
`-1-
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`Contrary to the Board’s findings, WAG argues that
`Carmel does not disclose sufficient client-side control to
`render the use of a pointer unnecessary. . . . We are not
`convinced by WAG’s arguments. A reasonable fact finder
`could find that Carmel does not require use of a pointer for
`the reasons stated by the Board: Carmel emphasizes client
`control, lacks specialized server software, and uses
`pointerless protocols.
`
`(EX2001, 121.) As recognized by the Federal Circuit (and the Board), Carmel
`
`emphasizes client-control, and PO’s arguments here characterizing Carmel as
`
`otherwise are unfounded.
`
`PO’s arguments do not overcome the obviousness grounds set forth in the
`
`Petition, all of which rely on Carmel. The Board should therefore find the
`
`Challenged Claims unpatentable.
`
`II.
`
`POSITA
`PO “clarifi[es]” the definition of a POSITA, arguing it includes additional,
`
`theoretical understanding of internet protocols. (POR, 6.) Petitioner disagrees, but
`
`PO’s clarification does not impact the analysis because, if anything, it only raises
`
`the level of skill and makes the claims more obvious. (EX1111 (“PolishReply”),
`
`¶¶11-13.)
`
`
`1 Unless otherwise noted, emphasis is added.
` 
`-2-
`
`
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`III. CLAIM CONSTRUCTION
`PO identifies purported claim construction disputes relating to five limitations
`
`to underscore its arguments regarding Carmel’s alleged deficiencies. PO’s
`
`positions—which were not advanced in district court or the POPR—are unclear
`
`(lacking any actual construction), unsupported by intrinsic evidence, and should be
`
`rejected.2 Nonetheless, even under PO’s views, Petitioner’s Grounds invalidate the
`
`Challenged Claims.
`
`A.
`Preambles
`PO contends the independent claim preambles should be interpreted to require
`
`streaming “an entire program[,]” and “not merely some portion of a program.”
`
`(POR, 8-11.) This reading is at odds with the claim language, specification, and
`
`testimony from PO’s expert.
`
`The claims do not include the word “entire.” Instead, the claims recite steps
`
`that are carried out for portions of the live audio/video program, such as “receiving
`
`requests at the server system via one or more data connections over the Internet, for
`
`
`2 If adopted, Petitioner “must be afforded a reasonable opportunity in reply to present
`
`argument and evidence under that new construction.” Axonics v. Medtronic, Nos.
`
`2022-1532, -1533, 2023 U.S. App. LEXIS 20272, at *17 (Fed. Cir. Aug. 7, 2023).
`
` 
`
`
`
`-3-
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`one or more of the media data elements,” not the “entire” program. (PolishReply,
`
`¶¶23-29.)
`
`The additional limitations PO cites do not require the streaming of an “entire”
`
`live audio/video program. (Id., ¶¶25-26.) For example, limitation “a” of claim 1
`
`recites “receiving at the server system a continuous digitally encoded stream for the
`
`audio or video program, via a data connection from a live source in real time . . .”
`
`(ʼ636, cl. 1.) PO quotes this limitation as “receiving . . . the . . . program [and not
`
`just some part of it] . . . from a live source.” (POR, 9.) PO improperly adds the
`
`bracketed portion; the actual limitation does not require the server system to receive
`
`“a continuous digitally encoded stream” for the entire live audio or video program.
`
`Likewise, PO’s other cited limitations, such as “receipt of the stream by the server
`
`system” and “supplying, at the server system, media data elements representing the
`
`program” do not use the word “entire” and a POSITA would not understand these
`
`limitations to pertain to the “entire” program. (ʼ636, cl. 1; PolishReply, ¶¶25-26.)
`
`PO points to the specification’s statement “[t]he user computer then continues
`
`with additional data requests for the duration of playing the audio/video material.”
`
`(ʼ636, 14:56-58.) But this merely discloses sending requests “for the duration of
`
`playing”—not for the “entire” program. And where the specification uses the word
`
` 
`
`
`
`-4-
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`“entire,” it shows the applicant understood when to use it and chose not to in the
`
`claims. (PolishReply, ¶27.)
`
`Moreover, PO’s expert, Mr. Hoarty, shares a view consistent with Petitioner
`
`and contradicts PO. Mr. Hoarty confirmed that “an audio or video program might
`
`only refer to a portion of the program.” (EX1103, 22:22-24:9; PolishReply, ¶29.)
`
`Critically, the ʼ636 patent pertains to the streaming of “live” audio/video
`
`content, and PO fails to explain what it means by “entire live video/audio program,”
`
`including whether a viewer has streamed an “entire” live video/audio program if
`
`they close out of the stream before the content maker has finished streaming or if the
`
`viewer joins the stream after it has already started. (PolishReply, ¶28.) Importing
`
`PO’s addition of “entire” before live video/audio program in the preambles would
`
`not only be improper but would also lead to confusing results. See Sunoco Partners
`
`Marketing & Terminals v. U.S. Venture, Inc., 32 F. 4th 1161, 1175-76 (Fed. Cir.
`
`2022) (in applying plain meaning, rejecting construction that term should be limited
`
`to “actual measure[d]” “vapor pressure of the butane stream” where plain language
`
`of “a vapor pressure of the butane stream” “d[id] not expressly require an actual
`
`measurement”).
`
`B.
`“Requests” Limitations
`PO identifies three “requests” limitations for which it improperly reads in
`
`additional requirements. (POR, 11-13, 21-23.) Specifically, for limitations “c-c[ii]”
` 
`-5-
` 
`
`
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`and “d,” PO argues that “even if the ‘received request’ is for more than one element,
`
`each such requested element is identified in the request by the respective serial
`
`identifier of that media data element.” (POR, 11-12.) And for limitation “d[iv],”
`
`PO takes issue with the Board’s “implicit claim construction” in the Institution
`
`Decision that “‘[a]lthough the limitation calls for ‘all’ of the media data elements to
`
`be sent in response to requests, it does not require every slice to be requested by slice
`
`number.’” (POR, 21 (citing ID, 39).) In PO’s view, when “read in combination with
`
`limitations c-c[ii],” this limitation “require[s] every element in the response to be
`
`requested by its serial ID.” (Id.)
`
`However, based on the claims’ plain language, and the specification, a
`
`POSITA would understand that the requests could identify: one serial identifier (e.g.,
`
`the identifier of the first portion being requested), more than one identifier (e.g., the
`
`identifiers of the first two portions being requested), or each identifier for each
`
`portion requested. (PolishReply, ¶34; EX1103, 96:10-101:3.) A POSITA would
`
`not understand the claims to require each-and-every media data element to be
`
`specifically identified in any request. (PolishReply, ¶¶30-37.) The claims expressly
`
`state: “each received request specifying one or more serial identifiers of the
`
`requested one or more media data elements.” (ʼ636, cl. 1.) And Mr. Hoarty agrees
`
`that in one embodiment in the specification, the server continues to send data after
`
` 
`
`
`
`-6-
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`receiving a single request. (EX1102, 24:2-27:7; EX1103, 100:9-101:3; PolishReply,
`
`¶35.)
`
`PO’s sole evidence is a sentence in the specification stating “the user computer
`
`transmits a request to the server to send one or more data elements, specifying the
`
`serial numbers of the data elements.” (POR, 12.) This sentence, however, does not
`
`state that the user computer identifies each-and-every serial number of each-and-
`
`every data element requested. Rather, it only requires “one or more” be requested
`
`by serial number. (PolishReply, ¶¶34-36.)
`
`C.
`“Data Rate of the Data Connection” Limitation
`PO has taken multiple positions for the “data rate of the data connection”
`
`limitation, but in the claim construction section of the POR, it interprets
`
`limitation d(i) to mean that the referenced data connection
`must meet the “more rapid than the playback rate”
`condition over the elements “sent via that connection” in
`response to any request (either for one or for more
`elements), and that this means that the data connection
`must be capable of a data rate that can transfer the
`elements sent over the connection in less time than
`required to play back those elements at a normal rendition.
`(POR, 16.) As PO admits, the “data rate of the data connection” limitation only
`
`requires a data connection that is “capable” of transferring media data elements in
`
`less time than required to play back those elements at a normal rendition. (Id.;
`
`EX1103, 26:19-29:7 (limitations refer to capacity of the data connection).)
`
` 
`
`
`
`-7-
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`However, to the extent PO is reading this limitation (and the larger claims) to
`
`require that the data connection must always transfer elements sent over the
`
`connection in less time than required to play back those elements at a normal
`
`rendition, such an interpretation is mistaken and contrary to PO’s own admissions
`
`(and its expert’s) that the “specification makes clear that there will be reception
`
`interruptions with an internet connection.” (POR, 15; EX1103, 33:17-34:9;
`
`PolishReply, ¶¶44-46.)
`
`Such an interpretation also leads to impossible results for the streaming of
`
`“live” audio/video content, as recited by the Challenged Claims. (PolishReply,
`
`¶¶52-54.) Under PO’s interpretation, each-and-every element must be transferred
`
`faster than the playback rate, but a “live” program cannot be continuously transferred
`
`at a rate faster than the playback rate since it is impossible to get ahead for a “live”
`
`program. (Id.) Additionally, PO’s cited specification support pertains to on-demand
`
`content. (See POR, 17 (citing ʼ636, 3:55-56 (“facilitate continuous content
`
`transmission on demand”).)
`
`Finally, PO refers to the Federal Circuit’s decision regarding the limitation
`
`“to send media data elements to the user system responsive to said requests, at a rate
`
`more rapid than the rate at which said streaming media is played back to a user.”
`
`(POR, 16-17 (citing EX2001, 10).) That limitation differs from the limitation here
`
` 
`
`
`
`-8-
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`in that the Challenged Claims recite three different types of rates—“data rate”
`
`(recited in this limitation), “playback rate,” and “transmission rate.” (PolishReply,
`
`¶¶47-51.) The limitation here pertains to the “data rate,” and not the “transmission
`
`rate,” while the limitation the Federal Circuit was analyzing relates to the
`
`“transmission rate.” (Id., ¶¶18-21, 38-54.)
`
`D.
`
`“Without Depending on the Server System Maintaining a Record”
`Limitation
`PO does not advance any specific construction for this limitation, instead
`
`relying on its positions regarding operations over an “entire program” and that the
`
`“requests” identify each-and-every element specifically. (POR, 19-21.) As
`
`discussed above, these interpretations contravene the intrinsic evidence and a
`
`POSITA’s understanding. (See supra §§III.A, III.B; PolishReply, ¶¶55-57.)
`
`IV. CARMEL GROUNDS (1-4)
`All four grounds in the Petition rely on Carmel as a primary reference. PO
`
`identifies five limitations that it alleges Carmel does not disclose. For three of the
`
`limitations, PO’s attacks on Carmel relate to its mischaracterization of Carmel as
`
`disclosing a server-managed method/system that only discloses “push.” (POR, 37-
`
`39, 49-51, 51-56.) Additionally, PO alleges that Carmel does not disclose the
`
`“supplying, at the server system, media data elements representing the program” and
`
`the “data rate of the data connection” limitations. (Id., 36-37, 40-48.) All of PO’s
`
` 
`
`
`
`-9-
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`attacks, including on combinations of Carmel with Narayan (EX1005) and/or Ravi
`
`(EX1004), fail.
`
`A. Carmel Discloses Client Control and “Pull”
`As shown in Figure 6A, Carmel teaches “client 30” opens an HTTP link with
`
`“server 36.” (Carmel, Fig. 6A, 10:35-47.) Carmel further teaches that when a “client
`
`30” connects to the “server 36” with the intention of receiving “data stream 40,”
`
`“client 30” reads an “index file 50” and then selects which slice within “data stream
`
`40” to receive first. (Id., Fig. 6A, 7:59-8:7, 10:42-48.) “[C]lient 30” selects and
`
`downloads a slice. (Id., Fig. 6A, 10:35-47.)
`
`If the link function is sufficient—i.e., the data connection is equal to or faster
`
` 
`
`
`
`-10-
`
` 
`
`
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`than playback so “client 30” is not falling behind—“client 30” will continue to use
`
`the single HTTP link. (PolishReply, ¶75.) Carmel recognizes there will be times
`
`when the link function is not sufficient so “client 30” opens a new link. (Carmel,
`
`2:64-67, 10:55-63; PolishReply, ¶76.) By teaching that “client 30” monitors links,
`
`establishes links, and controls the slices allocated to each link,3 Carmel teaches a
`
`client-driven and “pull”-based approach. (PolishReply, ¶¶62-84.) In addition, since
`
`“client 30” decides whether to break a link—and whether to drop the file from that
`
`link or use an existing link or a new link to re-request it—a POSITA would
`
`understand Carmel to teach “pull.” (PolishReply, ¶¶74-78 (citing Carmel, 10:6-17,
`
`13:30-35).)
`
` Moreover,
`
`the Federal Circuit has characterized Carmel as
`
`“emphasiz[ing] client control [and] lack[ing] specialized server software[.]”
`
`(EX2001, 12.)
`
`1.
`
`PO’s arguments and alleged evidence cannot overcome
`Carmel’s express disclosure
`PO’s arguments that Carmel does not disclose “pull” fail.
`
`First, PO points to instances where Carmel explains that, after selecting a
`
`
`3 (Carmel, 9:32-48 (describing allocation technique for computer 34 and stating “[a]
`
`similar technique is preferably employed by clients 30.”), 13:30-35 (confirming
`
`techniques used for upload are applicable to download in Fig. 6A).)
`
` 
`
`
`
`-11-
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`starting slice, “client 30” downloads plural “slices” or “files.” (POR, 28-29 (citing
`
`Carmel, 10:44-47).) PO reads too much into Carmel’s general disclosure that
`
`multiple slices/files will eventually be transmitted/received. Carmel Figure 6A
`
`teaches checking the link function after decoding and outputting each slice before
`
`deciding how to proceed. (PolishReply, ¶¶79-81.) Given that only “client 30”
`
`knows when the “DECODE” and “OUTPUT DATA” steps are complete, only
`
`“client 30” can decide when to proceed with the next slice. This is not “push.”
`
`Second, PO contends that Carmel’s reference to HTTP1.1 suggests “push.”
`
`(POR, 26-27, 35-36.) As a technical matter, PO’s argument is incorrect because
`
`even in HTTP1.1 each file must be individually requested—something PO’s expert
`
`admits. (PolishReply, ¶¶63-69; EX1103, 88:25-89:13; EX1101, 53:1-13, 52:13-16,
`
`66:11-67:1.)4 Moreover, even if HTTP1.1 could support transferring unrequested
`
`files (it cannot), PO fails to account for the fact that such an approach would not
`
`
`4 PO is also wrong that Carmel would use HTTP1.1’s “chunked transfer encoding.”
`
`As the HTTP1.1 standard makes clear, “chunked transfer encoding” is used when
`
`the file size is undefined or unknown. (PolishReply, ¶¶63-69; EX1016, 18; EX1107,
`
`3; EX1104, 2.) In Carmel, by the time slices are loaded on the server, the slice sizes
`
`are fixed and known. (Carmel, 9:1-2.)
`
` 
`
`
`
`-12-
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`work without specialized software that Carmel expressly says is not required.
`
`(PolishReply, ¶¶¶63-69, 81; Carmel, 2:17-21, 6:44-49, 7:9-12.)
`
`The fact that each file must be individually requested in HTTP1.1 is
`
`significant because Carmel expressly teaches that “[p]referably, each segment or
`
`slice is contained in a separate, respective file.” (Carmel, 2:22-23.) Accordingly, to
`
`stream an audio/video program according to Carmel’s preferred embodiment (where
`
`each slice is contained in a separate file) using HTTP1.1 (which require that each
`
`file must be individually requested), a POSITA would understand that Carmel uses
`
`“pull.” (PolishReply, ¶69.)
`
`Third, PO argues Figure 6A’s “SELECT SLICE” block reflects a single
`
`instance where a user selects the starting slice. (POR, 34-35.) But the fact that a
`
`“SELECT SLICE” box is included in every “CONTINUE” loop (and not just once
`
`at the beginning of the operation) undermines PO’s argument. (PolishReply, ¶82.)
`
`A POSITA would understand that, in Carmel, the user selects and identifies the
`
`slices by their serial ID. (Id.)
`
`Fourth, PO argues that “HTTP FROM SERVER” in Figures 6A-6B is
`
`“consistent with receiving a stream, as opposed to the client making successive
`
`individual file requests.” (POR, 35.) But given that Figures 6A-6B consistently
`
`recite steps being performed by “client 30,” a POSITA would understand the “HTTP
`
` 
`
`
`
`-13-
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`FROM SERVER” in each loop to be an “HTTP [PULL] FROM SERVER”
`
`performed by the client. (PolishReply, ¶83.) Even PO’s expert agrees that a “pull”
`
`approach can be described as an HTTP pull from the server. (EX1103, 59:9-18.)
`
`To support its argument that Figures 6A and 6B provide a “push” system, PO
`
`argues that there is “no explanation of what slices would be present to select from,
`
`to perform the step SELECT SLICE, or why DECODE and OUTPUT DATA
`
`precede the supposed ‘request’ to the server.” (POR, 51-52.) But PO’s argument is
`
`premised on a misreading of Carmel’s figures. As explained in the specification, the
`
`client connects to the server, opens at least one HTTP link, reads an index file to
`
`identify, select, and request the next-needed slice, and then once the slice is sent
`
`from the server, the client decodes, or decompresses, the slice and then “reconstructs
`
`and outputs the multimedia data for the appreciation of a user,” and continues the
`
`process. (Carmel, 10:35-50; PolishReply, ¶¶75-83.) Additionally, only “client 30”
`
`would know when the “DECODE” and “OUTPUT DATA” steps are complete, so
`
`only “client 30” can decide when to proceed with the next slice. (PolishReply, ¶80.)
`
`PO additionally attempts to buttress the third and fourth arguments above with
`
`citations to an ITC decision from a case that does not involve Petitioner or the ʼ636
`
`patent (or any related patent). (POR, 34-35 (citing EX2008, 177-78).) As an initial
`
`matter, it is unclear what evidence the ITC considered and how it would view Carmel
`
` 
`
`
`
`-14-
`
` 
`
`

`

`IPR2022-01413
`Reply to Patent Owner’s Response
`U.S. Patent No. 9,762,636 B2
`
`in light of the evidence presented here. Additionally, from the portion of the ITC’s
`
`decision cited by PO, it is clear that the claims asserted there differ markedly from
`
`the Challenged Claims, and the ITC’s distinction between Carmel and those asserted
`
`claims pertained, at least in part, to “automatic[]” selection. (Id.)
`
`Moreover, if decisions involving separate, unrelated parties are considered,
`
`th