[00:00:01] Speaker 05:
We have an admission this morning.

[00:00:03] Speaker 05:
Andrew, will you come forward to the podium?

[00:00:08] Speaker 05:
It is my great pleasure to move the admission of Andrew Edward O'Dell Morrell, who is a member of the bar of this court, a member of the bar in good standing with the highest courts of California and the District of Columbia.

[00:00:22] Speaker 05:
I have knowledge of his credentials and am satisfied that he possesses the necessary qualifications.

[00:00:30] Speaker 05:
Let me say that Andrew has been my law clerk.

[00:00:33] Speaker 05:
And it is with extreme pleasure that I make this motion.

[00:00:39] Speaker 05:
Having made the motion, let me ask Judge Chen what we do next.

[00:00:49] Speaker 03:
Oh, right.

[00:00:52] Speaker 03:
Right.

[00:00:52] Speaker 03:
I understand.

[00:00:53] Speaker 03:
You should recuse yourself from this.

[00:00:57] Speaker 03:
One moment, please.

[00:01:00] Speaker 04:
I would second the motion.

[00:01:02] Speaker 04:
I support this motion.

[00:01:04] Speaker 04:
Andrew has done an excellent job for the court.

[00:01:09] Speaker 03:
I concur.

[00:01:09] Speaker 03:
So on the strength of your case, Judge Newman, your motion is granted.

[00:01:15] Speaker 05:
Thank you.

[00:01:15] Speaker 05:
So now will you face the clerk to admit us to the oath?

[00:01:20] Speaker 02:
Do you solemnly swear that you will comport yourself as an attorney and counselor of this court, uprightly and according to law, and that you will support the Constitution in the United States of America?

[00:01:28] Speaker 00:
I do.

[00:01:29] Speaker 05:
Thank you.

[00:01:33] Speaker 05:
Welcome to the bar.

[00:01:34] Speaker 03:
Congratulations, Mr. Morell.

[00:01:36] Speaker 05:
Congratulations.

[00:01:40] Speaker 05:
All right.

[00:01:40] Speaker 05:
The first argued case this morning.

[00:01:43] Speaker 05:
It's number 18, 1617, white acquisition LLC against Web Power Incorporated.

[00:01:52] Speaker 05:
Mr. Abramson.

[00:01:55] Speaker 01:
Thank you.

[00:01:56] Speaker 01:
And may it please the Court.

[00:01:58] Speaker 01:
The 16-17 appeal concerns alleged anticipation of claims 10 and 15 of the 141 patent by Carmel.

[00:02:12] Speaker 01:
Appellee realized a great deal on waiver, so I'd like to address that briefly, as to claim 10.

[00:02:19] Speaker 01:
The IPR petition presented seven grounds of anticipation, of which anticipation was only a part.

[00:02:27] Speaker 01:
and sought no claim constructions in the petition.

[00:02:31] Speaker 01:
When the appellant submitted the patent owner response, it addressed what was in the petition.

[00:02:38] Speaker 01:
As to anticipation, the petition provided a straight up argument as to the alleged requested elements which the petition claimed were being sent faster than the playback rate.

[00:02:52] Speaker 01:
Appellees replied below after

[00:02:56] Speaker 01:
the patent owner response introduced new arguments for anticipation.

[00:03:01] Speaker 03:
If I could just go straight to the chase on something.

[00:03:06] Speaker 03:
I agree it looked like below in front of the board there was a lot of discussion about Carmel and its parallel links and so the claim was being immediately compared to whatever was going on in the Carmel disclosure without

[00:03:22] Speaker 03:
really defining what the right conception of the claim language was.

[00:03:27] Speaker 03:
And so what I'm trying to figure out is to what extent did you specify to the board that you were operating under an assumption that the claim called for the media data elements being sent to be the very requested media data elements that are specified by some kind of identifier.

[00:03:51] Speaker 03:
I didn't quite see that

[00:03:53] Speaker 03:
kind of discussion come out in any of your papers?

[00:03:56] Speaker 01:
You argued that very vigorously.

[00:03:58] Speaker 03:
Did you talk about the relying on identifiers to specify the requested media data elements as being the data elements being transmitted?

[00:04:11] Speaker 03:
Absolutely.

[00:04:11] Speaker 03:
Could you show me that?

[00:04:12] Speaker 01:
Well, it's in the oral argument.

[00:04:14] Speaker 01:
That's the issue.

[00:04:16] Speaker 04:
But it's in the appendix, right?

[00:04:18] Speaker 01:
In the appendix, that's right.

[00:04:20] Speaker 04:
Do you have a particular page in the oral argument that you would rely on for that?

[00:04:28] Speaker 04:
I thought maybe you'd be looking at page 650 or 651.

[00:04:37] Speaker 04:
You might have other pages.

[00:04:56] Speaker 01:
So the elements responsive to the request are the ones that are requested by serial identifier.

[00:05:05] Speaker 04:
What lines are you looking at on that page?

[00:05:09] Speaker 01:
Sorry, it was, again, that was 651.

[00:05:11] Speaker 04:
Yeah, I mean just because it seems to be a very important question of whether, given the waiver argument that's being made,

[00:05:20] Speaker 04:
for you to be able to respond and identify where you made the argument.

[00:05:24] Speaker 01:
Page 650, line 19 and 20.

[00:05:26] Speaker 03:
And then 651, starting on line 7.

[00:05:32] Speaker 01:
651, starting on line 7.

[00:05:37] Speaker 01:
The claim says responsive to mediate items or sent to said user responsive to said request is talking about the elements that are sent responsive

[00:05:45] Speaker 01:
to the request by serial identifier.

[00:05:47] Speaker 03:
Is that the first time you brought that up?

[00:05:49] Speaker 03:
Did you bring it up in the patent owner response?

[00:05:52] Speaker 01:
The petition did not make the new arguments that tease that out.

[00:06:01] Speaker 01:
The petition just said that elements in gross were sent faster than the playback rate.

[00:06:08] Speaker 01:
It didn't frame this as an issue.

[00:06:10] Speaker 01:
And we did argue in the patent owner response that every

[00:06:14] Speaker 01:
that it is the elements that are requested by serial identifier, that all of them have to be sent faster than the playback rate.

[00:06:22] Speaker 01:
That was in the petition.

[00:06:24] Speaker 01:
So our argument... I'm sorry.

[00:06:26] Speaker 01:
Excuse me.

[00:06:27] Speaker 01:
That was in the patent owner response.

[00:06:29] Speaker 03:
Where?

[00:06:53] Speaker 03:
You can wait till your reply time.

[00:07:12] Speaker 04:
Can I ask you another question relevant to this point, which is for the claim construction position.

[00:07:20] Speaker 04:
Are you relying primarily, I only see you relying on the plain claim language for your claim construction position.

[00:07:26] Speaker 04:
Do I understand that correctly?

[00:07:28] Speaker 01:
That we rely on the claim language?

[00:07:29] Speaker 01:
Yes, we rely on the claim language, obviously in light of the specification, but we rely on the claim language for the construction that the antecedent for said, let me get the exact language that we're referring to, the antecedent

[00:07:48] Speaker 01:
for that sending rate limitation, which is to send media data elements to the user system responsive to said requests.

[00:07:56] Speaker 01:
That the antecedent for that is the cause of Claim 10, in Claim 10, that says request specifying the identifiers of the requested data elements.

[00:08:06] Speaker 01:
So that when Claim 10 later on says, refers to said requests, it is request for the elements by their serial, by their serial identifiers.

[00:08:17] Speaker 01:
Those are the ones

[00:08:18] Speaker 01:
that have to be sent faster than the playback rate.

[00:08:22] Speaker 01:
And that's what they seek to blur on the other side.

[00:08:26] Speaker 01:
That's what the board sought to blur.

[00:08:28] Speaker 01:
The board did not focus, as we say that they had to, according to the claim language, on the elements that are requested by their serial identifiers.

[00:08:39] Speaker 03:
The claim language could have been written a little more clearly.

[00:08:44] Speaker 03:
I mean, it is a little squishy.

[00:08:46] Speaker 03:
The board is operating under the broadest reasonable interpretation rubric.

[00:08:52] Speaker 03:
And so when it says sending immediate data elements to the user responsive to said requests, it is a little on the vague side to understand what does that mean, responsive to said request.

[00:09:08] Speaker 03:
It could be, as you say, that it's precisely the very immediate data elements that were requested

[00:09:15] Speaker 03:
and specified by identifier, but responsive to is also a little opaque and could be understood to be including other data elements that come along with the precisely requested data elements.

[00:09:31] Speaker 03:
And so, I mean, if the claim it said caused the server to send the requested media data elements to the user system, I mean, that would be very clear.

[00:09:44] Speaker 03:
But here we've got maybe a little bit of wiggle room, and that's what I'm trying to understand.

[00:09:49] Speaker 01:
Well, I disagree.

[00:09:50] Speaker 01:
I would say it does say responsive to said request, which is referring to those specific requests.

[00:09:55] Speaker 01:
But furthermore, I would argue that that, and we do argue that that's an unreasonable interpretation in light of the specification.

[00:10:01] Speaker 01:
Because the specification makes very clear that specification gives six embodiments that are push embodiments, and then there's one different embodiment.

[00:10:12] Speaker 01:
We're talking about column 8.

[00:10:13] Speaker 01:
Right.

[00:10:14] Speaker 01:
One different embodiment here, which is a poll embodiment.

[00:10:17] Speaker 01:
And the specification is very clear.

[00:10:20] Speaker 01:
In this case, the server doesn't keep track of what's being sent to the client.

[00:10:27] Speaker 01:
The client is managing that process.

[00:10:30] Speaker 01:
So that is a poll.

[00:10:33] Speaker 01:
So when you start to interpret claim 10 more broadly than that,

[00:10:38] Speaker 01:
then you're just inconsistent with the technology that's disclosed for that embodiment.

[00:10:44] Speaker 01:
It's a pull.

[00:10:45] Speaker 04:
Can I ask you something?

[00:10:46] Speaker 04:
Do I understand your position to be that one of ordinary skill in the art reading column eight and the pull description would not, I guess, wouldn't think that this claim would result in an operative device without it having

[00:11:07] Speaker 04:
talking about pulling each data element as opposed to pulling multiple data elements at once, for example?

[00:11:17] Speaker 01:
Well, if the pull is going to work, if the client is now in charge of keeping its buffer at the proper level, then it's essential to that process that it knows that it's going to get the pieces of requests

[00:11:34] Speaker 01:
faster than the playback rate so that there's time between the pieces in order to adjust.

[00:11:40] Speaker 01:
Otherwise, there's no guarantee that it's going to be able to keep up.

[00:11:46] Speaker 01:
In order for this to work, the pieces that request have to get there faster than the playback rate for a client to be able to be in control.

[00:11:55] Speaker 01:
That's the assumption here.

[00:11:57] Speaker 01:
And the spec is also clear about that, that they're sent faster than the playback rate.

[00:12:01] Speaker 01:
So you're really getting away from pull.

[00:12:04] Speaker 01:
You're really inconsistent with poll when you start to read the claim that broadly.

[00:12:08] Speaker 01:
And that's our position on that.

[00:12:14] Speaker 01:
And I think in light of the spec, it has to be understood that way.

[00:12:17] Speaker 01:
Because otherwise, you don't have a poll embodiment that works.

[00:12:22] Speaker 05:
But is it correct then that the additional limitations that you are telling us about are not present in any of the subordinate claims?

[00:12:32] Speaker 01:
I'm sorry.

[00:12:32] Speaker 01:
I did not understand that.

[00:12:34] Speaker 05:
Limitations are not present in any of the subordinate claims.

[00:12:38] Speaker 01:
Certainly in claim 15.

[00:12:40] Speaker 01:
Certainly in claim 15 amplifies this.

[00:12:42] Speaker 01:
And if I'd like to turn to claim 15 so I don't use up all my time here.

[00:12:47] Speaker 01:
Claim 15, we think, is a very clear error by the board.

[00:12:51] Speaker 01:
Claim 15 is the one that actually recites the negative limitation.

[00:12:59] Speaker 01:
The server does not maintain a pointer into a buffer established within said server.

[00:13:04] Speaker 01:
for each said user.

[00:13:07] Speaker 01:
And this is, you know, appellants expert testified, it was unrebutted testimony that because Carmel's server streams autonomously after a given starting point via seek, right?

[00:13:26] Speaker 01:
So, you know, Carmel,

[00:13:28] Speaker 01:
In Carmel, Carmel does not request every element by a serial identifier.

[00:13:34] Speaker 01:
It identifies one identifier, and it tells the server to start streaming from that identifier.

[00:13:42] Speaker 01:
In order to do that, the server has to be able to keep track of the last element that is sent in order to know the next element that is sent.

[00:13:50] Speaker 01:
It has a pointer for that, and that's what the expert testified, and it's unrebutted.

[00:13:56] Speaker 01:
He said it couldn't operate without maintaining a pointer to the last element sent.

[00:14:01] Speaker 01:
He stated that to support the seek function, the server would need to maintain a pointer for each user to keep track.

[00:14:09] Speaker 03:
Sir, this is a substantial evidence standard of review that we have up here.

[00:14:15] Speaker 03:
I understand you have a piece of evidence for a declaration that you say suggests that Carmel has the

[00:14:26] Speaker 03:
server pointer, but at the same time, the board found otherwise, and then also found that Carmel talks about all these client-side controls and record keeping.

[00:14:37] Speaker 01:
Right.

[00:14:38] Speaker 03:
And also, in the combination of those two things, the absence of an express disclosure or necessary implication that a server pointer exists in Carmel, plus all these client-side controls in Carmel, the board found and

[00:14:56] Speaker 03:
Why wouldn't it be reasonable to find that there isn't a server pointer that's needed and all the client-side controls are taking care of this?

[00:15:06] Speaker 01:
Judge Chen, the board was in error in that finding, completely in error.

[00:15:11] Speaker 01:
The client-side control that the board was referring to was the language and the specification about synchronization of playback.

[00:15:19] Speaker 01:
Yes, the client needs to synchronize on its side, after it receives the elements, needs to synchronize playback.

[00:15:26] Speaker 01:
It has nothing to do with transmission from the server.

[00:15:30] Speaker 01:
It's misplaced reliance.

[00:15:32] Speaker 01:
It's completely off base.

[00:15:34] Speaker 01:
That does not support the conclusion that the board was just simply in error on that.

[00:15:41] Speaker 01:
This is not a pointer on the server side telling the server which element to send next.

[00:15:46] Speaker 01:
This is on the client side telling the client playback device which piece to play back through the speaker next.

[00:15:54] Speaker 01:
That's clearly erroneous.

[00:15:56] Speaker 01:
And I would submit that the board had no basis for its statements about client-side control, that they're just misplaced.

[00:16:07] Speaker 01:
And I'd like to reserve the balance of my time.

[00:16:09] Speaker 05:
So we will save you rebuttal time.

[00:16:11] Speaker 05:
And let's hear from Mr. Faulkner.

[00:16:27] Speaker 00:
May it please the court.

[00:16:29] Speaker 00:
The petitioners in the IPR have relied on the same evidence in Carmel as meeting the sending at a rate faster than playback limitation from the beginning of the petition.

[00:16:40] Speaker 00:
That evidence is on the appendix page 195.

[00:16:44] Speaker 00:
And there we cite first the general disclosure of sending at a rate faster than playback.

[00:16:52] Speaker 04:
Can I interrupt you for a minute to ask you about the claim construction issue?

[00:16:56] Speaker 04:
One thing that I thought was kind of odd is that the board in its decision on claim construction, instead of talking about the claim language and the words used in the patent specification, discuss the construction of the claim in the context of the prior art by using the terms links, talking about single links and multiple links.

[00:17:20] Speaker 04:
Do you know why it is that the board was talking about the prior art to construe this claim?

[00:17:25] Speaker 04:
Normally, you would look at the intrinsic evidence.

[00:17:28] Speaker 04:
You might not use words that are in the prior art.

[00:17:31] Speaker 04:
You'd interpret the claim.

[00:17:32] Speaker 04:
And then you'd, for anticipation, there's a factual question of whether the prior art teaches that claim limitation as properly interpreted.

[00:17:40] Speaker 04:
So do you know how the board did that?

[00:17:43] Speaker 00:
So I think it has to do with how the issue was presented to the board.

[00:17:47] Speaker 00:
Here, we argued that multiple links, the overall rate of items sent over multiple links, met the claim element.

[00:17:54] Speaker 00:
Uh, the patent owner argued that could not meet the claim element and neither party had presented a claim construction.

[00:18:01] Speaker 04:
So I think the board's decision does talk about, uh, it does provide a claim construction, right?

[00:18:06] Speaker 04:
I mean, it's in a section of the board's opinion titled claim construction.

[00:18:11] Speaker 00:
Correct.

[00:18:12] Speaker 00:
And I think the board is saying that there's nothing in particular, there's nothing in the plain language of the claim that limits it to the rate over a single link.

[00:18:20] Speaker 04:
But isn't it kind of odd to have the board talk about the prior art and use words in the prior art to interpret a claim?

[00:18:27] Speaker 00:
Certainly the prior art is not how the claim should be interpreted.

[00:18:32] Speaker 00:
It does not teach on that.

[00:18:34] Speaker 00:
That's correct.

[00:18:35] Speaker 00:
But I think what the board is saying is that there's nothing in this claim language, using the broadest reasonable interpretation standard, that would preclude the multiple link embodiment.

[00:18:45] Speaker 00:
And since that was the embodiment

[00:18:47] Speaker 00:
They were trying to consider whether or not it fell within the claim.

[00:18:50] Speaker 00:
I think that they used that as context for discussing.

[00:18:53] Speaker 04:
Would you say that's kind of harmless error by the board?

[00:18:56] Speaker 04:
Because I mean, the question really is first to interpret the claim, and then you're to look at does the prior, it's a factual question, right?

[00:19:04] Speaker 04:
We would be looking at is there substantial evidence to support the conclusion that Carmel teaches that claim limitation is properly interpreted.

[00:19:14] Speaker 00:
Well, I think ultimately the court construed the claim term correctly in that.

[00:19:20] Speaker 04:
By saying that it could be multiple links?

[00:19:23] Speaker 00:
Yes, that it could be that rate is not limited to the rate over a single link.

[00:19:28] Speaker 00:
Essentially, the patent owner was asking the board to read in a limitation.

[00:19:32] Speaker 04:
Why is that not the resolution of a factual issue of whether the prior teaches the claim limitation?

[00:19:39] Speaker 00:
So the board saw it as an implicit claim construction argument on the side of the patent owner.

[00:19:43] Speaker 00:
They state that the patent owner has implicitly argued that the claim is more limited than the claim language.

[00:19:50] Speaker 04:
Do you think that that's a proper way to resolve it, because they're saying that the prior reference doesn't teach the claim element, that it should be resolved as a claim construction issue?

[00:20:00] Speaker 00:
I think the board has to resolve the breadth of the claim in that situation to know, can rates

[00:20:07] Speaker 00:
is rates as limited as the patent owner's asking.

[00:20:11] Speaker 00:
And so that, I think, is what the board set out to do.

[00:20:15] Speaker 03:
The premise of the board's anticipation finding is that you look at all the data elements that are being sent over in Carmel and then figure out what the overall rate is, rather than just looking at the rate

[00:20:36] Speaker 03:
of the actual requested media data element or elements that's being transferred over?

[00:20:42] Speaker 03:
Is that right?

[00:20:44] Speaker 00:
I would say I would have a slight change to that.

[00:20:47] Speaker 00:
I think it was they said you look to the rate of the overall data elements, that part I agree with, rather than look to only the data elements over a single link.

[00:20:56] Speaker 00:
The board didn't have to address this entire issue of whether, in addition to being elements sent over multiple links,

[00:21:06] Speaker 00:
Whether the claim further require that each of those also be requested by serial identifier, that's the issue that had never been raised below.

[00:21:15] Speaker 00:
And so the board did not address that.

[00:21:16] Speaker 04:
Do you agree that that, though, was discussed during the argument before the board?

[00:21:22] Speaker 00:
So it was discussed only after the board raised the issue itself.

[00:21:27] Speaker 00:
So the entire argument before the board in the reply brief is this first argument of, can it be multiple links instead of one link?

[00:21:35] Speaker 00:
And that argument really didn't depend on this serial identifier, nor did it depend on the interplay between the two sections.

[00:21:43] Speaker 00:
There was no discussion of the interplay in the last two sections of the claim in the briefs either.

[00:21:49] Speaker 04:
When you say in the briefs, I just want to make sure I'm following.

[00:21:51] Speaker 04:
Which briefs?

[00:21:52] Speaker 04:
You're saying the patent owner response?

[00:21:54] Speaker 00:
Sure.

[00:21:54] Speaker 00:
The patent owner response below.

[00:21:55] Speaker 00:
And the board has a scheduling order in this case that says any argument not raised in the patent owner response is waived.

[00:22:02] Speaker 00:
And here, the word serial doesn't appear in the patent owner response.

[00:22:05] Speaker 04:
But the board never said anything was waived.

[00:22:07] Speaker 04:
Do I remember that correctly?

[00:22:09] Speaker 04:
Did the board say that they waived anything?

[00:22:13] Speaker 00:
No.

[00:22:13] Speaker 00:
They did not make a waiver finding.

[00:22:15] Speaker 00:
What they did was they said because it had not been briefed, the board was not going to address it.

[00:22:21] Speaker 00:
It did note that this interplay between these last two claim elements.

[00:22:24] Speaker 04:
It said this specific argument hadn't been raised, so it wasn't going to address it.

[00:22:27] Speaker 04:
Oh, that's the footnote.

[00:22:28] Speaker 00:
Yes, footnote three.

[00:22:30] Speaker 00:
Yeah.

[00:22:30] Speaker 00:
And so this is the argument.

[00:22:32] Speaker 00:
that had never come up, this interplay between the two parts of the claim and this whole idea of whether each item is requested by serial identifier.

[00:22:41] Speaker 00:
This came up for the first time at oral argument.

[00:22:44] Speaker 00:
And it actually came up when the judge raised the issue and he asked the question.

[00:22:48] Speaker 00:
The reason he asked the question is because there was a third disclosure we relied on that's not an issue here.

[00:22:53] Speaker 00:
And that third disclosure involved resizing the media data elements to send them faster.

[00:22:59] Speaker 00:
And the judge thought that resizing of those

[00:23:02] Speaker 00:
that might make them different media data elements.

[00:23:05] Speaker 00:
So he raises this question about the interplay of the last two.

[00:23:08] Speaker 00:
It was an argument that had never been raised.

[00:23:10] Speaker 00:
And building off that, there's a few scattered statements about serial identifiers made by the patent owner after the judge raised it.

[00:23:20] Speaker 00:
The judges ultimately, because it had not been briefed, declined to rule on that.

[00:23:24] Speaker 04:
Can I ask you a separate question, which is, do you agree, though, that at least what was argued in the patent owner response

[00:23:32] Speaker 04:
was that the data rate refers to the rate for each slice in Carmel?

[00:23:37] Speaker 00:
Correct.

[00:23:38] Speaker 00:
They did argue the data rates each slice, but now they're further arguing the data rate also has to be for each slice requested by serial identifier, which is a further limitation on what they said before.

[00:23:51] Speaker 00:
Because the PTAB already found you can have all these links and send a bunch of data elements over.

[00:23:58] Speaker 00:
And that's sufficient to meet it.

[00:24:00] Speaker 00:
It doesn't matter that they're using multiple links.

[00:24:03] Speaker 00:
Now they're arguing, even if we accept what the PTAB decided there, that it can be the multiple links, it's still not met because we think the claim also requires that each one be requested by serial identifier.

[00:24:18] Speaker 00:
That's the new issue that we've been discussing here for the first time.

[00:24:22] Speaker 05:
But you can't really, when an issue appears for the first time in the PTAB decision,

[00:24:28] Speaker 05:
They have to have an opportunity to argue it.

[00:24:34] Speaker 05:
Isn't that so, one way or another?

[00:24:36] Speaker 00:
Well, they've had the opportunity to argue against these disclosures of Carmel from the beginning.

[00:24:41] Speaker 00:
And they've argued in the beginning that this disclosure is not met because it uses multiple links.

[00:24:47] Speaker 00:
They could have at that time argued that each one also must be requested by serial identifier.

[00:24:52] Speaker 04:
So they've had a- Do you agree, though, that they didn't seek a construction, that it was limited to a single link?

[00:24:58] Speaker 04:
That was not a construction that they saw.

[00:25:00] Speaker 00:
They didn't seek it explicitly.

[00:25:02] Speaker 00:
They simply stated Carmel can't meet it because the claim requires using a single link.

[00:25:08] Speaker 04:
Well, or because Carmel only reaches the data rate specified by the claim by sending over multiple links.

[00:25:16] Speaker 00:
Right?

[00:25:16] Speaker 00:
Right.

[00:25:17] Speaker 00:
And that is not within the scope of the claim.

[00:25:18] Speaker 04:
So I just want to make sure that we were in agreement that that was not a claim construction argument.

[00:25:22] Speaker 04:
That's an anticipation argument.

[00:25:25] Speaker 00:
Correct, yes, and the board found that implicitly though they were ascribing a certain meaning to the claim and making that argument.

[00:25:33] Speaker 04:
One of the questions we're going to consider though is whether the board erred in doing that, right?

[00:25:41] Speaker 00:
Correct.

[00:25:42] Speaker 00:
So in terms of the construction itself, if we look at the last two clauses of the claim,

[00:25:50] Speaker 00:
The second to last clause asks that we request one or more media data elements by serial identifier.

[00:25:57] Speaker 00:
That can be met by identifying one media data element by serial identifier.

[00:26:02] Speaker 00:
For example, you request send media data elements starting at element 42.

[00:26:07] Speaker 00:
You've met the first of those two clauses.

[00:26:11] Speaker 00:
The second clause says you now must send media data elements.

[00:26:14] Speaker 00:
It doesn't say send media data elements.

[00:26:16] Speaker 00:
You must send some media data elements that are responsive to that request that was just made.

[00:26:21] Speaker 00:
That can be met here, as in Carmel, where you would request, you've requested element 42 and following, and then you now send element 42, 43, 44, and 45.

[00:26:33] Speaker 00:
Those are responsive to the request.

[00:26:35] Speaker 00:
They were not each separately requested by serial identifier, but they do meet the language of the claim here.

[00:26:41] Speaker 00:
And because of that, so the language isn't so limited.

[00:26:47] Speaker 03:
Why wouldn't the better reading so that the claim wouldn't

[00:26:51] Speaker 03:
Why wouldn't the internal logic of the claim call for the media data elements being sent responsive to said request be the very requested media data elements that's recited in the clause above?

[00:27:09] Speaker 00:
Uh, that'd be one way to interpret it.

[00:27:11] Speaker 00:
Certainly that would be more clear if it had the word said in it and referred back to those media data elements.

[00:27:15] Speaker 03:
Do you agree that in the specification, that's the specific conception of the embodiment described in the specification of column A?

[00:27:23] Speaker 00:
So the specification describes requesting items.

[00:27:26] Speaker 03:
Right, but do you agree that that's the very conception that's described in column A?

[00:27:32] Speaker 03:
That you request media data elements according to their specified identifiers

[00:27:38] Speaker 03:
and then you send those very requested media data elements.

[00:27:42] Speaker 00:
Yes, the preferred embodiment is a TCP embodiment.

[00:27:45] Speaker 00:
And so TCP does that.

[00:27:46] Speaker 00:
It requests each one by zero identifier.

[00:27:49] Speaker 03:
So I do request, but then it also sends those same very requested media data elements.

[00:27:55] Speaker 00:
Correct.

[00:27:56] Speaker 00:
Correct.

[00:27:57] Speaker 00:
So yes, if we're going to use the embodiment in the specification and hold the claim to that, then yes, you could so limit it.

[00:28:05] Speaker 00:
But sort of moving on from that,

[00:28:08] Speaker 00:
Even if this is considered and the narrow construction is determined to be the right one, the limitation is still met by the two disclosures we've relied upon in Carmel.

[00:28:18] Speaker 00:
And the board sort of implicitly notes this when the board says it doesn't need to consider this issue in order to rely on what it has relied on in the... At some point, didn't the board observe that the transmission across any

[00:28:35] Speaker 03:
Single Lincoln Carmel is slower than the playback, right?

[00:28:40] Speaker 00:
When you're opening multiple links, the board did observe that's true.

[00:28:44] Speaker 00:
So that's in a discussion of the board.

[00:28:45] Speaker 00:
The board's discussion of the multiple link embodiment.

[00:28:49] Speaker 03:
So why wouldn't that be contradicting what you just said?

[00:28:53] Speaker 00:
Well, because so the idea is the board has already decided that the rate could be the rate of achieved in the aggregate over multiple links.

[00:29:02] Speaker 00:
So then the question is, if it must also be each one requested by serial identifier, does Carmel, in the multiple link embodiment, disclose requesting by serial identifier?

[00:29:14] Speaker 00:
Are each one of those over the multiple links requested by serial identifier?

[00:29:18] Speaker 00:
And here they are.

[00:29:19] Speaker 00:
Carmel uses the same TCP mechanism, which will request by serial identifier.

[00:29:24] Speaker 00:
So Carmel opens multiple links.

[00:29:27] Speaker 00:
It requests the media data elements using TCP by serial identifier.

[00:29:32] Speaker 00:
And those media data elements, let's say there's 10 links open and 10 elements come over, those media data elements are transmitted faster than they are played back.

[00:29:42] Speaker 04:
Did you make that argument below and before this court?

[00:29:47] Speaker 00:
So we have made that argument before this court.

[00:29:49] Speaker 04:
Where would that be in your red group?

[00:29:52] Speaker 00:
Sure.

[00:30:07] Speaker 00:
So starting on page 25, this is where we explain that Carmel teaches sending at a rate more rapid under even the narrower construction that does require sending each one by serial identifier.

[00:30:29] Speaker 00:
I believe it first addressed Carmel's general disclosure.

[00:30:32] Speaker 00:
So Carmel generally says send

[00:30:35] Speaker 00:
rate send media data elements, preferably at or faster than the playback rate.

[00:30:40] Speaker 00:
So that general disclosure applies to just the first element that's sent over.

[00:30:44] Speaker 00:
That one is sent faster in playback.

[00:30:46] Speaker 00:
But then we also, starting on page 28, discuss this multiple links.

[00:30:52] Speaker 00:
And so we say it also describes faster in playback as a lag recovery mechanism.

[00:30:57] Speaker 00:
And then on page 29 is where we set forth the substantial evidence that supports the fact that each of these requests is made by serial identifier.

[00:31:06] Speaker 04:
I'm sorry.

[00:31:07] Speaker 04:
Where are you on page 29?

[00:31:09] Speaker 00:
Sure.

[00:31:09] Speaker 00:
So I guess in the middle of the full paragraph on there, it says, Carmel discloses that when opening the multiple links, the client does request each of these slicers by identifier.

[00:31:25] Speaker 04:
Got it.

[00:31:26] Speaker 04:
This is yours.

[00:31:27] Speaker 04:
I see where it's very clearly made, where it says, even assuming WAG's construction is correct.

[00:31:31] Speaker 04:
Thank you.

[00:31:32] Speaker 00:
Yeah.

[00:31:32] Speaker 00:
And so first, the evidence is the fact that the clients are the ones initiating these requests.

[00:31:37] Speaker 00:
Just like in the patent system, Carmel, at column 10, very clearly describes a system where the client is monitoring the rate of data coming in and making adjustments.

[00:31:49] Speaker 00:
Then Carmel discloses that the way that those links are open is using HTTP.

[00:31:54] Speaker 00:
HTTP was known at the time to use TCP.

[00:31:58] Speaker 00:
Patent owner's expert conceded that in his deposition.

[00:32:01] Speaker 00:
So what we have is clients making requests using TCP.

[00:32:06] Speaker 00:
That's the exact same disclosure that's in the 141 patent.

[00:32:09] Speaker 00:
Clients making requests using TCP.

[00:32:12] Speaker 00:
We have substantial evidence.

[00:32:14] Speaker 00:
We have expert testimony that TCP does make requests by serial identifier.

[00:32:19] Speaker 00:
And that's PENIX page 330.

[00:32:25] Speaker 00:
Page 59 is the expert, our expert, explaining that the TCP protocol requires requests for data specified sequence number of the desired data packet.

[00:32:38] Speaker 00:
So those are each requested by serial identifier, even if the narrow constructions adopted.

[00:32:43] Speaker 00:
There was some discussion in the reply brief in today that Carmel doesn't actually... Could you just point me somewhere that confirms that

[00:32:55] Speaker 03:
When you use TCP, you're transmitting the data at a rate that's faster than the playback rate.

[00:33:03] Speaker 00:
So TCP doesn't necessarily mean you're sending it a faster and playback rate.

[00:33:09] Speaker 00:
It just means that you're requesting a bi-zero identifier.

[00:33:12] Speaker 00:
The request faster and playback rate is the Carmel disclosure.

[00:33:17] Speaker 00:
And there's two separate disclosures.

[00:33:19] Speaker 00:
First, Carmel says that you should use a transmission rate that's generally equal to or faster than playback.

[00:33:26] Speaker 03:
That's overall, though.

[00:33:27] Speaker 00:
Overall.

[00:33:29] Speaker 00:
The disclosure, yeah, is general.

[00:33:31] Speaker 00:
Then for the multiple links embodiment, that's used to recover from a lag scenario.

[00:33:37] Speaker 00:
So you've fallen behind real time in playback, and you now have to recover and build up the buffer.

[00:33:42] Speaker 00:
So to recover, you have to send media data elements faster than their playback.

[00:33:47] Speaker 00:
Otherwise, you would never recover.

[00:33:49] Speaker 00:
So the entire reason for the multiple links embodiment is we're now going to open more links.

[00:33:54] Speaker 05:
It does seem as if the patent owner has stated that there are advantages over Carmel.

[00:34:01] Speaker 05:
Is the thrust of how this has come out has been that the way they're claiming it does not distinguish those differences, or that there are no differences that could conceivably be distinguished?

[00:34:16] Speaker 00:
So I think it's both, as a matter of fact.

[00:34:19] Speaker 00:
I think the claim is not as narrow as the patent owner has put forth.

[00:34:23] Speaker 00:
The plain reading of the language in the claim under the broadest reasonable interpretation doesn't require these extra features such as using a single link and requesting faster than playback.

[00:34:34] Speaker 00:
That said, Carmel discloses the same underlying system that their patent discloses so that any narrow reading of these claims is still going to be met by Carmel because Carmel is, in column 10, Carmel describes a client-side request

[00:34:51] Speaker 00:
It says explicitly the time stamps are used to have it monitor the pace of information coming in and if necessary open more links.

[00:35:03] Speaker 00:
So Carmel is a system that uses client side requests just like the 141 pattern.

[00:35:10] Speaker 00:
It explicitly says it's going to send media faster than playback and discloses ways to do that and then it also

[00:35:18] Speaker 00:
uses the same transport mechanism, TCP, to do that.

[00:35:22] Speaker 04:
I understand the patent owner to be saying that data rate refers to the data rate for each slice, not the data rate over which multiple slices are sent.

[00:35:33] Speaker 04:
To the extent that that's the proper construction, do you still maintain that Carmel teaches that data rate?

[00:35:41] Speaker 04:
I mean, as I understand it, you need to rely on the sending of the data collectively

[00:35:48] Speaker 04:
you know, five slices, for example.

[00:35:52] Speaker 00:
So not necessarily.

[00:35:53] Speaker 00:
That is an embodiment in Carmel, and Carmel does disclose that's a way to recover from lag.

[00:36:00] Speaker 00:
But Carmel, in column two, says, and this is just describing the general system, that when the data stream comprises... Can you tell me, I want to follow along, so if you can just tell me, you said column two, but what lines are you reading?

[00:36:18] Speaker 00:
So I'm starting at line 50, column 2.

[00:36:23] Speaker 00:
And it describes, in some preferred embodiments of the present invention, the transmitted computer and the clients monitoring the upload and downloading of data to and from the server.

[00:36:34] Speaker 00:
So there's a server in between an uploading computer and a downloading computer.

[00:36:40] Speaker 00:
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,

[00:36:47] Speaker 00:
When the data stream comprises multimedia data, the data rate should be generally equal to or faster than the rate at which data is generated at the transmitting computer.

[00:36:59] Speaker 00:
And here it's discussing two sides of the system.

[00:37:04] Speaker 00:
In figure two, there's an uploading computer that's recording video and uploading it to the server.

[00:37:15] Speaker 00:
And then there's a client computer 30 that's downloading from the server.

[00:37:19] Speaker 00:
And throughout this patent, it describes those two processes.

[00:37:23] Speaker 00:
And at the end of the patent, it says you can use the teachings from one process to the other.

[00:37:28] Speaker 00:
But what it's saying is it's those two machines on the two sides that are monitoring the rate.

[00:37:33] Speaker 00:
But generally, the goal is to have a rate that is equal to or faster than the rate at which data are generated.

[00:37:41] Speaker 04:
But how do I know that that data rate is the rate for each individual slice?

[00:37:47] Speaker 04:
And how do I know that that's not referring to the bandwidth and having multiple slices of data sent at once?

[00:37:53] Speaker 04:
How do I know that?

[00:37:55] Speaker 04:
I mean, this is kind of a general description here.

[00:38:00] Speaker 04:
And so I'm wondering, is there something else that explains to me exactly what this means?

[00:38:12] Speaker 00:
There's not other than we know that Carmel starts by opening a link and only will open additional links should it fall behind in playback.

[00:38:22] Speaker 00:
So the disclosure suggests that we have one link.

[00:38:26] Speaker 00:
It should be generally equal to or faster.

[00:38:28] Speaker 00:
If it becomes slower, we will then open multiple links.

[00:38:32] Speaker 00:
That's a secondary mechanism if the primary mechanism is not doing the job by itself.

[00:38:39] Speaker 00:
But that is, there's just this general statement and then later statements of how to recover from lag.

[00:38:47] Speaker 05:
Let's hear from the other side and we'll continue when we get to the next case as well.

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

[00:38:58] Speaker 05:
Mr. Eggerson.

[00:38:59] Speaker 01:
Thank you.

[00:39:00] Speaker 01:
I'd like to address, first of all, the issue of multiple links.

[00:39:07] Speaker 01:
The petition did

[00:39:08] Speaker 01:
mentioned multiple links, but it did not make any arguments about aggregating the rate, the rate over multiple links.

[00:39:15] Speaker 01:
That's, it was just not in the petition, did not come up until the response to the, the reply to the patent owner's response.

[00:39:24] Speaker 01:
And that's really the genesis of this, of, of how the, of how, of how the arguments evolved and why we ended up at our, at oral argument having to address, having to address that aspect for the first time, which then raises the issues about individual pieces,

[00:39:39] Speaker 01:
It brings out all of that.

[00:39:41] Speaker 01:
And there was nothing in the petition about aggregating the rate over multiple links.

[00:39:47] Speaker 01:
There was also nothing in the petition trying to make an argument that the limitation about requesting slices by their ID was satisfied by TCP.

[00:39:57] Speaker 01:
There's nothing in the petition about that.

[00:39:59] Speaker 01:
It's completely off base.

[00:40:01] Speaker 01:
TCP is a low-level protocol that concerns requesting bytes, not

[00:40:06] Speaker 01:
media data elements.

[00:40:08] Speaker 01:
It's totally off base.

[00:40:09] Speaker 01:
There's no foundation for it in the record satisfying this limitation, not the basis of the board's decision.

[00:40:17] Speaker 01:
It's really a red herring.

[00:40:18] Speaker 01:
I also note that my adversary didn't say anything to address claim 15, where we say that our position is that the board was just off base in finding that there were client-side control mechanisms that moderated

[00:40:37] Speaker 01:
that moderated the transmission.

[00:40:40] Speaker 01:
It might moderate opening individual links, but it's not telling the server which piece to send next.

[00:40:47] Speaker 01:
Client is not doing that.

[00:40:49] Speaker 01:
TCP, first of all, is not even properly in the record here as far as attaching this claim is concerned, but TCP doesn't do that either.

[00:41:00] Speaker 01:
TCP is request for bytes at a low level.

[00:41:02] Speaker 01:
It's not media data elements.

[00:41:06] Speaker 01:
There's really nothing on claim 15.

[00:41:08] Speaker 01:
The board was wrong on its characterization of client-side processes because those processes are internal to the client, not concerning communication with the server.

[00:41:22] Speaker 01:
So I think that pretty much sums it up, unless the panel has any further questions for me.

[00:41:32] Speaker 05:
No, I think we're all right on this case.

[00:41:36] Speaker 05:
All right, thank you.

[00:41:37] Speaker 05:
So this case is taken under submission and we shall proceed when you're ready.