`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________________________________
`
`
`
`I.M.L. SLU
`Petitioner
`
`
`
`v.
`
`
`
`WAG ACQUISITION, LLC
`Patent Owner
`
`
`
`U.S. Patent No. 8,122,141
`
`
`
`_______________________________________
`
`Inter Partes Review Case No. IPR2016-01656
`_______________________________________
`
`
`
`PATENT OWNER PRELIMINARY RESPONSE
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`TABLE OF CONTENTS
`
`I.
`
`DUPLICATION ............................................................................................. 1
`
`II.
`
`INTRODUCTION ......................................................................................... 3
`
`III. THE CHEN PATENT ................................................................................... 7
`
`IV. CLAIM CONSTRUCTION ........................................................................ 10
`
`A.
`
`“In a format capable of being served to users by said server”
`
`[Claims 19-23] .................................................................................... 10
`
`V. GROUND 1 FAILS TO SHOW ANTICIPATION BY CHEN ............... 12
`
`B.
`
`Chen does not disclose that media data elements sent by the
`
`server in response to requests for those elements by their
`
`serial identifiers are sent “at a rate more rapid than the rate at
`
`which said streaming media is played back by a user” ................. 14
`
`C. Chen does not disclose that media data elements requested
`
`from the server by their serial identifiers are sent or requested
`
`“in order to maintain a sufficient number of media data
`
`elements in the media player for uninterrupted playback” .......... 17
`
`D.
`
`If construed as limiting, Chen does not disclose
`
`distributing/receiving “streaming media comprising a
`
`plurality of sequential media data elements for a digitally
`
`encoded audio or video program” recited in the preambles of
`
`claims 1, 10, and 24 ............................................................................ 20
`
`E.
`
`Chen does fails to disclose a server “not maintaining a
`
`pointer” into a buffer for each of a plurality of users.................... 21
`
`VI. GROUNDS 1 AND 3-5 – CLAIMS 19-23 ARE NOT
`
`ANTICIPATED BY CHEN OR OBVIOUS OVER CHEN IN VIEW
`
`OF ANY OF THE CITED ART ................................................................. 24
`
`
`
`i
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`A. Chen does not disclose a routine to store and serially identify
`
`sequential data elements in a format capable of being served
`
`to users ................................................................................................ 24
`
`VII. GROUND 2 – ALLEGED OBVIOUSNESS OVER CHEN AND ITS
`
`FILE HISTORY........................................................................................... 28
`
`VIII. GROUND 3 – CARMEL DOES NOT CURE FUNDAMENTAL
`
`DEFICIENCIES OF CHEN ....................................................................... 32
`
`IX. GROUND 4 - ALLEGED OBVIOUSNESS OVER CHEN, CHEN
`
`FH, AND WILLEBEEK ............................................................................. 34
`
`A. Willebeek Does Not Cure Fundamental Deficiencies of Chen
`
`and Chen FH With Respect to Claims 1, 2, 4-7, 9-11, 13-16, 18,
`
`24, and 26-28 ...................................................................................... 35
`
`B. Willebeek Does Not Cure Fundamental Deficiencies of Chen
`
`and Chen FH With Respect to Claims 8, 17, and 21 ...................... 37
`
`1) The proposed combination would fundamentally alter Chen......................... 38
`2) The proposed combination of Chen and Willebeek has no provision for the
`buffer to recover ............................................................................................. 39
`3) The proposed combination of Chen and Willebeek offers no practical solution
`for copying and scheduling at the requisite scale ........................................... 43
`4) The proposed combination of Chen, Chen FH, and Willebeek fails to teach or
`suggest all features of claims 8, 17, and 21 .................................................... 46
`X. GROUND 5 - ALLEGED OBVIOUSNESS OVER CHEN IN VIEW
`
`OF CHEN FH, ISO-11172 AND WILLEBEEK ....................................... 49
`
`XI. CONCLUSION ............................................................................................ 49
`
`
`
`
`
`ii
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`Patent Owner WAG Acquisition, L.L.C. (“Patent Owner” or “WAG”)
`
`respectfully submits this Preliminary Response in accordance with 35 U.S.C. § 313
`
`and 37 C.F.R. § 42.107, responding to the Petition for inter partes review (the
`
`“Petition”) filed by I.M.L. SLU (“Petitioner”) regarding the claims of U.S. Patent
`
`No. 8,122,141 (the “’141 Patent”). While Patent Owner is not required to file a
`
`Preliminary Response (37 C.F.R. § 42.107(a)), WAG takes this limited opportunity
`
`to point out the shortcomings of the Petition and the reasons why the Board should
`
`not institute trial.
`
`By statute, the Board must decide whether to institute a trial based on “the
`
`information presented in the petition” while also determining whether to “reject the
`
`petition or request because, the same or substantially the same prior art or
`
`arguments previously were presented to the Office.” 35 U.S.C. §§ 314(a), 325(d).
`
`I.
`
`DUPLICATION
`
`The Petitioner acknowledges that there is an issue of duplication under 35
`
`U.S.C. § 325(d). (See Petition at 7-8.) A side-by-side comparison of the instant
`
`Petition with the Petition filed in IPR2016-01238 (the “2016 ’1238 Petition”)
`
`should make clear that the anticipation arguments in this case are at least
`
`substantially similar to those in the 2016 ’1238 Petition and are based upon
`
`identical art – e.g. U.S. Patent No. 5,822,524 to Chen (“Chen”); U.S. Patent No.
`
`6,389,473 to Carmel et al. (“Carmel”); “Bamba – Audio and Video Streaming
`
`
`
`1
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`Over the Internet,” published by Willebeek-LeMair, et al. (“Willebeek”).
`
`(Compare Petition at ii with 2016 ’1238 Petition at iii.) In a few instances,
`
`Petitioner seeks to present a different spin on these previously-asserted grounds by
`
`pressing tenuous alternative claim interpretations, but in the main, the Board will
`
`recognize the arguments as substantial repeats of those in the 2016 ’1238 Petition.
`
`Petitioner states that Grounds 2-5 rely “upon the combination of Chen with
`
`different prior art than used in the prior pending IPR” and argues the instant
`
`Petition should be instituted on this basis. (Petition at 7.) But Petitioner offers no
`
`explanation as to how this different prior art offers any new facts that cure
`
`deficiencies in Chen or in the art cited in the earlier 2016 ’1238 Petition. See
`
`Medtronic, Inc. v. Nuvasive, Inc., Case IPR2014-00487, slip op. at 6-7 (PTAB
`
`September 11, 2014) (Paper 8) (denying petition despite grounds “based on
`
`different prior art references and different arguments”) (internal quotations
`
`omitted).
`
`Petitioner even seeks to use its own last-minute filing of the present IPR as a
`
`“reason” to consider this Petition. (See Petition at 8.) Petitioner argues that “[t]he
`
`present petition is Petitioner’s only option for relief at the PTAB.” (Id.) In fact,
`
`Petitioner’s option to file an IPR expired more than a year before it filed the instant
`
`
`
`2
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`Petition.1 Petitioner’s delay in filing the Petition is not a reason to carve an
`
`
`
`exception from 35 U.S.C. § 325(d).
`
`Patent Owner recognizes that the Board has not yet ruled on institution with
`
`respect to 2016 ’1238 Petition and three other related, previously-filed petitions.
`
`(Cf. Petition at 3-4 (listing related IPRs).) Nevertheless, however the Board may
`
`rule in those cases, it would be wasteful for the Board to reconsider here
`
`substantially the same art and arguments it is already considering in these other
`
`proceedings. Hence, beyond the arguments presented below, duplication under 35
`
`U.S.C. § 325(d) provides an ample basis in itself on which to reject the present
`
`Petition in its entirety.
`
`II.
`
`INTRODUCTION
`
`Without waiving any of the threshold arguments referred to above, Patent
`
`Owner now turns to the merits. Some of what follows will be duplicative of prior
`
`submissions, but this duplication is necessitated by the redundancy of the present
`
`Petition.
`
`Since the Board has previously encountered the ’141 Patent, the following
`
`introduction will be abbreviated.
`
`
`1 Patent Owner will be seeking leave to file a motion to terminate by reason of
`Petitioner’s failure to name real parties in interest, and/or Petitioner being barred by
`35 U.S.C. § 315(b) by reason of a real party in interest or a privy of Petitioner having
`been served with a complaint for infringing the patent challenged herein more than
`a year prior to the filing date of the Petition.
`
`
`
`3
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`The ’141 Patent has 28 claims, of which claims 1, 10, 19, and 24 are
`
`independent. The claims are directed to methods and related media players and
`
`media servers for transmitting and receiving media content over an IP network.
`
`The media player utilizes a “pull” mechanism to obtain media content from the
`
`source media server. In particular, the client player repeatedly requests sequential
`
`media data elements from the media server, using respective serial numbers for
`
`each requested media data element, and keeps track of the serial number of the last
`
`element the player has received. The player repeats these requests as necessary to
`
`maintain a pre-determined number of media data elements in a player buffer of the
`
`media player, until the last media data element of the content has been received.
`
`The media player plays the received media data elements sequentially from the
`
`player buffer. (See ’141 Patent at 13:23-16:16.)
`
`Petitioner bears the burden of demonstrating a reasonable likelihood that it
`
`would prevail in showing unpatentability on the grounds asserted in the Petition.
`
`37 C.F.R. § 42.108(c). Petitioner’s burden includes, inter alia, explaining in the
`
`Petition how each challenged claim is construed and how the prior art teaches that
`
`claim. See 37 CFR § 42.104(b)(3)-(4); World Bottling Cap, LLC v. Crown
`
`Packaging Tech., Inc., Case IPR2015-00296, slip op. at 5 (PTAB May 27, 2015)
`
`(Paper 8).
`
`
`
`4
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`As in the previous 2016 ’1238 Petition, Petitioner relies upon Chen as the
`
`sole primary reference in alleging anticipation and obviousness of the claims at
`
`issue. (See Petition at 6.) The Board has already dealt with Chen in a number of
`
`prior petitions against Patent Owner’s patents, and in particular in the recent trial
`
`concerning Patent Owner’s related ’839 Patent in Duodecad IT Services
`
`Luxembourg S.à.R.L. v. WAG Acquisition, LLC, Case IPR2015-01036 (the “2015
`
`’1036 Petition”).
`
`As the Board may recall, unlike what is claimed in the ’141 Patent, the
`
`system disclosed in Chen is designed to stream a multimedia program via a server
`
`“push” mechanism. The server’s “transmission scheduler (13) drives data flow” in
`
`Chen. (Chen at 9:21.) In contrast to the “pull” design of the instant claims, in
`
`which the client player manages flow control of the data stream, in Chen “the
`
`[server] transmission scheduler (13) properly schedules the data execution path, by
`
`considering the timing specification in the multimedia files and the timing
`
`requirements of the [client-side] applications.” (Chen at 9:26-30.)
`
`Although Chen primarily relies upon this server “push” arrangement, Chen
`
`does disclose certain specific packet requests originating from the client. These
`
`requests are one-offs, which Chen’s client uses to gap-fill dropped packets in the
`
`media stream transmitted via a server-side “push” mechanism, and which
`
`
`
`5
`
`
`
`Petitioner mistakenly relies upon as anticipating or rendering obvious the instant
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`claims. (See, e.g., Chen at 10:42-50; Petition at 22-27, 47-60.)
`
`Relying upon this one-off, gap-filling process of Chen, in sum and substance
`
`the Petition argues that sending any one missing slice of media data in response to
`
`a request by its identifier is no different than sending an entire sequence of slices in
`
`this manner so as to form a media stream. Of course these are different. The
`
`argument overlooks that in order for this to work, the request of each slice in the
`
`sequence must be timed to manage both the client’s own receive buffer level, and
`
`sent to and received from the server fast enough that the entire stream can be
`
`played continuously within the total time for playback. These latter aspects (among
`
`others) are missing from the cited references. As a result, Petitioner’s attempt to
`
`squeeze the “push” mechanism of Chen into the “pull” mechanism of the instant
`
`claims is akin to a forcing a round peg into a square hole and creates significant
`
`problems, none of which are cured by the secondary references cited in the
`
`Petition. Whether considered alone or in combination, the references in the instant
`
`Petition fail to provide a workable implementation of the pull-based system recited
`
`and claimed in the ’141 Patent.
`
`The following discussion does not make each and every available argument.
`
`The fact that Patent Owner has not addressed particular claim elements should not
`
`be taken as a concession that they are disclosed in or made obvious by the applied
`
`
`
`6
`
`
`
`art. All such additional arguments are reserved for the Patent Owner Response (if
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`necessary).
`
`III. THE CHEN PATENT
`
`Although the Board has previously seen the Chen reference in various other
`
`IPR proceedings concerning Patent Owner’s patents, a brief summary of Chen is
`
`again provided in the following for ease of reference.
`
`Chen’s disclosure addresses the streaming of a pre-recorded video program
`
`from disk storage on a server over an Internet connection to a media player (client).
`
`Chen addresses the problem of maintaining a steady flow of streaming media
`
`between a server and a media player over a non-deterministic channel, such as an
`
`Internet connection – neither starving nor overwhelming the media player.
`
`Chen discloses a server that loads media data from disk storage into a
`
`transmission buffer in accordance with a “schedule” that is calculated to support
`
`proper transmission and playback. (See Chen at 9:21-30.) At any given time, the
`
`server is set to transmit at a certain speed. While this streaming is in process, the
`
`player continuously monitors its own buffer level, and can supply feedback (if
`
`necessary) to moderate the server’s sending rate, to keep the player’s receive buffer
`
`level between specified lower and upper bounds (“water marks”). The player sends
`
`this feedback by sending speed-up (“RUSH”), OK (“NORMAL”) or hold-up
`
`(“PAUSE”) transmission mode control commands to the server, if and when
`
`
`
`7
`
`
`
`necessary. (Id. at 6:9-15.) Thus, in this scheme of transmission (referred to herein
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`as the “push” mechanism of Chen), the server controls when each media data
`
`element is sent, and the player can send commands to moderate the speed at which
`
`the server transmits, via RUSH, NORMAL, and PAUSE command signals. (Id. at
`
`6:28-54.) Thus, the client acts to throttle the server so as to keep the player’s
`
`receive buffer level between a “low” and a “high” “water mark,” doing so by
`
`sending speed control commands to the server when certain conditions are met –
`
`not by timing requests for specifically identified media data elements. (Id.)
`
`However, because Chen uses the unreliable UDP transport for streaming
`
`media data (Chen at 7:18-19), there is no transport-level mechanism to deal with
`
`packets that can lose their way to the media player in Chen’s push transmission
`
`scheme.2 To address this problem, Chen separately describes a “lost packet”
`
`mechanism, at the application level, for replacing packets lost in the course of
`
`performing its push transmission method. (See id. at 7:24-45.) Chen discloses a
`
`“pull” mechanism for replacing lost packets, which is limited to requesting and
`
`receiving only those packets that the player has identified as “lost.” (Id.) The entire
`
`disclosure of Chen with regard to lost packet handling is the following:
`
`
`2 Chen discloses the use of TCP for the control channel and UDP for the data
`channel. (See Chen at 5:42-44.) Chen teaches away from using TCP for data
`transmission. (See Chen at 3:1-25; 8:33-42.)
`
`
`
`8
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`Fast and mostly reliable UDP-like channels transmit data packets. At
`
`some network nodes, packets may be lost, for example, due to line noise
`
`or buffer overflow. In one error-free embodiment the lost packets are
`
`traced and replaced and in another embodiment, not error-free, there is
`
`no attempt to replace lost packets.
`
`To detect lost packets, in an error-free embodiment, the client agent
`
`(30) uses a register to maintain a variable Last Pkt. Seq. No. (51), which
`
`is the packet sequence number of the last received packet. If the Pkt.
`
`Seq. No. of the newly arriving packet denoted as New Pkt Seq No
`
`differs from (Last Pkt. Seq. No. +1), then a packet loss has occurred.
`
`Specifically, the packets with Pkt. Seq. No.'s from (Last Pkt. Seq. No.
`
`+1) to (New Pkt. Seq. No. -1) have been lost.
`
`To deal with packet loss, the client agent (30) maintains a list of lost
`
`packets (56) in a linked list or other data structure. That list records the
`
`two most important pieces of information about the lost packet, namely,
`
`its Pkt. Seq. No. and Time Out Value (57). When the client agent (30)
`
`sends the “retransmission request” for lost packets to the server control
`
`(1) the Time Out Value is set. If the missing data packet arrives
`
`correctly before the Time Out Value expires, this removes that data
`
`packet from the list. If not, the client agent (30) (i) either sends another
`
`“retransmission request” to the server control (1) or (ii) gives up on
`
`obtaining the missing data packet and removes its number from the lost
`
`packet list.
`
`…
`
`
`
`9
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`The client agent also transmits a “lost packet request” to request the
`
`transmission scheduler (13) to obtain the specified “lost” packets and
`
`to retransmit them as soon as possible. These packets may still be in the
`
`stream buffer, in which case the transmission scheduler (13) responds
`
`to the request immediately. Otherwise, the transmission scheduler (13)
`
`reads the relevant data from the storage subsystem (12) and then
`
`transmits them as soon as possible.
`
`(Chen at 7:18-44; 10:41-49.) While Chen discloses player requests for specific
`
`packets by sequence numbers, there is nothing in the disclosure, expressly or
`
`inherently, that in any way teaches sequential requests so as to maintain a
`
`particular level in the player buffer.
`
`Moreover, while Chen teaches that the server should retransmit the
`
`requested lost packets “as soon as possible,” there is no teaching, expressly or
`
`inherently, as to the data rate at which the lost packets are retransmitted.
`
`IV. CLAIM CONSTRUCTION
`
`A. “In a format capable of being served to users by said server” [Claims
`
`19-23]
`
`Claim 19 recites that the sequential data elements served to the client player
`
`are “in a format capable of being served to users by said server.” (’141 Patent,
`
`14:57-58 (emphasis added)). Patent Owner asserts that the proper construction of
`
`the italicized portion in this claim language means that the claimed format of the
`
`serially identified elements must be of sufficient length such that the total time
`
`
`
`10
`
`
`
`required to request and send the element, which includes the related signaling
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`overhead using the serial identifiers, is less than the time required to play out the
`
`formatted element at the normal playback rate.
`
`The Petition does not seek a construction of this language. It merely quotes
`
`this language but fails to address what the claimed format limitation requires.
`
`The words in question appear in the following claim context:
`
`9. A non-transitory machine-readable medium on which there has been
`
`recorded a computer program for use in operating a computer to
`
`prepare streaming media content for transmission by a server
`
`wherein said server responds to user requests for media data elements
`
`identified by a serial identifier, said program recorded on said non-
`
`transitory machine readable medium comprising a routine to store and
`
`serially identify sequential data elements comprising said streaming
`
`media content, in a format capable of being served to users by said
`
`server.
`
`(’141 Patent, claim 19 (emphasis added).)
`
`Claim 19 and its dependents are directed at preparing streaming media for
`
`pull transmission by breaking it into serially identified elements and appropriately
`
`formatting the elements for transmission.
`
`The words “said server” in the claim language refer to the recited server that
`
`is going to transmit the streaming media by a pull mechanism (responding to client
`
`requests by serial identifiers) in accordance with this claim. The words “capable of
`
`
`
`11
`
`
`
`being served to users by said server,” when read in light of the specification, mean
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`a data format that is capable of being served in accordance with the features of
`
`such a “pull” server; that is, a format whose characteristics make it possible to
`
`serve the multimedia program comprised of those elements via the recited “pull”
`
`mechanism in order to achieve uninterrupted playback.
`
`If a given format is not suitable for being served by such a “pull” server in
`
`order to effect uninterrupted playback, then, clearly, the format is not “capable of
`
`being served to users by said server.” Hence, to meet the requirements of claim 19,
`
`the formatting of these data elements must be of sufficient length such that the total
`
`time required to request and send the element, which includes the related signaling
`
`overhead using the serial identifiers, is less than the time required to play out the
`
`formatted element at the normal playback rate. Otherwise, the client player will not
`
`be able to keep up with the program playback; the format in such a case would
`
`therefore be unsuitable for being served by such a server.
`
`V. GROUND 1 FAILS TO SHOW ANTICIPATION BY CHEN
`
`Ground 1 alleges that all of the independent claims of the ’141 patent
`
`(claims 1, 10, 19, and 24), and numerous dependent claims, are anticipated by
`
`Chen. (See Petition at 22.)
`
`“A claim is anticipated only if each and every element as set forth in the
`
`claim is found, either expressly or inherently described, in a single prior art
`
`
`
`12
`
`
`
`reference.” Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`(Fed. Cir. 1987).
`
`However, anticipation is not established simply because a single reference
`
`contains different disclosures somewhere within it of the individual elements of a
`
`claim. “Because the hallmark of anticipation is prior invention, the prior art
`
`reference — in order to anticipate under 35 U.S.C. § 102 — must not only disclose
`
`all elements of the claim within the four corners of the document, but must also
`
`disclose those elements “arranged as in the claim.” Connell v. Sears, Roebuck &
`
`Co., 722 F.2d 1542, 1548 (Fed. Cir. 1983).
`
`More recently, the Federal Circuit has clarified what the words “arranged as
`
`in the claim” requires for purposes of anticipation:
`
`[T]he ‘arranged as in the claim’ requirement applies to all claims and
`
`refers to the need for an anticipatory reference to show all of the
`
`limitations of the claims arranged or combined in the same way as
`
`recited in the claims, not merely in a particular order. The test is thus
`
`more accurately understood to mean ‘arranged or combined in the same
`
`way as in the claim.’
`
`Net MoneyIN, Inc. v. VeriSign, Inc., 545 F. 3d 1359, 1370 (Fed. Cir. 2008).
`
`Anticipation may also be established where claim limitations are
`
`“inherently” present in the anticipating reference. However, inherency is a matter
`
`of necessary implication: to establish inherent disclosure, the cited reference must
`
`
`
`13
`
`
`
`“make clear that the missing descriptive matter is necessarily present in the thing
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`described in the reference.” Cont’l Can Co. USA v. Monsanto Co., 948 F.2d 1264,
`
`1268 (Fed. Cir. 1991).
`
`A finding of inherent anticipation requires more than “probabilities or
`
`possibilities.” Motorola Mobility LLC v. Int’l Trade Comm’n, 737 F.3d 1345, 1350
`
`(Fed. Cir. 2013). In other words, “[t]he mere fact that a certain thing may result
`
`from a given set of circumstances is not sufficient to establish inherency.” In re
`
`Rijckaert, 9 F.3d 1531, 1534 (Fed. Cir. 1993).
`
`The following will address specific shortcomings of the Petition with regard
`
`to limitations pertinent to Ground 1.
`
`B. Chen does not disclose that media data elements sent by the server in
`
`response to requests for those elements by their serial identifiers are
`
`sent “at a rate more rapid than the rate at which said streaming
`
`media is played back by a user”
`
`Limitations 1[c]-[d]: providing a server programmed to receive
`
`requests from the user system for media data elements
`
`corresponding to specified serial identifiers and 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.
`
`Limitation 10[h]: a machine-readable, executable routine containing
`
`instructions to cause the server to send media data elements to the
`
`
`
`14
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`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.
`
`Claims affected: 1, 2, 4-7, 9-11, 13-16, and 18.
`
`The Petition argues that Chen meets the limitation of sending packets, which
`
`have been requested by specified serial identifiers, at a rate more rapid than the
`
`playback rate. (See Petition at 23-24, 41.) The basis for the argument is that Chen
`
`meets this limitation because Chen has a RUSH mode which, when invoked, sends
`
`media faster than the playback rate.
`
`However, anticipation requires elements arranged as in the claims. In Chen,
`
`RUSH mode is relevant only to the prevailing “push” mode of operation described
`
`in that reference. In contrast, the ’141 claim language addresses the speed at which
`
`the server sends those packets that have been requested by their serial identifiers
`
`(i.e., by “pull”).
`
`The Petition argues that all packets in Chen have serial identifiers, and that
`
`therefore this limitation is met when any of those packets are sent faster than the
`
`playback rate, as could occur in the prevailing push mode of transmission (as
`
`opposed to lost packet transmission) in Chen, when in RUSH mode. However, the
`
`literal claim language concerns the speed at which media data elements are sent
`
`“responsive to said requests.” The antecedent for “said requests” is “requests from
`
`the user system for media data elements corresponding to specified serial
`
`
`
`15
`
`
`
`identifiers.” Therefore, the relevant inquiry is not the speed at which any arbitrary
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`media data element is sent, but rather the speed of transmission of those media data
`
`elements in particular that are sent “responsive to” the specified “said requests” –
`
`that is, responsive to client requests for media data elements by their serial
`
`identifiers. This corresponds, then, not to the prevailing “push” mode in Chen, but
`
`rather to the separate mechanism for replacing specific lost or missing packets.
`
`The Petition fails to recognize that its argument does not address the actual
`
`media data elements referred to by the claim language (i.e., those that have been
`
`requested by their serial identifiers), and provides no response to it.
`
`In any case, as the Board may recall, the only media data elements in Chen
`
`that are transmitted in response to requests by identifiers are packets determined by
`
`Chen’s client to be lost or missing. Chen discloses only that those packets are sent
`
`“as soon as possible.” (See Chen at 10:42-50.) While this disclosure addresses
`
`when those packets are sent, it does not address at what speed they are sent.
`
`The Board has previously agreed with Patent Owner on this very point, in
`
`the prior institution decision in the 2015 ’1036 Petition on WAG’s ’839 Patent,
`
`that Chen does not disclose that packets sent pursuant to Chen’s lost packet
`
`mechanism are sent faster than the playback rate. (See 2015 ’1036 Petition, slip op.
`
`at 20 (PTAB Oct. 23, 2015) (Paper 8).) Petitioner seeks to avoid this same
`
`conclusion applied here based on a disingenuous argument. Petitioner’s argument
`
`
`
`16
`
`
`
`must be rejected as it is contrary to the express claim language, which addresses
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`the speed of transmission of those media data elements “responsive to said
`
`requests.”
`
`Therefore, for at least the reasons addressed under this heading, Ground 1
`
`fails to show a likelihood that any of claims 1, 2, 4-7, 9-11, 13-16, and 18 will be
`
`found anticipated by Chen.
`
`C. Chen does not disclose that media data elements requested from the
`
`server by their serial identifiers are sent or requested “in order to
`
`maintain a sufficient number of media data elements in the media
`
`player for uninterrupted playback”
`
`Limitation 1[g]: to transmit requests to the server to send one or
`
`more data elements, specifying the identifiers of the data elements, as
`
`said media player requires in order to maintain a sufficient number
`
`of media data elements in the media player for uninterrupted
`
`playback.
`
`Limitation 24[f]: a routine that requests transmission of the next
`
`sequential media data elements following said last sequential media
`
`data element, as said media player requires in order to maintain a
`
`sufficient number of media data elements in the media player for
`
`uninterrupted playback.
`
`Claims affected: 1, 2, 4-7, 9, 24, and 26-28.
`
`
`
`17
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`Petitioner’s argument disregards the words “sufficient number” that appear
`
`in both independent claims 1 and 24, and further disregards the words “requests
`
`transmission of the next sequential media data elements following said last
`
`sequential media data element,” which appear in claim 24.
`
`Chen does not fill in lost or missing packets “in order to maintain a
`
`sufficient number of media data elements in the media player for uninterrupted
`
`playback,” as recited in these claims. Chen does, in fact, disclose a mechanism “to
`
`maintain a sufficient number of media data elements in the media player for
`
`uninterrupted playback.” That mechanism is for the client to detect when its
`
`receive buffer level has fallen below the “low water mark” and to send a command
`
`for the server to switch into RUSH mode in such a case. (See Chen at 6:43-47.) But
`
`that is in the ordinary “push” mode of Chen, in which the client does not request
`
`transmission of individual packets by serial identifiers but instead relies upon the
`
`server to drive the data flow. (See Chen at 9:22-30.)
`
`Client requests in Chen for the server to send packets by their serial
`
`identifiers only occur in the case of replacing lost or missing packets. (See Chen at
`
`7:18-45; 10:42-50.) This is triggered when Chen’s client detects a break in packet
`
`sequencing and puts an ID for the missing element on a client-side list of lost
`
`packets. (Id. at 7:33-37.) There is no connection between this mechanism and the
`
`client buffer level. It cannot be said that the mechanism for replacing lost or
`
`
`
`18
`
`
`
`
`
`Case IPR2016-01656
`Patent 8,122,141
`
`missing packets in Chen operates “in order to maintain a sufficient number of
`
`media data elements in the media player for uninterrupted playback.” That is
`
`neither the purpose, method, nor effect of Chen’s lost packet mechanism.
`
`Further, limitat
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
