`
`
`
` Case IPR2022-01413
` Patent 9,762,636
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`______________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________________________________
`
`
`
`
`
`GOOGLE LLC,
`
`Petitioner
`
`v.
`
`WAG ACQUISITION, LLC
`
`Patent Owner
`
`U.S. Pat. No. 9,762,636
`
`
`
`
`
`_______________________________________
`
`Inter Partes Review Case No. IPR2022-01413
`
`_______________________________________
`
`
`
`PATENT OWNER RESPONSE
`
`
`
`
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`TABLE OF CONTENTS
`
`
`
`I.
`
`INTRODUCTION ............................................................................................. 1
`
`II. DESCRIPTION OF THE DISCLOSURE AND CLAIMS ............................... 2
`
`III. LEVEL OF SKILL ............................................................................................. 6
`
`IV. CLAIM CONSTRUCTION ............................................................................... 6
`
`A. Construction: Note (labeling of limitations) ................................................. 7
`
`B. Construction: Preambles (distributing a “program”) .................................... 8
`
`C. Construction: Limitations c–c(ii){f} (structure of “requests”) ..................... 11
`
`D. Construction: Limitation d{g} (“sending” limitation) ..................................13
`
`E. Construction: Limitation d(i){h} (data rate of the data connection) .............13
`
`Construction: Limitation d(iii){j} (no dependency on server maintaining
`F.
`record of last element it sent) ...............................................................................19
`
`G. Construction: Limitation d(iv){k} (all elements sent in response to the
`requests) ................................................................................................................21
`
`V. ARGUMENT ...................................................................................................23
`
`A.
`
`Issues in Dispute ..........................................................................................23
`
`B. Response to Ground 1: Asserted obviousness of claims 1-12 over Carmel
`(single-reference obviousness) .............................................................................24
`
`1. Overview of Carmel .................................................................................24
`
`a) Background and Disclosure .................................................................24
`
`b) Pull Mischaracterization of Carmel .....................................................31
`
`2. Response to Ground 1, claims 1-12 .........................................................36
`
`a) The Petition fails to show that limitation b(i){c} (supplying media data
`elements at the server system) is rendered obvious by Carmel ...................36
`
`b) The Petition fails to show that limitations c–c(ii){f} (structure of
`requests) are rendered obvious by Carmel ...................................................37
`
`c) The Petition fails to show that limitation d(i){h} (data rate of the data
`connection) is rendered obvious by Carmel ................................................40
`
`–ii–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`d) The Petition fails to show that limitation d(iii){j} (no dependency on
`server maintaining record of last element it sent) is rendered obvious by
`Carmel ..........................................................................................................49
`
`e) The Petition fails to show that limitation d(iv){k} (all elements sent in
`response to the requests) is rendered obvious by Carmel ............................51
`
`f) Dependent claims (2-4, 6-8, 10-12) .....................................................56
`
`C. Response to Ground 2: Asserted obviousness of claims 1-12 over Carmel
`in view of Narayan ...............................................................................................56
`
`D. Response to Ground 3: Asserted obviousness of claims 1-12 over Carmel
`in view of Ravi .....................................................................................................57
`
`E. Response to Ground 4: Asserted obviousness of claims 1-12 over Carmel
`in view of Narayan and Ravi ................................................................................59
`
`VI. CONCLUSION ................................................................................................59
`
`
`
`
`
`–iii–
`
`

`

`
`
`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`LIST OF PATENT OWNER’S EXHIBITS
`
`Exhibit
`
`Description
`
`2001
`
`WAG Acquisition, LLC v. WebPower, Inc., 781 F. App’x 1007
`(Fed. Cir. 2019)
`
`2002
`
`Declaration of W. Leo Hoarty
`
`2003
`
`Declaration of Henry Houh (Ex. 1002 of IPR2022-01228)
`
`2004
`
`May 23, 2023, Deposition of Dr. Kevin Jeffay
`
`2005
`
`IETF RFC 2068
`
`2006
`
`May 25, 2023, Deposition of Dr. Nathaniel Polish
`
`2007
`
`2008
`
`2009
`
`2010
`
`2011
`
`Declaration of Dr. Nathaniel Polish, Emblaze Ltd. v. Apple Inc.,
`case no. 11-CV-01079 (N.D. Ca. Feb. 14, 2014)
`
`In re Certain Fitness Devices, Streaming Components Thereof,
`and System Containing Same, Inv. No. 337-TA-1265, Initial
`Determination (ITC, Sept. 9, 2022) (CALJ Clark S. Cheney)
`
`In re Certain Fitness Devices, Streaming Components Thereof,
`and System Containing Same, Inv. No. 337-TA-1265, Evidentiary
`Hearing – Volume III (ITC, March 14, 2022)
`
`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)
`
`2012
`
`Microsoft Computer Dictionary, Fifth ed. (excerpts)
`
`2013
`
`Redline comparison of claims of ’824 and ’636 patents
`
`2014
`
`Claim term concordance table
`
`2015
`
`IETF RFC 1945
`
`–iv–
`
`

`

`
`
`
`
` Case IPR2022-01413
` Patent 9,762,636
`
`I.
`
`INTRODUCTION
`
`Pursuant to 37 CFR § 42.120, WAG Acquisition LLC (“WAG” or “Patent
`
`Owner”) files this response to the Petition herein by Google LLC, and the
`
`Institution Decision.
`
`U.S. Patent No. 9,762,636 (the “’636 patent” or the “patent,” EX1001)
`
`addresses problems that existed in the transmission of media programs over the
`
`internet, including startup delays when a user requests a stream, as well as repeated
`
`interruptions once streaming has started, due to irregularities in the transport of
`
`data over the internet.
`
`The claims of the ’636 patent are drawn to a “pull” streaming model, in which
`
`movement of each successive streaming media element from the server is
`
`responsive to repeated individual requests from the client for the successive
`
`elements, by their respective serial identifiers. More particularly, the claims of the
`
`’636 patent address the server side of the pull interaction, and where the media is
`
`provided to the server from a live source.
`
`The Petition relies throughout on one principal reference, Carmel (EX1003),
`
`representing Carmel as disclosing the type of individual requests for successive
`
`media elements by serial ID, as claimed. However, as shown by Patent Owner’s
`
`expert, there was never substantial evidence for such successive “individual
`
`request” disclosures within the four corners of the reference, nor is there any
`
`
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`credible basis to find that Carmel would or could have been understood as such by
`
`a POSITA. EX2002 ¶¶ 58-69.
`
`Carmel thus completely misses on several limitations for which it has been put
`
`forth. The Petition asserts secondary references, including Ravi (EX1004) and
`
`Narayan (EX1005), that it would combine with its failed view of Carmel, but it
`
`asserts these additional references only for very limited points, which fail to
`
`address the wholesale inadequacies of Carmel itself, let alone any sufficient
`
`motivation to combine.
`
`Petitioner cannot meet its burden of proof based on the insufficient evidence
`
`that it has put forth. The challenged claims must accordingly be found not
`
`unpatentable.
`
`II. DESCRIPTION OF THE DISCLOSURE AND CLAIMS
`
`The ’636 patent describes several embodiments. All but one of them are “push”
`
`embodiments,1 in which a server serves media to one or more users from a buffer
`
`
`1 Though not claim terms, the terms “push” and “pull” reflect how engineers think
`
`about systems that involve the transfer of data sequences from a device regarded as
`
`a server to a device regarded as a client. EX2002 ¶ 21 (see also the deposition
`
`transcript of Petitioner’s expert, Dr. Nathaniel Polish, EX2006-22:1-23:6, which is
`
`
`
`–2–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`on the server. The claims of the ’636 patent are directed in particular at the
`
`disclosed “pull” embodiment, described at EX1001-14:42-15:18.2
`
`This discussion begins with the push embodiments, to highlight the
`
`commonalities as well as differences in the push and pull approaches. The
`
`disclosed push embodiments (described, for example, at EX1001-8:1-67) involve
`
`sending to the client an initial buffer load comprising a predetermined number of
`
`streaming media data elements, more rapidly than the playback rate, and
`
`continuing thereafter to send the stream elements that follow, at about the playback
`
`
`in accord). In the context of internet streaming, where streams comprise sequential
`
`data elements from a sender to a receiver, push is understood to mean that
`
`movement of the data elements is initiated by the sender. Pull is understood to
`
`mean that movement of the data elements is initiated by the receiver. EX2002 ¶ 21.
`
`The difference implicates not only the direction of control, but the timing of
`
`transmission, the relative complexity of the server vs. the client, and the
`
`requirements for the linking communication channel. Id. In a push, the server
`
`controls the rate of transmission, at least in the first instance. In a pull, the client
`
`controls the pace of delivery. Id.; see also EX2012.
`
`2 The printed line numbers differ slightly among WAG’s challenged patents. The
`
`col:line references herein are specifically to the ’636 patent, EX1001 in this IPR.
`
`–3–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`rate. The server utilizes a buffer from which to send streaming media elements, and
`
`maintains a pointer into the server buffer to mark the current position of each user
`
`in the stream. The server uses that pointer to determine what element to send to the
`
`respective users next. EX1001-7:23-28.
`
`The lone embodiment that does not follow a push pattern is the embodiment
`
`described at EX1001-14:42-15:18. This lone embodiment is a “pull” embodiment,
`
`and it is the pull embodiment that corresponds to the claims herein.
`
`The specification distinguishes the pull embodiment from the others on the
`
`basis that, in the disclosed pull embodiment: “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.” EX1001-14:45-49 (emphasis added).
`
`In the disclosed pull embodiment, streaming data elements are accumulated on
`
`the server and each is associated with a respective serial identifier (EX1001-14:43-
`
`45). As streaming progresses, 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 (EX1001-15:9-18), and requests media data elements from
`
`the server by their serial identifiers (EX1001-14:50-53), so as to maintain about a
`
`predetermined number of media data elements in the client buffer to provide
`
`uninterrupted playback. The player keeps doing this for the duration of the
`
`–4–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`program. EX1001-14:56-58. The connection from the internet to the user is faster
`
`than that required for media playback (EX1001-9:64-65), and in this embodiment,
`
`each element, when requested, is transmitted as fast as the data connection will
`
`allow (EX1001-14:60-14:62).
`
`The data connection as claimed is over the internet. Thus, the connection will
`
`predictably exhibit a degree of irregularity, because that is the nature of internet
`
`connections. See EX1001-2:34-40; EX2002 ¶¶ 26-27. However, so long as the
`
`connection allows the needed elements, requested as needed by the player, to be
`
`sent in less time than it takes to play them back, this technique, allowing the player
`
`to determine when it needs data elements, can serve as an effective transmission
`
`and stream control mechanism, providing a fast startup and making sure that the
`
`player has enough, but not too much, data to continue uninterrupted playback for
`
`the duration of the program, notwithstanding transient changes in connection
`
`quality. EX2002 ¶¶ 23-27.
`
`Also of note is what the push and pull embodiments have in common, which
`
`means that some of the advantages provided by the respective embodiments are
`
`shared. While the request/response mechanisms are completely different for the
`
`push and pull embodiments, in both cases, an initial “predetermined number” of
`
`media data elements are transferred from the server to the client more rapidly than
`
`the playback rate. EX1001-8:13-22 (push embodiment); EX1001-14:60-62,
`
`–5–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`EX1001-15:9-13 (pull embodiment). As a result of this initial rapid transfer, the
`
`client-side buffer then holds the specified amount of audio/video data and can play
`
`continuously despite data reception interruptions of less than the duration of that
`
`amount of media. Further, as soon as the interruption ceases, the user buffer (or
`
`other player memory that stores streaming data awaiting playback) can begin to
`
`rebuild, and similarly play through (and again recover from) the next such
`
`interruption. See EX1001-12:14-17.
`
`III. LEVEL OF SKILL
`
`Petitioner and Patent Owner provide descriptions as to the level of skill in the
`
`art at the time of the claimed invention. See EX1002 ¶ 21; EX2002 ¶ 13. Patent
`
`Owner largely agrees with Petitioner’s 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. EX2002 ¶ 13.
`
`IV. 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
`
`–6–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`1335, 1342 (Fed. Cir. 2016). According to Phillips, when construing a term, the
`
`“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)).
`
`A. Construction: Note (labeling of limitations)
`
`Google’s Petition refers to the preambles as “preamble” and begins from “a” in
`
`labelling the body limitations, whereas co-pending petitions filed by others label
`
`the preamble “a” and then continue, labelling the body limitations as “b” etc. The
`
`–7–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`“wherein” limitations, labelled in the other cases as [h]-[l], are labelled in the
`
`Google Petition as d[i]-d[v].3
`
`To maintain clarity, labelled limitations are cross-referenced herein, at the
`
`beginning of text discussing them, to the labels commonly used in the co-pending
`
`cases to address the same limitations. For example, “limitation d(i)” herein may
`
`sometimes be referred to as “limitation d(i){h},” the first label being the label in this
`
`case, and the label in braces {} connoting the label in the other IPRs, for the same
`
`limitation. A concordance is also provided in EX2014.
`
`B. Construction: Preambles (distributing a “program”)
`
`A [method] [computer program product] for distributing a live
`audio or video program over the Internet from a server system
`[] to a plurality of user systems […] EX1001-16:28-30, EX1001-
`18:10-16 (claims 1-4 and 9-12)
`
`A server system for distributing a live audio or video program
`over the Internet to a plurality of user systems EX1001-17:15-
`17 (claims 5-8)
`
`The plain meaning of the claims is that the claimed method, server, and
`
`program are for distributing an entire program over the internet, and not merely
`
`some portion of a program.
`
`
`3 As addressed below, Google’s labelling convention here should not be taken as
`
`evidence of the status of the preamble or that the “wherein” limitations relate only
`
`to limitation d.
`
`–8–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`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, and are limiting.
`
`See EX1001, for example, claim 1 (“A method for distributing a live audio or
`
`video program over the Internet”).
`
`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 “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., EX1001-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 … the … program [and not just some
`
`part of it] … from a live source.”
`
`Limitation “b” recites “upon receipt of the stream by the server system.”
`
`–9–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`Limitation “b(i)”{a} recites “supplying, at the server system, media data
`
`elements representing the program,” which is thus all of the elements that represent
`
`the program.
`
`Limitations “b(ii)”{d} and “b(iii)”{e} 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.
`
`Limitations “c”{f}, “c(i)”{f}, and “c(ii)”{f} recite “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,” and “each
`
`received request originating from a requesting user system of a plurality of user
`
`systems,” while limitation “d”{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-d{b-g}, that the entire program is delivered to
`
`the client computer.
`
`Moreover, limitations d(i){h} and d(ii){i} recite (i) the characteristics of “the data
`
`connection,” which would be understood to be the same connection throughout the
`
`distributing, and (ii) relate to “each sending” over that connection, again
`
`addressing the entire transmission, and limitations d(iii){j} and d(iv){k} recite further
`
`–10–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`conditions relating to the “pull” character of the streaming that likewise apply
`
`throughout the entire stream.
`
`This read, which is reasonably evident on the face of the claims, closely tracks
`
`the specification, which states: “the user computer transmits a request … to send
`
`one or more data elements, specifying the serial numbers of the data elements….
`
`The user computer then continues with additional data requests for the duration of
`
`playing the audio/video material.” EX1001-14:56-58.
`
`The claims thus address a continuous, time-sensitive process, whose continuity
`
`is critical to the user, as also made clear by the specification, and its limitations
`
`apply for the entire streaming of the program.
`
`C. Construction: Limitations c–c(ii){f} (structure of “requests”)
`
`receiving requests at the server system via one or more data
`connections over the Internet, for one or more of the media data
`elements stored in the data structure, each received request
`specifying one or more serial identifiers of the requested one or
`more media data elements, each received request originating
`from a requesting user system of a plurality of user systems
`EX1001-16:45-52.4
`
`The plain and literal meaning of limitations c–c(ii) is that, even if the “received
`
`request” is for more than one element, each such requested element is identified in
`
`
`4 In contrast to the ’824 patent, which recites “one or more” user systems, the
`
`instant claim language recites “a plurality of user systems,” reflecting that “live”
`
`
`
`–11–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`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
`
`in kind. EX1001-14:51-54. The “one” term in the claim language is 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.
`
`Furthermore, read in light of limitation d (see below), this is the only reasonable
`
`interpretation of limitations c–c(ii). Should the Board nevertheless be of the view
`
`that this limitation is fairly susceptible to a different construction, the foregoing
`
`interpretation should prevail, because it also conforms to the actual invention. See
`
`Phillips, 415 F.3d at 1322. The only disclosed embodiment corresponding to this
`
`claim makes clear that each requested element is requested by its serial identifier.
`
`EX1001-14:51-53 (“the user computer transmits a request to the server to send one
`
`or more data elements, specifying the serial numbers of the data elements”).
`
`
`transmission will generally be to a plurality of simultaneous consumers of the
`
`media. See EX2002, n.3 preceding ¶ 71.
`
`–12–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`D. Construction: Limitation d{g} (“sending” limitation)
`
`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 EX1001-16:53-56.
`
`The antecedent of “the requests” in limitation d is the “requests” received per
`
`limitations c–c(ii). The plain and ordinary meaning of this limitation is that if the
`
`request responded to is for more than one element, then each of the elements in the
`
`response must have been specified as part of the request by its respective serial ID.
`
`E. Construction: Limitation d(i){h} (data rate of the data connection)
`
`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. EX1001-16:57-60.
`
`Over the internet, the capabilities of the “data connection” between the server
`
`system and each requesting user system is a function of the server’s connection, the
`
`client’s connection, and the capabilities of the connections along the route
`
`therebetween. EX2002 ¶ 48. The “data rate,” as that term is used in this limitation,
`
`is the rate of data transfer, such as in bits per second, that the data connection
`
`supports, i.e., its capacity. See EX1001-4:37-54.5 The “playback rate” is the rate at
`
`
`5 The rate that data is actually carried over the connection having the specified
`
`capacity is addressed separately in the claims, in limitation d(ii){i}.
`
`–13–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`which the media (however encoded) will be played out at a normal rendition. See
`
`EX1001-5:60-65, 9:32-35.6
`
`
`6 In ¶ 150 of his declaration (EX1002), Petitioner’s expert, Dr. Polish, addressing
`
`data connection rate and playback rate, cited an example from the ’636 patent,
`
`EX1001-9:32-35, which, in full context stated the following:
`
`Connections from the server 12 through the Internet 10 commonly
`are much faster than the data rate required for audio or video
`playback… The user, typically interacting with media player
`software on the user’s computer, selects a media source requiring a
`data rate slower than that available by the user’s connection to the
`Internet. For example, if the user’s connection to the Internet is
`made via a 56,000 bits per second modem, the user might select a
`media source encoded for playback at 24,000 bits per second.
`
`EX1001-9:22-35. Dr. Polish introduced his discussion of this disclosure with the
`
`statement that “the ‘playback rate’ of a media file is the rate at which the media is
`
`played at normal speed, from beginning to end, through the computer.” EX1002 ¶
`
`150. The plain and ordinary meaning, therefore, of the d(i) limitation read in view
`
`of the accompanying disclosure, as reflected in Dr. Polish’s own example, is that
`
`the “data rate” of the “data connection” between the server and the client means the
`
`capacity of the connection established, as that is what is meant when referring to,
`
`e.g., a “56K” connection made by a “56,000 bits per second modem.” EX2002 ¶
`
`76. A POSITA would understand that the user deploying a 56K modem to its
`
`
`
`–14–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`Patent Owner does not construe limitation d(i) 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., EX1001-12:14-18;
`
`EX2002 ¶ 49.
`
`Further, while the terms reviewed so far go to the required capacity of the data
`
`connection, the claim also addresses over how many elements the specified data
`
`rate condition must hold—its durational scope. In this regard, limitation d(i) further
`
`requires that the data rate specification hold true for the connection over “the one
`
`or more media data elements sent via that connection.”
`
`The Petition appears to address alternative constructions in regard to the
`
`durational scope of the “more rapid than the playback rate” condition. See Pet. 33-
`
`36 (appearing to argue that the rate of transfer of any one slice that is greater than
`
`the playback rate would meet this limitation) and compare with “Third” at the
`
`bottom of p. 36 (addressing the construction that “‘data rate’ refers to the speed of
`
`
`expected benefit would have a service that supports such a rate, and that the
`
`capacity of such a connection in the sense addressed by limitation d(i) would be
`
`the connection’s general expected rate of data transfer in the absence of network or
`
`server interruptions or slowdowns (i.e., 56K). Id.
`
`–15–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`the overall connection between server 36 and client 30, rather than the speed with
`
`which an individual slice is transmitted from the server 36 to client 30”).
`
`Patent Owner 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.
`
`Patent Owner further interprets “any request” to be not just any single request
`
`(for one or more elements), but any such request among the plurality of such
`
`requests made in the course of transmitting the program. This further assertion is
`
`because limitation d(i), read in view of the surrounding claim language and in view
`
`of the specification, recites a characteristic of the data connection itself, which
`
`applies throughout performance or operation of the claimed subject matter, with
`
`respect to all media data elements sent over the connection in transmitting the
`
`requested program.
`
`The Federal Circuit, addressing claim 10 of related U.S. Patent No. 8,122,141
`
`(the “’141 patent”), ruled: “In our view, the “rate” in claim 10 refers to the rate at
`
`which each requested media data element is transmitted from the server to the user
`
`computer.” EX2001 at 10. It would be inconsistent with this ruling if limitation
`
`–16–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`d(i), based on the same disclosure, were to be construed such that the data rate of
`
`the data connection was not more rapid than the playback rate of “each” requested
`
`media data element. Here, the elements in question comprise at least the one or
`
`more elements sent in response to any request for one or more elements sent by the
`
`user system to the server system.7
`
`The foregoing interpretation also follows from the specification. A stated object
`
`of the invention was to “facilitate continuous content transmission on demand”
`
`(EX1001-3:55-56 (emphasis added)), “maintaining protection against playback
`
`interruption” (EX1001-3:57-58), “as [the] media player requires for continuous
`
`and uninterrupted playback” (EX1001-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., EX1001-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
`
`
`7 In its 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 EX2011 at 19-20. The instant claim language
`
`rules out such a piecemeal approach. The claim here goes to the connection itself,
`
`and to the elements “sent via that connection.”
`
`–17–
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`will allow.” EX1001-14:60-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.” EX1001-14:45-49 (emphasis added). The
`
`media data is sent piecewise, responsive to requests by serial identifier. EX1001-
`
`14:50-56. The FIFO buffer on the client is “arranged to maintain the pre-
`
`determined number of data elements in the FIFO buffer.” EX1001-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.” EX1001-15:15-18.
`
`Furthermore, “The user computer … continues with additional data requests for
`
`the duration of playing the audio/video material.” EX1001-14:56-58 (emphasis
`
`added).
`
`Limitation d(i) is