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

`

`
`
`
`
`
`I.
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`TABLE OF CONTENTS
`
`INTRODUCTION ............................................................................................. 1
`
`Summary of Patent Owner’s argument .................................................................. 2
`
`II. LEGAL STANDARDS FOR INSTITUTION .................................................. 4
`
`III. BACKGROUND ............................................................................................... 5
`
`A. Context of this Proceeding ............................................................................. 5
`
`B. Replay of prior challenges falls short as to later family patents .................... 8
`
`C. Overview of the ’636 patent disclosure ......................................................... 9
`
`D. Level of ordinary skill in the art ...................................................................14
`
`IV. CLAIM CONSTRUCTION .............................................................................14
`
`V. EACH ALLEGED GROUND OF PATENTABILITY FAILS THE
`“REASONABLE LIKELIHOOD” TEST ...............................................................19
`
`A. Ground 1 – Alleged obviousness over Carmel (Ex. 1003) ..........................19
`
`1. The Petition incorrectly casts the server push mechanism of Carmel as a
`client pull mechanism to find limitation 1[d(iv)] (“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”) ...........................................................21
`
`2. Because Carmel uses a push-based method, Carmel also fails to teach or
`suggest limitation 1[d(iii)] (“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”) ....................28
`
`3. 1[d(i)] (“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”) ..................................30
`
`a) Carmel does not teach (or suggest) each media data element being sent
`faster than the playback rate ........................................................................30
`
`B. Ground 2 – Carmel (Ex. 1003) in view of Narayan (Ex. 1005) ...................36
`
`C. Ground 3 – Carmel (Ex. 1003) in view of Ravi (Ex. 1004) .........................36
`
`D. Ground 4 – Carmel (Ex. 1003) in view of Narayan (Ex. 1005) and Ravi (Ex.
`1004) ....................................................................................................................37
`
`VI. CONCLUSION ................................................................................................38
`
`- ii -
`
`

`

`
`
`
`I.
`
`INTRODUCTION
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`Petitioner has 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 Petitioner 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. 1003 (“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).
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`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 (Grounds 2-4). These failures cannot be corrected by
`
`anything that might reasonably be expected to develop as a result of institution.
`
`Summary of Patent Owner’s argument2
`
`To set the stage for the argument that follows, Patent Owner submits, in
`
`summary, first, that Carmel fails to disclose limitation 1[d(i)] (“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”). Further, and as set forth in more detail below, since Carmel relies
`
`upon a “push” methodology, Carmel fails to disclose the combination of
`
`limitations 1[c] (“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
`
`
`2 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. The deficiencies in the Petition thus noted
`
`with respect to the independent claims apply with respect to the dependent claims
`
`as well.
`
`- 2 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`the data structure”), 1[c(i)] (“each received request specifying one or more serial
`
`identifiers of the requested one or more media data elements”), 1[c(ii)] (“each
`
`received request originating from a requesting user system of a plurality of user
`
`systems”), 1[d] (“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”), 1[d(iii)] (“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”), and 1[d(iv)] (“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”).
`
`Carmel certainly does not disclose limitation 1[d(i)], 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.
`
`Additionally, the plain language of limitations 1[c]-1[c(ii)], 1[d], 1[d(iii)],
`
`and 1[d(iv)] collectively make clear that the independent claims are directed to a
`
`server that transmits an entire stream via serial requests, in which the server
`
`receives a plurality of requests for media data elements from the client, each media
`
`data element being specified by a serial identifier, and the server responds by
`
`sending the corresponding media data elements, in which all such media data
`
`elements sent to the client are sent in response to such requests, and the server has
`
`- 3 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`no dependency on maintaining a record of what it sent last to determine what to
`
`send next. In short, the entire program is streamed, from beginning to end, by the
`
`client issuing requests by serial identifier and the server responding, and
`
`consequently the server does not need to maintain state to determine what media
`
`data element to send next. Carmel completely fails in this regard since it relies
`
`upon a push-based server that must maintain state to determine what slice to send
`
`next.
`
`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
`
`the challenge to each claim is based, and the evidence that supports the grounds for
`
`the challenge to each claim” (emphasis added)).
`
`It is Petitioner 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
`
`- 4 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`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.
`
`III. BACKGROUND
`
`A. Context of this Proceeding
`
`In this and two other now-pending IPRs, the present Petitioner challenges
`
`three patents that have been asserted against it in parallel litigation: (i) the ’636
`
`patent (Ex. 1001), (ii) U.S. Patent No. 9,742,824 (the “’824 patent”) (see IPR2022-
`
`01412), and (iii) U.S. Patent No. 9,729,594 (the “’594 patent”) (see IPR2022-
`
`- 5 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`01411). 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
`
`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 predetermined level of
`
`fill, so as 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
`
`- 6 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`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 ’824patents 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
`
`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
`
`- 7 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`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.
`
`Petitioner relies on Carmel as its 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.
`
`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
`
`- 8 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`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. To attempt to show that Carmel meets the requirements of the present
`
`claims, it reproduces Fig. 6A of Carmel four (4) times, arguing (without pointing
`
`to any support) that the “SELECT SLICE” box in its flowchart applies to every
`
`slice, rather than simply the starting slice, as the accompanying description states.
`
`In sum, the Petition fails to address how the references, individually or in
`
`combination, 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
`
`- 9 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`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).
`
`- 10 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`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
`
`- 11 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`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.
`
`- 12 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`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, “request[ing] … “sequential data elements …
`
`from the server in such a fashion as to approximately maintain the predetermined
`
`number of data elements in the user’s buffer.” Id., 15:6-18. It requests those
`
`elements from the server by their serial identifiers (id., 14:50-53), so as to maintain
`
`approximately specified level of 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, also serves as an
`
`effective stream control mechanism, making sure that the player has enough, but
`
`- 13 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`not too much data, to continue uninterrupted playback for the duration of the
`
`program, notwithstanding transient changes in connection quality.
`
`D. Level of ordinary skill in the art
`
`Petitioner alleges that a person having ordinary skill in the art (“POSITA”)
`
`would have had a B.S. degree in computer science or an equivalent field requiring
`
`learning computation principles, and two years of experience in networking or
`
`streaming media. Petition at 8-9. 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
`
`understood by one of ordinary skill in the art and the prosecution history pertaining
`
`to the patent.” 37 C.F.R. § 42.100.3
`
`
`3 The ’636 patent is also expired, which points as well to a Phillips standard for
`
`claim construction.
`
`- 14 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`Patent Owner contends that the claim terms are entitled to their plain and
`
`ordinary meaning, disagrees with the constructions of certain terms Petitioner has
`
`proffered, and disagrees that any of the terms are indefinite. See Petition at 10.
`
`Since Petitioner has advanced no theories or arguments in support of its
`
`contentions, the plain and ordinary meaning should be adopted. Phillips v. AWH
`
`Corp., 415 F.3d 1303, 1312-13 (Fed. Cir. 2005) (“words of a claim ‘are generally
`
`given their ordinary and customary meaning.’”) (quoting Vitronics Corp. v.
`
`Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)).
`
`At the same time, the Petition suggests that claim constructions and factual
`
`findings from earlier Board decisions concerning the ’141 patent are applicable
`
`here. See, e.g., Petition at 34 n.4, 36 n.5. The Petition advances no legal arguments
`
`as to why findings from earlier proceedings against another patent should be
`
`applicable here. Certainly, there can be no collateral estoppel with respect to claim
`
`constructions made on a different legal standard (BRI), or to §§ 102 and 103
`
`conclusions based on different claim language, as is the case here. 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
`
`- 15 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`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 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.” The ’636 claims also recite that “all” of the 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 claim wording here goes beyond the claims of the ’141 patent in expressly
`
`spelling out that the limitations set forth apply over and throughout the
`
`- 16 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`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
`
`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. As will be addressed, the (later issued)
`
`claims at issue here do recite that all elements transmitted are indeed “requested,”
`
`- 17 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`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.4 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
`
`server system and each requesting user system allows,” over a connection having a
`
`data rate more rapid than the playback rate.
`
`
`4 To the extent the Board views this as a claim construction issue, Patent Owner
`
`takes the position that the plain meanings of limitations 1[d(i)]-1[d(iv)], taken
`
`together, necessitate that the recited “rate” limitations apply with respect to all
`
`media data elements sent.
`
`- 18 -
`
`

`

`
`
`
`
`
`
`Case IPR2022-01413
`Patent 9,762,636
`
`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.
`
`A. Ground 1 – Allege