[00:00:00] Speaker 04:
16, Wag Acquisition LLC against Web Power.

[00:00:04] Speaker 04:
Mr. Abramson, when you're ready.

[00:00:13] Speaker 04:
And it would be helpful to find out distinctions between these cases.

[00:00:18] Speaker 00:
Okay.

[00:00:20] Speaker 00:
Let me, may it please the court again, now we're on the 1619 appeal.

[00:00:29] Speaker 00:
Yes.

[00:00:30] Speaker 00:
which is a different embodiment arising out of a common disclosure.

[00:00:34] Speaker 00:
So as I emphasized in the argument on 1617, we were talking there about a pull embodiment.

[00:00:44] Speaker 00:
Here on this appeal, we're talking about really what's a push embodiment, where the server's in control of what's being sent to the client.

[00:00:52] Speaker 00:
And now the server has to control the process of sending to the client

[00:00:58] Speaker 00:
at a great enough speed to be able to maintain the playback without dropping.

[00:01:05] Speaker 00:
So it needs to do two things.

[00:01:06] Speaker 00:
It needs to get a fast startup.

[00:01:09] Speaker 00:
So the claims describe an initial, the claim one, the base claim describe an initial transfer of a buffer full of information to the client at faster than the playback rate.

[00:01:21] Speaker 00:
That's so the client can get a fast startup.

[00:01:23] Speaker 00:
And then after that, the server has to be able to

[00:01:28] Speaker 00:
avoid either overflowing or underflowing, having the client run dry of material to play back.

[00:01:37] Speaker 00:
And whereas in the patent we discussed in the prior appeal, the client said, the client was in charge of telling the server when it needed more information, my buffer's getting low, send me another piece.

[00:01:49] Speaker 00:
On this side, it's up to the server to figure that out.

[00:01:53] Speaker 00:
So that's the difference.

[00:01:54] Speaker 00:
This is server moderated.

[00:01:56] Speaker 00:
And the other embodiment was client-moderated.

[00:02:04] Speaker 00:
So the issue on this appeal concerns motivation to combine.

[00:02:11] Speaker 00:
There are two obviousness combinations at issue.

[00:02:15] Speaker 00:
There's Chen and its file history plus, now we have two different combinations, Willoughby, Chen plus Willoughby, and Chen plus Cannon.

[00:02:27] Speaker 00:
Both the Chen prior art as well as the 839 patent have the same objectives, which is to achieve a smooth and uninterrupted delivery of program stream to overcome the problem of erratic delivery of data packets over a network such as the internet.

[00:02:48] Speaker 00:
The whole premise of these patents is that you've got a transmission channel that's faulty.

[00:02:55] Speaker 00:
And then you have to find some way to get a smooth transmission over a faulty channel.

[00:03:00] Speaker 00:
Because if you didn't have a faulty channel, you wouldn't need either of these inventions.

[00:03:04] Speaker 00:
You would just take the data as it comes in and send it bite by bite down the channel and everybody would be happy.

[00:03:09] Speaker 00:
There would be no problems.

[00:03:10] Speaker 00:
The reason for both Chen and the present invention is it doesn't work that way.

[00:03:16] Speaker 00:
You've got to do something to overcome the vagaries of the transmission channel.

[00:03:20] Speaker 00:
That's the setting here.

[00:03:23] Speaker 00:
And that's really any motivation is you've got to look back to what it is they're trying to do with this technology.

[00:03:31] Speaker 00:
Only Chen, Chen only deals, here's a key point, Chen only deals with streaming pre-recorded program, which differs from a live feed.

[00:03:41] Speaker 00:
The claims involved in this appeal involve transmission from a live feed.

[00:03:48] Speaker 00:
Chen, you're streaming a pre-recorded program

[00:03:51] Speaker 00:
And in these claims, you have a live feed.

[00:03:53] Speaker 00:
The difference is that when you have a pre-recorded program, the server can reach back into the program and get anything it wants out of that data to send it down the line.

[00:04:04] Speaker 00:
With a live feed, all you get is what's arrived already.

[00:04:08] Speaker 00:
You can't look forward in time.

[00:04:10] Speaker 00:
You can't say what's going to come three seconds from now because we're not there yet.

[00:04:16] Speaker 00:
And that's the fundamental difference between live and pre-recorded.

[00:04:21] Speaker 00:
What happened in this case is that they used Chen as the base references for an obviousness combination.

[00:04:29] Speaker 00:
And they took two embodiments, Wilby and Cannon, and grafted a live feed onto the front of Chen in place of the pre-recorded medium that was native to Chen.

[00:04:45] Speaker 00:
The problem here is that Chen was never designed to handle a live feed to begin with.

[00:04:49] Speaker 00:
and incorporates many operations that presume possession of the entire recorded program.

[00:04:55] Speaker 00:
Putting a live feed in a system meant to be industry and pre-recorded programs is not as straightforward as the appellee would like to represent it.

[00:05:05] Speaker 00:
The evidence is uncontroverted that the combinations of Chen plus Willoughby and Chen plus Cannon will quickly run out of buffer.

[00:05:14] Speaker 00:
That is, freeze or go blank or go silent in the event of interruptions in the delivery channel.

[00:05:19] Speaker 02:
Are you sure that's uncontroverted?

[00:05:21] Speaker 00:
Pardon me?

[00:05:22] Speaker 02:
Are you sure that's uncontroverted?

[00:05:24] Speaker 02:
You said that that's uncontroverted, and I did not get that from the police.

[00:05:27] Speaker 00:
Well, there's attorney argument, but there's no competent evidence.

[00:05:32] Speaker 00:
There's no expert that said otherwise.

[00:05:35] Speaker 00:
Our expert said that that would happen.

[00:05:36] Speaker 00:
There's nobody who came in and said otherwise.

[00:05:39] Speaker 00:
There's a lot of attorney argument.

[00:05:41] Speaker 00:
There's a lot of conclusions by the board to this effect, but there's no evidence.

[00:05:46] Speaker 02:
Some of the things the board suggests is that

[00:05:49] Speaker 02:
It's okay.

[00:05:50] Speaker 02:
There might be some disruption.

[00:05:52] Speaker 02:
There might be some lag.

[00:05:53] Speaker 02:
It might not be perfect, but you still obtain the advantage of having Chen then be able to provide a live broadcast.

[00:06:04] Speaker 00:
How do you respond to that?

[00:06:05] Speaker 00:
Judge, it's no better than the prior art.

[00:06:08] Speaker 00:
Once you've run down the initial... I apologize.

[00:06:10] Speaker 00:
What did you say?

[00:06:11] Speaker 00:
It's no better than the prior art.

[00:06:13] Speaker 02:
Does it have to be better than the prior art?

[00:06:15] Speaker 00:
It has to be, there has to be some motivation to come up with something better than prior art.

[00:06:20] Speaker 00:
Why bother?

[00:06:20] Speaker 02:
What if it's a motivation to have Chen not just have pre-recorded broadcasts, but also have live broadcasts?

[00:06:28] Speaker 00:
Sorry, what was what?

[00:06:30] Speaker 00:
Why use Chen?

[00:06:32] Speaker 00:
If you don't have to worry about interruptions on your channel, why bother with Chen?

[00:06:38] Speaker 00:
You don't need Chen.

[00:06:40] Speaker 00:
You know, all you need to do is plug your microphone into your computer and have it send it byte-by-byte through port 80, and you're done.

[00:06:50] Speaker 00:
You don't need these inventions.

[00:06:52] Speaker 00:
The whole motivation for these inventions is that your channel is not going to let you do that.

[00:06:58] Speaker 02:
The question, though, is not the motivation for your patented invention, right?

[00:07:03] Speaker 02:
And the question is whether there's substantial evidence to support the board's conclusion that a

[00:07:10] Speaker 02:
person of ordinary scale in the art would have been motivated to modify Chen in order to provide the live broadcast as taught by one of the secondary references.

[00:07:19] Speaker 02:
Isn't that the right inquiry?

[00:07:21] Speaker 00:
Right, but the, but the problem is, is that by making this combination, Chen is able to, is, is perfectly able to deal with interruptions on the channel because Chen has rush mode.

[00:07:32] Speaker 00:
Chen says that if you get into a situation where the client buffer runs low,

[00:07:37] Speaker 00:
client buffer sends a rush command to the server.

[00:07:41] Speaker 00:
Servers rush me some data so I can reconstitute my buffer so I don't run out of gas, don't run out of data.

[00:07:49] Speaker 00:
That is, and Chen works to do that.

[00:07:54] Speaker 00:
Now, when you come along and draft a live feed onto that like they have done here, that mechanism no longer works.

[00:08:00] Speaker 00:
You break Chen because you don't have the data to rush.

[00:08:04] Speaker 00:
Once the initial buffer is depleted,

[00:08:06] Speaker 00:
and you send a rush command, there is nothing to rush.

[00:08:10] Speaker 00:
So the problem with motivation here is this is one of those cases where the combination undoes the ability of the base reference to solve the problem.

[00:08:23] Speaker 00:
That's fundamentally what the problem is.

[00:08:26] Speaker 00:
The board just did not address that.

[00:08:29] Speaker 00:
The board came up with these explanations about how the user could push the pause button, which is really

[00:08:35] Speaker 00:
That's not a solution to the problem.

[00:08:37] Speaker 00:
That's giving up.

[00:08:38] Speaker 00:
That's saying, oh, well, there's going to be interruptions on the channel, so I'll just hit pause and wait till everything straightens out and then listen again.

[00:08:46] Speaker 00:
That doesn't address the motivation issue.

[00:08:50] Speaker 00:
Why would a person of skill in the art be motivated to make a combination that predictably is going to undermine the ability of the prior art to do what it was intended to do?

[00:09:03] Speaker 01:
How would the resulting combination differ from the claimed invention?

[00:09:08] Speaker 01:
The claimed invention also would have some of these challenges with, ultimately, somewhere perhaps during a playback, deplete the server buffer.

[00:09:19] Speaker 00:
Well, the disclosure of the claimed invention does explain.

[00:09:23] Speaker 00:
But the claimed invention.

[00:09:25] Speaker 00:
The claimed invention.

[00:09:26] Speaker 00:
But is somebody motivated to modify?

[00:09:32] Speaker 00:
The claim does not spell out the additional part.

[00:09:36] Speaker 00:
This particular claim does not spell out the additional part that allows the server to recover from an interruption.

[00:09:42] Speaker 00:
It just goes so far as to say it detects an interruption.

[00:09:45] Speaker 00:
And claim two, which is not an issue in this appeal, gets into the recovery part.

[00:09:53] Speaker 01:
So my point is it appears that the claim one claimed invention is in the same situation as the combination of

[00:10:01] Speaker 01:
Chen and Willoughby.

[00:10:03] Speaker 00:
Right, but my argument is that somebody is not really motivated, somebody's motivated to solve a real-world problem, not to reproduce claim one.

[00:10:11] Speaker 00:
And I agree with you, claim one says what it says, but the question still is, is it obvious?

[00:10:17] Speaker 00:
We're going to go back to the table.

[00:10:20] Speaker 01:
It sounds like your argument is basically that nobody be motivated to make this combination because it'd be inoperable, but the board found otherwise that it

[00:10:31] Speaker 01:
there would be a basis for it to be operable.

[00:10:33] Speaker 01:
It might not be optimal.

[00:10:35] Speaker 01:
It might not be as clean of a transmission and playback as, say, with downloading something, I don't know, a pre-existing stored file, but it would still be good enough and it would still be attractive that people would want to be able to stream not only pre-recorded data but also stream a live broadcast.

[00:10:57] Speaker 00:
Well, I would argue that

[00:10:59] Speaker 00:
Our argument is not that it's inoperable.

[00:11:01] Speaker 00:
Our argument is that it renders the prior art incapable of performing its intended purpose, which is overcoming, which is sending smoothly over the internet.

[00:11:12] Speaker 00:
And it is not a sufficient motivation.

[00:11:15] Speaker 00:
We argue it's not a sufficient motivation for somebody to put together something that can't even do what the prior art did.

[00:11:25] Speaker 00:
To make a modification that impairs the ability of the prior art to meet its intended purpose, that is cited as a situation that counters motivation.

[00:11:39] Speaker 00:
So to say that somebody would be motivated to make something that doesn't even solve the problem that the prior art solves, in the real world, nobody would do that.

[00:11:54] Speaker 00:
That's not a combination that a person of skill in the art would seek to do because it does not even solve the problem that was solved by what he started with.

[00:12:08] Speaker 00:
It leads to an unsatisfactory result that doesn't meet the objects of even the prior art that he starts with.

[00:12:15] Speaker 00:
And the risk case law, which we cited, which says that

[00:12:23] Speaker 00:
A negative to motivation is a modification that impairs the ability of the prior art to function to a performance intended purpose.

[00:12:33] Speaker 04:
Let's move to the other side and we'll save you rebuttal.

[00:12:36] Speaker 00:
I'll save the remainder of my time.

[00:12:38] Speaker 00:
Thank you.

[00:12:39] Speaker 04:
Thank you.

[00:12:42] Speaker 04:
Mr. Faulkner.

[00:12:46] Speaker 05:
May it please the court.

[00:12:47] Speaker 05:
There is substantial evidence to support the board's finding that there would be a motivation to combine these references.

[00:12:53] Speaker 05:
Chen describes a system for pacing delivery of multimedia content that's packetized.

[00:12:59] Speaker 05:
It describes using a pre-stored video, but it does state that it can perform its necessary calculations for the pacing on the fly or during transmission.

[00:13:10] Speaker 05:
The Willoughby reference then states

[00:13:12] Speaker 05:
a motivation.

[00:13:13] Speaker 05:
It says, more recently, streamed audio and video have become available from both stored and live sources on the web.

[00:13:21] Speaker 05:
Willabeek discloses a pre-stored system, but then it also, in another section, discloses a way to provide live video to this type of pre-stored system.

[00:13:31] Speaker 05:
There's evidence in the form of expert testimony that it would be obvious to modify the references, modify Chen to use Willabeek's

[00:13:41] Speaker 05:
provision of live data so that Chen could provide live video as well as pre-stored video.

[00:13:47] Speaker 05:
You say that doing so would be nothing more than combining the teachings in a known way to achieve predictable results.

[00:13:52] Speaker 05:
It would be the use of a known technique, Willoughby's capture station and the circular buffer queue that could provide a buffer, a pre-made buffer of live data to improve a similar known devices.

[00:14:04] Speaker 05:
And that would be Chen's system for storing streaming video.

[00:14:07] Speaker 05:
Now the system can provide both live and streaming video.

[00:14:10] Speaker 04:
so whether it would have been obvious to an expert.

[00:14:15] Speaker 04:
The question is whether it would have been obvious to a person of ordinary skill.

[00:14:20] Speaker 05:
That's correct.

[00:14:22] Speaker 05:
The expert simply states that the reasons that one would combine them.

[00:14:27] Speaker 05:
He did opine on what the level of ordinary skill would be.

[00:14:30] Speaker 04:
He says it was obvious to him.

[00:14:33] Speaker 05:
He says it would have been obvious.

[00:14:34] Speaker 05:
That's correct.

[00:14:35] Speaker 05:
He didn't

[00:14:37] Speaker 05:
His statement there does not say to one of ordinary skill in the art.

[00:14:40] Speaker 05:
I believe that's correct.

[00:14:43] Speaker 05:
But the reasons to provide are still there.

[00:14:45] Speaker 05:
They're both in Willoughby, which itself provides a market need for the ability to provide both live and pre-stored video.

[00:14:54] Speaker 05:
And then according to the basic teachings of KSR, this is a situation where we're taking a known solution

[00:15:04] Speaker 05:
and applying it to similar known devices, a known improvement to similar known devices.

[00:15:10] Speaker 05:
The primary issue seems to be, the issue the FAT NONER raises seems to be the fact that they don't think it's going to be reliable enough delivery.

[00:15:21] Speaker 05:
That given enough time, we're going to run out of the buffer.

[00:15:25] Speaker 05:
So Willoughby describes a buffer that's several seconds.

[00:15:28] Speaker 05:
And in the combined system, Willoughby is going to rush a portion of the buffer over to

[00:15:33] Speaker 05:
Chen's client buffer.

[00:15:35] Speaker 05:
And then Chen continues to operate as it always would.

[00:15:39] Speaker 05:
Chen has the remainder of the server buffer and the client buffer, and it paces transmission between those two buffers.

[00:15:47] Speaker 05:
Now it is true, if you have enough interruptions, you'll always run out of buffer space.

[00:15:53] Speaker 05:
That would always happen.

[00:15:55] Speaker 05:
And patent owner seems to say, well, a few seconds, that's not enough.

[00:15:59] Speaker 05:
There's no evidence of why that would not be enough.

[00:16:02] Speaker 05:
a buffer.

[00:16:03] Speaker 05:
This video would continue to play.

[00:16:05] Speaker 05:
Chen would continue to do its high-level, low-level pacing until you experience more than that amount of interruptions, more than a few seconds of interruptions.

[00:16:14] Speaker 05:
For many videos, that might be completely adequate.

[00:16:17] Speaker 05:
There's no evidence that that's somehow inadequate.

[00:16:20] Speaker 05:
But there is evidence in the record that a few seconds at the time was considered enough of a buffer.

[00:16:26] Speaker 05:
Willabeek itself is a live system at this time, and Willabeek

[00:16:32] Speaker 05:
chose a few seconds of buffer for its live embodiment.

[00:16:36] Speaker 05:
So that's evidence that at the time Willabeek believed a few seconds was the proper amount of buffer size.

[00:16:43] Speaker 05:
And that's substantial evidence in the record to support that this idea that it's somehow too little, which has no evidence, is unsupported.

[00:16:51] Speaker 01:
I guess Willabeek doesn't have the rush mode.

[00:16:54] Speaker 01:
Is that right?

[00:16:56] Speaker 05:
Willabeek doesn't have a rush mode to do the initial fast startup.

[00:17:00] Speaker 05:
Right.

[00:17:00] Speaker 05:
In Chen, you have a portion in the server buffer and a portion in the client buffer.

[00:17:05] Speaker 05:
It does rush some to start up, but in both instances, the amount of buffer you have is the amount of buffer you have.

[00:17:12] Speaker 05:
In Willoughby, it's all at the server, so if you have three seconds of buffer, that's three seconds of delay you can account for.

[00:17:18] Speaker 05:
In Chen, even if that's split between the two buffers and you've done the fast startup, the amount of buffer that you have is still the amount of interruptions you can do.

[00:17:29] Speaker 05:
that you can account for.

[00:17:32] Speaker 05:
And the same would be true of the inventive system.

[00:17:34] Speaker 05:
Whatever size that buffer is, that's how many seconds you have to buffer before you're going to start experiencing some kind of interruption.

[00:17:42] Speaker 05:
That's just a fact of why video, we can't generate new video faster than it's being made.

[00:17:49] Speaker 05:
There's also a discussion that Chen, that we're throwing out the teachings of Chen.

[00:17:54] Speaker 05:
And in this combination, the teachings of Chen are not thrown out.

[00:17:57] Speaker 05:
And the expert says it's going to continue to operate according to its known teachings.

[00:18:01] Speaker 05:
So Chen describes that you have a low watermark and a high watermark on the client buffer.

[00:18:06] Speaker 05:
You always try to keep the buffer in the middle of that.

[00:18:09] Speaker 05:
Well, with Willoughby's server buffer, you have a few seconds of buffer.

[00:18:14] Speaker 05:
You'll rush a portion of it until you're above the low watermark.

[00:18:18] Speaker 05:
You may still have a portion in the server.

[00:18:20] Speaker 05:
And then Chen's going to do its pacing.

[00:18:22] Speaker 05:
If you run low in the client,

[00:18:24] Speaker 05:
you're going to rush more because you're below the low water mark and so you'll rush more to the extent you can.

[00:18:32] Speaker 05:
And if you go to the high water mark of Chen, if you're sending more packets that are being viewed, well then it will back up at the server buffer.

[00:18:39] Speaker 05:
That would still happen.

[00:18:41] Speaker 05:
So everything would continue to operate as it does in Chen.

[00:18:45] Speaker 05:
Now Chen doesn't say what are the exact situations where the client buffer fills to the high water mark.

[00:18:53] Speaker 05:
Because it is kind of a funny thing.

[00:18:54] Speaker 05:
In Chen, when you're in between these two watermarks, you're sending at the playback rate.

[00:19:01] Speaker 05:
And so you're sending items at the playback rate at the same rate they're being watched.

[00:19:06] Speaker 05:
You should never go above the high watermark.

[00:19:10] Speaker 05:
You should be watching at it exactly the same time.

[00:19:12] Speaker 05:
So it's not entirely clear from Chen.

[00:19:14] Speaker 05:
Chen's silent and just says, look, if that buffer does fill because you're sending more than you're watching, well then we're going to stop.

[00:19:21] Speaker 05:
Pause transmission, let it build up on the server buffer.

[00:19:24] Speaker 05:
We did ask patent owner's expert about the Chen disclosure, and so at the appendix on page 938, we said in Chen, what would cause the system to go in pause mode?

[00:19:37] Speaker 05:
What would cause it to go above the watermark, the high watermark?

[00:19:43] Speaker 05:
And he said, well, when the buffer's above the high watermark, it goes into pause mode.

[00:19:48] Speaker 05:
Why would the client buffer in Chen fill to the higher watermark?

[00:19:51] Speaker 05:
He said, one possible reason is there's more incoming packets for a period of time than outgoing.

[00:19:57] Speaker 05:
He said, okay, but what situation in the real world would cause more incoming packets to the buffer than outgoing packets?

[00:20:04] Speaker 05:
And he said, for example, if the client hits a pause button, then at that time, you're not using the client buffer, you're still sending data at the normal rate, it will go to the top, and at that point it will pause.

[00:20:18] Speaker 05:
So he said that would cause the buffer level to rise, possibly above that mark.

[00:20:23] Speaker 05:
So the Chen pause scenario is equally applicable in our combined reference.

[00:20:29] Speaker 05:
If someone has Willoughby, and the Willoughby buffer is there and it's pacing transmission to Chen at about the playback rate, as Chen teaches, if someone pauses it, it will fill above the high water mark.

[00:20:42] Speaker 05:
So you continue to use all of Chen's features.

[00:20:45] Speaker 05:
You're using the Chen low water mark to rush more data

[00:20:48] Speaker 05:
you're using the high watermark to pause so things don't overbuild at the client buffer and use the server.

[00:20:54] Speaker 05:
So it's simply not the case that in the live embodiment we throw out any teachings of Chen.

[00:20:59] Speaker 05:
Although it should be noted, even if there were some aspects of Chen that didn't function in the live watermark, it wouldn't matter.

[00:21:09] Speaker 05:
There can be trade-offs when you make combinations.

[00:21:12] Speaker 05:
And here, it's undisputed, Chen would now be able to serve live video.

[00:21:17] Speaker 05:
The fact that all of Chen's schedule would be used when it's serving live video, it's still an improvement to the system that previously could only do pre-stored video.

[00:21:27] Speaker 05:
And finally, it's also been noted that this is not a claim requirement.

[00:21:32] Speaker 05:
Some of these requirements are in other claims.

[00:21:34] Speaker 05:
And there's no need for this combined system to meet every requirement of other claims.

[00:21:40] Speaker 05:
And the combined system also doesn't need to meet the objectives of the patent

[00:21:44] Speaker 05:
The analysis is simply whether, looking at these two references, there's substantial evidence of a motivation to combine them.

[00:21:52] Speaker 05:
And then once they're combined, do they meet all the claim elements?

[00:21:55] Speaker 05:
That's the analysis.

[00:21:56] Speaker 02:
On the second issue, there was some reliance by the board on estoppel and whether the combined references would meet a particular claim limitation.

[00:22:11] Speaker 02:
When you are talking about whether Chen teaches the claim limitation, isn't that a different question than whether Chen, in view of Willoughby, teaches the claim limitation?

[00:22:20] Speaker 02:
And can we really apply a stopple in that situation?

[00:22:23] Speaker 05:
So it could be a different question if somehow we weren't using that aspect of Chen, or the combination causes some change in how that functionality of Chen would work.

[00:22:37] Speaker 02:
Let's say that I didn't agree with the equitable stopple argument.

[00:22:40] Speaker 02:
not that would be just the estoppel, sorry, argument.

[00:22:44] Speaker 02:
Did the board have an alternative rationale for its conclusion?

[00:22:48] Speaker 05:
It did.

[00:22:49] Speaker 05:
The equitable estoppel was one of multiple grounds for finding that it was not persuasive that the combined references would not, that there would be no motivation to combine.

[00:23:04] Speaker 05:
So yes, there were alternate grounds.

[00:23:10] Speaker 04:
Have you formed a conclusion as to really the validity of invoking collateral estoppel in these cases?

[00:23:22] Speaker 05:
So I think the particular argument made here, it is proper to find that it was a stop.

[00:23:28] Speaker 05:
So what was being argued was that this lost packet mechanism that had already been found to be in Chen was not met by the combined system.

[00:23:38] Speaker 05:
But the lost packet mechanism

[00:23:40] Speaker 05:
would operate the same way in the combined system as it would in Chan.

[00:23:44] Speaker 05:
Again, it's all just about under the same limitations.

[00:23:48] Speaker 02:
And that was your expert's position, right?

[00:23:50] Speaker 05:
Correct.

[00:23:54] Speaker 05:
So the estoppel sort of went to the fact that the party had already, that it had already been litigated whether Chan's loss packet mechanism meets his claim element.

[00:24:07] Speaker 05:
The loss packet mechanism

[00:24:08] Speaker 05:
was unaltered by the combination.

[00:24:12] Speaker 05:
Chen could still request a missing packet within whatever the size buffer was available.

[00:24:18] Speaker 05:
So here, a few seconds buffer, if we say that's the limit of the buffer, Chen can still be requesting the packets as long as they're sort of within that buffer.

[00:24:29] Speaker 05:
Chen also has a timeout mechanism.

[00:24:31] Speaker 05:
For once it's been too long and we've got to move on, Chen stops looking for the lost packets.

[00:24:38] Speaker 05:
function the same here.

[00:24:39] Speaker 05:
It has a few seconds to try to grab that lost packet before it's going to play it for the user.

[00:24:47] Speaker 05:
So I think the estoppel goes to the fact that the court wasn't going to reconsider whether that element of Chen met this limitation.

[00:24:57] Speaker 05:
And there had been no indication that that element of Chen should operate any differently.

[00:25:07] Speaker 05:
And in terms of the collateral stopple, on page 28 of the decision is where the board does go on to say, even if collateral stopple is inapplicable, they agree that Chen and Chen file history disclosed the reloading limitations of Plans 8 and 15.

[00:25:26] Speaker 05:
And then it goes on to explain how the combined system would operate in the same way.

[00:25:33] Speaker 03:
Any more questions?

[00:25:35] Speaker 03:
Any more questions for Council?

[00:25:37] Speaker 03:
Okay, thank you.

[00:25:38] Speaker 05:
Thank you.

[00:25:39] Speaker 04:
Mr. Abramson.

[00:25:45] Speaker 00:
Yes.

[00:25:47] Speaker 00:
Just a couple of points.

[00:25:50] Speaker 00:
I believe there was mention of the 839 patent being unable to reconstitute its server buffer, and I thought I made that clear in my argument.

[00:26:04] Speaker 00:
The disclosed embodiment certainly has

[00:26:07] Speaker 00:
it does have the capability to reconstitute its server buffer.

[00:26:11] Speaker 00:
So when the client buffer runs low, the server side, this is not in claim one, but it's the embodiment, the server side will back up data in the server buffer so that it can use that to replenish the client side.

[00:26:27] Speaker 00:
That's how it maintains the equilibrium.

[00:26:31] Speaker 00:
And the thing about the combinations here is that

[00:26:36] Speaker 00:
The rush mode in Chen doesn't work anymore because of this combination.

[00:26:41] Speaker 00:
Mr. Faulkner addressed that it was going to operate on the fly and do things during transmission, and that's fine.

[00:26:53] Speaker 00:
But one thing you can't do during transmission is send data that the server hasn't received yet.

[00:26:58] Speaker 00:
That's the flaw in that analysis, and that's why it's going to run out of data at the client end.

[00:27:06] Speaker 00:
Now, just getting back briefly to motivation to combine, the combination here is between Chen and Willoughby and Carmel.

[00:27:17] Speaker 00:
And the fundamental question is why use Chen?

[00:27:21] Speaker 00:
They've thrown out everything in Chen.

[00:27:24] Speaker 00:
And the thing they absolutely need Chen for here, these claims are dependent from base claims.

[00:27:31] Speaker 00:
And the base claims recites a very definite requirement

[00:27:35] Speaker 00:
that there has to be an initial transfer of a buffer load of data from the server to the client.

[00:27:41] Speaker 00:
That's initial burst that gets a fast start on the client.

[00:27:46] Speaker 00:
That's key to this.

[00:27:47] Speaker 00:
Now, you can't put together an obvious combination unless you have a reference that does something like that.

[00:27:54] Speaker 00:
That's why they need Chen.

[00:27:56] Speaker 00:
But when you look at this from an obviousness standpoint, why use Chen?

[00:28:00] Speaker 00:
There's nothing in Chen that they're relying on.

[00:28:03] Speaker 00:
They're throwing out the entire

[00:28:05] Speaker 00:
the entire frame-based transmission mechanism in Chen, you're throwing out the rush pause mechanism of throttling in Chen, completely throwing that out.

[00:28:18] Speaker 02:
I didn't understand them to be throwing it out.

[00:28:20] Speaker 00:
Pardon me?

[00:28:21] Speaker 02:
I didn't understand them to be throwing it out.

[00:28:22] Speaker 02:
They don't use it.

[00:28:23] Speaker 02:
I understood them to be saying that you would use the Willoughby portions and combine it with Chen.

[00:28:29] Speaker 02:
And it might have problems.

[00:28:30] Speaker 02:
It might not be perfect.

[00:28:31] Speaker 02:
It might not be as fast.

[00:28:33] Speaker 02:
It might not

[00:28:33] Speaker 02:
It might have more disruptions.

[00:28:35] Speaker 00:
Let's look at it.

[00:28:36] Speaker 00:
The rush mode doesn't work.

[00:28:39] Speaker 00:
What doesn't work?

[00:28:40] Speaker 00:
The rush mode won't work once the buffer is empty.

[00:28:43] Speaker 02:
It depends on how you define what the rush mode is.

[00:28:45] Speaker 00:
The rush mode is defined in Chen as accelerating the playback, sending a batch of data from the server buffer down to the client.

[00:28:55] Speaker 00:
It's not there.

[00:28:56] Speaker 00:
It doesn't work.

[00:28:56] Speaker 02:
It has to be filled up first.

[00:28:58] Speaker 00:
Yes, it has to be filled up first.

[00:28:59] Speaker 00:
There's no need for a pause mode anymore.

[00:29:03] Speaker 00:
And it's only a normal mode, which is nothing.

[00:29:07] Speaker 00:
A normal mode is just a pass-through transmission.

[00:29:10] Speaker 00:
The entire mechanism of Chen is unnecessary to implement this combination.

[00:29:15] Speaker 00:
So why is it obvious to pick Chen to begin with?

[00:29:18] Speaker 00:
We contend that it's not.

[00:29:20] Speaker 00:
And it's not obvious to combine them, because now that you've picked Chen, you now make a modification that impairs its ability to function as intended.

[00:29:31] Speaker 03:
Any more questions?

[00:29:32] Speaker 03:
More questions?

[00:29:34] Speaker 04:
Thank you.

[00:29:34] Speaker 04:
Thank you.

[00:29:35] Speaker 04:
Thank you both.

[00:29:35] Speaker 04:
The case is taken under submission.