Case IPR2016-01238
`Patent 8,122,141
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________________________________
`
`
`
`WEBPOWER, INC.
`Petitioner
`
`
`
`v.
`
`
`
`WAG ACQUISITION, LLC
`Patent Owner
`
`
`
`U.S. Patent No. 8,122,141
`
`
`
`_______________________________________
`
`Inter Partes Review Case No. 2016-01238
`_______________________________________
`
`
`
`PATENT OWNER PRELIMINARY RESPONSE
`
`
`
`
`
`
`
`

`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`TABLE OF CONTENTS
`
`I.
`
`INTRODUCTION AND SUMMARY OF ARGUMENT .......................... 1
`
`II.
`
`PETITIONER’S PRIMARY REFERENCES ............................................ 3
`
`A.
`
`B.
`
`Chen ....................................................................................................... 3
`
`Carmel ................................................................................................... 4
`
`III. GROUND 1: ALLEGED ANTICIPATION OVER CHEN ...................... 5
`
`A.
`
`B.
`
`C.
`
`D.
`
`E.
`
`(Claims 1 and 24, and dependent Claims 2, 4-7, 9 and 26-28) The
`media player requests are made “as said media player requires in
`order to maintain a sufficient number of media data elements in
`the media player for uninterrupted playback.” [limitations 1g, 24f] .... 5
`
`(Claims 1 and 10, and dependent Claims 2, 4-7, 9, 11, 13-16, 18,
`and 28) Sending the responsive media data elements to the user
`system at a rate more rapid than the playback rate [limitations 1d
`and 10h] ................................................................................................. 6
`
`(Claims 1, 10, and 24, and dependent Claims 2, 4-7, 9, 11, 13-16,
`18, and 26-28) Preamble [limitations 1a-b, 10a-b, 24a] ....................... 9
`
`(Claim 19, and dependent Claims 20 and 23) “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” [limitations 19a-b] ............................................ 11
`
`(Claims 6 and 15) Distribution to multiple users wherein the
`server does not maintain a pointer into a server-side buffer for
`each user .............................................................................................. 11
`
`IV. GROUND 2: ALLEGED OBVIOUSNESS OVER CHEN IN VIEW
`OF WILLEBEEK ........................................................................................ 13
`
`A.
`
`B.
`
`There is no motivation to combine Chen and Willebeek in the
`manner argued and it would change the principle of operation of
`Chen ..................................................................................................... 13
`
`(Claims 8 and 17) The proposed combination does not disclose or
`suggest “send[ing] media data elements to the user system
`responsive to said requests.” [limitations 1d and 10h] ........................ 15
`
`
`
`i
`
`

`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`C.
`
`(Claim 21) The proposed combination does not disclose or
`suggest “stor[ing] and serially identify[ing] sequential data
`elements.” [limitation 19c] .................................................................. 16
`
`V. GROUND 3: ALLEGED OBVIOUSNESS OVER CARMEL IN
`VIEW OF WILLEBEEK ............................................................................ 17
`
`A.
`
`B.
`
`(Claim 1, and dependent Claims 2, 4-9, and 28) server
`“programmed to receive requests from the user system for media
`data elements corresponding to specified serial identifiers” and
`“send[ing] media data elements to the user system responsive to
`said requests.” [limitations 1c-1d] ....................................................... 18
`
`(Claims 1 and 24, and dependent Claims 2, 4-9 and 26-28) The
`media player requests are made “as said media player requires in
`order to maintain a sufficient number of media data elements in
`the media player for uninterrupted playback.” [limitations 1g, 24f] .. 21
`
`VI. GROUND 4: ALLEGED ANTICIPATION OVER CARMEL .............. 22
`
`A.
`
`B.
`
`(Claim 10, and dependent Claims 11 and 13-18) The proposed
`combination does not disclose or suggest “receiv[ing] requests
`from the user system for one or more media data elements
`specifying the identifiers of the requested data elements” and
`“send[ing] media data elements to the user system responsive to
`said requests.” [limitations 10g-10h] .................................................. 23
`
`(Claim 19, and dependent Claims 20-21 and 23) “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” [limitations 19a-b] ............................................ 23
`
`VII. GROUNDS 5, 6, AND 7: ALLEGED OBVIOUSNESS OVER
`VARIOUS COMBINATIONS - CONSTANT BIT RATE ...................... 24
`
`VIII. CONCLUSION ............................................................................................ 25
`
`
`
`
`
`ii
`
`

`
`
`
`Case IPR2016-01238
`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 Webpower, Inc. (“Petitioner”) regarding the claims of U.S.
`
`Patent No. 8,122,141 (the “’141 Patent”). While the patent owner is not required to
`
`file a Preliminary Response, WAG takes this limited opportunity to point out the
`
`shortcomings of the Petition and the reasons why the Board should not institute
`
`trial.
`
`I.
`
`Introduction and Summary of Argument
`
`By statute, the Board must decide whether to institute a trial based on “the
`
`information presented in the petition.” 35 U.S.C. § 314(a). 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).
`
`The claims of the ’141 Patent are directed in various respects to methods,
`
`systems and their components, in which one or more media player clients receive
`
`and play streaming media over an Internet Protocol network from a server via a
`
`

`
`“pull” mechanism – where transmission of data elements within the stream is
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`requested by the client. Streaming media transmission occurs in response to
`
`repeated requests by the client for serially identified media data elements
`
`comprising the program stream. The media data elements are served in response to
`
`those client requests, the result of which is that transmission is not metered by the
`
`server.
`
`The Petition’s references, including primary references Chen and Carmel, do
`
`not use repeated client requests for media data elements in order to transmit a
`
`multimedia program. As discussed below, Chen’s main transmission mechanism
`
`uses a server “push,” and specific requests are used only to fill-in missing packets.
`
`In Carmel, the client uses an index to identify a starting point in the stream, and the
`
`Carmel server operates to transmit the stream from that point forward. The
`
`secondary references used by the Petition do nothing to cure these fundamental
`
`deficiencies. There are additional problems with the Petition discussed in the
`
`arguments made below.
`
`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
`
`art. All such additional arguments are reserved for Patent Owner’s Response (if
`
`necessary).
`
`
`
`2
`
`

`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`II.
`
`Petitioner’s Primary References
`
`A. Chen
`
`As described in WAG’s preliminary response in connection with WAG’s
`
`U.S. Patent No. 8,327,011 (IPR Case No 2016-01161), Chen’s disclosure
`
`addresses the streaming of a pre-recorded video program from disk storage on a
`
`server, over an Internet connection to a client / media player. Chen addresses the
`
`problem of maintaining a steady flow of streaming media between a server and a
`
`media player with encoding that varies from frame-to-frame over a channel such as
`
`an Internet connection, which is subject to variable latencies, without starving or
`
`overwhelming the media player.
`
`In Chen’s standard mode of transmission (referred to herein as the “push”
`
`mechanism), the server controls when each media data element is sent. The client
`
`acts so as to keep the player’s receive buffer level between a “low” and a “high”
`
`“water mark,” but it does so by sending speed control commands to the server
`
`when certain conditions are met – not by timing requests for specifically identified
`
`media data elements. Indeed, the description specifically states that transmission
`
`by the server “should be in NORMAL mode most of the time” (Chen at 6:31-32),
`
`and that “[t]ransmission occurs very efficiently in this NORMAL mode because no
`
`need exists for the client agent (30) to send periodic feedback to server control
`
`(1).” (Chen at 6:37-39.)
`
`
`
`3
`
`

`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`Chen describes a different mechanism as well, but only for situations where,
`
`during the “push” transmission, packets are detected as “lost” or otherwise found
`
`to be missing from the client buffer. (Chen at 7:18-44; 5:59-66.) In the prevailing
`
`NORMAL mode transmission of the program, the Chen client does not send
`
`specific “feedback” to the server. (Chen at 6:37-39; see also Chen at 10:2-6 (the
`
`NORMAL mode “requires minimum overhead, because limited interaction occurs
`
`between the client agent (30) and server control (1).”).) While this disclosure deals
`
`with particular missing packets, there is no teaching, suggestion, or enablement in
`
`Chen to send the entire streaming media program by this mechanism.
`
`B. Carmel
`
`Carmel discloses a system that can work with either live or prerecorded
`
`media. The media is divided into “slices” indexed in an index file, and the slices
`
`and index file are uploaded to a server. (Carmel at 7:25-28; 8:20-25.) When a user
`
`computer connects to a stream, the user computer downloads and analyzes the
`
`index file to identify at what point in the stream to begin, to receive the data stream
`
`from that point in substantially real time as it is transmitted. (Carmel at 8:1-7;
`
`10:44-47.)
`
`Carmel refers to the client as utilizing the index, but as an internal
`
`mechanism to synchronize timing to determine when it is necessary to adapt to a
`
`higher or lower encoding rate. (Carmel at 10:64-11:8.) However, there is no
`
`
`
`4
`
`

`
`teaching in Carmel that the client “pulls” the stream by requesting individual slices
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`from the server, and certainly not by making requests for slices by serial
`
`identifiers.
`
`III. Ground 1: Alleged Anticipation Over Chen
`
`A. (Claims 1 and 24, and dependent Claims 2, 4-7, 9 and 26-28) The
`
`media player requests are made “as said media player requires in
`
`order to maintain a sufficient number of media data elements in the
`
`media player for uninterrupted playback.” [limitations 1g, 24f]1
`
`Claims 1 and 24 each recite that the player requests elements “as said media
`
`player requires in order to maintain a sufficient number of media data elements in
`
`the media player for uninterrupted playback.”
`
`To address this limitation, the Petition cites scattershot excerpts from Chen
`
`concerning RUSH-NORMAL-PAUSE “push” transmission and the “missing
`
`packet” and “lost packet” mechanisms. (Petition at 14-15; 26-30.) The Petition
`
`conflates these mechanisms but, as discussed above, only the standard “push”
`
`mechanism of Chen addresses the server sending a continuous stream so as to
`
`maintain the client buffer level (along with the Chen client’s ability to change
`
`modes between RUSH, NORMAL, and PAUSE). As the specification makes clear,
`
`
`1 For the convenience of the board, WAG will use Petitioner’s limitation
`
`numbering scheme herein.
`
`
`
`5
`
`

`
`this “push” mechanism does not serve data responsive to requests for specific data
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`elements. (Chen at 4:37-39; 10:3-6.)
`
`In contrast, the “missing packet” and “lost packet” mechanisms of Chen,
`
`while they involve specific requests, involve requests only to replace particular
`
`missing or lost packets, not requests “as said media player requires in order to
`
`maintain a sufficient number of media data elements in the media player for
`
`uninterrupted playback” as recited in Claims 1 and 24 of the ’141 Patent. There is
`
`no teaching in Chen that its missing and lost packet mechanisms are triggered in
`
`any way with reference to the client buffer level.
`
`For at least this reason, Chen fails to anticipate either of independent Claims
`
`1 and 24. Claims 2, 4-7, 9 and 26-28 depend from Claims 1 and 24 and are
`
`patentable over Chen for at least the same reason.
`
`B. (Claims 1 and 10, and dependent Claims 2, 4-7, 9, 11, 13-16, 18, and
`
`28) Sending the responsive media data elements to the user system at
`
`a rate more rapid than the playback rate [limitations 1d and 10h]
`
`Claims 1 and 10 recite “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.”
`
`The words “said requests” refer back to the elements specified by serial
`
`identifier in limitations 1c and 10d. Therefore, limitations 1d and 10h recite that
`
`
`
`6
`
`

`
`media data elements sent in response to the client requests by serial identifiers are
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`sent by the server “at a rate more rapid than the rate at which said streaming media
`
`is played back by a user.”
`
`Chen lacks this disclosure.
`
`The Petition relies on the disclosure of RUSH mode in Chen to support this
`
`limitation, but RUSH mode is relevant only to Chen’s prevailing “push” mode of
`
`operation. The ’141 claim language, however, addresses the speed at which
`
`packets requested by their serial identifiers are sent.
`
`The Petition argues that “lost packets” are retransmitted faster than the
`
`playback rate. (Petition at 13.) However, Chen discloses only that those packets are
`
`sent “as soon as possible” (Chen at 10:42-50), which discloses something about
`
`when those packets are sent, but not at what speed.
`
`The Board has previously agreed with Patent Owner on the very point, in the
`
`prior institution decision 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. Duodecad IT Services Luxembourg S.à.R.L. v. WAG Acquisition,
`
`LLC, Case IPR2015-01036, slip op. at 20 (PTAB Oct. 23, 2015) (Paper 8). The
`
`Petition ignores the Board’s prior decision on this point even though Petitioner’s
`
`attorney was of record in that prior IPR.
`
`
`
`7
`
`

`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`The current Petition adds to the “lost packet mechanism” the brief disclosure
`
`in Chen of the client making “specific requests” when packets needed by the client
`
`multimedia playback application are not found in the client’s packet buffer. (Chen
`
`at 5:59-67.) But the Petition fails to provide any explanation as to why this
`
`disclosure of requests “for immediate retrieval” is any more indicative of the
`
`sending rate than retransmitting lost packets “as soon as possible” (which the
`
`Board has already decided is not “at a rate more rapid than the rate at which said
`
`streaming media is played back by a user.”).
`
`The Petition attempts to make a shoehorn argument, combining separate
`
`disclosures from Chen to argue that “lost packets are requested using individual
`
`packet sequence numbers . . . [and] . . . Chen discloses such packets being sent ‘as
`
`fast as possible’ which in Chen is the ‘Rush’ mode.” (Petition at 13 (citing claim
`
`18 of Chen) (emphasis added).) This assertion is incorrect and misleading. Claim
`
`18 of Chen addresses the transmission speeds of RUSH, NORMAL, and PAUSE
`
`modes. But the media data elements recited in Claims 1 and 10 of the ’141 Patent
`
`are those requested by their serial identifiers. Chen’s claim 18 refers only to
`
`Chen’s standard “push” mechanism, and has nothing to do with any data elements
`
`specifically requested. The Petition glosses over the actual disclosures, seeking to
`
`conflate the “push” mechanism (including RUSH) with the separate mechanisms
`
`for requesting specific missing packets. There is no disclosure in Chen as to the
`
`
`
`8
`
`

`
`data rates of transmissions of the mechanisms for requesting specific packets,
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`which are the only mechanisms that the Petition argues relate to the claims of the
`
`’141 Patent.
`
`For at least these reasons, Chen fails to anticipate either of independent
`
`Claims 1 and 10. Claims 2, 4-7, 9, 11, 13-16, 18, and 28 depend from Claims 1 and
`
`10 and are patentable over Chen for at least the same reason.
`
`C. (Claims 1, 10, and 24, and dependent Claims 2, 4-7, 9, 11, 13-16, 18,
`
`and 26-28) Preamble [limitations 1a-b, 10a-b, 24a]
`
`Patent Owner does not believe it is necessary to construe the claim
`
`preambles as limiting in order to distinguish Chen. However, if so construed, the
`
`preambles provide an additional argument for distinguishing Chen from Claims 1,
`
`10, and 24 of the ’141 Patent and their dependent claims.
`
`The preambles of Claims 1, 10, and 24 recite distribution of / receiving
`
`“streaming media comprising a plurality of sequential media data elements for a
`
`digitally encoded audio or video program.” When read in light of the specification,
`
`these preambles require at least a continuous segment of a program, if not the
`
`entire program, to be sent by the server or requested by the player. These are not
`
`met by exceptional / missing, fragmentary portions of a program.
`
`The Petition ignores the primary “push” mechanism of Chen and instead
`
`relies upon the lost / missing packet mechanisms. In these scenarios, Chen’s client
`
`
`
`9
`
`

`
`sends a specific request / retransmission request for the data elements to the server.
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`But these specific requests in Chen will be for individual pieces / packets, and not
`
`for a program as a whole, or for a sequential portion of a program.
`
`These fragmentary, fill-in requests are the only two circumstances described
`
`in Chen where the client requests specific media data elements from the server.
`
`These are the only requests that are even arguably requests for “media data
`
`elements corresponding to specified serial identifiers” (as recited in limitations 1c
`
`and 10g) or the “plurality of sequential media data elements . . . being available on
`
`request by said player” (as recited in limitations 24a-b).
`
`The Petition’s argument fails to show sending “streaming media comprising
`
`a plurality of sequential media data elements” for a digitally encoded audio or
`
`video program.
`
`For at least this additional reason, Chen fails to anticipate independent
`
`Claims 1, 10, and 24. Claims 2, 4-7, 9, 11, 13-16, 18, and 26-28 depend from
`
`Claims 1, 10, and 24, and are patentable over Chen for at least the same reason.
`
`
`
`10
`
`

`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`D. (Claim 19, and dependent Claims 20 and 23) “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” [limitations 19a-b]
`
`Claim 19 recites “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.” As discussed above, Chen’s server does not
`
`respond to repeated “user requests for media data elements identified by a serial
`
`number.” Chen’s primary mechanism of operation is a “push” mechanism, and the
`
`lost/missing packet mechanism is only triggered for particular packets.
`
`Chen therefore does not anticipate Claim 19. Claims 20 and 23 depend from
`
`Claim 19, and are therefore patentable over Chen for at least this reason.
`
`E. (Claims 6 and 15) Distribution to multiple users wherein the server
`
`does not maintain a pointer into a server-side buffer for each user
`
`Dependent Claims 6 and 15 recite, including through dependency,
`
`distributing “said streaming media to a plurality of users . . . wherein said server
`
`does not maintain a pointer into a buffer established within said server, for each
`
`said user.”
`
`
`
`11
`
`

`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`The meaning of this negative limitation is clear on its face, and is consistent
`
`with the specification. (’141 Patent at 8:38-40 (“The server buffer manager does
`
`not maintain a pointer into the server buffer for each user”).)
`
`The Petition states that Chen services multiple users. (Petition at 43.) For the
`
`pointer limitation of Claims 6 and 15, the Petition relies on the missing and lost
`
`packet mechanisms of Chen, where the client requests data elements by their serial
`
`identifiers. (Petition at 43-44.)
`
`The Petition simply asserts that in one mode the Chen server transmits
`
`without relying on the pointers, as recited in Claims 6 and 15, but the Petition does
`
`not address the substance of the limitation, which is that the server simply does not
`
`maintain such a pointer for each user in any manner related to the claimed
`
`transmission mechanism.
`
`The main (push) mechanism of Chen maintains a pointer for each user to
`
`which it is serving media. Chen discloses setting up a separate stream buffer for
`
`each user session. (Chen at 9:44-48.) Chen further states that in NORMAL mode,
`
`which its server “should be in” “most of the time” there is “limited interaction”
`
`between the client and server and “no need exists for the client agent (30) to send
`
`periodic feedback to the server control (1).” (Chen at 6:32-39; 10:2-3.) Chen’s
`
`server must track what is in each of its transmission buffers at least to know which
`
`media data element to send next, from each buffer to each user. This is what
`
`
`
`12
`
`

`
`Claims 6 and 15 recite that the server should not be doing. Chen does not therefore
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`meet the negative limitations of these claims.
`
`For at least this additional reason, Chen fails to anticipate Claims 6 and 15.
`
`IV. Ground 2: Alleged Obviousness Over Chen in View of Willebeek
`
`Ground 2, as to dependent Claims 8, 17, and 21, is based on alleged
`
`obviousness of those claims over Chen in view of Willebeek. Ground 2’s claims
`
`add a live transmission limitation to their respective parent claims, which were
`
`each addressed above in Ground 1.
`
`A. There is no motivation to combine Chen and Willebeek in the
`
`manner argued and it would change the principle of operation of
`
`Chen
`
`In short, Petitioner’s argument is that Willebeek provides a “captured”
`
`circular buffer of a live broadcast and hands this to Chen, in place of Chen’s video-
`
`on-demand server buffer.2 The combination proposed in the instant Petition would
`
`
`2 Petitioner argued the same combination of Chen and Willebeek in its copending
`
`IPR with respect to WAG’s ’839 Patent. See IPR Case No. 2016-01239. In that
`
`case, the claimed subject matter involved a push mechanism. WAG argued in its
`
`preliminary response that the combination would not work because, inter alia,
`
`successive RUSH commands would drain the server buffer, which would be
`
`
`
`13
`
`

`
`slap Willebeek’s circular buffer onto Chen to provide a live feed, but would
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`completely ignore Chen’s scheduler and primary mode of push operation, and use
`
`only the lost and missing packet mechanisms of Chen. The proposed combination
`
`would change the principle of operation of Chen. Further, the Petition provides no
`
`explanation of how the referenced mechanisms could possibly work under the
`
`proposed combination.
`
`Ground 1 relies on anticipation, but Ground 2 relies on obviousness. It is
`
`Petitioner’s burden, in an obviousness argument, to show why a POSITA would
`
`combine the references in the specified manner.
`
`A POSITA would not look to combine Chen with Willebeek at all, and
`
`certainly not in the manner urged by the Petition. The Petition makes contortions to
`
`try to arrive at the claimed subject matter but, for motivation to combine, argues
`
`only that it would have been obvious to combine these references “so that Chen
`
`could provide live video.” (Petition at 46.) This is inadequate justification for the
`
`proposed combination and untrue, as discussed below.
`
`
`
`unable to recover and honor subsequent RUSH commands. Webpower v. WAG
`
`Acquisition, LLC, Case IPR2016-01239, at 24-28 (Sept. 30, 2016) (Paper 6).
`
`
`
`14
`
`

`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`B. (Claims 8 and 17) The proposed combination does not disclose or
`
`suggest “send[ing] media data elements to the user system responsive
`
`to said requests.” [limitations 1d and 10h]
`
`In arguing for the combination of Chen with Willebeek, the Petition states
`
`that
`
`Since the circular buffer queue contains a few seconds of video, Chen
`
`would then be able to rush the first packets to the user. After that, the
`
`packets would be sent at the normal (playback rate), as they are
`
`received—packets would be received at the server as they are
`
`generated by the capture station from the live feed and, barring
`
`interruptions, would be passed to the client packet buffer 31 at the
`
`playback rate.
`
`(Petition at 47.)
`
`This makes no sense. Willebeek, in its circular buffer, holds “the most recent
`
`several seconds” of the live program. (Willebeek at 278.) Petitioner argues that this
`
`should somehow be rushed to the client in the proposed combination, after which
`
`Willebeek’s server buffer would be empty and packets would be apparently passed
`
`through as they arrive.
`
`However, parent Claims 1 and 10 of the ’141 Patent (and therefore
`
`dependent Claims 8 and 17) recite that media data elements are sent in response to
`
`requests by serial identifier. There is no mention of this in the Petition’s Ground 2.
`
`The proposed combination, as described by the Petition, does not disclose or
`
`
`
`15
`
`

`
`suggest “send[ing] media data elements to the user system responsive to said
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`requests” as recited in parent Claims 1 and 10 (and hence dependent Claims 8 and
`
`17). The argued functionality of the proposed combination is an initial rush and
`
`then a pass through. There is no discussion in the Petition of any repeated requests,
`
`or from where the server could get these packets even if it received such requests.
`
`Further, the Petition fails to address how the live data of Willebeek would be
`
`assigned any identifiers, how and when such identifiers would be known to the
`
`client in the proposed combination, and how and when the client would make any
`
`such requests.
`
`Moreover, Chen only requests packets by identifier in cases where a packet
`
`is determined to be lost or missing, not to send the entire stream.
`
`Therefore, Claims 8 and 17 are patentable over the proposed combination.
`
`C. (Claim 21) The proposed combination does not disclose or suggest
`
`“stor[ing] and serially identify[ing] sequential data elements.”
`
`[limitation 19c]
`
`Claim 21 depends from parent Claim 19, which recites preparing streaming
`
`media by “stor[ing] and serially identify[ing] sequential data elements.” The
`
`Petition is silent on how this would be done with live data as provided by
`
`Willebeek. The Petition does not address what facility would perform the claimed
`
`storing and identifying in real time, or how it would be done.
`
`
`
`16
`
`

`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`Therefore, Petitioner has failed to meet its burden with respect to Claim 21,
`
`and Claim 21 is patentable over the proposed combination.
`
`* * *
`
`Additionally, the proposed combination would suffer from all of the
`
`infirmities discussed above with respect to Ground 1, which distinguish Claims 1,
`
`10, and 19 from Chen. Willebeek does not cure any of the deficiencies addressed
`
`in Ground 1 with respect to Chen. Therefore, dependent Claims 8, 17, and 21 are
`
`patentable over the combination of Chen and Willebeek for the additional reasons
`
`discussed above in Ground 1.
`
`V. Ground 3: Alleged Obviousness Over Carmel in View of
`Willebeek
`
`Ground 3 shifts from Chen to a different primary reference, Carmel. Ground
`
`3 asserts the alleged obviousness of Claims 1, 24, and most of their dependent
`
`claims, over Carmel in view of Willebeek.
`
`The Petition makes clear that Willebeek is added only with respect to
`
`limitations 1g and 24f. (Petition at 65.) Ground 3 otherwise relies exclusively on
`
`Carmel.
`
`It is unclear how Carmel could be combined with Willebeek, and the
`
`Petition fails to substantively discuss the combination. (Petition at 51.) The Petition
`
`merely argues to pluck a specific piece out of Willebeek and combine it with
`
`Carmel. It says this would be done “to provide the benefit of ensuring continuous
`
`
`
`17
`
`

`
`playback even when network congestion delayed packet transmission.” (Id.)
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`However, as explained below, Carmel already has its own adaptive mechanism to
`
`deal with data flow issues. The Petition does not explain why a POSITA would
`
`think Willebeek’s approach is any better than that already provided by Carmel. The
`
`lack of any benefit from the proposed combination completely undercuts any
`
`motivation to combine.
`
`Moreover, the Petition fundamentally misreads Willebeek and presumes
`
`functionality in Willebeek’s client that is quite different from what Willebeek
`
`actually discloses.
`
`A. (Claim 1, and dependent Claims 2, 4-9, and 28) server “programmed
`
`to receive requests from the user system for media data elements
`
`corresponding to specified serial identifiers” and “send[ing] media
`
`data elements to the user system responsive to said requests.”
`
`[limitations 1c-1d]
`
`As discussed above in the summary of Carmel, the Carmel system does not
`
`operate to send media via multiple requests for data elements by serial identifiers.
`
`“After preparing the multimedia sequence, computer 34 uploads the sequence over
`
`network 28, preferably using the Internet File Transfer Protocol (FTP).” (Carmel at
`
`6:50-52.) Carmel discloses that this “preparing” can include slicing the data and
`
`keeping a “running slice index.” (Carmel at 7:25-28; see also Carmel at 8:20-25.)
`
`
`
`18
`
`

`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`In Carmel, “[e]ach client 30 connects to server 36, optionally using multiple
`
`HTTP links.” (Carmel at 10:35-36.) “The client first reads index file 50” which
`
`allows a user to choose “at which slice of data stream 40 to begin downloading.”
`
`(Carmel at 10:41-44.) After the user selection of which slice to begin with, the
`
`Carmel client “begins to download and decode (decompress) files 42, 44, 46, etc.”
`
`(Carmel at 10:44-47.) Carmel also discloses that the stream can be encoded at
`
`multiple quality levels, which allows the user to select an appropriate level, after
`
`which “server 36 begins to transmit data slices at the chosen quality level [and]
`
`[t]he slices are received, decoded and output by the client.” (Carmel at 10:64-11:8.)
`
`Carmel does not disclose or suggest that the server is programmed to receive
`
`user requests for media data elements or that the stream is sent by “send[ing]
`
`media data elements to the user system responsive to said requests” as recited in
`
`Claim 1 of the ’141 Patent. The plain meaning of the ’141 claim language is that
`
`the server receives a plurality of requests and that each request is for one or more
`
`media data elements by identifier. The claims thereby recite a “pull” mechanism,
`
`wherein the client “pulls” the stream by making repeated requests.
`
`Carmel divides a stream and can apply indices to the slices, which allows the
`
`user to