`
`
`
`
`
`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,
`AND HULU LLC,
`
`Petitioners
`
`v.
`
`WAG ACQUISITION, LLC
`
`Patent Owner
`
`U.S. Pat. No. 9,762,636
`
`
`
`_______________________________________
`
`Inter Partes Review Case No. IPR2022-01227
`
`_______________________________________
`
`
`
`PATENT OWNER RESPONSE
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`TABLE OF CONTENTS
`
`
`
`I.
`
`INTRODUCTION ............................................................................................. 1
`
`II. EFFECT OF PRIOR PROCEEDINGS .............................................................. 4
`
`A.
`
`B.
`
`IPR2016-01238 ............................................................................................. 4
`
`Federal Circuit Decision ................................................................................ 6
`
`III. DESCRIPTION OF THE DISCLOSURE AND CLAIMS ............................... 7
`
`IV. LEVEL OF SKILL ............................................................................................. 9
`
`V. CLAIM CONSTRUCTION ............................................................................... 9
`
`VI. ARGUMENT ...................................................................................................21
`
`A.
`
`Issues in Dispute ..........................................................................................21
`
`B. Response to Ground 1: Asserted single-reference obviousness over Carmel
`
`22
`
`1. Overview of Carmel .................................................................................22
`
`2. The Petition fails to show that limitation h is disclosed by Carmel ........29
`
`3. The Petition fails to show that limitation h would have been an obvious
`modification of Carmel ....................................................................................32
`
`4. The Petition fails to show that limitation j is disclosed by Carmel .........34
`
`5. The Petition fails to show that limitation k is disclosed by Carmel ........37
`
`6. The Petition fails to show that limitation k would have been an obvious
`modification of Carmel ....................................................................................49
`
`C. Response to Ground 2: Asserted combination of Carmel and Shteyn ........51
`
`1. Overview of Shteyn ..................................................................................51
`
`2. The Petition fails to assert that Shteyn overcomes the deficiencies of
`Carmel with regard to limitations h and k and Ground 2 must therefore fail .53
`
`3. The Petition fails to show that Shteyn discloses limitation j – “the one or
`more media data element sent are selected without depending on the server
`system maintaining a record of the last media data element sent to the
`requesting user systems.” Ex. 1001, 16:64–67. ...............................................54
`
`–ii–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`4. The Petition does not provide an adequate rationale for modifying
`Carmel in accordance with Shteyn to meet the claimed limitations................60
`
`VII. CONCLUSION ................................................................................................61
`
`
`
`
`
`
`
`
`
`
`
`
`
`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
`
`–iii–
`
`

`

`
`
`
`I.
`
`INTRODUCTION
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`Pursuant to 37 CFR § 42.120, WAG Acquisition LLC (“WAG” or “Patent
`
`Owner”) files this response to the Petition and the Institution Decision.
`
`The claims of U.S. Patent No. 9,762,636 (the “’636 patent” or the “patent,” Ex.
`
`1001) address technical issues and resulting user frustration that arise in
`
`transmitting live media programs over the internet, including startup delays when a
`
`user requests to join a live stream, as well as repeated interruptions once streaming
`
`has started, due to irregularities in the transport of data over the internet.
`
`To address these problems, the patent provides solutions in two principal
`
`embodiments—one a “push” solution involving pre-buffering of content, and the
`
`other a “pull” of identified streaming data elements accumulated or loaded on the
`
`server.
`
`The challenged claims are drawn to the pull embodiment, which the
`
`specification distinguishes from the other disclosed embodiments, in that the server
`
`in the pull embodiment “does not maintain a pointer” marking the position of each
`
`user in the stream (rather, the server in the pull embodiment is “stateless” with
`
`respect to successive client requests). Ex. 1001, 14:45-49.
`
`The patent’s claims are all drawn to the pull embodiment. In each of the claims,
`
`the program stream comprises a plurality of time-sequenced data elements
`
`representing the entire program. The elements are time sequenced and serially
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`identified, and the server receives and responds to user system requests for the
`
`elements, the requests specifying the serial IDs of the requested elements. The
`
`claims go on to recite, inter alia, that the method provided for streaming the
`
`program uses a data connection between the server and user systems having a data
`
`rate more rapid than the playback rate of the elements, that the elements sent are
`
`selected without depending on a record of the last element sent, and that in
`
`transmitting the program, all of the media data elements sent are sent in response to
`
`the recited requests by serial identifier.
`
`Petitioners rely primarily on Carmel et al., U.S. Pat. No. 6,389,473, Ex. 1004,
`
`which they claim sufficiently discloses all claim limitations such that, Carmel,
`
`taken by itself, in view of the knowledge of a POSITA, renders the challenged
`
`claims obvious. The final pages of the Petition put forth a second ground under
`
`§ 103, based on a combination of Carmel with Shteyn, U.S. Pat. No. 7,529,806,
`
`Ex. 1008.
`
`First, as to Carmel—Patent Owner respectfully submits that the Petition and Dr.
`
`Houh’s declaration reflect a basic misunderstanding of the teachings of Carmel.
`
`Carmel nowhere discloses the type of element-by-element successive requests
`
`from client to server that characterize a pull. To the contrary, Carmel’s literal
`
`disclosures unmistakably describe a push. Dr. Houh disregards Carmel’s literal
`
`disclosures in favor of conjecture as to how the disclosed transmission protocol
`
`–2–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`ought to work. A huge hole exists in the Petition’s analysis, however. Dr. Houh’s
`
`declaration (Ex. 1002) overlooked the relevant version 1.1 standard for HTTP cited
`
`on the face of the Carmel disclosure. HTTP version 1.1 was a revised standard that
`
`specified implementations well beyond the simple characteristics that Dr. Houh
`
`attributes to HTTP, and Carmel explicitly referenced this revised standard. The
`
`literal disclosure of Carmel, taken together with a POSITA’s understanding of how
`
`HTTP functioned under version 1.1 cited in Carmel (as addressed by Patent
`
`Owner’s expert W. Leo Hoarty in Ex. 2006), makes abundantly clear that Carmel
`
`discloses a mechanism based only on server push, not client pull. To read anything
`
`else into Carmel is to rewrite that reference in hindsight. The Board cannot
`
`rationally find that Carmel discloses the element-by-element requests by serial
`
`identifier that the Petition and Dr. Houh would have the Board read into it.
`
`The Petition tacks on brief obviousness arguments, as fallbacks, seeking to
`
`project Carmel beyond its actual disclosures. However, the rationales provided for
`
`modifying Carmel, e.g., from a server push to a client pull, lack technical support
`
`and/or a reasoned basis.
`
`The Petition’s second ground, based on combining Carmel with Shteyn, does
`
`not even cite Shteyn for two of the limitations lacking from Carmel and must
`
`therefore fail for that reason alone. Moreover, Shteyn does not support one of the
`
`limited points for which it is cited. In addition, the Petition provides no motivation
`
`–3–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`to make the modifications to Carmel that would have been necessary to convert
`
`Carmel’s “push” method of streaming and flow control (in which a stream of
`
`elements is triggered and transmitted continuously), into a system (incorrectly
`
`attributed to Shteyn) based on individual element-by-element client requests by
`
`serial ID.
`
`Respectfully, the Institution Decision is flawed as well, in a number of respects.
`
`To a large extent, it draws its description of the patent from embodiments not
`
`related to the claims. On the merits, it appears to give considerable latitude to
`
`conclusory assertions of Petitioners’ expert, opting to await an expert counter on
`
`behalf of Patent Owner (e.g., Inst. Dec. at 43-45).
`
`Patent Owner has come forward with a qualified expert, whose testimony is
`
`independently supported by published industry standards and express disclosures
`
`of the asserted references. If Patent Owner’s expert’s testimony is credited, which
`
`it should be on its own merits, the Board cannot reasonably reach any
`
`determination of unpatentability.
`
`II. EFFECT OF PRIOR PROCEEDINGS
`
`A.
`
`IPR2016-01238
`
`The Petition cites to prior PTAB decisions on related patents, including U.S.
`
`Patent Nos. 8,364,839, 8,327,011, and 8,122,141. These cases, however, concern
`
`substantially different patent claims under a different claim construction standard –
`
`–4–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`broadest reasonable interpretation (BRI) versus the Phillips standard applicable
`
`here.
`
`The Petition (at 18) suggests that these earlier cases implicate “collateral
`
`estoppel,” but collateral estoppel cannot apply with respect to claim constructions
`
`made under a different legal standard (BRI) and §§ 102 and 103 conclusions based
`
`on different claim language. See e.Digital Corp. v. Futurewei Techs., Inc., 772 F.3d
`
`723, 727 (Fed. Cir. 2014) (“[A] court cannot impose collateral estoppel to bar a
`
`claim construction dispute solely because the patents are related.”); Novartis
`
`Pharms. Corp. v. Abbott Lab’ys, 375 F.3d 1328, 1334 (Fed. Cir. 2004) (no
`
`collateral estoppel when patent challenger did not meet burden to show that claim
`
`construction was necessary to prior noninfringement decision). An issue decided
`
`with respect to one patent cannot be presumed to be held against a related patent.
`
`See Comair Rotron, Inc. v. Nippon Densan Corp., 49 F.3d 1535, 1539 (Fed. Cir.
`
`1995) (“[I]t can not be presumed that related patents rise and fall together.”). See
`
`also VirnetX Inc. v. Apple, Inc., 909 F.3d 1375, 1377 (Fed. Cir. 2018) (collateral
`
`estoppel requires identity of issues).
`
`The claims considered in the prior IPR proceeding against the ’141 patent differ
`
`from the current claims, which are directed at streaming “a program” and recite a
`
`further string of “wherein” limitations applicable to that process. The present
`
`–5–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`claims will not be met by a process that meets the limitations only in a piecemeal
`
`manner.
`
`B.
`
`Federal Circuit Decision
`
`The Petition relies on the PTAB’s decision on remand in IPR2016-01238,
`
`concerning the ’141 patent (Ex. 1007). The remand followed the Federal Circuit’s
`
`reversal of an earlier PTAB decision (Ex. 1006) in WAG Acquisition, LLC v.
`
`WebPower, Inc., 781 F. App’x 1007 (Fed. Cir. 2019) (Ex. 2001).
`
`The Board, in ruling against the challenged claims of the ’141 patent (in that
`
`case, under a BRI claim construction standard), considered that the claims there at
`
`issue did not recite a beginning-to-end characteristic, and found it sufficient that
`
`Carmel addresses at least some portion of a partial stream. See Ex. 1007 at 19.
`
`However, while claim 10 of the ’141 patent addresses “send[ing] media data
`
`elements” faster than the playback rate, which the prior IPR found to have been
`
`met by Carmel, the present claims address distributing “a program” via a specified
`
`mechanism, which Carmel’s disclosure does not reflect.
`
`Though the claims now differ, the Federal Circuit decision nevertheless
`
`concerns claims made under a common disclosure. Although it was proceeding
`
`under BRI, the Federal Circuit, in reversing the Board, clearly adopted a narrower
`
`construction than the construction that was appealed. In particular, the Federal
`
`Circuit construed “the claimed ‘rate’ [under claim 10 of the ’141 patent] as the rate
`
`–6–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`at which each requested data element is transmitted from the server to the user
`
`computer.” 781 F. App’x at 1012 (emphasis added). The Federal Circuit’s
`
`interpretation, under claim 10 of the ’141 patent that “each” requested element
`
`under that claim must be sent at the specified rate, should be considered as
`
`providing at least guidance as to how to approach the issues here. It should not be
`
`disregarded.1
`
`III. DESCRIPTION OF THE DISCLOSURE AND CLAIMS
`
`The patent describes several embodiments. All but one of them are “push”
`
`embodiments, in which a server serves media to one or more users from a buffer on
`
`the server. It sends to the client an initial buffer load comprising a predetermined
`
`number of elements more rapidly than the playback rate and continues sending
`
`thereafter at about the playback rate. It maintains a pointer into the buffer to mark
`
`the current position of each user in the stream and uses that pointer to determine
`
`what element to send to the respective users next. The lone embodiment that does
`
`
`1 The Federal Circuit also ruled out considering multiple links in the aggregate as
`
`constituting a virtual link having a data rate faster than the playback rate. See id.
`
`(“The rate limitation in claim 10 therefore refers to the rate at which requested
`
`media data elements are sent, not the overall rate at which data is transmitted from
`
`the server to the user computer.”).
`
`–7–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`not follow that pattern is the embodiment described at Ex. 1001, 14:42-15:18. This
`
`lone embodiment is a “pull” embodiment and corresponds to the claims herein.
`
`The pull embodiment is distinguished from the others on the basis that: “The server
`
`buffer manager does not maintain a pointer into the server buffer for each user.
`
`Instead, the media player buffer manager in the user computer maintains a record
`
`of the serial number of the last data element that has been received.” Ex. 1001,
`
`14:45-49 (emphasis added).
`
`In this pull embodiment, streaming data elements are accumulated on the
`
`server-side and each associated with a respective serial identifier (Ex. 1001, 14:43-
`
`45). The player monitors the state of its own buffer, including without limitation
`
`the level of the buffer and what elements it needs for continuous playback (15:15-
`
`18), and requests them from the server by their serial identifiers (14:51-53), so as
`
`to maintain contents in the client buffer to provide uninterrupted playback. The
`
`player keeps doing this for the duration of the program. 14:56-58. The elements are
`
`transmitted as fast as the data connection will allow. 14:60-14:62. So long as the
`
`connection allows each element to be sent in less time than it takes to play it back
`
`(and per the disclosure, the connection itself is expected to have this capability, see,
`
`e.g., Ex. 1001, 9:62-10:4), this technique, allowing the player to determine when it
`
`needs data elements, can also serve as an effective stream control mechanism,
`
`making sure that the player has enough, but not too much, data to continue
`
`–8–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`uninterrupted playback for the duration of the program, notwithstanding transient
`
`changes in connection quality.
`
`The Institution Decision mixes descriptions of the push and pull embodiments.
`
`For example, Figure 3, reproduced in the Institution Decision, reflects subject
`
`matter not being claimed. Respectfully, the disclosures at 14:42-15:18 of the ’636
`
`patent are most pertinent to the claims at issue.
`
`IV. LEVEL OF SKILL
`
`Petitioners and Patent Owner provide descriptions as to the level of skill in the
`
`art at the time of the claimed invention that differ as to the requisite skills of such a
`
`person. See Ex. 1002 ¶ 54; Ex. 2006 ¶ 13. Patent Owner largely agrees with
`
`Petitioners’ formulation. One clarification Patent Owner would add is that the level
`
`of skill thus specified would include some theoretical understanding as well as
`
`some familiarity with basic internet protocols and tools for working with dynamic
`
`content and creating interactive web sites to handle such content. Ex. 2006 ¶ 13.
`
`V. CLAIM CONSTRUCTION
`
`Inter partes review now proceeds under the claim construction standard
`
`outlined in Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc).
`
`37 C.F.R. § 42.100. In addition, the subject patent has expired, and a Phillips
`
`construction applies for that reason as well. See In re CSB Sys. Int’l, Inc., 832 F. 3d
`
`1335, 1342 (Fed. Cir. 2016). According to Phillips, when construing a term, the
`
`–9–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`“objective baseline” is the “ordinary and customary meaning,” which is “the
`
`meaning that the term would have to a person of ordinary skill in the art in
`
`question at the time of the invention.” 415 F.3d at 1303, 1312-13. “[T]he best
`
`source for understanding a technical term” is a patent’s intrinsic evidence, which
`
`includes the patent and its prosecution history. Id. at 1315 (internal quotations
`
`omitted). However, because the prosecution history represents an “ongoing
`
`negotiation … rather than the final product of that negotiation, it often lacks the
`
`clarity of the specification and thus is less useful for claim construction purposes.”
`
`Id. at 1317. Additionally, if a term is fairly susceptible of two constructions, the
`
`construction that conforms to the actual invention should prevail. See id. at 1322
`
`(citing Smith v. Snow, 294 U.S. 1, 14 (1935)).
`
`Preambles
`
`Each of the preambles of claims 1 (method), 5 (server), and 9 (computer
`
`program product) recite distributing over the internet a live audio or video
`
`program, using respective language in each independent claim. See Ex. 1001, claim
`
`1 (“A method for distributing a live audio or video program over the Internet”);
`
`claim 5 (“A server system for distributing a live audio or video program over the
`
`Internet”); claim 9 (“A computer program product for distributing a live audio or
`
`video program”).
`
`–10–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`The plain meaning of the claims is thus that the related method, server, and
`
`program are for distributing an entire program over the internet, and not merely
`
`some portion of a program.
`
`This understanding is reflected in the body of each claim, which repeatedly
`
`refers to “the program” recited in the preamble, by way of the first step of
`
`“receiving at the server system a continuous digitally encoded stream for the audio
`
`or video program,” and a second step of supplying media data elements
`
`“representing the program,” which are the same media data elements that are
`
`referred to at length in the remainder of the body of each claim. This understanding
`
`is also confirmed by the specification. See, e.g., Ex. 1001, 14:56-58 (“The user
`
`computer then continues with additional data requests for the duration of playing
`
`the audio/video material.”)
`
`Using claim 1 as an example, the body of claim 1 makes clear that the recited
`
`method is applicable to the entire program, and not merely some portion thereof.
`
`Limitation “a” of the body recites “receiving at the server system a continuous
`
`digitally encoded stream for the audio or video program [and not just some part of
`
`it] from the computer-readable media.”
`
`Limitation “b” recites “supplying, at the server system, media data elements
`
`representing the program,” which is thus all of the elements that represent the
`
`program.
`
`–11–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`Limitations “c” and “d” recite “serially identifying the media data elements,”
`
`and “storing the media data elements,” for which the antecedent is all of the media
`
`data elements representing the entire program.
`
`Limitation “e” recites “receiving requests … for one or more of the media data
`
`elements … each received request specifying one or more serial identifiers of the
`
`requested one or more media data elements,” while limitation “g” recites
`
`“responsive to the requests, sending, by the server system, the one or more media
`
`data elements having the one or more specified serial identifiers, to the requesting
`
`user systems corresponding to the requests.” It is through these steps, a-g, that the
`
`entire program is delivered to the client computer.
`
`The claims thus address a continuous, time-sensitive process, whose continuity
`
`is critical to the user, as also made clear by the specification, and apply to an entire
`
`streaming program.
`
`f. “each received request specifying one or more serial identifiers of the
`requested one or more media data elements.” Ex. 1001, 16:48-50.
`
`The plain and literal meaning of limitation f is 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. This
`
`understanding is confirmed by the specification, which explains that “the user
`
`computer transmits a request to the server to send one or more data elements,
`
`specifying the serial numbers of the data elements,” to which the server responds
`
`–12–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`in kind. Ex. 1001, 14:51-56. The “one” term in the claim language is simply
`
`directed to the case of a request for a single element, while the “or more” term
`
`contemplates that a request may identify more than one element, by the elements’
`
`respective serial identifiers.
`
`h. “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.” Ex. 1001, 16:57-60.
`
`Patent Owner interprets limitation h to mean that the referenced data connection
`
`must have a data rate that can transfer the elements sent via the connection in less
`
`time than required to play back those elements at a normal rendition, where the
`
`elements “sent via that connection” include all media data elements comprising the
`
`requested program.
`
`Patent Owner does not construe limitation h to require that the instantaneous
`
`transfer rate of the connection be faster than the playback rate at all times during
`
`transmission of the requested program, as the specification makes clear that there
`
`will be reception interruptions with an internet connection. E.g., Ex. 1001, 12:14-
`
`18.
`
`A Phillips construction requires claim terms to be interpreted in light of the
`
`literal language at issue itself, as well as the surrounding claim language.
`
`Per limitation h itself, the data connection must have the specified data rate in
`
`excess of the playback rate, for “the one or more media data elements sent via that
`
`–13–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`connection.” This is not satisfied if, for example, in the course of streaming a
`
`program, the limitation is met for only one of the many requests/responses
`
`involved in streaming the program over the specified connection. When limitation
`
`h is read together with the other limitations of the claim, limitation h recites a data
`
`rate requirement for the specified connection, which applies over the entire
`
`streaming of the program referenced in the claim.
`
`The claims are directed to streaming “a program.” The preamble of claim 1, for
`
`example, recites “[a] method for distributing a live audio or video program over
`
`the Internet.”
`
`As discussed earlier, limitations “a” through “g” recite steps used to deliver the
`
`entire program to a client computer, by way of request and response interactions
`
`between client and server, with limitation g reciting “responsive to the requests,
`
`sending, by the server system, the one or more media data elements having the one
`
`or more specified serial identifiers, to the requesting user systems corresponding to
`
`the requests”.
`
`Thus, the words in limitation h, “the one or more media data elements sent via
`
`that connection” refers to those elements sent responsive to the plurality of
`
`“requests” recited in limitation g, that is, to all responsive media data elements.
`
`Moreover, limitation k provides that all such elements that are sent, are sent per
`
`the recited requests.
`
`–14–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`Consequently, limitation h must be read as applying the data rate requirement to
`
`the entire program stream, not just some arbitrary portion of it.
`
`The foregoing interpretation also follows from the specification. A stated object
`
`of the invention was to “facilitate continuous content transmission of streaming
`
`content” (Ex. 1001, 3:47-48 (emphasis added)), “maintaining protection against
`
`playback interruption (3:56-58), “as [the] media player requires for continuous and
`
`uninterrupted playback (4:11-12 (emphasis added)). The server’s connection to the
`
`media player is presumed to be faster than the playback rate (see, e.g., Ex. 1001,
`
`9:62-10:4), and “[t]he media data will be transmitted to the user computer as fast as
`
`the data connection between the user computer and the server will allow.” 14:60-
`
`14:62. “The server buffer manager does not maintain a pointer into the server
`
`buffer for each user. Instead, the media player buffer manager in the user computer
`
`maintains a record of the serial number of the last data element that has been
`
`received.” 14:45-49 (emphasis added). The media data is sent piecewise,
`
`responsive to requests by serial identifier. 14:51-56. The FIFO buffer on the client
`
`is “arranged to maintain the pre-determined number of data elements in the FIFO
`
`buffer.” 15:6-7. “As data is played out, the next sequential data elements are
`
`requested from the server in such a fashion as to approximately maintain the
`
`predetermined number of data elements in the user’s buffer.” 15:15-18.
`
`–15–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`Furthermore, “The user computer … continues with additional data requests for
`
`the duration of playing the audio/video material.” 14:56-58 (emphasis added).
`
`To send an entire program stream for rendition in real time, in the form of
`
`individually requested chunks or elements, imposes timing constraints. This is
`
`evident in itself, and in any case is corroborated by expert testimony. See Ex. 2006
`
`¶¶ 25, 45. In order for such a process to keep up with playback, the data connection
`
`that it uses must accommodate not only transmission within the time allowed by
`
`the aggregate element playback duration times, but must also accommodate the
`
`time required for the individual requests to the server and for the server to respond
`
`and begin transmitting the sending responsive to each request, as well as the
`
`irregularity of when the requests will be made. See Ex. 2006 ¶ 46. Hence, the
`
`specification contemplates and discloses, and the corresponding claims recite, a
`
`data connection more rapid than the playback rate, which is in effect during the
`
`entire program transmission, from beginning to end. This is what allows the
`
`claimed subject matter to meet the objects of the invention.
`
`Limitation h is phrased as a “wherein” limitation, and as such the context of the
`
`preceding claimed method must be understood to be performed over a data
`
`connection used to transmit each of the media data elements comprising the
`
`program.
`
`–16–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`The Petition does not cite the Federal Circuit decision on claim 10 of the ’141
`
`patent, but that decision should be noted. The Federal Circuit found that “each”
`
`requested element must be sent faster than the playback rate. 781 F. App’x at 1012.
`
`This could not be met, for example, by aggregating multiple links to add together
`
`their transfer rates. Here, the claim specifies that the rate of the data connection
`
`itself must be greater than the playback rate, for the elements sent via the
`
`connection. (A separate limitation (limitation i, not here at issue) further requires
`
`that “each sending is at a transmission rate as fast as the data connection between
`
`the server system and each requesting user system allow.”)
`
`In the Remand Decision, the PTAB, applying BRI, found that, for claim 10 of
`
`the ’141 patent, “each” did not require “all,” and thus that “each” could be satisfied
`
`where each element of some arbitrarily small segment of the program stream was
`
`sent faster than the playback rate. See Ex. 1007, 19-20.
`
`The instant claim language rules out such a piecemeal approach. The claim here
`
`extends to the elements “sent via that connection,” and the correct interpretation of
`
`limitation h is that the data rate criterion for the data connection applies with
`
`respect to the elements sent via the connection, which is elements that constitute
`
`the requested program.
`
`–17–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`j. “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.” Ex. 1001, 16:64–67.
`
`Patent Owner requests construction of limitation j. The Petition does not argue
`
`any particular construction for this term. The language of limitation j on its face
`
`means that whatever elements the server sends in response to a received request,
`
`and thus regardless of whether what is being sent is one element or more than one
`
`element that was specified in the request by its ID, those one or more elements
`
`(whichever the case may be) “are selected without depending on the server system
`
`maintaining a record of the last media data element sent to the requesting user
`
`systems.” This is so because each request tells the server specifically which
`
`respective elements to send. The server does not need to know or have any record
`
`of what it sent previously, to the same or other user system, in order to select each
`
`element in its response.
`
`Patent Owner further contends that limitation j applies to the entire program and
`
`is not satisfied by simply identifying a single element that starts a stream.
`
`Reference in limitation j to “the one or more media data elements sent” refers to
`
`what is sent “responsive to the requests” referenced in limitation g, which by its
`
`terms includes all of the elements responsive to “the requests,” which in turn refers
`
`back to all requests made per limitation f – in other words, all of the elements that
`
`make up the program stream.
`
`–18–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`As discussed above, and as described in the specification, the claimed method
`
`applies to the entire program, and limitation j applies to every element in the
`
`delivery of the program. The Institution Decision’s rationale suggests that
`
`limitation j can be satisfied by a single element, at the start of the stream, because
`
`the client specified that starting element. Since a stream starts, by definition, when
`
`no prior element in the sequence would have been sent, such an interpretation
`
`would render limitation j meaningless.
`
`k. “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.” Ex. 1001,
`17:1–3.
`
`Patent Owner requests construction of limitation k. The Petition does not argue
`
`any particular construction for this term.2
`
`
`2 Patent Owner notes that in t