UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`WEBPOWER, INC.,
`
`FRIENDFINDER NETWORKS INC., STREAMRAY INC., WMM, LLC,
`WMM HOLDINGS, LLC, and MULTI MEDIA, LLC,
`
`DUODECAD IT SERVICES LUXEMBOURG S.À R.L.,
`ACCRETIVE TECHNOLOGY GROUP INC., ICF TECHNOLOGY, INC,
`RISER APPS LLC, and STREAMME, INC. (f/k/a VUBEOLOGY, INC.),
`
`Petitioner,
`
`v.
`
`WAG ACQUISITION, LLC
`Patent Owner
`________________
`
`Case IPR2016-01238
`Patent No. 8,122,141 B2
`________________
`
`PETITIONER’S CONSOLIDATED REPLY
`TO PATENT OWNER’S RESPONSE
`
`
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`WEBPOWER, INC.,
`
`FRIENDFINDER NETWORKS INC., STREAMRAY INC., WMM, LLC,
`WMM HOLDINGS, LLC, and MULTI MEDIA, LLC,
`
`DUODECAD IT SERVICES LUXEMBOURG S.À R.L.,
`ACCRETIVE TECHNOLOGY GROUP INC., ICF TECHNOLOGY, INC,
`RISER APPS LLC, and STREAMME, INC. (f/k/a VUBEOLOGY, INC.),
`
`Petitioner,
`
`v.
`
`WAG ACQUISITION, LLC
`Patent Owner
`________________
`
`Case IPR2016-01238
`Patent No. 8,122,141 B2
`________________
`
`PETITIONER’S CONSOLIDATED REPLY
`TO PATENT OWNER’S RESPONSE
`
`
`
`Exhibit Number
`1001
`1002
`
`EXHIBIT LIST
`Description
`U.S. Patent No. 8,122,141 to Price (“the ’141 patent”)
`U.S. Patent No. 5,822,524 to Chen et al. (“Chen”)
`
`1003
`
`1004
`
`1005
`
`1006
`
`1007
`
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`
`1014
`
`U.S. Patent No. 6,389,473 to Carmel et al. (Carmel”)
`
`Willebeek-LeMair, et al., “Bamba – Audio and Video
`Streaming Over the Internet,” IBM Journal of Research and
`Development¸ Vol. 42, No. 2, March 1998 (“Willebeek”)
`
`Declaration of Dr. Nathaniel Polish in Support of Inter
`Partes Review of U.S. Patent 8,122,141 (“Polish Decl.”)
`
`F. Kozamernik, “Webcasting - The Broadcasters’
`Perspective.” EBU Technical Review, March 2000
`(“Kozamernik”)
`
`U.S. Patent No. 6,625,656 to Goldhor (“Goldhor”)
`
`S. Boll et al., “Intelligent Prefetching and Buffering for
`Interactive Streaming of MPEG Videos” (“Boll”)
`
`N. Polish, “The Burstware Family of Protocols”
`
`Hollfelder et al., “Transparent Integration of Continuous
`Media Support into a Multimedia DBMS” (“Hollfelder”)
`
`Prosecution history for U.S. Patent No. 8,122,141
`
`Curriculum Vitae of Dr. Nathaniel Polish
`
`Petitioner’s Waiver of Service
`
`Transmission Control Protocol – DARPA Internet Program
`Protocol Specification
`
`ii
`
`
`
`1015
`
`1016
`
`1017
`
`1018
`
`1019
`
`1020
`
`1021
`
`10221
`
`Dawna Dwire, Client/Server Computing (McGraw-Hill, Inc.
`1993)
`
`Declaration of Jonathan Falkler
`
`Z. Shae, X. Wang, and S.P. Wood, “Large Scale
`Experiments on Low Bit Rate Multimedia Broadcast,
`IS&T/SPIE Conference on Visual Communications and
`Image Processing ’99, SPIE Vol. 3653, Jan. 1999 (“Shae”).
`International Standard ISO/IEC 11172-1, “Information
`Technology – Coding of moving pictures and associated
`audio for digital storage media at up to about 1,5 Mbit/s –
`Part 1: Systems,” August 1993 (“ISO-11172-1”)
`International Standard ISO/IEC 11172-2, “Information
`Technology – Coding of moving pictures and associated
`audio for digital storage media at up to about 1,5 Mbit/s –
`Part 2: Video,” August 1993 (“ISO-11172-2”)
`International Standard ISO/IEC 11172-3, “Information
`Technology – Coding of moving pictures and associated
`audio for digital storage media at up to about 1,5 Mbit/s –
`Part 3: Audio,” August 1993 (“ISO-11172-3”)
`April 6, 2016 Deposition of Dr. Patel, IPR2015-01036
`
`June 20, 2017 Deposition of Dr. Chiang
`
`1 New Exhibit
`
`iii
`
`
`
`TABLE OF CONTENTS
`
`INTRODUCTION..............................................................................................1
`I.
`II. DISCUSSION ....................................................................................................1
`A. Claim 10: “sending media data elements to a user system
`responsive to requests therefore, at a rate more rapid than the rate
`at which the streaming media is played back by a user” ...........................1
`1. Carmel discloses sending media data elements at a rate faster
`than playback.........................................................................................2
`2. Patent Owner’s arguments conflict with the specification
`disclosure. ..............................................................................................6
`B. Claim 15: “said server does not maintain a pointer into a buffer
`established within said server, for each said user”...................................11
`C. Claims 19-23.............................................................................................15
`III. CONCLUSION ................................................................................................16
`
`iv
`
`
`
`I.
`
`INTRODUCTION
`
`The Petition establishes that claims 10-23 are invalid as anticipated or
`
`obvious in view of the cited prior art. Patent Owner does not dispute the invalidity
`
`of claims 19-23 in its Response. Rather, Patent Owner only takes issue with the
`
`Petition and Institution Decision with respect to claims 10-18, and for only two
`
`reasons. First, Patent Owner argues claims 10-18 should be found valid because
`
`Carmel does not disclose transmitting data elements at a rate more rapid than the
`
`playback rate. Second, Patent Owner argues claim 15 should be found valid
`
`because Carmel discloses the use of a pointer into a server buffer. Patent Owner’s
`
`arguments are contrary to the plain disclosure of the Carmel reference and should
`
`be rejected.
`
`II.
`
`DISCUSSION
`
`A.
`
`Claim 10: “sending media data elements to a user system
`responsive to requests therefore, at a rate more rapid than the
`rate at which the streaming media is played back by a user”
`
`The Patent Owner argues that claims 10-18, all depending from claim 10,
`
`are not anticipated because Carmel allegedly does not disclose sending media data
`
`elements at a rate faster than the playback rate. Carmel, however, repeatedly
`
`discloses sending data elements at a rate faster than playback.
`
`1
`
`
`
`1. Carmel discloses sending media data elements at a rate faster
`than playback
`
`Carmel describes transmitting media data elements in slices. Carmel, Ex.
`
`1003 at Fig. 3A. A transmitting computer generates and uploads the slices to a
`
`server, and they are downloaded by clients. Id. at 2:1-21. Carmel states that “the
`
`transmitting computer and the clients monitor the uploading and downloading of
`
`data . . . in order to determine the amount of time required to convey each slice and
`
`to verify that the slices are conveyed at a sufficient rate.” Id. at 2:51-56. “When
`
`the data stream comprises multimedia data, the data rate should be generally equal
`
`to or faster than the rate at which the data are generated at the transmitting
`
`computer.” Id. at 2:51-59. Here, Carmel describes a data transmission rate that is,
`
`at least sometimes, “faster” than the rate at which the multimedia data is generated
`
`or played.2 Thus, the claim limitation requiring “sending media data elements to a
`
`2 This sentence refers to the transmitting computer (i.e., uploading to the server),
`
`and it is undisputed that “Carmel treats download rates throughout equivalently to
`
`upload rates.” PO Response at 11 (citing Chiang Decl., Ex. 2001 at ¶ 12); see also
`
`Carmel, Ex. 1003 at 13:29-35 (description of uploading applies to downloading).
`
`The prior sentence makes clear the context is both uploading and downloading (id.
`
`at 2:51-56), and in this context a transmission rate that is faster than video is
`
`2
`
`
`
`user system responsive to requests a rate more rapid than the rate at which the
`
`streaming media is played back by a user” is met by this disclosure.
`
`Carmel also describes a faster-than-playback transmission rate when it states
`
`that clients monitor time codes as a file is received to ensure that the transmission
`
`is “keeping up” and “[i]n the event that a lag is detected, steps are taken to increase
`
`the data transmission or reception rate.” Id. at 7:39-42.
`
`A first way Carmel describes increasing the transmission rate (thus
`
`recovering from lag) is by opening additional download links. Carmel states that
`
`“Client 30 preferably monitors the rate of data coming in over each of its links with
`
`server 36” and “if it determines that there is a significant lag in the time codes
`
`relative to the real-time clock, opens additional links with the server 36 in order to
`
`increase the overall data rate.” Id. at 10:55-63. After opening these additional
`
`links, the next group of data elements will be sent at a rate more rapid than they are
`
`played back (because, for example, the next data elements will be sent
`
`simultaneously over two links), accounting for the lag that was experienced. Thus,
`
`this mechanism for “increas[ing] the overall data rate” also meets the claim
`
`generated by an uploading computer (i.e., the broadcast computer) is also faster
`
`than a rate at which data is played.
`
`3
`
`
`
`requirement of “sending media data elements . . . at a rate more rapid than the rate
`
`at which the streaming media is played back by a user.”3
`
`A second, independent, way Carmel describes increasing the transmission
`
`rate is by changing the quality level of the data, permitting each slice to be sent
`
`faster than playback: “Periodically, client 30 makes an assessment of the rate of
`
`data transfer over the link from the server and, if necessary, changes the quality
`
`level accordingly.” Id. at 11:9-11. “For example, if the rate is low, such that the
`
`time stamps 59 indicate that the slices need to be played as fast or faster than they
`
`are being received, the client will preferably select a lower quality level.” Id. at
`
`11:11-15. By selecting a lower quality level for the slices, the size of the files is
`
`decreased, and each slice may be individually transmitted at a faster rate. The
`
`slices would no longer need to be “played as fast or faster than they are being
`
`3 Notably, the claims do not recite that “each” slice is individually sent faster than
`
`playback. Rather, they recite sending “media data elements” at a rate more rapid
`
`than “said streaming media is played back by a user.” The broadest reasonable
`
`construction of this claim is met when a group of media data elements are
`
`transmitted at a rate more rapid than they are, collectively, played back by a user.
`
`Or, as stated by Carmel, the “overall data rate” is increased. Carmel, Ex. 1003 at
`
`10:55-63.
`
`4
`
`
`
`received”—which means that they would now be played slower than they are
`
`being received. Id. After this correction, the transmission of the media data
`
`elements is faster than the media is played, as required by the claim. The data rate
`
`is maintained at this preferable rate by dynamically setting “upper and lower data
`
`rate thresholds, or watermarks.” Id. at 11:19-22. Carmel thus discloses that a
`
`“low” rate is one where slices are merely transmitted as fast as they are played; that
`
`is, a rate that must be increased to the “normal” or “medium” rate where slices will
`
`be transmitted faster than they are played.
`
`The description of these two different lag-recovery mechanisms in Carmel—
`
`which were cited in the Petition at pages 56-57 and largely avoided by the Patent
`
`Owner’s Response—mean that Carmel necessarily discloses transmitting media
`
`elements faster than the playback rate. Transmitting media elements faster than the
`
`playback rate is the only way to recover from a lag in transmission.
`
`Patent Owner states that Dr. Polish has not discussed the “more rapid than
`
`playback rate” limitation in detail. Dr. Polish, however, states that he agrees with
`
`the Petition’s characterization of the Carmel reference, and states that he finds the
`
`limitations of claim 10 to be disclosed by Carmel (Polish Decl., Ex. 1005 at ¶ 55).
`
`And in any event, no expert opinion is necessary to supplement the disclosure
`
`because this feature is explicitly disclosed by the reference in a number of ways.
`
`No further expert testimony was or is necessary.
`
`5
`
`
`
`2. Patent Owner’s arguments conflict with the specification
`disclosure
`
`Patent Owner’s Response focuses on the first statement in Carmel that the
`
`data rate of the data stream should be “generally equal to or faster” than the rate
`
`media is generated. Patent Owner alleges that the “data rate” in this description
`
`does not “necessarily refer to the rate at which the server in Carmel sends
`
`individual slices.” PO Response at 4. That understanding of this “rate,” however,
`
`is in direct conflict with the disclosure:
`
`In some preferred embodiments of the present invention, the
`transmitting computer and the clients monitor the uploading and
`downloading of data to and from the server, respectively, in order to
`determine the amount of time required to convey each slice and to
`verify that the slices are conveyed at a sufficient rate. When the data
`stream comprises multimedia data, the data rate should be generally
`equal to or faster than the rate at which the data are generated at the
`transmitting computer.
`
`Carmel, Ex. 1003 at 2:51-59. The preceding sentence equates the “rate” to
`
`“amount of time required to convey each slice.” Thus, the “data rate” discussed
`
`here is the rate at which the server conveys slices to the user computer.
`
`Patent Owner also relies on a statement by its expert that the “data rate” in
`
`this passage is the bandwidth of the available transmission channel and not the rate
`
`at which individual media data elements are sent. PO Response at 4-5. First, as
`
`6
`
`
`
`described above, this is in conflict with the prior sentence of Carmel, which
`
`equates the rate to the “amount of time required to convey each slice.” Second,
`
`this appears to be a distinction without a difference. Even if data rate refers to the
`
`overall bandwidth of the channel the claim 10 limitation is still met. Patent
`
`Owner’s expert conceded that bandwidth is measured “in bits per second, the
`
`ability of the underlying channel to support transmission.” Chiang Tr., Ex. 1022 at
`
`96:16-21. Thus, if Carmel discloses that the “bandwidth”—the bits per second at
`
`which data can be transmitted—is “faster than the rate at which the data are
`
`generated” then the claim limitation requiring transmission at a “rate more rapid”
`
`than playback is met.4
`
`Patent Owner and Dr. Chiang note that, in other places, Carmel describes
`
`transmission “at about playback rate.” This is entirely consistent with the teaching
`
`that the transmission is sometimes “faster”—the word “about” allows for the data
`
`4 Patent Owner states several times that Carmel teaches “to maximize usage of the
`
`overall transmitting bandwidth.” PO Response at 8; see also id. at 7. Even if the
`
`data rate refers to the overall bandwidth of the available channel, as suggested by
`
`Patent Owner’s argument, Carmel teaches to maximize usage of this bandwidth.
`
`Thus, in this case, the bandwidth of the available transmission channel is the same
`
`as the rate at which individual media data elements are sent.
`
`7
`
`
`
`to be sent “generally equal to or faster” than the consumption rate to ensure
`
`continuous playback. Dr. Chiang admitted in his deposition that “about the
`
`playback” rate means “it is transmitted slightly faster than playback rate and then
`
`slightly lower.” Id. at 92:16-19. This admission is dispositive. Transmitting
`
`“slightly faster” than the playback rate meets the claim limitation of transmitting at
`
`a “rate more rapid” than playback.
`
`Patent Owner also argues that Carmel does not teach faster-than-playback
`
`rates because it discloses increasing the size of slices if there is excess capacity.
`
`This argument, however, fails for two reasons. First, the fact that the system
`
`recognizes this need for an adjustment is itself evidence that the prior slices were
`
`sent faster-than-playback. Carmel discloses that the adjustment referenced by
`
`Patent Owner—to increase the size of data—is made after a period where the slice
`
`transmission time (Tsl) is less than the slice duration (Tmin). Carmel, Ex. 1003 at
`
`13:21-22; see also 12:64 (defining Tsl); 13:10-11 (defining Tmin). In other words,
`
`the adjustment is made after a period where slices have been transmitted faster
`
`than they are being played. The claim limitation is met by the period of time
`
`where slices are transmitting faster than playback. Second, Patent Owner is
`
`referring to just one of two ways to adjust transmission of media data elements.
`
`The other—cited in the petition—is to decrease the size of files so that they can be
`
`transmitted faster over a given link. Id. at 11:11-15. One reason for performing
`
`8
`
`
`
`this is to recover from lag, where the smaller files must necessarily be transmitted
`
`faster than playback to achieve the intended result. Id. at 7:40-49.
`
`Patent Owner’s discussion of “gaps” does not show that media data elements
`
`are not transmitted faster than playback. First, there is no discussion of avoiding
`
`“gaps” in Carmel. Even assuming, arguendo, Carmel discloses a lack of “gaps,”
`
`elements can still be transmitted faster than playback without “gaps” between
`
`them, for example, when the size of each data element is reduced to recover from a
`
`lag. Id. at 7:40-49; 11:11-15.
`
`Patent Owner also points to an unsigned Dr. Polish declaration filed in
`
`another case as supporting its arguments. 5 That declaration describing Carmel’s
`
`disclosure of a “generally equal” rate does not, however, contradict the above
`
`understanding of the “faster” rate also described in Carmel. That declaration
`
`includes an opinion on non-infringement of Carmel claims 1 and 25 by an Apple
`
`5 The exhibit submitted by Patent Owner is an unsigned declaration. During his
`
`deposition Dr. Polish testified it appeared to be “at least some version of a
`
`declaration that [he] executed in a District Court case” but stated that “[t]his
`
`doesn’t bear my signature, so I don’t know where you got this from, and whether
`
`this is the final version.” Polish Tr., Ex. 2003 at 49:18-50:5. Patent Owner’s
`
`statement that the document was “authenticated” by him is therefore incorrect.
`
`9
`
`
`
`product. Ex. 2101 at ¶ 10. Claims 1 and 25 of Carmel include a limitation
`
`requiring a “generally equal” upload rate, a term construed by the Court. Id. The
`
`declaration states that the claims with the “generally equal” limitation require
`
`“some kind of generally equal relationship . . . between the two.” Id. at ¶ 12
`
`(emphasis added). This does not preclude sometimes sending data faster than the
`
`playback rate, nor is it a statement of whether the (unclaimed) disclosure of Carmel
`
`contemplates transmission faster than playback under certain conditions.
`
`In the present action, it is Carmel’s disclosure of sending at a data rate
`
`“faster” than the playback rate—including when recovering from lag—that is
`
`relevant, not the limitation of a “generally equal relationship” in Carmel’s claims.
`
`The declaration statement in Paragraph 11 quoted by Patent Owner—noting the
`
`patent places emphasis on maintaining a generally equal relationship between the
`
`data rate of the stream and the upload rate—is consistent with Petitioner’s
`
`explanation of the reference. The upload/download rate can be generally equal to
`
`(or faster) than the upload rate, and adjustments can be made when situations such
`
`as a lag in transmission occur.
`
`Finally, Patent Owner states that, if slices in Carmel were transmitted at
`
`faster than playback rate, there would be a problem in Carmel with the unregulated
`
`filling of client buffers. That is incorrect, because Carmel’s process is not
`
`unregulated. Much like the ‘141 patent, Carmel discloses that the client “monitors
`
`10
`
`
`
`the rate of data coming in.” Carmel, Ex. 1003 at 10:55-56. For example, it uses
`
`“upper and lower data rate thresholds, or watermarks, [that] are set dynamically” to
`
`increase or decrease the transmission rate as necessary. Id. at 11:19-21.
`
`Carmel thus discloses transmitting at a rate faster than playback in at least
`
`three ways. First, it describes using a transmission channel that is itself “faster”
`
`than the playback rate for multimedia, so that each data element can be sent over a
`
`single link faster than playback. Id. at 2:51-59. Second, it describes opening
`
`multiple links so that, for a given sequence of slices, the slices are collectively sent
`
`at a rate faster than they are played back. Id. at 10:55-63. Third, it discloses
`
`decreasing the size of the files so that each individual data element can be sent
`
`faster than playback, even if using one link. Id. at 11:9-15. Each of these
`
`disclosures meet the limitation of “sending media data elements to a user system
`
`responsive to requests therefore, at a rate more rapid than the rate at which the
`
`streaming media is played back by a user.”
`
`B.
`
`Claim 15: “said server does not maintain a pointer into a buffer
`established within said server, for each said user”
`
`Patent Owner argues that claim 15 should be found valid because Carmel
`
`does not disclose the limitation that the “server does not maintain a pointer into a
`
`buffer established within said server, for each said user.” Patent Owner does not,
`
`because it cannot, point to any disclosure of a pointer into a server buffer for each
`
`user in Carmel. Rather, Patent Owner relies on a statement by its expert
`
`11
`
`
`
`unsupported by any evidence, intrinsic or extrinsic. Conclusory expert testimony
`
`cannot contradict the express disclosure of Carmel explaining that the system
`
`operates based on client-side requests for particular slices, not server-side pointers.
`
`Carmel states that a user on the client side can decide and indicate at which
`
`slice to begin downloading, and “[r]esponsive to a user input, client 30 selects an
`
`appropriate starting slice and begins to download and decode (decompress files 42,
`
`44, 46, etc.).” Carmel, Ex. 1003 at 10:45-48. Any subsequent adjustments are
`
`controlled by the “client 30 [which] makes an assessment of the rate of data
`
`transfer over the link from the server.” Id. 11:9-11. Maintaining a server-side
`
`pointer for each user is not a part of Carmel’s system. In Carmel, it is the client
`
`that selects files for download, there is no disclosure of (or need for) a server-side
`
`pointer.
`
`The Carmel disclosure is the same as the ‘141 patent in this regard. The
`
`‘141 patent presents the “pointer-less” embodiment as an alternative to an
`
`embodiment where broadcast software on the server maintains a pointer for each
`
`user. With respect to the embodiment with no pointer, the ‘141 patent states:
`
`In another embodiment . . . [t]he 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.
`Via the use of standard data communications protocol techniques such
`
`12
`
`
`
`as TCP, the user computer transmits a request to the server to send
`one or more data elements, specifying the serial numbers of the data
`elements. The server responds by sending the requested data elements,
`and depends upon the reliable transmission protocol to assure
`delivery.
`Ex. 1001 at 8:35-48. Thus, the ‘141 pointer-less embodiment is achieved “via the
`
`use of standard data communications protocols such as TCP,” where the request is
`
`received from the client, and the server “depends upon the reliable transmission
`
`protocol to assure delivery.” Id. Dr. Chiang confirmed that this is the way the
`
`‘141 patent operated without a pointer, and that no pointer would be necessary,
`
`even for multiple users. Chiang Tr. Ex. 1022 at 60:24-64:8.
`
`Carmel describes the same thing. “One or more client computers download
`
`the encoded sequence using an Internet download protocols, most preferably HTTP
`
`or alternatively, UDP or RTP.” Ex. 1003 at 2:11-15; see also Chiang Tr., Ex. 1022
`
`at 50:10-51:4 (HTTP was known to use TCP in 2000). As Dr. Polish explained,
`
`“Carmel uses the indices associated with the media frames to maintain a record of
`
`the slices on the client-side, and the server responds to requests for slices identified
`
`by index.” Dr. Polish Decl., Ex. 1005 at ¶ 58. Thus, in Carmel, like the ‘141
`
`embodiment, existing reliable transmission protocols, such as HTTP using TCP,
`
`are used to assure delivery. Id.; see also Dr. Polish Decl., Ex. 1005 at ¶¶ 59-60
`
`(explaining the TCP protocol operation).
`
`13
`
`
`
`Dr. Chiang’s opinion that Carmel discloses a pointer into a server buffer is
`
`also contradicted by the Carmel specification’s statements that no special-purpose
`
`broadcasting software is required on the server: “Since FTP and HTTP are
`
`supported by substantially all network servers, server 36 need not include any
`
`special-purpose broadcasting hardware or software, as noted above.” Carmel, Ex.
`
`1003 at 7:9-12. Carmel states that the client-side control enables this: “the
`
`inclusion of the slice indices in the data stream to be used by the clients in
`
`maintaining synchronization allows the broadcast to go on substantially in real
`
`time without the use of special-purpose hardware.” Id. at 2:1-21. Patent Owner’s
`
`expert did not consider this in forming his opinion—he testified that Carmel’s
`
`disclosure of using standard network servers is “a matter about Carmel that [he
`
`has] not expressed opinion on.” Chiang Tr., Ex. 1022 at 76:10-22.
`
`Finally, Patent Owner’s argument is premised on an incorrect assumption
`
`that Carmel must (1) provide media for multiple users, and (2) perform a seek
`
`function. Neither of these things are in the ‘141 patent claims (which require
`
`merely “at least one user” and do not describe a seek function). And, these are
`
`both optional features of Carmel. Carmel, Ex. 1003 at 4:12-15 (“Preferably, the
`
`one or more client computers include a plurality of client computers . . . .”); 4:7-11
`
`(“In a preferred embodiment, downloading the sequence includes selecting a file in
`
`the sequence earlier than the file whose index is contained in the index file . . . .”).
`
`14
`
`
`
`Since neither function is a requirement of Carmel, even if a pointer was required
`
`for these functions (which Petitioner disputes), the claims are invalidated by the
`
`Carmel embodiments that do not require these particular functions.
`
`Carmel’s disclosure of client-side control, a lack of specialized software on
`
`the server, and the same pointer-less protocols disclosed in the ‘141 patent show
`
`that Carmel operates with a “server [that] does not maintain a pointer into a buffer
`
`established within said server, for each said user.” Against this, Patent Owner
`
`provides the bare statement that “Carmel would need to use a pointer to keep track
`
`of which slice 42-48 to next multicast to clients 30.” Petition at 14. Neither Patent
`
`Owner nor its expert cite anything in the reference that describes the need for such
`
`a pointer, nor do they provide any evidence, intrinsic or extrinsic, for why
`
`Carmel’s system “would need to use a pointer.” If, as in the ‘141 patent, the slices
`
`are requested by the client computers by index number, and transmitted using
`
`“standard data communications protocol techniques such as TCP” as in the ‘141
`
`patent, then no pointer is needed (as explained in the ‘141 patent). Carmel has no
`
`more “need” for a pointer than the ‘141 patent’s embodiments without a server-
`
`side “buffer manager.”
`
`C.
`
`Claims 19-23: Invalidity is not Disputed
`
`Patent Owner does not dispute the invalidity of claims 19-23 in its Response.
`
`Patent Owner previously made certain arguments in its Preliminary Response, but
`
`15
`
`
`
`has abandoned them. Arguments not made in the Response brief are waived.
`
`Scheduling Order, Paper 9 at 3 (“The patent owner is cautioned that any arguments
`
`for patentability not raised in the response will be deemed waived”); see also In re
`
`NuVasive, Inc., 842 F.3d 1376, 1380 (Fed. Cir. 2016) (arguments made during
`
`preliminary proceedings but not during the trial phase are waived). And in any
`
`case, each of the arguments in the Preliminary Response were considered,
`
`addressed, and appropriately found unpersuasive in the Institution Decision. See
`
`Paper 7 at 14-15. Claims 19-23 should therefore be invalidated for the reasons
`
`already explained in the Petition and the Institution Decision.
`
`III. CONCLUSION
`
`For the foregoing reasons, Petitioner respectfully requests that claims 10-23
`
`be cancelled as unpatentable.
`
`Dated: June 30, 2017
`
`Respectfully submitted,
`By: /Frank M. Gasparo/
`Frank M. Gasparo
`Registration No. 44,700
`Venable LLP
`Rockefeller Center
`1270 Avenue of the Americas
`Twenty-Fourth Floor
`New York, NY 10020
`
`16
`
`
`
`CERTIFICATE OF COMPLIANCE
`
`I hereby certify that this brief complies with the type-volume limitations of
`
`37 C.F.R. § 42.24, because it contains 3,809 words (as determined by the
`
`Microsoft Word word-processing system used to prepare the brief), excluding the
`
`parts of the brief exempted by 37 C.F.R. § 42.24.
`
`Dated: June 30, 2017
`
`Respectfully submitted,
`
`By: /Frank M. Gasparo/
`Frank M. Gasparo
`Registration No. 44,700
`Venable LLP
`Rockefeller Center
`1270 Avenue of the Americas
`Twenty-Fourth Floor
`New York, NY 10020
`
`
`
`CERTIFICATE OF SERVICE
`
`I hereby certify that on June 30, 2017, I caused a true and correct copy of the
`foregoing materials:
`
`• Petitioner’s Reply
`
`• Exhibit 1022
`
`to be served via:
`
`Via Electronic Mail
`
`Ernest D. Buff & Associates, LLC
`231 Somerville Road
`Bedminster, NJ 07921
`ebuff@edbuff.com
`
`Ronald Abramson
`David G. Liston
`Lewis Baach PLLC
`The Chrysler Building
`405 Lexington Avenue
`New York, NY 10174
`Ronald.Abramson@lewisbaach.com
`
`By: /Frank M. Gasparo/
`Frank M. Gasparo
`Registration No. 44,700
`Venable LLP
`Rockefeller Center
`1270 Avenue of the Americas
`Twenty-Fourth Floor
`New York, NY 10020
`
`
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
