`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________________________________
`
`AMAZON.COM, INC., AMAZON WEB SERVICES, INC.,
`AND AMAZON.COM SERVICES LLC,
`Petitioners
`
`v.
`
`WAG ACQUISITION, LLC
`Patent Owner
`
`U.S. Pat. No. 9,762,636
`
`
`_______________________________________
`
`Inter Partes Review Case No. IPR2022-01433
`_______________________________________
`
`
`
`
`
`
`PATENT OWNER PRELIMINARY RESPONSE
`
`
`
`
`
`
`
`

`

`
`
`
`
`
`I.
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`TABLE OF CONTENTS
`
`
`INTRODUCTION ......................................................................................... 1
`
`Summary of Patent Owner’s argument .................................................................. 2
`
`II.
`
`III.
`
`LEGAL STANDARDS FOR INSTITUTION .............................................. 3
`
`BACKGROUND ........................................................................................... 5
`
`A. Context of this Proceeding ............................................................................. 5
`
`B. Replay of prior challenges falls short as to later family patents .................... 7
`
`C. Overview of the ’636 patent disclosure ......................................................... 8
`
`D. Level of ordinary skill in the art ..................................................................13
`
`IV.
`
`V.
`
`CLAIM CONSTRUCTION .........................................................................13
`
`EACH ALLEGED GROUND OF PATENTABILITY FAILS THE
`“REASONABLE LIKELIHOOD” TEST ...................................................18
`
`A. Alleged obviousness over Carmel (Ex. 1005) in view of Feig (Ex. 1031)
`and Willebeek (Ex. 1006) ...........................................................................19
`
`1. The cited references, taken either individually or in combination, fail to
`teach [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”) ........19
`
`a) Carmel does not teach (or suggest) each media data element being sent
`faster than the playback rate ..................................................................20
`
`b) The Petition fails to show where limitation [h] is found in Feig ...........27
`
`c) The Petition fails to show where limitation [k] is found in Carmel ......30
`
`2. The combination of Carmel and Feig is non-obvious ..............................35
`
`a) The Petition points to baseless reasons for a POSITA to modify Carmel
`in accordance with Feig .........................................................................36
`
`b) Incorporating Feig’s pull-based method in Carmel’s push-based system
`fundamentally changes the principle of operation of Carmel and raises
`additional unaddressed problems ...........................................................38
`
`VI.
`
`CONCLUSION ............................................................................................40
`
`
`
`- ii -
`
`

`

`
`
`
`I.
`
`INTRODUCTION
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`Petitioners have challenged the validity of U.S. Patent No. 9,762,636 (the
`
`“’636 patent”). Patent Owner WAG Acquisition, L.L.C. (“Patent Owner”) opposes
`
`institution.
`
`Any case for invalidity must be made, in the first instance, in the Petition. If
`
`the Petition does not show a reasonable likelihood that the Petitioners would
`
`prevail as to at least one of the claims challenged, institution should be denied.
`
`The Petition heavily relies on a reference, Carmel et al., U.S. Patent No.
`
`6,389,473, Ex. 1005 (“Carmel”), which was the focal point of prior IPR
`
`proceedings with regard to other family patents owned by Patent Owner. Carmel,
`
`and the prior Board institution decision in IPR2016-01238 (on U.S. Patent Nos.
`
`8,122,141 (the “’141 patent”)) based on Carmel, were before the Examiner, as
`
`reflected on the front page of the ’636 patent. However, the claims to which
`
`Carmel was applied against the ’141 patent in the prior IPR proceedings lacked a
`
`number of explicit limitations incorporated in the claims of the ’636 patent
`
`addressed herein.1 The Petition fails to provide any reference or combination of
`
`
`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).
`
`- 1 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`references that disclose all of those further limitations introduced in the ’636
`
`claims. It fails as well to provide a sufficient rationale for combining Carmel with
`
`the other cited references. These failures cannot be corrected by anything that
`
`might reasonably be expected to develop as a result of institution.
`
`Summary of Patent Owner’s argument
`
`To set the stage for the argument that follows, Patent Owner submits, in
`
`summary, first, that neither Carmel nor Ex. 1031 (“Feig”) discloses limitation [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”).
`
`Carmel certainly does not disclose limitation [h], as Carmel contemplates,
`
`and the entire Carmel system is designed to account for, situations in which the
`
`data connection has a data rate slower than the playback rate.
`
`Even if the Board were to find even a provisional basis to accept that Feig
`
`might be shown to disclose limitation [h] and thereby overcome the deficiency of
`
`Carmel in this regard (although Patent Owner would submit that the disclosure of
`
`Feig does not meet this threshold), the Petition also fails to provide a sufficient
`
`rationale for combining Feig with Carmel as to limitation [h] (and as next
`
`addressed, limitation [k] as well).
`
`- 2 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`To the extent Petitioners would rely on Carmel alone for obviousness of
`
`modifying its teachings with respect to limitation [h], the proposed modification to
`
`Carmel would require additional changes to Carmel, which the Petition fails to
`
`address.
`
`Second, Carmel, relying upon a “push” streaming methodology (as will be
`
`addressed herein), does not disclose limitation [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”). To the extent Petitioners rely on Feig to overcome this
`
`shortcoming of Carmel, they likewise fail to provide a suitable rationale to
`
`combine, insofar as the Petition merely repeats the same inadequate rationale it
`
`provided for limitation [h].
`
`For these and the other reasons set forth herein, Patent Owner respectfully
`
`submits that the Petition is inadequate to trigger institution.
`
`II. LEGAL STANDARDS FOR INSTITUTION
`
`Institution requires “a reasonable likelihood that the petitioner would prevail
`
`with respect to at least 1 of the claims challenged in the petition.” 35 U.S.C.
`
`§ 314(a). In the first instance, this showing must be made in the Petition. See 35
`
`U.S.C. § 312(a) (“A petition filed under section 311 may be considered only if …
`
`(3) the petition identifies, in writing and with particularity … the grounds on which
`
`- 3 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`the challenge to each claim is based, and the evidence that supports the grounds for
`
`the challenge to each claim” (emphasis added)).
`
`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.” 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, slip op. at 5 (PTAB May 27, 2015) (Paper 8).
`
`Key requirements and burdens applicable to the Board’s institution decision
`
`in an IPR were summarized by the Federal Circuit in Harmonic Inc. v. Avid Tech.,
`
`Inc., 815 F.3d 1356 (Fed. Cir. 2016):
`
`In an IPR, the petitioner has the burden from the onset to show with
`particularity why the patent it challenges is unpatentable. See 35
`U.S.C. § 312(a)(3) (requiring IPR petitions to identify ‘with
`particularity … the evidence that supports the grounds for the
`challenge to each claim.’).
`
`Id. at 1363 (emphasis added).
`
`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.
`
`- 4 -
`
`

`

`
`
`
`III. BACKGROUND
`
`A. Context of this Proceeding
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`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,724,824 (the “’824 patent”) (see IPR2022-
`
`01430), and (iii) U.S. Patent No. 9,729,594 (the “’594 patent”) (see IPR2022-
`
`01429). As the Board is aware (and as identified below), other challengers have
`
`filed petitions against these patents as well.
`
`Each of the ’636, ’824, and ’594 patents addresses a particular embodiment
`
`disclosed in the common specification underlying the three patents. The pertinent
`
`common disclosure in this regard concerns an internet media streaming
`
`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 from the respective client
`
`devices, made by the elements’ serial identifiers. The express claim limitations,
`
`taken together, recite a transmission of the elements comprising the stream that is
`
`driven, from beginning to end, by client requests for identified elements, and thus
`
`the claimed streaming process may be thought of as a “pull.” Proper reception and
`
`playback of the successive elements has a time dependency, and hence the
`
`- 5 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`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.
`
`The claims of the ’636, ’824, and ’594 patents 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 ’824
`
`patent directed to the situation in which the media to be streamed is pre-recorded,
`
`and the ’636 patent directed to a similar server embodiment but where the feed
`
`being distributed is instead provided to the server from a live source). 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 (prerecorded
`
`or live), 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
`
`prerecorded and live media respectively); and the ’594 patent addresses the
`
`mechanism from the client side (for either prerecorded or live media).
`
`In prior proceedings, other parties (accused of infringement in earlier
`
`parallel litigation) have challenged claims of previously issued family patents. The
`
`- 6 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`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
`
`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).
`
`B. Replay of prior challenges falls short as to later family patents
`
`The applicability of Carmel to other family patents, most particularly the
`
`’141 patent, was litigated at length, including a reversal in the Federal Circuit
`
`(WAG Acquisition, LLC v. WebPower, Inc., 781 F. App’x 1007 (Fed. Cir. 2019)),
`
`which narrowed the Board’s construction of the ’141 patent claims.
`
`Petitioners rely on Carmel as their lead reference here as well. However,
`
`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 (IPR2016-01238) against the ’141 patent. Among those differences is
`
`that the current (’636 patent) claims, by comparison to those previously ruled on
`
`by the PTAB (’141 patent), incorporate a string of “wherein” limitations that were
`
`not recited in the ’141 claims.
`
`- 7 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`The further “wherein” limitations in the ’636 patent claims, 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
`
`specifically limit the claims of the ’141 patent there at issue, finding it sufficient
`
`that Carmel addresses the speed of transmission of at least some portion of a partial
`
`stream. See WebPower, Inc. v. WAG Acquisition, LLC, IPR2016-01238, Paper 28
`
`at 19. As will be addressed herein, however, Carmel simply does not concern
`
`streaming an entire program via a “pull” mechanism. Even though now recast as a
`
`§ 103 challenge, the Petition proceeds without even acknowledging the difference
`
`in claim language between this and the prior cases. It fails to address how the
`
`references fall short on the differing claim language, let alone provide any rationale
`
`to render the unacknowledged differences obvious.
`
`C. Overview of the ’636 patent 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
`
`audio-visual media stream, as well as thereafter maintaining uninterrupted
`
`delivery. See, e.g., ’636 patent, 3:45-58 (“respond on demand without
`
`- 8 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`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 getting data delivered, 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.
`
`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).
`
`- 9 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`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. One
`
`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 is reflected in the “hourglass” streaming experience that was
`
`prevalent before Patent Owner’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 (not the embodiment
`
`directly involved here, but described here to provide additional 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
`
`- 10 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`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 controls the
`
`timing of 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 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.
`
`- 11 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`’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 accumulated on the
`
`server side (similar to the “buffer” in the first above-described embodiment). In the
`
`pull embodiment, each streaming media data element is associated with a
`
`respective serial identifier (id., 14:44-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:6-18), and
`
`requests them from the server by their serial identifiers (id., 14:50-53), so as to
`
`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-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 uninterrupted playback for the duration of the program,
`
`notwithstanding transient changes in connection quality.
`
`- 12 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`D. Level of ordinary skill in the art
`
`Petitioners allege that a person having ordinary skill in the art (“POSITA”)
`
`would have had a bachelor’s degree in computer science, computer engineering, or
`
`electrical engineering, or the equivalent, and at least two years of work experience
`
`in streaming media systems for delivering audio and video. According to
`
`Petitioners, additional education could have substituted for professional
`
`experience, and significant work experience could have substituted for formal
`
`education. Petition at 9-10. 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.
`
`IV. 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
`
`- 13 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`understood by one of ordinary skill in the art and the prosecution history pertaining
`
`to the patent.” 37 C.F.R. § 42.100.2
`
`Patent Owner agrees with Petitioners that the claim terms are entitled to their
`
`plain and ordinary meaning. See Petition at 11.
`
`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 12 (claim construction) and 21-22, 25, 38, 41, 43 (factual findings)).
`
`On page 22, 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), or to §§ 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 Labs., 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
`
`
`2 The ’636 patent is also expired, which points as well to a Phillips standard for
`
`claim construction.
`
`- 14 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`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 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 allow[s],” 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.
`
`- 15 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`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
`
`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
`
`- 16 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`interpretation that “each” element that is requested must be sent at the specified
`
`rate, applies here with comparable force.3 Moreover, the present claims, on their
`
`face, also resolve the issue of which elements are requested, specifying (for these
`
`claims) that it is indeed all of them, 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
`
`
`3 To the extent the Board views this as a claim construction issue, Patent Owner
`
`takes the position that the plain meanings of limitations [h]-[k], taken together,
`
`necessitate that the recited “rate” limitations apply with respect to all media data
`
`elements sent.
`
`- 17 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`server system and each requesting user system allows,” over a connection having a
`
`data rate more rapid than the playback rate.4
`
`The question then becomes whether the references cited in this IPR reach the
`
`present claim limitations as they read, or render them obvious. The answer is that
`
`they do not, under any basis presented in the Petition, and there is no likelihood
`
`that institution under the present Petition would lead to any other result.
`
`V. EACH ALLEGED GROUND OF PATENTABILITY FAILS THE
`“REASONABLE LIKELIHOOD” TEST
`
`Patent Owner addresses below specific shortcomings that militate against
`
`institution. Where possible, Patent Owner uses the same claim element numbering
`
`scheme as used in the Petition.
`
`
`4 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….”).
`
`- 18 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`A. Alleged obviousness over Carmel (Ex. 1005) in view of Feig (Ex.
`1031) and Willebeek (Ex. 1006)
`
`1. The cited references, taken either individually or in combination,
`fail to teach [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”)
`
`Limitation [h]5 must be read together with other limitations in the respective
`
`independent claims (e.g., [i] and [k]). When thus properly read, the plain language
`
`of the independent claims necessarily implies the following:
`
`• 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],
`• over [h] a data connection having a data rate more rapid than the
`playback rate.
`
`Taken together, the limitations of each of the independent claims require that
`
`every media data element is sent at a rate specified to be faster than the playback
`
`rate and as a result, each of the requested media data elements is received in less
`
`time than is required to play it back. None of Carmel, Feig, or Willebeek teach this.
`
`
`5 Each of the referenced limitations exist in independent claim 1 (method claim) as
`
`well as in claims 5 (system claim) and 9 (computer-recorded medium claim).
`
`Unless otherwise stated, the arguments herein, expressly referring to claim 1, are
`
`intended to apply in all three contexts.
`
`- 19 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01433
`Patent 9,762,636
`
`a) Carmel does not teach (or suggest) each media data element
`being sent faster than the playback rate
`
`Carmel teaches a number of measures for transmitting streaming media data
`
`elements (referred to as “slices” in Carmel) over one or more data connections, but
`
`the techniques