`
`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 B2
`
`
`
`_______________________________________
`
`Inter Partes Review Case No. IPR2016-01238
`_______________________________________
`
`
`
`PATENT OWNER RESPONSE
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`TABLE OF CONTENTS
`
`I.
`
`II.
`
`SUMMARY OF CARMEL ........................................................................... 1
`
`DISCUSSION ................................................................................................. 3
`
`a)Carmel does not disclose sending media data elements to a user
`
`system responsive to requests therefrom, at a rate more rapid
`
`than the rate at which the streaming media is played back by a
`
`user ........................................................................................................ 3
`
`b)The uncontroverted evidence shows that claim 15 is not
`
`anticipated by Carmel ....................................................................... 14
`
`III. CONCLUSION ............................................................................................ 17
`
`
`
`
`
`
`
`i
`
`
`
`
`
`EXHIBIT LIST
`
`Case IPR2016-01238
`Patent 8,122,141
`
`Exhibit
`
`Number
`
`Description
`
`2001
`
`2002
`
`2003
`
`2101
`
`Declaration of Prof. Mung Chiang (“Chiang Decl.”)
`
`Curriculum vitae of Prof. Mung Chiang
`
`March 17, 2017, Deposition of Nathaniel Polish, Ph.D.
`
`(“Polish Dep.”)
`
`Declaration of Dr. Nathaniel Polish, Ph. D., In Support of
`
`Defendant Apple Inc.’s Motion for Summary Judgment of
`
`Non-Infringement, Case No. 5:11-cv-01079-PSG (N.D. Ca.,
`
`filed Feb. 14, 2014)
`
`
`
`
`
`ii
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`Patent Owner WAG Acquisition, L.L.C. (“Patent Owner” or “WAG”)
`
`respectfully submits this Response in accordance with 37 C.F.R. § 42.120,
`
`responding to the Petition for inter partes review (the “Petition”) filed by
`
`Webpower, Inc. (“Petitioner”) regarding claims 10–23 of U.S. Patent No.
`
`8,122,141 (Ex. 1001) (the “’141 Patent”). Accompanying this response is the
`
`declaration of Prof. Mung Chiang of Princeton University, who addresses certain
`
`technical issues in connection herewith (Ex. 2001) (“Chiang Decl.”).
`
`I.
`
`SUMMARY OF CARMEL
`
`U.S. Patent No. 6,389,473 to Carmel et al. (Ex. 1003) (“Carmel”) discloses a
`
`system in which a source computer provides live or prerecorded media to a server,
`
`which then streams this media to a plurality of clients. Of particular importance is
`
`the live streaming capability of the Carmel system, which is discussed in the
`
`following. Figs. 2 and 3A from Carmel are reproduced below:
`
`
`
`
`
`As disclosed in Carmel, transmitting computer 34 receives audio-visual
`
`input from input device 22 and converts this input into a data stream 40 comprising
`
`a plurality of multimedia sequences or slices 42-48. (Carmel, 6:24-35.) Each slice
`
`
`
`42-48 contains a segment of audio-visual data corresponding to a respective time
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`interval T1-T4 and is stored in a respective file. (Id., 7:23-28.) Transmitting
`
`computer 34 uploads the files of data stream 40 to server 36. (Id., 6:50-52.) Server
`
`36 also includes an index file 50 (not shown in the figures above) that indicates the
`
`most recent slice 42-48 (by slice number) that has been uploaded to server 36. (Id.,
`
`7:63-64.)
`
`Carmel discloses that the steps used by transmitting computer 34 to upload
`
`data stream 40 to server 36 are substantially identical to those used by server 36 to
`
`send data stream 40 to client computers 30. (See id., 10:35-37; 13:29-34.). With
`
`respect to transmitting computer 34, when uploading data stream 40, transmitting
`
`computer 34 opens a plurality of links with server 36 and sends respective slices
`
`42-48 in successive alternation down the links. (Id., 9:13-30.) Carmel notes that,
`
`“[t]he bandwidth open for transmission between computer 34 and server 36 is
`
`effectively roughly equal to a sum of the bandwidths of the plurality of open
`
`links.” (Id., 9:37-39.) Transmitting computer 34 monitors each link and adjusts the
`
`duration and compression ratio of slices 42-48 so that that the upload time of each
`
`slice 42-48 is substantially equal to the time duration T1-T4 of that slice 42-48, thus
`
`fully maximizing the entire available bandwidth. (See id., 13:7-22, 11:44-47,
`
`11:52-54.)
`
`
`
`2
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`A similar process is performed when server 36 sends stream data stream 40
`
`to client computers 30. However, in addition, client computer 30 can read index
`
`file 50 and determine from which slice 42-48 in stream 40 to receiving the data
`
`stream 40. (See id., 8:1-9.)
`
`II. DISCUSSION
`
`a)
`
`Carmel does not disclose sending media data elements to a
`
`user system responsive to requests therefrom, at a rate more
`
`rapid than the rate at which the streaming media is played back
`
`by a user
`
`In its Institution decision, the Board noted that Petitioner relied upon column
`
`2, lines 51-59 of Carmel as allegedly disclosing the limitation “send[ing] 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,” recited in
`
`claim 10. (See Institution of Inter Partes Review 20-21) (Paper 7) (“Institution
`
`Decision”.)
`
`Carmel states at column 2, lines 56-59, that: “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.” This is the
`
`exact language that Petitioner relied upon, and which the Board cited in granting
`
`institution with regard to claim 10.
`
`
`
`3
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`Yet the Petition fails to explain what Carmel means by “the data rate” in this
`
`disclosure. This language appears only in the claim chart of the Petition. The
`
`Petition does not explain or provide any basis as to why the words “data rate”
`
`necessarily refer to the rate at which the server in Carmel sends individual slices
`
`42-48 to a user system. Moreover, the declaration of Petitioner’s expert, Dr. Polish
`
`(Ex. 1005), does not address this issue at all and, indeed, does not even cite or
`
`quote the language at column 2, lines 51-59 of Carmel. Rather, Dr. Polish appears
`
`to steer away from this issue, stating only in a conclusory manner that he “agrees”
`
`with the Petition, without addressing the specifics and thus adds nothing to the
`
`substance of the Petition. (See Declaration of Dr. Nathaniel Polish in Support of
`
`Inter Partes Review of U.S. Patent 8,122,141, ¶ 55) (Ex. 1005) (“Polish Decl.”.)
`
`Patent Owner thus asserts that Carmel lacks any explicit teaching “to send[]
`
`media data elements to a user system responsive to requests therefrom, at a rate
`
`more rapid than the rate at which the streaming media is played back by a user,” as
`
`recited in claim 10, and that the submission of Petitioner’s expert is entirely silent
`
`on this issue and lends no support to it.
`
`Moreover, the Declaration of Prof. Chiang submitted herewith (Ex. 2001)
`
`expressly and authoritatively states that Carmel fails to contain any express - or
`
`inherent - teaching “to send[] media data elements to a user system responsive to
`
`requests therefrom, at a rate more rapid than the rate at which the streaming media
`
`
`
`4
`
`
`
`is played back by a user”. (See Chiang Decl. ¶¶ 11-23.) As explained by Prof.
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`Chiang, although the cited language in column 2 of Carmel concerning the “data
`
`rate” is not consistently defined, in this context it is actually addressing the
`
`bandwidth of the available transmission channel and not the rate at which
`
`individual media data elements are sent. (See Chiang Decl. ¶¶ 16-17.) In fact,
`
`Carmel actually teaches to the contrary of what Petitioner asserts, and rather than
`
`sending slices 42-48 at a rate faster than the playback rate, Carmel instead seeks to
`
`regulate the sending of the individual slices 42-48, adaptively varying their
`
`encoding so as to maintain transmission of each slice at about playback rate. (See
`
`Chiang Decl. ¶¶ 19-20.) Because of Dr. Polish’s complete silence on the subject,
`
`Prof. Chiang’s account of Carmel is uncontroverted on the record.
`
`The specific excerpt of column 2 from Carmel, in full context, is as follows:
`
`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.
`
`
`
`
`
`5
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`In some of these preferred embodiments, the transmitting computer
`
`and/or the clients each open a plurality of FTP or HTTP links,
`
`respectively, with the network server. The slices are transferred over
`
`different ones of the links in alternation. Although typically none of
`
`the plurality of links has sufficient bandwidth on its own to convey the
`
`entire data stream in real time, the combined bandwidths of the
`
`plurality of links are generally sufficient for this purpose.
`
`(Carmel, 2:50-67.)
`
`In the first paragraph excerpted above, the statement of Carmel that “the data
`
`rate should be generally equal to or faster than the rate at which the data are
`
`generated at the transmitting computer” is discussing the data rate available from
`
`the total bandwidth of the channel(s). The language does not say that each slice 42-
`
`48 is, or even that it may be, transmitted at a rate greater than the playback rate for
`
`that slice. Rather, the term “data rate” in this sentence, when read in context of the
`
`disclosure, refers to the total bandwidth of the link or links, and not to how fast any
`
`given slice is sent to a client computer 30. (See Chiang Decl. ¶¶ 16-17.)
`
`This interpretation is clarified in the very next paragraph, also quoted above.
`
`As set forth in that paragraph, Carmel contemplates utilizing multiple links to
`
`accommodate the entirety of the stream, even if each individual link has a
`
`bandwidth less than that of the stream. (See id., 9:31-47; 10:35-37; see also Chiang
`
`Decl. ¶ 21.) The “data rate” in the first paragraph is thus only referring to the total
`
`transmitting bandwidth of the channels and not to whether or not each slice 42-48
`
`
`
`6
`
`
`
`is transmitted at a rate greater than the playback rate for that slice 42-48. (See
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`Chiang Decl. ¶¶ 16-17.)
`
`Indeed, far from teaching that each slice should be transmitted at a rate
`
`greater than the playback rate, as would be required of claim 10, Carmel teaches
`
`regulating the encoding and transmission speed of each slice so as to maintain
`
`transmission at the playback rate. Carmel teaches that, should there be any excess
`
`capacity, the time length of the slices, the encoding, or both is changed to adapt to
`
`and match the individual capacity of each link. (See Carmel, 11:44-47; 52-54;
`
`13:7-15; Chiang Decl. ¶¶ 13-15, 20-21.) Consequently, in Carmel each link is
`
`maximally used, without any “gaps” between successive transmissions of slices
`
`42-48. (See Chiang Decl. ¶¶ 18-19.) Carmel does not teach, either expressly or
`
`inherently, “caus[ing] the server to send media data elements to the user system
`
`responsive to said requests, at a rate more rapid than the rate at which said
`
`streaming media is played back by a user,” since transmitting slices in such a
`
`manner would create “gaps” between each of the slices. (See Chiang Decl. ¶ 20;
`
`see also Polish Dep. 47:7-48:9.) Instead, Carmel teaches adjusting the timing and
`
`encoding of slices so as to maximize usage of the total available bandwidth,
`
`thereby removing any inter-slice “gaps,” and thus to maintain transmission of
`
`slices at about the playback rate. (See Chiang Decl. ¶¶ 20-21.)
`
`
`
`7
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`Notably, the Petition fails to show where Carmel discloses transmitting
`
`slices 42-48 at a rate more rapid than the playback rate. Rather than providing any
`
`analysis at all, the Petition simply presents various excerpts from Carmel. (See
`
`Petition 56-57 and 65.) Yet, far from teaching the sending of media data elements
`
`at a rate faster than the playback rate, these excerpts from Carmel teach sending
`
`them at a rate equal to the playback rate. (See Chiang Decl. ¶¶ 18-21.)1 For
`
`example, in addition to the above-noted excerpt from column 2 of Carmel, the
`
`Petition also presents, without any analysis, excerpts from column 7, column 10,
`
`column 11 and Figure 6B of Carmel – all of which teach adjusting the timing and
`
`encoding of slices 42-48 to maximize usage of the overall transmitting bandwidth.
`
`(See Chiang Decl. ¶¶ 14, 21.) Indeed, this feature of Carmel (in contradistinction to
`
`that of claim 10) is best on display in Figure 6B (see Petition 57; Carmel, Fig. 6B),
`
`which is a flow chart clearly illustrating the adjusting of encoding levels so that
`
`each slice exactly fits within the available bandwidth of its channel. (See also
`
`Chiang Decl. ¶¶ 14, 21.) Because each slice maximally uses the available
`
`
`1 In fact, Carmel teaches that when multiple communication links are used to
`
`transmit the media stream 40, the actual transmission rate on each link will be less
`
`than the playback rate. But nowhere in Carmel is there an express or inherent
`
`teaching to transmit individual slices faster than the playback rate.
`
`
`
`8
`
`
`
`bandwidth of its channel, and as Carmel anticipates one or more channels, each
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`slice 42-48 in Carmel is sent at a rate that is, at best, equal to the playback rate and,
`
`in the preferred embodiments of Carmel, at a rate less than the playback rate, and
`
`in either case with no gaps between slices 42-48. (See Carmel, 2:50-67; Chiang
`
`Decl. ¶ 20.) Remarkably, Petitioner puts this flow chart of Fig. 6B into its own
`
`claim chart (Petition 57), despite the fact that instead of supporting the alleged
`
`disclosure of the claimed limitation, it supports only the opposite.
`
`The declaration of Dr. Polish adds nothing to this analysis, doing little more
`
`than to incorporate by reference the arguments presented in the Petition. (See
`
`Polish Dep. ¶ 55.)
`
`Moreover, not only did Dr. Polish steer away from even addressing this
`
`issue in his Declaration, he has a prior inconsistent statement.
`
`Dr. Polish was previously retained by Apple Inc. as an expert on
`
`infringement and validity when Apple was accused of infringing Carmel, the very
`
`reference at issue here as prior art. In his prior testimony defending Apple against
`
`infringement, Dr. Polish testified that Carmel teaches sending the slices without
`
`any gaps, and on this basis found that Apple could not infringe. (See Declaration of
`
`Dr. Nathaniel Polish, Ph. D., in Support of Defendant Apple Inc.’s Motion for
`
`Summary Judgment of Non-Infringement, Case No. 11-CV-01079 PSG, ¶ 11)
`
`(N.D. Ca., filed Feb. 14, 2014) (Ex. 2101) (“The [Carmel] patent also places
`
`
`
`9
`
`
`
`significant emphasis on maintaining a generally equal relationship between the
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`data rate of the stream and the upload rate (in fact, this is a limitation for all of the
`
`claims), including describing adjusting the compression level to ‘adjust the data
`
`streaming rate to the available bandwidth.’”) (“Apple Decl.”)
`
`In his deposition, Dr. Polish authenticated his declaration in the Apple case
`
`and stated that “the substantive opinions that I had in the [Apple] case did not
`
`change relative to what's in this document [Ex. 2101].” (Polish Dep., 52:20-25.)
`
`Apple did not infringe, according to Dr. Polish, because the claims of Carmel,
`
`interpreted by Dr. Polish with considerable reliance on the disclosure of its
`
`specification did not, according to him, cover transmission if individual slices are
`
`played faster than the playback rate. In particular, Dr. Polish found that Apple did
`
`not infringe because it did not transmit “files from the transmitting computer to the
`
`server at an upload rate generally equal to the data rate of the stream.” (See Apple
`
`Decl. ¶¶ 10-11.) In the view of Dr. Polish, “upload rate” meant the rate of actual
`
`transmitting, not a rate also based on gaps between files when no uploading occurs.
`
`(See Apple Decl. ¶ 11.) Dr. Polish also noted the “significant emphasis on
`
`maintaining a generally equal relationship between the data rate of the stream and
`
`the upload rate . . . including describing adjusting the compression level to ‘adjust
`
`the data streaming rate to the available bandwidth.’” (Id.)
`
`
`
`10
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`Since Carmel discloses that uploading to server 36 and downloading to
`
`clients 30 are performed in substantially the same way (see Carmel, 13:31-35),
`
`these arguments made by Dr. Polish concerning uploading are equally applicable
`
`to downloading. (See also Chiang Decl. ¶ 12.)
`
`In sum, Dr. Polish confirms through his Apple Declaration that Carmel
`
`contemplates upload transmissions at an upload rate “generally equal” to the
`
`playback rate, and that the Carmel specification does not support an interpretation
`
`under which slices are sent faster than the playback rate.
`
`As Prof. Chiang explains, Dr. Polish’s prior declaration on behalf of Apple
`
`cannot be reconciled with the Petitioner’s assertions regarding the alleged
`
`teachings of Carmel. (See Chiang Decl. ¶ 23.) Prof. Chiang states that he agrees
`
`with Dr. Polish’s analysis in Dr. Polish’s Apple Declaration. (See id.) Prof. Chiang
`
`further explains that Carmel treats download rates throughout equivalently to
`
`upload rates, and that by the same reasoning articulated by Dr. Polish with respect
`
`to upload, Carmel also cannot be read to support an interpretation under which
`
`slices are sent from the server to the client more rapidly than the playback rate.
`
`(See Chiang Decl. ¶ 12.) Polish’s declaration in the Apple case is therefore
`
`fundamentally inconsistent with Petitioner’s position here and it is thus
`
`uncontroverted that that Carmel fails to teach “send[ing] media data elements to
`
`the user system responsive to said requests, at a rate more rapid than the rate at
`
`
`
`11
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`which said streaming media is
`
`played back by a user,” as recited in claim 10.
`
`This understanding is consistent with, and necessitated by, the functioning of
`
`the Carmel system. Nowhere does Carmel teach or suggest waiting between slices
`
`42-48 before sending the next slice, as would be required if Carmel were
`
`transmitting each slice at a rate faster than the playback rate for that slice. (See
`
`Chiang Decl. ¶ 20.) In fact, Fig. 6B of Carmel teaches to the contrary, insofar as it
`
`discloses a tight loop without any pauses, adjusting encoding levels on the fly to
`
`maximize bandwidth usage and thereby regulate transmission so that each slice is
`
`sent at about (or, in the case of multiple links, less than) the playback rate. (See
`
`Chiang Decl. ¶¶ 14, 20-21.) Absent signaling between the client and server, which
`
`Carmel does not disclose, the only way to prevent buffer overflow in such
`
`circumstances is to ensure that the playout rate of clients 30 in Carmel is
`
`substantially equal to the total rate at which the clients receive the multimedia data.
`
`(See Chiang Decl. ¶ 22.)
`
`Even Dr. Polish agrees that a PHOSITA would recognize that unregulated
`
`filling of client buffers would lead to overflow if the download rate were greater
`
`than the playback rate:
`
`Q. If there were no gaps between the arrival of those elements, and
`
`they were arriving at the maximum rate of the channel, and the buffer
`
`was being consumed at the encoding rate of the media, that would be
`
`
`
`12
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`a situation in which the buffer is being filled faster than it's being
`
`consumed.
`
`A. Yes, certainly it's true that if it is being downloaded at the channel
`
`rate, and consumed at the playback rate, that the buffer's contents
`
`would grow.
`
`Q. And if that continues indefinitely, the buffer would overflow;
`
`correct?
`
`A. If it continued indefinitely for a finite buffer, the buffer would
`
`overflow.
`
`(Polish Dep., 43:1-18.)
`
`A PHOSITA would thus understand that, to avoid such overflow, and in
`
`view of the fact that Carmel contemplates the use of one or more transmission
`
`channels, the transmission rate of the slices 42-48 in Carmel must be substantially
`
`equal to the playback rate for those slices 42-48, in the case of a single link, and
`
`less than the playback rate of each slice when multiple links are used. (See Chiang
`
`Decl. ¶ 22.)
`
`Since the uncontroverted evidence is that Carmel does not teach or suggest
`
`“send[ing] 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
`
`
`
`13
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`user,” as recited in claim 10, Carmel does not anticipate claim 10.2 Dependent
`
`
`
`claims 11-18 are thus also patentable over Carmel, or any combination thereof, for
`
`at least this reason as well.
`
`b)
`
`The uncontroverted evidence shows that claim 15 is not
`
`anticipated by Carmel
`
`In addition to the reasons set forth above with respect to claim 10, claim 15
`
`is further patentable over Carmel because Petitioner has offered no evidence that
`
`server 36 of Carmel does not maintain a pointer into a buffer for each client 30,
`
`and a PHOSITA would recognize that quite the opposite must be the case.
`
`Carmel contemplates that server 36 can multicast stream 40 to multiple
`
`clients 30. In order to do so, Carmel would need to use a pointer to keep track of
`
`which slice 42-48 to next multicast to clients 30. (See Chiang Decl. ¶ 27.) In other
`
`embodiments, server 36 delivers streams 40 to clients 30 on an individual basis. In
`
`such embodiments of Carmel, client computers 30 may use index file 50 to
`
`
`2 Indeed, a PHOSITA would understand Carmel to teach the opposite - that in
`
`Carmel’s preferred embodiment of using multiple links, the transmission rate of
`
`each slice 42-48 must be less than the playback rate. Hence, Carmel not only does
`
`not disclose every feature of claim 10, but also teaches away from claim 10 and
`
`thus cannot defeat the patentability of claim 10 by either anticipation or
`
`obviousness.
`
`
`
`14
`
`
`
`determine what slices 42-48 are available for download. In particular, Carmel
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`discloses:
`
`When one of computers 30 reads index file 50 and begins to download
`
`stream 40, indicator 58 preferably marks the most recent slice, as
`
`shown in FIG. 3C. This is the point at which the download will begin,
`
`unless the user of the computer chooses otherwise. If the user wishes
`
`to begin the download at an earlier point, he may move indicator 58 to
`
`the left along bar 56 to that point, preferably using a mouse or other
`
`pointing device, as is known in the art. Indicator 58 may be moved
`
`back and forth along bar 56 to jump back and forth along stream 40.
`
`(Carmel, 8:31-41.)
`
`In other words, Carmel discloses a “seek” function, after which server 36
`
`then streams slices 42-48 from the requested “seek” location. (See Chiang Decl.
`
`¶¶ 26-27.) This is also the understanding of Dr. Polish:
`
`Q. So instead of streaming the exact same slice to all recipients as a
`
`multicast, this, what's described in that sentence, allows each user to
`
`start streaming from a specified point; is that right?
`
`A. Yes. So in what you just described, at the top of column 8, is the
`
`client computer reading an index file which contains information
`
`about the slices including their numbers, and then the client computer
`
`starts from the specified place as compared to later in that paragraph
`
`where you could simply connect up to a multicast and receive what
`
`slices are being sent.
`
`
`
`15
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`(Polish Dep., 26:8-23.)
`
`According to claim 15, the “server does not maintain a pointer into a buffer
`
`established within said server, for each said user.” (’141 Patent, 14:38-40.) The
`
`Petition, however, provides a wholly conclusory argument as to how Carmel
`
`teaches this feature, merely stating “Carmel discloses a system that operates
`
`without reference to pointers in a server-side buffer. In Carmel, the client 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.”
`
`(Petition 62-63) (internal citations omitted.) Dr. Polish’s declaration adds nothing
`
`to this. (See Polish Decl. ¶ 58.)
`
`While it is true that a user can “seek” to a specific slice 42-48 by number,
`
`and that Carmel’s server 36 responds accordingly, nothing in Carmel teaches or
`
`suggests that thereafter server 36 streams slices 42-48 without maintaining a
`
`pointer into a buffer established within server 36, for each client 30. Certainly,
`
`neither the Petition nor Dr. Polish point to any such disclosure. To the contrary, a
`
`PHOSITA would understand that server 36 of Carmel necessarily uses pointers to
`
`keep track of which slice to send next. (See Chiang Decl. ¶ 27.) In particular,
`
`Carmel discloses:
`
`Files 42, 44, 46, 48, etc., in stream 40 are transmitted respectively
`
`over links 60, 62, 64, 66 and 68 in successive alternation, so that at
`
`any given time (except at the very beginning of the sequence) up to
`
`
`
`16
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`five files are transmitted in parallel. Alternatively, more than five
`
`links may be opened, so that more than five files may accordingly be
`
`transmitted in parallel.
`
`(Carmel, 9:23-30.)
`
`A PHOSITA would recognize that in order to stream slices 42-48 over links
`
`60-68 “in successive alternation,” server 36 would need to keep track of which
`
`slices 42-48 have been sent, and which slices 42-48 are to be sent next, on
`
`respective links 60-68, and would have to use pointers to do so. (See Chiang Decl.
`
`¶¶ 24-27.) Petitioner has proffered no evidence to the contrary, and thus claim 15 is
`
`patentable over Carmel.
`
`III. CONCLUSION
`
`Because substantial evidence shows that Carmel fails to teach or suggest
`
`certain features of claim 10, Carmel does not anticipate claim 10. Dependent
`
`claims 11-18 are thus also patentable over Carmel, alone or in combination with
`
`any of the other cited references, for at least this reason as well. In addition, claim
`
`15 has further features supporting patentability. At least claims 10-18 should thus
`
`be found patentable.
`
`
`
`
`
`17
`
`
`
` Dated: March 30, 2017
`
`Respectfully submitted,
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`
`
`/Ronald Abramson/
`Ronald Abramson
`(Attorney for Patent Owner)
`Reg. No. 34,762
`212-822-0163
`
`
`
`18
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`CERTIFICATION UNDER 37 CFR § 42.24(d)
`
`Under the provisions of 37 CFR § 42.24(d), the undersigned hereby certifies
`
`that the word count for the foregoing Patent Owner Response totals 4,092, which is
`
`less than the 14,000 allowed under 37 CFR §§ 42.24(a)(1)(i); 42.24(b)(2).
`
`
`
`Dated: March 30, 2017
`
`
`
`
`
`
`
`/Ronald Abramson/
`Ronald Abramson
`(Attorney for Patent Owner)
`Reg. No. 34,762
`212-822-0163
`
`
`
`
`
`Case IPR2016-01238
`Patent 8,122,141
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 C.F.R. § 42.6(e), the undersigned hereby certifies that on
`
`March 30, 2017, a complete and entire copy of this Patent Owner Response was
`
`provided to the Petitioner by filing through the PTAB E2E System and via email,
`
`to FMGasparo@Venable.com and JLFalkler@Venable.com as authorized in
`
`Petitioner’s mandatory notices.
`
`
`
`Dated: March 30, 2017
`
`
`
`/Ronald Abramson/
`Ronald Abramson
`(Attorney for Patent Owner)
`Reg. No. 34,762
`212-822-0163
`
`
`
`2
`
`
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
