throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________
`
`WEBPOWER, INC.,
`Petitioner,
`
`V.
`WAG ACQUISITION, LLC
`Patent Owner.
`_____________
`
`Case IPR2016-01238
`Patent 8,122,141 B2
`_____________
`
`Record of Oral Hearing
`Held: September 25, 2017
`_____________
`
`
`Before TREVOR M. JEFFERSON, BRIAN J. McNAMARA, and
`PATRICK M. BOUCHER, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONERS:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`FRANK M. GASPARO, ESQ.
`JONATHAN L. FALKLER, ESQ.
`VENABLE, LLP
`Rockefeller Center
`1270 Avenue of the Americas
`New York, New York 10020
`(212) 370-6273
`E-mail: fgasparo@venable.com
`jlfalkler@venable.com
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`
`
`
`
`
`
`
`
`
`
`RONALD ABRAMSON, ESQ.
`ARI J. JAFFESS, ESQ.
`LEWIS, BAACH, KAUFMANN, MIDDLEMISS, PLLC
`The Chrysler Building
`405 Lexington Avenue
`62nd Floor
`New York, New York 10174
`(212) 822-0163
`E-mail: ronald.abramson@lbkmlaw.com
`ari.jaffess@lbkmlaw.com
`
`The above-entitled matter came on for hearing on Monday, September
`25, 2017, commencing at the U.S. Patent and Trademark Office, 600 Dulany
`Street, Alexandria, Virginia.
`
`
`
`
`
`
`
`
`
`
`2
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`
`
`P R O C E E D I N G S
`JUDGE JEFFERSON: Good afternoon. We're here for WebPower
`
`and other Petitioners v. WAG Acquisitions, for Case Nos. IPR2016-01238
`and IPR2016-01239.
`
`We maintain, as the Order said, separate transcripts for these cases, so
`we'll have to take a brief intermission at the end of the first one, and I'll ask
`the counsel to make appearances in both. So we'll start now with
`appearances for Petitioner.
`
`MR. GASPARO: Good afternoon, Your Honor. Frank Gasparo with
`Venable, counsel for Petitioner WebPower, Inc. and also various joint
`parties.
`
`JUDGE JEFFERSON: And for Patent Owner?
`
`MR. ABRAMSON: Yes. Ronald Abramson from the firm of Lewis,
`Baach, Kaufmann, Middlemiss, PLLC, for the Patent Owner, WAG
`Acquisition, Inc. And with me is Ari Jaffess from my firm.
`
`JUDGE JEFFERSON: Thank you. With the first case, which is
`IPR2016-01238, each party will have 40 minutes to make and present its
`argument. Petitioner may reserve rebuttal time for its case and let me know
`at the outset. We'll do our best to keep time up here. Make sure that Judge
`Boucher can hear us remotely. Can --
`
`JUDGE BOUCHER: Yes, I can hear you fine.
`
`JUDGE JEFFERSON: Very good. And obviously with the remote
`Judge, any demonstratives you use or any documents you refer to, you
`should refer to by exhibit number or page number, as appropriate.
`
`Counsel for Petitioner can begin when ready for Case 01238.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`3
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`MR. GASPARO: Thank you, Your Honor. And I should also
`
`mention I'm joined by my colleague, John Falkler, who may or may not say
`something on behalf of Petitioner.
`
`JUDGE JEFFERSON: Understood. Would you like to reserve any
`rebuttal time?
`
`MR. GASPARO: I would. I would, Your Honor.
`JUDGE JEFFERSON: Okay. How much?
`MR. GASPARO: It could be as much as 20 minutes, but at least 10
`
`minutes.
`
`JUDGE JEFFERSON: Okay. I’ll set a warning for you at 20.
`
`MR. GASPARO: Great. Thank you.
`
`JUDGE JEFFERSON: You may begin when ready.
`
` OPENING ARGUMENT
`
`BY MR. GASPARO: So, Your Honors, we're here today on --
`regarding Claims 10 to 23 of what I'll refer to as the 141 Patent. Those are
`the claims that the proceeding was instituted on. We thought it would be
`helpful to sort of summarize what we believe to be uncontested as well as
`contested.
`
`First, what we believe to be uncontested is the invalidity of Claims 19
`to 23, as well as the teachings of Carmel, with the exception of two claim
`elements. We believe those claims and the claim elements of the other
`claims are -- those arguments were waived. They were not addressed by the
`Patent Owner in its response.
`
`So the two claim limitations that we will be talking about today are
`found in Claim 10 and Claim 15. Specifically, the limitation in Claim 10 is
`whether Carmel teaches "send media data elements to the user system
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`4
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`responsive to said requests at a rate more rapid than the rate at which said
`streaming media is played back by a user."
`
`And then in Claim 15, whether Carmel teaches the limitation "said
`server does not maintain a pointer into a buffer established within said server
`for each said user."
`
`On Slide No. 3 we have reproduced Claim 10. As can be seen, it's a
`server claim, and the limitation that we will be talking about today is found
`at the end of the claim, and we emphasize the language that I recently just
`read into the record.
`
`The next slide, Slide No. 4, we set forth two figures from Carmel.
`The one on the left-hand side is the client server architecture of Carmel, and
`the illustration on the right is what's referred to as the structure of a data
`stream. And as can be seen, it's broken into slices, and each slice has a time
`interval associated with it.
`
`So on Slide No. 5, just to jump into things, we set forth one instance
`where Carmel teaches the limitation "send media data elements to the user
`system responsive to said request at a rate more rapid than the rate at which
`said streaming media is played back by a user."
`
`And you'll see there, there is a -- that is some text from Carmel, and
`we've emphasized what we believe to be some important language, and I'd
`like to read that text.
`
`"In some preferred embodiments of the invention -- of the present
`invention," I'm sorry, "the transmitting computer and the clients monitor the
`uploading and downloading of data to and from the server, respectfully, 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
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`5
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`comprises multimedia data, the data rates should be generally equal to or
`faster than the rate at which the data are generated at the transmitting
`computer."
`
`Following up on that slide, on Slide No. 6, we --
`
`JUDGE BOUCHER: Actually, could we just stop at Slide No. 5 for
`just a moment?
`
`MR. GASPARO: Yes, sir.
`
`JUDGE BOUCHER: My understanding is -- so am I correct that
`there's no dispute between the parties as to what "rate" means when used in
`the claim; is that right?
`
`MR. GASPARO: That's my understanding, yes. We are both
`proposing the plain and ordinary meaning under the broadest reasonable
`construction, correct.
`
`JUDGE BOUCHER: Okay. But the parties seem to disagree as to
`what "data rate" means in this passage that you've reproduced on Claim 5
`from -- on Slide No. 5 from Carmel. Could you address that disagreement
`and how that's being understood?
`
`MR. GASPARO: Yes. I'd like to start with how we believe this
`passage should be interpreted.
`
`So the first -- there's two sentences. The first sentence refers to
`determining "the amount of time required to convey each slice and to verify
`that the slices are conveyed at a sufficient rate." And the next sentence
`continues "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."
`
`So we read that, that we -- our belief is that "the data rate" in the
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`6
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`second sentence is referring back to the amount of time it takes to convey a
`slice and to confirm that it's a sufficient rate.
`
`Our understanding of the Patent Owner's position is that "the data
`rate" refers to the bandwidth of the respective channel that the data is
`traveling on.
`
`Did that answer your question, Your Honor?
`
`JUDGE BOUCHER: I guess. It doesn't really clarify things for me.
`Maybe my questions are better posed to the Patent Owner. Why don't you
`continue for now, please?
`
`MR. GASPARO: Okay. So following up on that slide, Carmel
`teaches when its system will send multimedia data faster than the playback
`rate, and specifically it will send data faster than the playback rate to account
`for lag. And here is a teaching from Carmel that sort of sets up what we'll
`explain next are the two ways that Carmel teaches to catch up from lag.
`
`And here Carmel reads, "Computer monitors the time codes as file is
`transmitted and clients similarly monitor the time codes as the file is
`received, in order to ensure that the transmission or reception is keeping up
`with the input of the data to the computer. In the event that a lag is detected,
`steps are taken to increase the data transmission or reception rate as
`described further herein below." And you'll see on the next two slides we set
`forth what those two ways are for -- once lag is detected.
`
`On Slide No. 7, the first way taught by Carmel to address lag and
`increase the data rate is to increase the overall download rate by opening
`additional download links. And Carmel teaches us that, "Further preferably,
`the client compares the times stamped in the data stream to a local real-time
`clock and, if it determines that there is a significant lag in the time codes
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`7
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`relative to the real-time clock, opens additional links with server in order to
`increase the overall data rate."
`
`On the next slide we put together a demonstrative to help explain what
`Carmel teaches. What we're illustrating here on the left of Slide No. 8 is that
`you have one second of video that's taking two seconds to get to the client,
`so there's a lag. It's getting there too slow.
`
`So what Carmel teaches us is that you open up additional links, and by
`doing so -- for instance, here we opened up three additional links. By doing
`so, the client now will get three seconds of video in two seconds and
`therefore the result is that the overall data rate has been increased.
`
`JUDGE BOUCHER: But the data rate for each of those links would
`still be below the playback rate; is that right?
`
`MR. GASPARO: That's correct, Your Honor. And the second
`embodiment in Carmel addresses increasing the rate on each channel, on
`each link.
`
`JUDGE BOUCHER: Okay. Is it true that Carmel -- I mean, this
`diagram you have on the left-hand side of it, that's an accurate depiction of
`what Carmel has? Carmel does not limit its embodiments to instances where
`there are multiple links? Carmel includes embodiments where there's only a
`single link?
`
`MR. GASPARO: That's correct, Your Honor.
`
`JUDGE BOUCHER: Okay. Thank you.
`
`MR. GASPARO: And I just -- before I get off this slide, we believe
`that, under the broadest reasonable construction, the claim limitation that's
`shown at the top of the slide is broad enough to cover increasing the
`playback rate -- sorry, increasing the data rate beyond the playback rate by
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`8
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`having multiple links. The claim doesn't recite sending each media data
`element along the link to the user system. It's much broader than that. So
`we believe this embodiment of Carmel reads on the limitation of the 141
`patent.
`
`But to address Your Honor's specific question about what's happening
`on each link, Carmel teaches us there is a second way to increase the
`download rate, by decreasing the quality of each of the slices. And Carmel
`states, "Periodically client makes an assessment of the rate of data transfer
`over the link from the server and, if necessary, changes the quality level
`accordingly. For example, if the rate is low such that timestamps indicate
`that the slices need to be played as fast as or faster than they are being
`received, the client will preferably select a lower quality level if one is
`available."
`
`So what that tells us, what that teaches, is that sending data at the
`playback rate is not good enough. It's considered -- Carmel considers that a
`low rate. And we created a demonstrative on the next slide, on Slide No. 10,
`to illustrate that embodiment of Carmel.
`
`And like the first embodiment, we've got one second of video. It's
`taking two seconds to get there. It's too slow. So what Carmel teaches us is
`let's decrease the size of that one second of video.
`
`And here we've created a hypothetical where -- let's say that one
`second of video is two megs. So we are -- Carmel tells us let's decrease the
`size. So we're decreasing it 75 percent, to about -- so to 0.5 megabytes. And
`because we've done that, that same one second of video, because it's smaller,
`takes 75 percent -- it gets to the client 75 percent faster, so in 0.5 seconds.
`So that one second of video which takes one second to play back was sent
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`9
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`faster than that. It was sent in 0.5 seconds.
`
`I'd like to next jump to some of Patent Owner's arguments and address
`those at this point, although I may get back to some of these during my
`rebuttal.
`
`The Patent Owner argues in its response --
`
`JUDGE BOUCHER: Actually, before you do that --
`
`MR. GASPARO: Yes?
`
`JUDGE BOUCHER: -- there's a question I wanted to get to, and
`maybe this is a good point to do it. But the Patent Owner submitted a
`declaration from Dr. Polish in the Apple litigation. And I know you
`objected to that at Dr. Polish's deposition, but you never filed a motion to
`exclude. Do you have a position on what we should be doing with that
`declaration?
`
`MR. GASPARO: I mean, we did not file a motion to exclude. We --
`our position is that it should carry very little, if any, weight. It was an
`unsigned declaration. Dr. Polish, during his cross examination, was unable
`to verify that it was a final version.
`
`Even assuming it's a final version, which we're not sure if it is, it's -- it
`was a non-infringement opinion looking at very specific claim language in
`the Carmel patent, and Dr. Polish was opining on whether his client, Apple,
`infringed that language. His testimony or his opinions in that declaration
`cannot be -- should not be viewed as limiting what else Carmel teaches that's
`relevant to this case.
`
`JUDGE BOUCHER: Okay. And I don't know what we would
`necessarily conclude from it at this point, but given that you haven't filed a
`motion to exclude and that the Patent Owner represented that it was
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`10
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`downloaded from PACER, so it would seem to be a self-authenticating
`document, doesn't that put us in a position where we should consider it?
`
`MR. GASPARO: I think, since we haven't filed a motion to exclude,
`yes, I think you should consider it. I would just hope that you assign very
`little weight, if any, to it based on what else Carmel teaches and the context
`of the declaration which dealt with Dr. Polish interpreting the scope of a
`claim in relation to non-infringement.
`
`JUDGE BOUCHER: Okay. Thank you.
`
`MR. GASPARO: You're welcome.
`
`JUDGE McNAMARA: Counsel, let me ask you a question about the
`claim itself. We're talking about Claim 10, right?
`
`MR. GASPARO: Correct.
`
`JUDGE McNAMARA: And the limitation we're talking about in
`Claim 10 is the last limitation, right? "Instructions to cause the server to send
`media data elements to the user system at a rate more rapid than the rate at
`which the streamed media is played back," right?
`
`MR. GASPARO: Yes.
`
`JUDGE McNAMARA: Okay. And you were just talking about
`Carmel disclosing, for example, sending a degraded video, for example. I
`presume that would happen by perhaps eliminating certain media data
`elements; is that right?
`
`MR. GASPARO: Not necessarily. Just different -- more compression.
`
`JUDGE McNAMARA: How does Carmel tell us to do that?
`
`MR. GASPARO: Different compression, more compression.
`
`JUDGE McNAMARA: More compression.
`
`MR. GASPARO: Yes.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`11
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`JUDGE McNAMARA: Okay. So if it compresses it in some way,
`
`shape, or form, that -- and so the last part of this claim that refers to "send
`media data elements," my question then becomes what media data elements?
`The first part of the claim says "a server for distributing streaming media via
`a data communications medium such as the internet to at least one user
`system of at least one user, the streaming media comprising a plurality of
`sequential media data elements."
`
`So now I recognize the last element of the claim here does not say
`"said media data elements," but my question that I pose to you is what other
`media data elements would they be?
`MR. GASPARO: I mean, I see the same -- I'm not seeing the same
`thing you're not seeing, which is the word "said" before "media data
`elements." So, I mean, it's broad enough to include the media data elements
`that were requested in the prior limitation. But I would say it's broad enough
`to even go beyond that. And I can't really come up with a hypothetical the
`top of my head as to what that would be, but it doesn't say "said."
`
`JUDGE McNAMARA: Well, and this is -- this may actually turn out
`to be important because I can't conceive of there being any media data
`elements other than like what happened -- it would make no sense if there
`weren't media data elements other than the sequential media data elements.
`
`But the example that you just gave me in Carmel where they use
`compression, the last limitation are media data elements, and they're not the
`same media data elements then in Carmel that they were -- that would be at
`the beginning of the claim because now they've been compressed and
`modified.
`
`MR. GASPARO: So what Carmel teaches us is that there's requests
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`12
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`on the client side for media data elements and media data elements are sent.
`And Carmel teaches us that there could be a lag at some point in the
`communication when an end user wants to -- is watching a video.
`
`Because of that lag, when subsequent media data elements are
`requested, Carmel teaches us we can do one of two things. We can open up
`additional links or we can further compress to make the media data elements
`smaller because we've got to catch up. If data is getting there too slow, it's a
`lot -- we're watching something. We don't want to have any jitter.
`
`And so, I mean, you've got -- the client first has to know that there's a
`problem, but for the data that comes after that, that's what's being sent there
`faster, the playback.
`
`JUDGE McNAMARA: Right. I'm just looking at the claim language
`about the media data elements and the sequential media data elements and
`I'm wondering if the portion of Carmel that you talked about that does some
`kind of compression isn't sending the same media data elements, sending
`them revised, compressed, that sort of thing.
`
`Now, I agree; maybe I'm implying the word "said" into the claim
`which isn't there. On the other hand, if you don't imply that, then there could
`be media data elements that don't even relate to the media that you're
`watching.
`
`So I'm just trying to get a sense as to what the claim -- what your
`version of what the claim means and whether or not that -- the media data
`elements referred to in the limitation and the sequential media data elements
`referred to and I guess a preamble at the beginning of the claim are the same
`media data elements and whether or not that would not be true in Carmel.
`
`MR. GASPARO: Yeah. I mean, Carmel is -- we think is quite
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`13
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`similar to the 141. And you've got a client that is requesting media data
`elements by serial identifiers, and Carmel teaches us that -- I mean, the first
`teaching we put up on Slide No. 5, which is Carmel's sort of general
`statement that they can send -- a server can send faster than the playback
`rate. And then Carmel goes on to talk about situations when some of those
`media data elements aren't getting there quite fast enough and so something
`has to happen to catch up.
`
`So it's all part of the same communication, if we're going to stick with
`sort of one example of watching a video. But, unfortunately, for -- I guess
`this claim doesn't say "send media data elements," but even if it did, we
`think that Carmel teaches it.
`
`JUDGE McNAMARA: Okay. It may be important too in the context
`of my understanding of -- which I'll hear more about in a few minutes -- the
`Patent Owner's position relative to the slices and what pieces of data we're
`talking about as to what the media data elements are at the end of the claim
`and the sequential media data elements are at the end. Okay. Thank you.
`
`MR. GASPARO: So one of the Patent Owner's arguments is that
`Carmel increases file sizes to use the available bandwidth and it has a sort of
`no gaps argument, which is not entirely clear to us. And because Carmel,
`according to Patent Owner, teaches trying to use up the entire bandwidth, it
`will never transmit faster than the playback.
`
`And this, Your Honor, goes to the earlier question you were asking
`about how Patent Owner interprets the data rate versus how Petitioner
`interprets the data rate. They're looking at the data rate as the bandwidth.
`
`So our response to this is twofold. I mean, first and foremost, we've
`been talking about the Carmel teaching of lag recovery, and we believe this
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`14
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`position by the Patent Owner ignores that. For instance, as I've been saying,
`it's -- Carmel teaches speeding up transmission by reducing file sizes.
`
`The second problem with this argument by the Patent Owner is you'll
`see -- I'm sure you saw in their response they talk about this adjustment of
`increasing file sizes to use up the available bandwidth. But that's only
`performed after a period where transmission was faster than playback. In
`other words, the Patent Owner is implicitly acknowledging that for a period
`of time the data was being sent too fast so it has to throttle it back.
`
`And that period of time is captured in the text that we've put inside a
`box in Carmel, and that reads, "If TSL," which is the slice transmission time,
`"is substantially less than Tmin," which is the slice duration, "then the slice
`duration may optionally be increased as noted herein above."
`
`So to carry through with our example in the demonstratives, if TSL is
`0.5 seconds and Tmin is one second of video, so 0.5 is substantially less than
`one second. In other words, it got there way too fast. You've got to throttle
`that. And based on the language of the claim, the broadest reasonable
`construction of the claim, we believe that this teaching in Carmel would read
`on that limitation.
`
`Notably, the Patent Owner's expert --
`
`JUDGE BOUCHER: That language, though, wasn't cited in your
`petition, right? That's just a response to the Patent Owner's argument. The
`aspects of Carmel that you relied on in your petition are different.
`
`MR. GASPARO: That is correct, Your Honor. That argument is in
`reply to an argument that they made, that Patent Owner made, in its
`response, yes.
`
`Notably, the Patent Owner's expert, during his cross examination,
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`15
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`admitted that Carmel discloses sometimes transmitting slightly faster than
`the playback rate, and we've set forth on Slide No. 12 some of that
`testimony.
`
`And I'm not going to read it all, but you can see we emphasize some
`language where Professor Chang testifies that sometimes it's slightly faster
`than playback rate, sometimes it's slightly slower than playback rate, slightly
`higher, slightly lower. So we feel this is further evidence of Carmel's
`teaching of sending it faster than the playback rate.
`
`If there's no further questions on Claim 10, I was going to move on to
`Claim 15.
`
`JUDGE JEFFERSON: Please.
`
`MR. GASPARO: Okay. So, Claim 15. The term in dispute in Claim
`15 is "said server does not maintain a pointer into a buffer established within
`said server for each said user."
`
`It's undisputed that Carmel does not describe a pointer. That is there's
`no text or figures in Carmel that either describe or illustrate the use of a
`pointer.
`
`The Patent Owner's argument is that there must be a pointer in the
`server buffer, and that's -- and they're relying solely on their expert's
`testimony. We obviously disagree, and I'm going to explain why.
`
`Carmel uses the same standard HTTP TCP protocol that's taught in
`the 141 patent. On Slide No. 14, on the left side of Slide No. 14, we have
`the relevant language from the 141 patent, and on the right side of the slide
`we have the relevant language from Carmel. And below that we have some
`testimony from Patent Owner's expert.
`
`The 141 patent describes the use of TCP and client-side control as the
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`16
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`way of accomplishing not using a pointer. And similarly, in Carmel, the
`reason there's no description or illustration of using a pointer is because
`Carmel teaches client-side control and using HTTP TCP. So it's not
`surprising that Carmel is silent on not using a pointer.
`
`On Slide No. 15 we just have some exemplary teachings of client side
`control in Carmel.
`
`And moving on to the next slide, on Slide No. 16, further support for
`Carmel not teaching the use of a pointer in a server buffer is that Carmel
`states that there's no special purpose software used on the server to serve the
`media. And we have on Slide No. 16 some text from Carmel noting that
`there's no special purpose broadcasting hardware or software.
`
`We just want to highlight on -- this is actually the last slide. I just
`wanted to highlight that the Patent Owner's expert actually testified that
`Carmel would require a pointer into a server buffer, but he did not in
`forming his opinion consider Carmel's use of standard network servers
`without special purpose hardware or software.
`
`And you'll see on Slide No. 17 what we believe to be the relevant
`testimony whereby Dr. -- sorry, Professor Chang acknowledged that he
`didn't consider that section of Carmel where it teaches not using any special
`purpose hardware or software.
`
`So unless Your Honors have any further questions, I'm going to
`reserve my remaining time for rebuttal.
`
`JUDGE JEFFERSON: No further questions.
`
`MR. GASPARO: Thank you, Your Honors.
`
`JUDGE JEFFERSON: You have nine minutes and 30 seconds left for
`rebuttal.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`17
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`Patent Owner, you may begin when ready.
`
` OPENING ARGUMENT
`
`BY MR. ABRAMSON: Thank you, Your Honor.
`
`So two aspects of Claim 10 at issue here. So Claim 10 recites
`
`receiving requests for specified IDs -- specified identifiers of requested data
`elements. And Claim 10 recites sending media data elements to the user
`system responsive to said request at a rate more rapid than the playback rate.
`
`To start off, Petitioners, first of all, rely on the statement that we heard
`earlier when -- which is, quote, "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 by the transmitting computer."
`
` Well, the question was raised, and I think it's a very pertinent one, is
`what does Carmel mean by "the data rate"? And the Petitioners go to the
`conclusion that, well, "the data rate" must mean that it's the date -- it's the
`rate at which individual elements are being transmitted to the client.
`
`And we don't see that here. In the context of the entire disclosure of
`Carmel, Carmel is teaching an embodiment in which you could have
`multiple links opened up in which you can recode, you can transcode
`elements, and this is just -- this is simply a statement that "the data rate,"
`whatever it is as a result of the operations that are disclosed in Carmel, that
`that data rate, be it in the aggregate or as the items are modified, that data
`rate is generally equal to or faster than the rate at which data are generated
`by the transmitting computer.
`
`The quote doesn't indicate that the antecedent for "the data rate" is the
`speed at which individual elements -- individual requested elements are
`transmitted. The Petitioner also relies on two more quotes, as we just went
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`18
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`through.
`
`JUDGE BOUCHER: Let's stay on this one for a second because the
`way you just described it, it sounds to me like the parties are not that far
`apart, and it may be that I'm not understanding correctly.
`
`But when the -- I can't remember what slide it was. I think it was
`Slide No. 8 of the Petitioner's presentation where they show this example
`where you open up additional links. It seems to me that what the Petitioner
`was saying is that the individual rate on each of those links remains less than
`the playback rate but the overall data rate, because you have multiple links,
`can exceed the playback rate.
`
`It seems to me you just said the same thing, although you
`characterized it in terms of bandwidth. Am I misunderstanding something
`there?
`
`MR. ABRAMSON: No, I think Your Honor --
`
`JUDGE BOUCHER: I mean, it seems to me the disagreement
`between the parties boils down to whether or not "rate" in Claim 10 refers to
`the rate across an individual link or refers to rate in the aggregate across all
`of the links.
`
`MR. ABRAMSON: I think that's correct. And I think they were --
`and that -- if you look at the chronology here, that's an argument that is
`nowhere in the petition. It came up -- it didn't even come up in reply. The
`reply brief does not articulate this. If you look at the reply brief, the reply
`brief does not articulate what's on Slide No. 8.
`
`Slide No. 8 certainly isn't in Carmel. Slide No. 8 is an attorney
`argument. There's no expert support for it. It's simply an attorney argument.
`
`But they were pushed into that, Your Honor, because the first
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`19
`
`

`

`Case IPR2016-01238
`Patent 8,122,141 B2
`
`interpretation that they preferred in the petition, that quote meant it was the
`data rate of individual elements, that doesn't stand up. And their expert
`contradicted that in the declaration. The expert's declaration in the Apple
`case is inconsistent with that assertion.
`
`The other side was pushed into what you see on Slide No. 8. And
`Your Honor is quite right that that is -- although Slide No. 8 goes beyond
`what's actually taught in Carmel, but the concept that it's the aggregate data
`rate as opposed to the rate of individual elements, we would agree that's
`what Carmel was talking about.
`
`But we disagree that the claim covers that because the claim talks
`about -- if you look at

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket