UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________
`
`WEBPOWER, INC., ET AL.
`Petitioner
`
`v.
`
`WAG ACQUISITION, LLC
`Patent Owner.
`_____________
`
`Case IPR2016-01239
`Patent 8,364,839
`_____________
`
`Record of Oral Hearing
`Held: September 25, 2017
`_____________
`
`
`
`Before TREVOR M. JEFFERSON, BRIAN J. McNAMARA, and
`PATRICK M. BOUCHER, Administrative Patent Judges.
`
`
`
`
`
`
`
`_____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________
`
`WEBPOWER, INC., ET AL.
`Petitioner
`
`v.
`
`WAG ACQUISITION, LLC
`Patent Owner.
`_____________
`
`Case IPR2016-01239
`Patent 8,364,839
`_____________
`
`Record of Oral Hearing
`Held: September 25, 2017
`_____________
`
`
`
`Before TREVOR M. JEFFERSON, BRIAN J. McNAMARA, and
`PATRICK M. BOUCHER, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`Case IPR2016-01239
`Patent 8,364,839
`
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`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-01239
`Patent 8,364,839
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE JEFFERSON: Good afternoon. On the record for Case
`
`IPR2016-01239, for WebPower and Various Interveners v. WAG
`Acquisition.
`
`Start with appearances for Petitioner.
`
`MR. GASPARO: Frank Gasparo with Venable, LLP, counsel for
`WebPower, Inc. and also several joint parties. And I'm here with my
`colleague Falkler, also from Venable, LLP.
`
`JUDGE JEFFERSON: Thank you. And for Patent Owner?
`
`MR. ABRAMSON: Ronald Abramson from Lewis, Baach,
`Kaufmann, Middlemiss, PLLC. And with me is Ari Jaffess from my firm.
`
`JUDGE JEFFERSON: Thank you. And we will get started. Each
`party will have 40 minutes, and the Petitioner can reserve rebuttal time as
`appropriate.
`
`Mr. Gasparo, the Petitioner may begin when ready.
`
`BY MR. GASPARO: Good afternoon, Your Honors. I'd like to start
`with a summary of what is contested and what's uncontested in this
`proceeding on Slide No. 2.
`
`Independent Claims 1, 8, and 15 of the 839 patent have already been
`invalidated by the Patent Office Board, and the Patent Owner has -- did not
`appeal that decision. So we're here today on the institution of three
`dependent claims, 5, 12, and 19. And they each recite "wherein the media
`data elements are provided from a live broadcast."
`
`And those claims respectfully depend from Claims 1, 8, and 15, that
`have already been invalidated by Chen in the Chen file history.
`
`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-01239
`Patent 8,364,839
`
`So what's uncontested is that Willebeek and Cannon both disclose
`
`media data elements are provided from a live broadcast. What Patent Owner
`is contesting is the combination of Chen and the Chen file history with
`Willebeek and also alternative- ly with Cannon. And then lastly, they are
`contesting a reloading limitation that's recited in independent Claims 8 and
`15. And as I've now mentioned twice, those claims have already been
`invalidated in a prior IPR.
`
`On Slide No. 3, we thought it would be helpful just to put in front of
`you some of the teachings from Chen, including, on the left, the server client
`architecture, which is Figure 1, and that shows that data is coming from
`what's called a storage subsystem in Chen. That is reference numeral 12.
`And on the right we have some text from Chen that just sets forth sort of the
`watermark model and the normal, rush, pause commands taught by Chen.
`
`So Willebeek describes adapting a stored video system to serve live
`video. Here on Slide No. 4, we have some text from Willebeek. Willebeek
`refers to its live video embodiment as the -- it calls it the Live Bamba
`architecture and says a Live Bamba system was developed to stream audio
`and video from a live source across the web to multiple recipients.
`
`And on the next slide, Slide No. 5, we include some teachings from
`Willebeek regarding this Live Bamba system. And Willebeek uses what's
`called a reflector, and that reflector has a circular buffer queue. And you'll
`see on the left that's the relevant teaching from Willebeek that describes the
`reflector and the circular buffer queue, and it says it contains the most recent
`several seconds of a live transmission for each playback station to which it is
`connected. When a new station connects, the reflector produces a new copy
`of the circular buffer queue for that connection.
`
`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-01239
`Patent 8,364,839
`
`And on the right, we have a figure from Willebeek that illustrates the
`
`reflector and the circular buffers in the middle of that Figure 6, I think it is.
`
`You'll probably remember this illustration. This is from the petition.
`This is the proposed combination of combining Chen and Willebeek. And
`as shown on Slide No. 6, Petitioners are adding Willebeek to the front end
`of the Chen system so that -- to support the argument that a copy of the
`Willebeek circular buffer will become the Chen server buffer and then Chen
`teaches what happens thereafter.
`
`On Slide No. 7, we summarize -- hopefully this is helpful. We
`summarize our positions as to why Chen and Willebeek combined render the
`claims obvious. They both utilize packetized data. They both maintain
`server buffers to serve multimedia via either TCP and/or UDP. They both
`serve stored multimedia. And Willebeek goes on to suggest desirability of
`also streaming live data because at the time of Willebeek it noted more
`recently streamed audio and video have become available from both stored
`and live sources on the web.
`
`And as we set forth in our petition as supported by Dr. Polish, Chen
`can handle live data. It teaches frame-level pacing. Can be done on the fly
`during multimedia transmission. So we believe the references can be
`combined to render those claims obvious. So the next three slides are
`actually rebuttal slides which I'd like to save for my rebuttal. So unless
`there's any questions, I was going to move on to Cannon.
`
`JUDGE JEFFERSON: I'll let you go on.
`
`MR. GASPARO: Cannon describes yet another system with a very
`similar client server buffer architecture that can serve both stored video and
`live video. And on Slide No. 11, we have some of the relevant description
`
`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-01239
`Patent 8,364,839
`
`from the specification and a figure, Figure 1a.
`
`And as noted on the left side with some emphasis, Cannon teaches
`two play modes: Live play mode and real-time play mode. Real-time play
`mode in Cannon, what's meant by -- that's a file store mode.
`
`And on the right, Figure 1 illustrates the buffer in the server that is
`receiving either a live feed or a feed from a file store system.
`
`And for really very similar reasons, Petitioner's -- for very similar
`reasons as explained with regards to Willebeek in the petition and in
`responsive in our reply, we believe that -- we respectfully submit that Chen
`and the Chen file history combined with Cannon also render the instituted
`claims obvious.
`
`JUDGE JEFFERSON: Counsel, regarding the combination of Chen
`and the Chen file history with either Cannon or Willebeek -- and I'm
`paraphrasing because I don't think this is exactly how Petitioner phrases it or
`Patent Owner phrases it for both. They basically say that Chen would
`require either far too many changes to operation such that it would be
`unsuitable for its purpose or basically there's a lot of engineering required to
`combine these systems. What's your general response to that and why? And
`does your petition address those required modifications to either Chen or
`Chen file history?
`
`MR. GASPARO: So our petition is -- position is that it does not
`require reengineering. It's -- as we set forth in our petition, because Chen
`teaches that it can do -- it can perform its frame-level pacing on the fly
`that having a live source of data would fit very nicely into the Chen system.
`
`Now, Patent Owner in its response says otherwise. It says it would be
`overly complicated, it would -- too much processing power. You've got 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-01239
`Patent 8,364,839
`
`Chen system. You'd have to redesign it.
`
`We disagree. We don't think so. We think because Chen teaches that
`it can make its decisions on the fly that adding a different source of data
`would not be complicated, would not cause Chen to be gutted. Chen still
`operates as Chen operates with the normal, rush, pause commands. It
`packetizes data. It does everything Chen does. It's just the source of data is
`now coming from the live source. And Chen tells us it can handle that.
`
`This is a rebuttal slide that I may address during my rebuttal.
`
`I lastly want to address this reloading limitation, and I'll try to go
`through this very quickly. I mean, this is an argument that Patent Owner
`already made. Same exact argument in IPR2015-01036. Here's a quote
`from the final written decision. The Patent Owner argued that the loss
`packet mechanism of Chen did not meet the reloading limitation and -- but
`the Board disagreed. And here is the relevant language from the final
`written decision where the Board says so. So --
`
`JUDGE JEFFERSON: You're looking at Slide No. 14 there?
`
`MR. GASPARO: Yes, I'm sorry. Slide No. 14 is the relevant
`language from the final written decision where the board disagreed with
`Patent Owner and said that Chen in fact does teach the reloading limitation
`of the independent claims.
`
`And because of that, we think the law is pretty clear that the Patent
`Owner is collaterally estopped and should not be allowed to reargue it.
`
`That's all I have for now. I'd like to reserve the last 28 minutes for
`rebuttal if necessary.
`
`JUDGE JEFFERSON: Okay. Thank you, Petitioner.
`
`You may begin when ready.
`
`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-01239
`Patent 8,364,839
`
` OPENING ARGUMENT
`
`BY MR. ABRAMSON: Thank you, Your Honor.
`
`Chen, the primary reference here, as my colleague indicated, is strictly
`
`designed for video on demand where the server has in its local possession if
`you will a copy of the entire program that's going to be streamed. So the
`server is able -- could random access that file however it needs in order to
`proceed.
`
`Streaming a live program is a different proposition because you only
`receive the live transmission in real time as it occurs. You don't have
`available -- you can't flash forward because it hasn't happened yet. You're in
`the third inning. You can't say what's going to happen in the bottom half of
`the third inning or even in the next 10 seconds. So you're stuck with the data
`as it comes in. That's a fundamental difference.
`
`So Willebeek makes a provision to serve the live data, but what it
`does -- actually, before I get into it, we're presented with two different
`arguments for combining Chen, which doesn't deal with live, with something
`else which can handle live and putting the combination together. So you
`really have very redundant grounds here. We have Chen plus Willebeek and
`Chen plus Cannon.
`
`And the Petitioner never informed the Board, as it should in the case
`of these types of redundant grounds, which ground it prefers and why.
`There's a definite shortcoming here in the presentation as far as the
`redundancy is concerned. Well, I will address both grounds.
`
`The petition on these grounds is very thin. The argument as to the
`combination of Willebeek and Chen and then the argument as to the
`combination of Cannon and Chen are very short and they don't address
`
`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-01239
`Patent 8,364,839
`
`fundamental questions. About as far as it gets is to suggest that there's one
`sentence in Chen which says that Chen can do scheduling on the fly, and
`they rely on that to say, well, if it can do it on the fly then it can do it with
`live data.
`
`Well, it's two different propositions. Doing it on the fly when you
`have the random access file and you can access the whole file, as much of it
`as you want, that's a different proposition than being stuck to have to deal
`with frames of video as they come in and do the scheduling that's required in
`Chen. So it doesn't really -- Chen doesn't really address that. "On the fly" is
`not a panacea that makes that problem go away.
`
`But more fundamentally --
`
`JUDGE JEFFERSON: Counsel, let me stop you right there very
`quickly.
`
`I understand Petitioner's argument includes the notion that both
`Cannon and Willebeek have a buffer and that there is some data, not just a
`serial stream of individual -- trying to avoid using the word "slices" --
`individual data that comes from the live source but there is some connection
`between the system of Chen alone, which maybe has access to the full file,
`and some portion of the live broadcast.
`
`MR. ABRAMSON: Right. It has a buffer, but it has to use up that
`buffer because the argument -- remember the argument here -- the claim
`says -- we're on the 839 patent. The claim has -- there's two aspects of the
`claims. One is an initial burst where you send a chunk of data from that
`buffer. It's gone from the buffer. And if that doesn't completely deplete the
`buffer, the next time you send a burst, which this claim also contemplates,
`that when the transmission slows down you're going to send -- you're going
`
`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-01239
`Patent 8,364,839
`
`to catch up and send another burst. You can't do it.
`
`So you're going to use up that buffer. So you're going to have that
`buffer on hand at the beginning of the transmission. Maybe you can
`schedule what's in that buffer. But that's it. Then the data arrives in real
`time and you have to process it. Whatever is in the buffer you process and
`then that buffer will eventually be gone. And then as new data comes in,
`you have to deal with it on the fly. So --
`JUDGE JEFFERSON: But if I
`understand Patent Owner's argument, the initial burst mode, this rush mode,
`that Chen goes into you're saying would be depleted if there was a live
`source. I mean, isn't it equally an option or is it also an option that some of
`it might be depleted and the system would operate as -- go back to normal
`mode as Chen contemplates? Or maybe there's a pause -- pause is selected
`and then it goes back into a normal mode?
`
`MR. ABRAMSON: It can't pause. The only way Chen pauses is if the
`client buffer gets above its high water mark. That's the only way Chen can
`pause. That can't happen.
`
`So you get the initial -- let's take the case of -- let me stick to
`Willebeek.
`
`JUDGE JEFFERSON: Why can it never happen?
`
`MR. ABRAMSON: It can never happen because when -- if you take
`an initial rush to the client, you fill the client buffer as full as it's ever
`going to get, then you're sending data -- after that point you're sending data
`at the playback rate. If there's interruptions, the client buffer drops down.
`It's going to have to rush again to fill it up, and that's going to happen to the
`extent that there's anything left in the buffer. But --
`
`JUDGE JEFFERSON: By "that buffer" you mean the buffer?
`
`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-01239
`Patent 8,364,839
`
`MR. ABRAMSON: The server buffer.
`
`JUDGE JEFFERSON: Server.
`
`MR. ABRAMSON: The server buffer can never recover. The server
`
`buffer is going to go down. Then you'll get a rush again. It's going to go
`down. And the client buffer is going to be -- is going to get filled up to the
`amount that it takes to get to the high water mark. You can't get above the
`high water mark.
`
`So Chen only triggers pause when you get above the high water mark
`in the client buffer. That cannot happen in this combination. There's no
`pause. The only thing there is, is normal and there's rush. Rush will use
`up the server buffer. There's nothing left in the server buffer. In the steady
`state that's fine. You can have an empty server buffer. As data comes in,
`you send it out. But the minute you get an interruption and you have to rush
`again, there's nothing there to rush.
`
`And they do not address that. They don't explain in the petition how
`you can sustain rush normal operation of Chen after the server starts up, and
`Chen definitely has -- contemplates that you're going to serve an entire
`multimedia program over an imperfect channel without interruption. So it's
`going to fizzle out very quickly, and there's no explanation in the petition of
`how you prevent that from happening. They do not address it. They try to
`address it in the reply, but the petition is devoid of that explanation.
`
`JUDGE JEFFERSON: Where do I find it in the claims, then, counsel,
`that there is a requirement that it never run out of -- the server never run out
`of data? Maybe there is a pause because the live transmission has no
`further packets? Doesn't that happen in every live system?
`
`MR. ABRAMSON: It's in Chen because Chen -- remember 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
`
`
`
`11
`
`
`
`Case IPR2016-01239
`Patent 8,364,839
`
`mechanism of Chen has rush, normal, and pause. It has to be able to do that.
`This is a question of whether Chen, rigged up with Willebeek -- I'm going to
`just stick with Willebeek. I'll come to Carmel later because I think that that's
`--
`JUDGE JEFFERSON: Cannon.
`
`MR. ABRAMSON: Chen cannot function as it's intended to function
`
`because Chen needs to have the ability to go into rush mode in order to
`recover from interruptions and it cannot do that.
`
`So the difficulty here -- it's obvious in this case. This is obvious in
`this case. Chen is unsuitable -- is rendered unsuitable for its intended
`purpose by this combination because its rush capability soon becomes
`disabled in the operation of the server.
`
`JUDGE JEFFERSON: So I want to make sure I understand. It's not
`the claim that requires Chen to operate -- that means that Chen doesn't
`read on the limitations. It's that Chen's operation itself --
`
`MR. ABRAMSON: Correct.
`
`JUDGE JEFFERSON: -- would be compromised by having the live
`source be either Willebeek or Cannon for that matter.
`
`MR. ABRAMSON: That is correct. Now, Cannon is an even worse
`situation because Cannon, the first thing it does is it flushes the buffer before
`it starts transmitting. It has nothing. I mean, it doesn't -- it can't even start.
`It can't even do the initial rush. The data isn't there.
`
`And their expert admitted that. There's a quote -- they've quoted the
`expert on his cross examination, but they didn't reproduce the entire quote.
`If you look at the exhibits, which is the Polish deposition, which is Exhibit
`2001 -- now I'm talking about Cannon, okay?
`
`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-01239
`Patent 8,364,839
`
`In 2001 exhibit at Page 156, Line 21, to 158, Line 1 -- it's in our reply
`
`brief. I'll read it. My question, "So before the user asks for a live
`transmission you've got this live buffer ready to go."
`
`Answer: "When you hit live transmission, then there's a delay while
`that buffer fills. There's a delay while the buffer fills."
`
`"And then live play starts." Can't be a rush. It has to wait for the
`buffer -- in Cannon, it has to wait for the buffer to fill because it's already
`flushed the buffer.
`
`Then I go on. The next question: "And it's going to fill at the
`playback rate under your hypothesis, correct?"
`
`Answer: "Yes, that's correct."
`
`Question: "Okay. And so there's a latency of how long it takes to fill
`the buffer, correct?"
`
`Answer: "Well, there's an amount of time it takes to fill the buffer.
`You flush the buffer. And you've got an initial I frame. Then you fill that
`buffer and then you send."
`
`Question: "The next scenario would be the startup delay for whatever
`the duration of the buffer was, correct?"
`
`Answer: "Yes, that's right."
`
`Question: "Okay. But that does not eliminate startup delay, correct?"
`
`Answer: "It does not eliminate startup delay, no."
`
`Question: "And the scenario you just described is not in your
`declaration, correct?"
`
`Answer: "No, it's not."
`
`So I think it's fairly clear. Cannon does not start -- can't even get
`started. You can't send the initial rush. Willebeek can send the initial rush
`
`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-01239
`Patent 8,364,839
`
`but it can't keep functioning as data in Chen.
`
`The other thing about the claims, not to neglect the claims completely
`here. The claims do say -- do recite serving a multimedia program. So it has
`to be able to serve the program. That much the claim says. But Chen itself
`requires that it serve the program with this rush, normal, pause mechanism
`and that it be able to do so smoothly for the duration of the program.
`
`So the two references just don't work together to function as
`contemplated by Chen. So there's a flaw in the obviousness of either
`combination, is Patent Owner's position.
`
`JUDGE McNAMARA: Looking at Petitioner's Slide Page 7, counsel,
`of their slide presentation, they catalog the similarities if you will between
`Chen and Chen file history and Willebeek. Why doesn't teach -- you're
`saying it's not within the scope of skill of one of ordinary skill in the art or
`the knowledge of one of ordinary skill in the art to combine the live system
`of Willebeek with the system of Chen given the similarities between the
`two?
`MR. ABRAMSON: Because Chen's mechanism breaks when you
`
`make the combination.
`
`JUDGE McNAMARA: Well, what specifically in Chen breaks?
`
`MR. ABRAMSON: You cannot continue to rush. Rush will not --
`rush stops working. Rush stops working because you don't have a buffer
`there to rush from. All you have is -- once you've used up that initial
`buffer, all you're getting is the data as it comes in, which has to go out as fast
`as it comes in. So you don't have a buffer.
`
`JUDGE McNAMARA: So turning to the claims, counsel, where is it
`in the claims to require the rush mode to be able to be operational beyond
`
`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-01239
`Patent 8,364,839
`
`that first initial rush?
`
`MR. ABRAMSON: I believe I addressed this. It's not a question of
`the claims. It's a question of the references that's being put up.
`
`So if you make the combination in order to address the elements of
`the claims, it follows from that combination that Chen is no longer suitable
`for its intended purpose, which we think rebuts an obviousness argument as
`to the combination.
`
`Briefly, with regard to Claims 8 and 15, this was address in the prior
`IPR. We certainly don't dispute that. But I think the scope of collateral
`estoppel is not really settled as far as this type of issue is concerned. The
`quote that they have in their argument is a prior district court decision and
`collateral estoppel effect of that. This is a question of what's the effect of a
`prior IPR decision in a subsequent IPR. It's not exactly the same panel, but
`it's substantially the same panel and we're looking at the same question.
`
`So I think that the panel has some latitude here to deal with that if the
`panel feels that it might have made a mistake on this point in the previous
`case. And Patent Owner believes that that's the case.
`
`In those claims, 8 and 15, which are base claims, those aren't at issue
`here. What's at issue here are the dependent claims. In those claims, the
`reloading step is after the server detects an interruption or delay. So to
`reload as opposed to load means rereading or repositioning -- at least
`repositioning -- the pointer and the buffer so as to send the elements
`determined to have been interrupted and delayed. That's how we understand
`what "reload" means.
`
`And respectfully, Your Honor, when we read the prior decision, we
`believe that the language of the prior decision treats reloading the same as
`
`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-01239
`Patent 8,364,839
`
`loading, which we believe is incorrect. Not -- it treats it the same as loading,
`not reloading after an interruption.
`
`So the Patent Owner respectfully submits that the panel can reassess
`this issue for these claims, which are 12 and 19 in this case, which were not
`at issue in the prior case.
`
`And there is a legal question of collateral estoppel, but we don't
`believe that it's settled, that we are collaterally estopped to that extent.
`
`JUDGE JEFFERSON: Thank you.
`
`MR. ABRAMSON: Thank you, Your Honor.
`
`MR. GASPARO: Your Honors, Petitioners have nothing further
`unless Your Honors have any questions.
`
`JUDGE JEFFERSON: You rest on your paper; is that the question?
`
`MR. GASPARO: Yes, we do.
`
`JUDGE JEFFERSON: Thank you. The claims will be submitted.
`
`MR. GASPARO: Thank you.
`
`MR. ABRAMSON: Thank you, Your Honor.
`
`JUDGE JEFFERSON: We are adjourned.
`
`(Hearing concluded at 2:48 p.m
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`
`
`
`16
`
`
`
`Case IPR2016-01239
`Patent 8,364,839
`
`
`
`
`PETITIONER:
`
`Frank Gasparo
`Jonathan Falkler
`VENABLE, LLP
`fmgasparo@venable.com
`JLFalkler@venable.com
`
`
`PATENT OWNER:
`
`Ronald Abramson
`LEWIS, BAACH, KAUFMANN, MIDDLEMISS, PLLC
`ronald.abramson@lbkmlaw.com
`
`Ernest Buff
`ERNEST D. BUFF & ASSOCIATES, LLC
`ebuff@edbuff.com
`
`
`
`
`17
`
`
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
