`
`
`
`
`
`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 PRELIMINARY RESPONSE
`
`

`

`
`
`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`TABLE OF CONTENTS
`
`
`I.
`
`INTRODUCTION ............................................................................................... 1
`
`Context of this Petition .......................................................................................... 3
`
`Replay of Prior Challenges Falls Short as to Later Family Patents ....................... 5
`
`II. BACKGROUND OF THE ’636 PATENT ......................................................... 6
`
`A. Overview of the disclosure ............................................................................... 6
`
`B. Level of Ordinary Skill in the Art ..................................................................11
`
`III. CLAIM CONSTRUCTION ..............................................................................11
`
`IV. EACH ALLEGED GROUND OF PATENTABILITY FAILS THE
`“REASONABLE LIKELIHOOD” TEST ...............................................................16
`
`A. Ground 1 – Carmel (Ex. 1004) (alleged single-reference obviousness) ........16
`
`[1.k], [5.k], [9.k] – all of the media data elements that are sent by the
`1.
`server system to the plurality of user systems are sent in response to the
`requests .............................................................................................................17
`
`Obviousness contention ...................................................................................23
`
`[1.h], [5.h], [9.h] - the data connection between the server system and
`2.
`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; [1.i], [5.i],
`[9.i] each sending is at a transmission rate as fast as the data connection
`between the server system and each requesting user system allows ...............26
`
`B. Ground 2 – Carmel (Ex. 1004) in view of Shteyn (Ex. 1008) .......................30
`
`[1.j], [5.j], [9.j] - the one or more media data elements sent are selected
`1.
`without depending on the server system maintaining a record of the last media
`data element sent to the requesting user systems .............................................31
`
`2. The Petition fails to set forth identify a sufficient motivation for a
`POSITA to combine Carmel and Shteyn .........................................................35
`
`V. CONCLUSION ..................................................................................................38
`
`
`
`- ii -
`
`

`

`
`
`
`I.
`
`INTRODUCTION
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`Patent Owner takes the opportunity of this Preliminary Response to point out
`
`why the Petition fails to provide a sufficient basis under which the Board could
`
`find any claim of U.S Patent No. 9,762,636 (the “’636 patent”) to be unpatentable.
`
`Any case for invalidity must be made, in the first instance, in the Petition.
`
`Applicable law specifies that it is Petitioners who must specify “[h]ow the
`
`challenged claim is to be construed” and “[h]ow the construed claim is
`
`unpatentable,” including “specify[ing] where each element of the claim is found in
`
`the prior art patents or printed publications relied upon.” 35 U.S.C. § 312(a)(3); 37
`
`CFR § 42.104(b)(3)-(4). “[I]t is Petitioner’s burden to establish, in the Petition, a
`
`reasonable likelihood of success, which includes, inter alia, explaining how a
`
`challenged claim is construed and how the prior art teaches that claim.” World
`
`Bottling Cap, LLC v. Crown Packaging Tech., Inc., Case IPR2015-00296, Paper 8
`
`at 5 (P.T.A.B. May 27, 2015) (denying rehearing). See also Harmonic Inc. v. Avid
`
`Tech., Inc., 815 F.3d 1356, 1363 (Fed. Cir. 2016) (citing 35 U.S.C. § 312(a)(3)
`
`(requiring inter partes review petitions to identify “with particularity … the
`
`evidence that supports the grounds for the challenge to each claim”)).
`
`Fundamentally, the Petition heavily relies on a reference, Carmel et al., U.S.
`
`Patent No. 6,389,473, Ex. 1004 (“Carmel”), which was the focal point of prior IPR
`
`proceedings with regard to other patents owned by Patent Owner. Carmel, and the
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`prior Board institution decision based on Carmel (on U.S. Patent Nos. 8,122,141
`
`(the “’141 patent”)), were before the Examiner, as reflected on the front page of the
`
`’636 patent. However, the claims to which Carmel was applied in the prior IPR
`
`proceedings lacked a number of explicit limitations incorporated in the claims
`
`addressed herein.1 The Petition seeks to gloss over the additional limitations that
`
`are incorporated in the present claims, failing to provide any reference or
`
`combination of references that address all of those limitations. It fails as well to
`
`provide a sufficient basis on which the Board could find the additional claim
`
`features obvious, based on the foundation of the present Petition, whether now or
`
`as a result of anything that might reasonably be expected to develop as a result of
`
`institution.
`
`This submission addresses only the issue of institution of trial. Should a trial
`
`be instituted, Patent Owner reserves any and all arguments not expressly addressed
`
`herein.
`
`
`1 The patents challenged in the current round of IPRs all issued in 2017, well
`
`after the filing of the prior round of IPRs (which (other than joinder petitions)
`
`was in 2015 and 2016).
`
`- 2 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`Context of this Petition
`
`In this and two other now-pending IPRs, the present Petitioners challenge
`
`three patents that have been asserted against them in parallel litigation: (i) the ’636
`
`patent (Ex. 1001), (ii) U.S. Patent No. 9,742,824 (the “’824 patent”) (see IPR2022-
`
`01228), and (iii) U.S. Patent No. 9,729,594 (the “’594 patent”) (see IPR2022-
`
`01346).
`
`All three of these patents address a particular embodiment disclosed in the
`
`common specification underlying the three patents. That disclosure is of an internet
`
`streaming media mechanism – wherein (among other required specified aspects
`
`and limitations) the stream consists of serialized, time-sequenced elements of an
`
`audio or video program, and the elements are served to one or more clients over
`
`the internet, in each case responsive to specific requests for the elements that
`
`originate from the respective client devices. The express claim limitations, taken
`
`together, recite a transmission of the respective elements comprising the stream
`
`that is driven, from beginning to end, by client requests for specified elements, and
`
`thus the claimed streaming process may be thought of as a “pull.” These requests,
`
`each made by the client, are timed as the client determines to be necessary in order
`
`to keep its incoming media buffer at a sufficient level of fill to sustain continuous
`
`playback, despite variations in connection quality over the course of the
`
`transmission.
`
`- 3 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`The claims of all three patents addressed by the current round of IPRs
`
`involve “client-server” interactions. However, the respective claims are directed to
`
`one side or the other of the client-server interaction. Thus, on the one hand, the
`
`’636 and ’824 patent claims are drawn to streaming from the viewpoint of the
`
`server (with the ’636 patent directed to an embodiment where the feed being
`
`distributed is from a live source, and the ’824 patent directed to a similar server
`
`embodiment in which the media to be streamed is pre-recorded). On the other
`
`hand, the claims of the ’594 patent are drawn to a client-side mechanism that could
`
`be used for requesting the stream elements from either type of server (live or
`
`prerecorded), serving as a media source to the requesting client.
`
`In summary, all three patents address a “pull” streaming mechanism; the
`
`’636 and ’824 patents address this mechanism from the server side (for live and
`
`prerecorded media, respectively); and the ’594 patent addresses the mechanism
`
`from the client side (for either live or prerecorded media).
`
`In prior proceedings, other parties (accused of infringement in earlier
`
`parallel litigation) have challenged claims of previously issued family patents. The
`
`other family patents include without limitation the ’141 patent and U.S. Patent No.
`
`8,327,011 (the “’011 patent”). The IPR challenges against the ’011 patent (which,
`
`like the ’594 patent, address a steaming mechanism from the client side) were
`
`declined institution (though a reexamination of the ’011 patent (s/n 90/014,833) is
`
`- 4 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`in process). An IPR on certain claims of the ’141 patent (which primarily concern
`
`streaming from the server side) was instituted (IPR2016-01238), which IPR led to
`
`a final written decision cancelling certain of those claims (and reexamination of
`
`further claims of the ’141 patent is pending, s/n 90/014,834).
`
`Replay of Prior Challenges Falls Short as to Later Family Patents
`
`Significantly, the lead reference in the most recent prior IPR challenges of
`
`the ’141 and ’011 patents was Carmel (Ex. 1004), and that reference was litigated
`
`at length, including a reversal in the Federal Circuit (WAG Acquisition v.
`
`WebPower, Inc., 781 F. App’x 1007 (Fed. Cir. 2019)), which narrowed the Board’s
`
`construction of the ’141 patent claims. Significantly, Petitioners rely on Carmel as
`
`their lead reference here as well.
`
`There is a considerable difference between the claims of the current round of
`
`challenged patents and the claims considered as against Carmel in the prior IPR
`
`proceeding against the ’141 patent. This difference lies in the fact that the current
`
`claims incorporate a further string of “wherein” limitations, which, taken together,
`
`leave no room for doubt that the claimed streaming mechanisms, and the
`
`limitations set forth for streaming the respective elements, apply to transmission of
`
`the entire stream, from beginning to end. The Board, in ruling against the
`
`challenged claims of the ’141 patent (and in that case, under a BRI claim
`
`construction standard), considered that a beginning-to-end characteristic did not
`
`- 5 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`specifically limit the claims there at issue, finding it sufficient that Carmel
`
`addresses at least some portion of a partial stream. See WebPower, Inc. v. WAG
`
`Acquisition, LLC, IPR2016-01238, Paper 28 at 19 (Ex. 1007). As will be addressed
`
`herein, however, Carmel simply does not concern streaming an entire program
`
`stream via a “pull” mechanism. Thus, the Petition’s reliance on Carmel is
`
`misplaced, even if recast as a § 103 challenge (as here), rather than under § 102 (as
`
`previously litigated).
`
`Ground 1 rests on asserted single-reference obviousness. However, no
`
`sufficient rationale has been provided to support a case of single-reference
`
`obviousness that overcomes the deficiencies of Carmel.
`
`While Ground 2 cites an additional piece of prior art, in an effort to make an
`
`obviousness combination, the added item of prior art fails to address significant
`
`gaps in disclosure that are left by Carmel, and which correspond to express claim
`
`limitations, and fails to provide a sufficient rationale for combining the disclosures.
`
`For these reasons, Patent Owner respectfully submits that the Petition is
`
`inadequate to trigger institution.
`
`II. BACKGROUND OF THE ’636 PATENT
`
`A. Overview of the disclosure
`
`The ’636 patent addresses the problem of how to achieve the perception of
`
`immediate startup (“Instant-On”) of internet streaming when the user clicks on an
`
`- 6 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`audio-visual media stream, as well as thereafter maintaining uninterrupted
`
`delivery. See, e.g., ’636 patent, 3:45-58 (“respond on demand without
`
`objectionable buffering delay”); see also id., 6:15-18 (“Immediate playing on a
`
`user’s computer is afforded”).
`
`Audio and visual media transmitted over a computer network are streams of
`
`data – sets of time-sequenced media data elements. Id., 6:30-32. When delivered
`
`over the network, the data stream flows from a source (server) to a player (client)
`
`for playback. Id., 6:59-7:2.
`
`A problem arises when the aim is to distribute a media program via
`
`streaming over the Internet, as opposed to transferring (downloading) an entire
`
`recorded version of the program and playing it back after the entire recording has
`
`been transferred. The problem arises because transmission can be uneven over the
`
`Internet. The Internet is a patchwork of relayed connections and, while it can work
`
`well for delivering data, does not guarantee timely delivery of data between nodes.
`
`See, e.g., ’636 patent, 2:34-38 (citing “delays and losses that are inherent in many
`
`Internet protocols), 3:5-6, 5:7-15. The Internet can ensure that all data items will be
`
`delivered but cannot assure when any individual item will arrive. Thus, since
`
`media programming relies on time-sequenced data, the Internet is susceptible to
`
`transmission delays of varying magnitude, for delivering such programming.
`
`- 7 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`Internet delivery delays result (inter alia) from transient congestion and
`
`contention at routing nodes. Larger delays in data transit potentially result in
`
`sustained interruptions for the data consumer (see, e.g., ’636 patent, 2:38-42).
`
`Internet delivery delay of a stream can result in a delayed or stuttering startup and
`
`frequent recurring interruptions. See id., 6:11-12 (“startup delays and dropouts”).
`
`A pre-existing partial solution is to add a buffer to the client device. Id.,
`
`2:42-45. Allowing the client-side buffer first to receive and accumulate a portion of
`
`the stream, amounting to, e.g., 30 seconds’ worth of data, before beginning
`
`playback, allows the playback to withstand up to 30 seconds (cumulatively) of
`
`transmission delays before the client-side buffer runs out of data, which if it
`
`occurred would cause a playback interruption. See, e.g., id., 3:16-27. The drawback
`
`of this approach is the need to wait on streaming startup in order to fill the client-
`
`side buffer in advance, before playback can begin. See id., 2:50-55. This startup
`
`delay was the “hourglass” streaming experience that was prevalent before
`
`Plaintiff’s patents, and it was very frustrating to users, severely limiting the
`
`marketability of programming streamed over the Internet. Id., 3:35-41.
`
`The inventor, Harold Price, conceived of alternate embodiments to address
`
`the above-described problems perceived in the prior art. One such embodiment,
`
`referred to herein as the “buffering” or “push” embodiment (and not the
`
`embodiment directly involved here, but described here to provide additional
`
`- 8 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`context), uses two buffers, one on the server side, and one on the client side, which
`
`interact in a particular way. See ’636 patent, 8:1-29. The server waits until the
`
`server-side buffer is full before sending its data to the client. In this embodiment,
`
`the server buffer operates on a first-in-first-out (FIFO) basis – starting delivery
`
`back from the point the data was buffered from – so that there is a block of
`
`accumulated data in the buffer, which can be sent quickly (e.g., as fast as the
`
`connection with the client will allow), in order to jump-start the transmission to the
`
`client. See, e.g., id., 9:36-45. Thereafter, the server (in this embodiment) continues
`
`to push data to the client, but since the initial buffer load has already been sent at
`
`this point, it only does so at about the rate that the data continues to arrive at the
`
`server buffer, i.e., at about the playback rate. Id., 9:53-66. Hence, in this
`
`embodiment, the server paces the delivery of media data elements to the client.
`
`In a separate embodiment (see ’636 patent, 14:42-15:18), which is the
`
`embodiment most pertinent to the claims in this case, the pace of transmission of a
`
`stream can instead be regulated, not by the server modulating its delivery, but
`
`rather by the player’s timing of its own requests for elements of the stream. The
`
`latter is referred to herein as the “pull” embodiment. The disclosure specifically
`
`distinguishes this further embodiment:
`
`In another embodiment, the server is connected to the Internet and
`provisioned as initially described. The server buffer manager, or the
`media source, provides for sequentially numbering the media data
`elements. The server buffer manager does not maintain a pointer
`
`- 9 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`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.
`
`’636 patent, 14:42-49 (emphasis added). Thus, the pull embodiment, as further
`
`detailed, (id., 14:50-15:18), relies on client requests to pace the delivery, based on
`
`what the client has received, as opposed to the server managing its sendings, based
`
`on what the server has already sent.
`
`In the pull embodiment, streaming data elements are (similar to the first
`
`embodiment) accumulated on the server side (similar to the “buffer” in the above-
`
`described embodiment). In that embodiment, each such element is associated with
`
`a respective serial identifier (id., 14:43-45). Further per this embodiment, 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 (id., 15:15-18), and
`
`requests them from the server by their serial identifiers (id., 14:50-53), so as
`
`maintain contents in the client buffer to thus provide uninterrupted playback. The
`
`elements are transmitted as fast as the data connection will allow (id., 14:60-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., id., 9:62-63), 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
`
`- 10 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`continue uninterrupted playback for the duration of the program, notwithstanding
`
`transient changes in connection quality.
`
`B.
`
`Level of Ordinary Skill in the Art
`
`Petitioners allege that a person having ordinary skill in the art (“POSITA”)
`
`would have had a B.S. degree in computer science or electrical engineering (or
`
`comparable degree) and two years of experience in networking or streaming
`
`media, or a M.S. in computer science or electrical engineering (or comparable
`
`degree). Petition at 8. For purposes of this Preliminary Response only, Patent
`
`Owner does not dispute this characterization of a POSITA. Patent Owner,
`
`however, reserves the right to more clearly characterize a POSITA should the
`
`Board decide to institute review.
`
`III. CLAIM CONSTRUCTION
`
`“In an inter partes review proceeding, a claim of a patent … shall be
`
`construed using the same claim construction standard that would be used to
`
`construe the claim in a civil action under 35 U.S.C. 282(b), including construing
`
`the claim in accordance with the ordinary and customary meaning of such claim as
`
`understood by one of ordinary skill in the art and the prosecution history pertaining
`
`to the patent.” 37 C.F.R. § 42.100.
`
`- 11 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`Petitioners have not asserted that any claim terms require any construction
`
`other than plain and ordinary meaning (see Petition at 9-10), and Patent Owner
`
`does not argue otherwise herein.
`
`At the same time, the Petition repeatedly suggests that claim constructions
`
`and factual findings from earlier Board decisions concerning the ’141 patent, as
`
`well as U.S. Patent No. 8,364,839 (the “’839 patent”) are binding here (see, e.g.,
`
`Petition at 10 (claim construction), and 21, 28, 29, 33, 35 (factual findings)).
`
`The Petition (at 10) cites “[l]ogic and consistency” in support of this
`
`analysis. On page 18, the Petition even goes so far as to use the words “collateral
`
`estoppel,” but of course collateral estoppel does not apply with respect to claim
`
`constructions made on 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) (“it can not be presumed that related patents rise and fall
`
`- 12 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`together.”). See also VirnetX Inc. v. Apple, Inc., 909 F.3d 1375, 1377 (Fed. Cir.
`
`2018) (collateral estoppel requires identity of issues).
`
`In addition to the fact that the applicable claim construction standard has
`
`changed since the prior IPRs, the claim language at issue here is different. For
`
`example, claim 10 of the ’141 patent recites “caus[ing] the server 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 by a user,” whereas
`
`claim 1 here recites, among other limitations, that “each sending is at a
`
`transmission rate as fast as the data connection between the server system and each
`
`requesting user system allows,” over a connection having “a data rate more rapid
`
`than the playback rate,” that all media data elements sent “are sent in response to
`
`the requests [i.e., the user requests by serial ID],” and that this is done “without
`
`depending on the server system maintaining a record of the last media data element
`
`sent to the requesting user systems.” Thus, the claims here go beyond the claims of
`
`the ’141 patent in expressly spelling out that the limitations set forth apply over
`
`and throughout the transmission of the stream. Legal conclusions that concerned
`
`earlier issued claims that lacked such additional language do not necessarily apply.
`
`Nevertheless, Patent Owner will agree that there is considerable relevance
`
`here of the Federal Circuit decision, under the ’141 patent, regarding which media
`
`data elements had to be sent faster than the playback rate, insofar as the Federal
`
`- 13 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`Circuit’s analysis in this regard arose by reference to the same disclosures of a
`
`common patent specification that are relevant here. Although it was proceeding
`
`under BRI, the Federal Circuit, in reversing the Board, clearly adopted a narrower
`
`construction than the earlier Board construction that was appealed. In particular,
`
`the Federal Circuit, viewing the claim language there at issue in light of the
`
`specification, construed “the claimed ‘rate’ [under claim 10 of the ’141 patent] as
`
`the rate at which each requested data element is transmitted from the server to the
`
`user computer.” WAG Acquisition, 781 F. App’x at 1012 (emphasis added). The
`
`Board on remand found that under the particular wording of claim 10 of the ’141
`
`patent, sending “each” of the requested elements at the specified rate did not
`
`necessitate sending “all” of the elements comprising the stream at that rate, i.e., did
`
`not (in the Board’s view) necessitate that the recited “requested elements”
`
`extended to all elements of the stream. See WebPower, Inc. v. WAG Acquisition,
`
`LLC, IPR2016-01238, Paper 28 at 19-20 (Ex. 1007). As will be addressed, the
`
`(later issued) claims at issue here do recite that all elements transmitted are indeed
`
`“requested,” so the situation here clearly differs from the prior case. Nevertheless,
`
`apart from the question of which elements are “requested,” the Federal Circuit’s
`
`interpretation that “each” element that is requested must be sent at the specified
`
`rate, applies here with comparable force. The present claims, on their face, resolve
`
`the issue of which elements are requested, specifying that it is indeed all of them,
`
`- 14 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`but the Federal Circuit’s rationale and conclusion as to the rate at which each of
`
`the elements must be sent remains applicable.
`
`Thus, whatever room may have existed (in the prior remand) for the Board
`
`to reach the result that the ’141 patent did not apply its “rate” limitation to all
`
`stream elements, such room cannot be found in claim 1 of the ’636 patent, as the
`
`latter, by distinct contrast, recites that all media data elements sent by the server
`
`system are sent in response to the recited client requests by serial ID, and that
`
`“each sending is at a transmission rate as fast as the data connection between the
`
`server system and each requesting user system allows,” over a connection having a
`
`data rate more rapid than the playback rate.2
`
`The question then becomes whether the cited references reach the present
`
`claim limitations as they read or render them obvious. The answer is that they
`
`clearly do not, and there is no likelihood that institution under the present Petition
`
`would lead to any other result.
`
`
`2 Other proceedings cited in the Petition involved the ’839 patent. Claim 1 of the
`
`’839 patent recites a “push” distribution method and thus presents an entirely
`
`different factual scenario (“loading the server buffer with streaming media data
`
`elements; sending an initial amount of streaming media data elements to the
`
`user system at an initial sending rate more rapid than the playback rate….”).
`
`- 15 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`IV. EACH ALLEGED GROUND OF PATENTABILITY FAILS THE
`“REASONABLE LIKELIHOOD” TEST
`
`Patent Owner addresses below specific shortcomings that it asserts weigh
`
`strongly against institution. Where possible, Patent Owner uses the same claim
`
`element numbering scheme as used in the Petition.
`
`Out of the gate, the Petition mischaracterizes Carmel, stating that
`
`“[Carmel’s] [c]lients 30 connected with server 36 read an index file containing …
`
`numbered slices and request or pull the sequential slices by identifier at a fast rate
`
`over the network.” Petition at 13. The Petition purports to support this assertion
`
`with a string cite, but none of the citations actually disclose what the Petition
`
`asserts. This mischaracterization runs throughout the Petition and is fundamental to
`
`its attempt to map the claim language to Carmel, which fails on several limitations.
`
`A. Ground 1 – Carmel (Ex. 1004) (alleged single-reference
`obviousness)
`
`Limitations g, and the “wherein” provisos that follow, h, i, j, and k, all being
`
`in the same claim (claim 1, and corresponding claims 5 and 9), must be read
`
`together. Taken together:
`
`• all elements sent are sent in response to client requests [k] and without
`
`dependency on a record of the last element sent [j],
`
`• each sending (referring here to the sending of each and every element) is
`
`as fast as the data connection allows [i],
`
`- 16 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`• over [h] a data connection having a data rate more rapid than the
`
`playback rate.
`
`Carmel does not meet k and j. Nor does it meet h and i. Patent Owner will
`
`first address limitations k and j, which in itself should be dispositive, and then
`
`limitations h and i, which Carmel also fails to meet.
`
`1.
`[1.k], [5.k], [9.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
`
`and
`
`[1.j], [5.j], [9.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
`
`Despite how it is characterized in the Petition, Carmel is not based upon a
`
`“pull” methodology. Rather, it is based upon seeking to a location in the stream
`
`specified by a client request to the server, followed by the server “pushing” the
`
`stream from that location to the client. Carmel, 10:42-48 (“client 30 selects an
`
`appropriate starting slice and begins to download and decode (decompress) files
`
`42, 44, 46, etc.”).
`
`Because of its “seek then download” nature, Carmel fails to disclose or
`
`suggest limitation 1.k, and the corresponding limitations in claims 5 and 9, of “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.” The antecedent in the claims for
`
`- 17 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`“the” requests is the recited “request specifying one or more serial identifiers.” By
`
`reciting that “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,” and further, per
`
`1.j, 5.j, and 9.j, that the server has no dependency on maintaining a record of the
`
`identifier of the last media data element sent to any client, it is inescapable here
`
`from the claim language alone, that each and every element in the presently
`
`challenged claims, i.e., “all” of the elements, are sent only responsive to client
`
`requests for stream elements by their serial ID. Again, the Board found room with
`
`respect to claim 10 of the ’141 patent to find otherwise under that claim, but the
`
`claim language at issue here leaves no such room.
`
`Carmel teaches to seek to a specified element and for the server to then
`
`stream autonomously from there. Carmel has no disclosure of repeated requests
`
`from the client for sequential elements specified by their serial numbers for all
`
`slices in the stream.
`
`The Petition notes at pages 31-32 that Carmel discloses “a user can decide
`
`and indicate at which slice of data stream 40 to begin downloading.” (Quoting
`
`Carmel at 10:36-48). That much is correct. However, merely selecting a starting
`
`point does not meet all limitations of 1.k, 5.k, and 9.k. Considerably more is
`
`required, specifically that “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,” and not
`
`- 18 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01227
`Patent 9,762,636
`
`merely some of them, but the Petition does not show how these claim limitations
`
`are met.
`
`The only thing the Petition has to say on this is to advance conjecture as to
`
`how the Carmel system allegedly operates at a lower level than its specification
`
`addresses. The Petition seeks to argue that even though Carmel may not address
`
`the detail of what transpires when the server starts downloading media from a
`
`specified starting point (it does not), the situation nevertheless “requires” this to be
`
`done by individual elements requests by serial ID. In this regard, the Petition
`
`states: “[b]ecause Carmel’s data stream is divided into various media data elements
`
`(‘[t]he data stream is divided into a sequence of segments or slices of the data’ id.,
`
`2:4-5), it requires every slice file to be requested individually using an HTTP GET
`
`request and the server sends each requested slice to the user system in response,
`
`when using the HTTP protocol to download each of the slice files.” Petition at 46-
`
`47. Notably, the statement about what Carmel allegedly “requires” does not come
`
`from Carmel, but rather directly from ¶ 130 of Petitioners’ Ex. 1002 expert
`
`declaration. The Petition, however, fails to note t