[00:00:00] Speaker 02:
2021-1511 Broadcom Corporation versus Renaissance Electronics.

[00:00:10] Speaker 02:
Mr. Yabrnitsky, please proceed.

[00:00:14] Speaker 00:
Thank you, Your Honor.

[00:00:15] Speaker 00:
Good morning, Your Honors.

[00:00:16] Speaker 00:
Tom Yabrnitsky on behalf of Appellant Broadcom Corporation.

[00:00:20] Speaker 00:
Broadcom challenges the board's determination that Foster alone discloses each and every limitation of claims one, two, and five

[00:00:28] Speaker 00:
and that the combination of Foster and C renders obvious Claim 5.

[00:00:32] Speaker 00:
The words used in each claim limitation have meaning, and when properly construed, it's Broadcom's contention that the board failed to establish that Foster or C disclosed the limitations of Claims 1, 2, and 5.

[00:00:43] Speaker 00:
Unless Your Honors have a different preference, I'd like to start by discussing Claim 2, then address Claim 5, and then finally Claim 1.

[00:00:50] Speaker 02:
As you wish.

[00:00:53] Speaker 00:
Claim 2 requires the Memory Access Unit, or MAU,

[00:00:56] Speaker 00:
to receive requests for blocks of pixels that are whole blocks of pixels.

[00:01:00] Speaker 00:
The board wrongly held that claim two does not require requests for whole blocks of pixels, and based on that wrong construction, determined that Foster's request for lines of pixels discloses the limitations of claim two.

[00:01:13] Speaker 00:
Renaissance wrongly dismisses the board's erroneous construction by arguing that Renaissance, that Foster does not need to actually receive the request for whole blocks of pixels.

[00:01:22] Speaker 00:
It only needs to have an input port that is capable of receiving the request

[00:01:26] Speaker 00:
which they assert was found below.

[00:01:28] Speaker 00:
However, Renaissance is wrong for at least two reasons.

[00:01:31] Speaker 00:
The first reason is that there is no finding below that the import port is capable of receiving a request for whole blocks of pixels.

[00:01:39] Speaker 00:
When addressing Broadcom's argument that Claim2's request for blocks of pixels must be for request for whole blocks of pixels, the board simply dismissed Broadcom's construction as incorrect and held that the term request for blocks of pixels can be request for any size or configuration of pixels.

[00:01:56] Speaker 00:
The board did not find that Foster's input port was capable of receiving requests for whole blocks of pixels.

[00:02:01] Speaker 00:
And that's clear if you look at APPX 16 and 17.

[00:02:05] Speaker 00:
Instead, the board only found that Foster's input port is capable of receiving pixels generally.

[00:02:12] Speaker 00:
Accordingly, there was no finding that Foster's input port was capable of receiving requests for whole blocks of pixels as claim two requires.

[00:02:20] Speaker 00:
The second reason Renaissance's capability argument fails is that the term request for blocks of pixels.

[00:02:25] Speaker 01:
This is Judge Stowell.

[00:02:26] Speaker 01:
I noticed that during your argument, they keep on saying whole, whole blocks of pixels.

[00:02:30] Speaker 01:
How do you think that changes the meaning of the phrase request for blocks of pixels?

[00:02:36] Speaker 00:
Your Honor, we don't believe it changes the meaning of the term.

[00:02:39] Speaker 00:
We believe that request for blocks of pixels, the plain and ordinary meaning of that term, requires request.

[00:02:45] Speaker 00:
And those requests are for whole blocks of pixels.

[00:02:49] Speaker 01:
What's home blocks versus block?

[00:02:53] Speaker 00:
Correct.

[00:02:54] Speaker 00:
Correct, Your Honor.

[00:02:54] Speaker 00:
We believe that the plain language of the claim, requests for blocks of pixels, is clear.

[00:02:58] Speaker 00:
It's requests for blocks of pixels.

[00:03:01] Speaker 00:
And that each request has to be for a full block.

[00:03:04] Speaker 01:
What do you think a block has to be?

[00:03:06] Speaker 01:
That's what I'm trying to figure out.

[00:03:07] Speaker 01:
You say home blocks, and I'm getting confused.

[00:03:09] Speaker 01:
So what is a block?

[00:03:11] Speaker 01:
What's blocks of pixels?

[00:03:13] Speaker 01:
Tell me, is it two or more pixels?

[00:03:15] Speaker 01:
What is it?

[00:03:17] Speaker 00:
And as the specification makes clear, they're a square block of pixels.

[00:03:23] Speaker 00:
The specification describes blocks as small as 2 by 2 and as large as 21 by 21.

[00:03:28] Speaker 00:
And importantly, to the application of what is a block to the foster limitation, Broadcom's expert opined that a row of pixels is not a block.

[00:03:39] Speaker 00:
And that testimony was unrebutted.

[00:03:41] Speaker 00:
And that's in the APPX 1671 paragraph 54 of her declaration.

[00:03:46] Speaker 00:
So importantly to the application of what is a block, a line of pixels as Foster describes is not a block and that is all that Foster discloses.

[00:03:58] Speaker 01:
Do you think that the board was obligated to accept that testimony, that fact testimony instead of relying on the patent itself and other intrinsic evidence to make an interpretation?

[00:04:15] Speaker 00:
No, Your Honor.

[00:04:16] Speaker 00:
A fulsome claim construction analysis requires a look at the specification and the claim language.

[00:04:25] Speaker 00:
And we believe, as we explain in our briefing, both of those dictate that a block of pixels is a block as small as 2 by 2 as large as 21 by 21.

[00:04:34] Speaker 00:
The board didn't actually conduct a fulsome analysis of the specification to disregard Broadcom's proposed construction.

[00:04:43] Speaker 00:
They simply just concluded without any citations to the specification that the claim language or claim to request blocks of pixels can be for anything and there's no need for a one-to-one correspondence between a request and a block.

[00:04:59] Speaker 01:
Neither view of being a block could be one by one.

[00:05:04] Speaker 00:
Well, I would disagree with that, Your Honor.

[00:05:07] Speaker 00:
One by one at that point is just a single pixel.

[00:05:10] Speaker 00:
And that would not be a block.

[00:05:12] Speaker 00:
A pixel is a fundamental unit that is used and combined to build a block, which would be, you know, at a minimum of two by two.

[00:05:20] Speaker 00:
But a single pixel, one by one.

[00:05:23] Speaker 01:
Your view is it can't be a two by one.

[00:05:27] Speaker 00:
Correct, Your Honor, because at that point, that is just a line of pixels.

[00:05:32] Speaker 00:
That's not described as a block anywhere in the specification.

[00:05:35] Speaker 00:
And the unrebutted testimony of our expert says that a line, a person skilled in the art reading the specification wouldn't consider a line of pixels to be a block.

[00:05:46] Speaker 02:
Okay.

[00:05:49] Speaker 00:
The, and going back to the second reason why the capability argument does not work and fails is because the full scope of claims two and five

[00:06:02] Speaker 00:
requires the memory access unit to actually receive requests for blocks of pixels because the logic limitation in both of those claims actually use the request for blocks of pixels.

[00:06:13] Speaker 00:
Specifically, claim two recites logic for generating the list of addresses from the request for blocks of pixels and claim five recites wherein the logic generates the access request based on sizes of each of the requests for blocks of pixels.

[00:06:27] Speaker 00:
The requirements and the full scope of those claims require the memory access unit to actually receive the request for blocks of pixels.

[00:06:38] Speaker 00:
As to the proper construction of the claim, as we discussed, the specification and both the plain language of the claim dictate that it is request blocks of pixels are, you know, as small as two by two or as large as 21 by 21, and that's supported by the specification and our expert's unrebutted testimony, all which is cited in our briefing.

[00:06:59] Speaker 00:
Barring any other questions on claim two from your honors, I'll move on to claim five.

[00:07:04] Speaker 00:
Please.

[00:07:06] Speaker 00:
Claim five requires the memory access unit's logic to generate the output memory request using the size of the input request for blocks of pixels and the memory addresses generated by the logic of claim two.

[00:07:18] Speaker 00:
The board determined that claim five is rendered obvious by foster alone and the combination of foster and C, and Broadcom appeals both those determinations.

[00:07:27] Speaker 00:
As to the board's determination that Foster alone discloses claim five's limitations, Broadcom contends that the board can use the input and the output request.

[00:07:35] Speaker 00:
The board relied on Foster's optimizations as disclosing claim five's limitations.

[00:07:40] Speaker 00:
However, Foster's optimizations do not use any information related to the input request.

[00:07:45] Speaker 00:
Foster looks to the size of the data request, which is the output request, and determines if the size of the data request is compliant with the BUS protocol that it must be transmitted over in order to reach memory.

[00:07:56] Speaker 00:
As RODCOM shows in the annotated version of Foster Figure 8 on page 12 of its gray brief, the optimizations are performed on the output data request with no consideration of the sizes of the input request or blocks of pixels.

[00:08:09] Speaker 00:
And that is actually also what the ALJ found in the co-pending, in the ITC case below.

[00:08:18] Speaker 00:
Moving on to the board's determination of the combination of Foster and C renders obvious,

[00:08:22] Speaker 00:
Claim 5, Broadcom raises three independent reasons why the board's determination should be reversed.

[00:08:28] Speaker 00:
First is that the board improperly relied on arguments related to the motivation to combine Foster and C that Renaissance presented for Claim 1 and then waived at the oral argument.

[00:08:37] Speaker 00:
For Claim 1, Renaissance only relied on the combination of Foster and C to argue that Claim 1 was obvious based on Renaissance's proposed claim construction positions.

[00:08:48] Speaker 00:
Then at oral argument, Renaissance abandoned their claim construction positions.

[00:08:52] Speaker 00:
The board acknowledged that it did not have to address the combination of Foster and C for claim one based on petitioner's waiver.

[00:08:59] Speaker 00:
But then in their final written decision when discussing claim five, the board reached back to claim one and relied on the arguments that Renaissance presented for claim one under their, Renaissance's proposed constructions to find a motivation to combine Foster and C, which had nothing to do for the reasons for combining Foster and C with respect to claim five.

[00:09:18] Speaker 00:
Broadcom contends that Renaissance affirmably waived the claim one argument and thus it was improper for the board to rely on them in its final written determination.

[00:09:27] Speaker 00:
The second independent reason why the board's determination should be reversed is that there's no evidence supporting its determination that there would be a reasonable expectation of success in combining Foster and C. As Renaissance admits, the board's reasonable expectation of success determination was based solely on the similarities between Foster and C. And you can see that in the

[00:09:47] Speaker 00:
read brief on page 51.

[00:09:50] Speaker 00:
However, as this court affirmed in Samsung Electronics Company versus Elm 3DS Innovations, even if there's a motivation to combine the prior art references, expert testimony that merely states that the prior art references are in the same technological field was insufficient to meet petitioner's burden to prove that a person of ordinary skill in the art would have a reasonable expectation of success in combining those references.

[00:10:12] Speaker 00:
And that's at page 1380 to 1381 of that decision.

[00:10:18] Speaker 00:
The third and final independent reason why the board's determination should be reversed is that there is no evidence supporting the board's determination that C's input size information is used as a basis for generating the output access request.

[00:10:30] Speaker 00:
While it is true that C discloses that size information is provided as an input into the MAU, C is silent as to how the size information is used in generating the output request, as claim five requires.

[00:10:42] Speaker 00:
Renaissance experts only testimonies conclusory, stating that the size information is provided for a reason

[00:10:48] Speaker 00:
and plays a role, both conclusory statements and supported by no actual discussion.

[00:10:54] Speaker 00:
And you can see those statements at ACPX 2119.

[00:11:00] Speaker 00:
And finally, moving on to claim one.

[00:11:03] Speaker 00:
Claim one requires an MAU with an output port that transmits memory access requests over a link to a memory controller and a queue for those access requests.

[00:11:13] Speaker 00:
The board determined that Foster Loan discloses claim one's MAU.

[00:11:17] Speaker 00:
Foster does not disclose such a device.

[00:11:19] Speaker 00:
The board took disclosures from Figures 1 and 2, which has an external memory controller, and from Figure 4, which is an internal memory controller, and combined them into a single embodiment not disclosed in Foster.

[00:11:29] Speaker 00:
Central to the board's determination was that Foster's figures all disclose a single embodiment, and it was its opinion that it didn't matter where the memory controller was located.

[00:11:41] Speaker 00:
Specifically, the board stated, whether the memory controller is internal or external, memory requests are output from the memory port to the memory controller.

[00:11:48] Speaker 00:
And in a second quote, thus, Foster's disclosures that even when the memory controller is internal to the MAU, the memory port connections to memory controller 24 are over dedicated bus 22.

[00:12:01] Speaker 00:
But these statements demonstrate a fundamental flaw in the understanding of the board and the understanding of the evidence by the board.

[00:12:08] Speaker 00:
If the memory controller is internal, then the output of the MAU is directly to memory and not a memory controller.

[00:12:13] Speaker 00:
Why?

[00:12:14] Speaker 00:
Because it is an undisputed fact that Foster would not include both internal and external memory controller.

[00:12:20] Speaker 00:
And we cite that in our blue brief on page 39.

[00:12:25] Speaker 00:
Barring any further questions, Your Honor, I will reserve the rest of my time for rebuttal.

[00:12:31] Speaker 02:
Thank you, Mr. Evaneski.

[00:12:33] Speaker 02:
We'll save three minutes for rebuttal.

[00:12:35] Speaker 02:
Mr. Matsui?

[00:12:39] Speaker 03:
Thank you, Your Honor.

[00:12:39] Speaker 03:
May it please the Court, Brian Natsui for Renaissance.

[00:12:42] Speaker 03:
Substantial evidence supports the Board's findings that claims one, two, and five would have been obvious.

[00:12:49] Speaker 03:
I'm going to follow Broadcom's order unless the Court has any additional order of prefer.

[00:12:54] Speaker 01:
So starting with claim two, substantial evidence supports... Counsel, do you agree with Broadcom's interpretation of block?

[00:13:01] Speaker 01:
And if so, is it then your position is more that Foster actually teaches blocks?

[00:13:09] Speaker 03:
I think there's two points there, Your Honor.

[00:13:12] Speaker 03:
One is that there really was no discussion as to what a block of pixel was, because Broadcom never asked for a claim construction.

[00:13:21] Speaker 03:
And it just argued that a person of ordinary skill and the art would not consider Foster's disclosure as a block of pixel.

[00:13:28] Speaker 03:
And then the board just found against Broadcom on that issue.

[00:13:32] Speaker 03:
I think that the way that we presented the case was that when we have a block of data that's

[00:13:38] Speaker 03:
explicitly disclosed in Foster, our expert said, and it was credited by the board, that a person of orderly skill in the art would understand that to be a block of pixels.

[00:13:49] Speaker 03:
And that was a factual finding that was against Broadcom on the issue.

[00:13:54] Speaker 01:
And I think that goes to... I do agree that, you know, it does say block of data expressly.

[00:14:00] Speaker 01:
And if it is a block of pixels, would that necessarily have to be two by two, you know, could a two by one be a block?

[00:14:09] Speaker 03:
I mean, I don't think we need to go, I think that we didn't, that was not something that needed to be decided.

[00:14:15] Speaker 03:
I think that, you know, the board would only decide what was a clean construction dispute to, it's necessary for the case.

[00:14:24] Speaker 03:
And I think that when you have this disclosure where it says block of data, you have expert testimony explaining that a block of data and motion compensation would be understood as pixels.

[00:14:34] Speaker 03:
that there just was no need to do any coin construction on the granular level as to one by one or one by two is a block versus something that is two by two or four by four or whatever.

[00:14:48] Speaker 03:
And I think that that gets to a predicate issue which Broadcom really has ignored, which is that the board really found that Foster discloses a block of pixels just in and of itself regardless

[00:15:02] Speaker 03:
of whether or not you look at the way that Broadcom wants to look at the case.

[00:15:06] Speaker 03:
And that's at appendix 15 through the beginning of 17, where the board goes through the evidence and says, at appendix 16, we disagree with patent owner.

[00:15:17] Speaker 03:
And then at the very end of that paragraph, it agrees with our expert who says that a person of ordinary skill in the art would know that a block of data in Foster refers to a block of pixels.

[00:15:27] Speaker 03:
They haven't challenged that at all in their opening brief, and that's basically

[00:15:32] Speaker 03:
which should be considered to be fatal to this whole claim construction argument, which they never really made at the board at all.

[00:15:40] Speaker 03:
And if you look at our expert testimony at appendix 2115 to 2116, our experts specifically disagreed with the interpretation that Dr. Wolf, Broadcom's expert, was making with respect to what Foster actually disclosed.

[00:16:00] Speaker 03:
You know, given all that, there is this predicate finding that you have Foster disclosing blocks of pixels, and that's just something that Broadcom did not challenge and instead tried to make a claim construction argument, which they never squarely made, on appeal.

[00:16:18] Speaker 03:
And I think that when you look at the claims themselves, this is an apparatus claim.

[00:16:21] Speaker 03:
It's talking about an input port.

[00:16:23] Speaker 03:
And so what matters is just what can be received, that the motion compensation can retrieve the desired blocks

[00:16:30] Speaker 03:
of reference pixels stored in memory.

[00:16:32] Speaker 03:
And that's what the board found.

[00:16:35] Speaker 03:
It found that Dr. Wolf basically said that you would have in Foster an input port that would be capable of receiving those blocks of pixels.

[00:16:45] Speaker 03:
And under the central evidence standard or review, given the evidence that we have both from Dr. Wolf and from our expert, that's enough to affirm the decision and not even get to any sort of claim construction dispute

[00:16:59] Speaker 03:
that Broadcom is trying to make with respect to this claim limitation.

[00:17:08] Speaker 03:
So if I could next turn to claim five, again, there are two independent grounds with respect to claim five and use this to affirm.

[00:17:16] Speaker 03:
The first is foster alone, and the second is foster in C. With respect to foster alone, foster discloses access requests based on the size.

[00:17:29] Speaker 03:
The board was not confused and didn't treat requests for blocks of pixels as the output request.

[00:17:37] Speaker 03:
At Appendix 20, the board found that Foster discloses generating access requests based on the size of the request of pixels because of the size of the request is taken into account to make sure that it's appropriate for the destination memory.

[00:17:50] Speaker 03:
And our expert testified at Appendix 2117 of Paragraph 13

[00:17:56] Speaker 03:
that the requests in Foster are optimized according to the destination because an adjustment to the request would be necessary if the request takes data in a specific memory that is the wrong size for that memory, such as if the memory was shared memory, which is too short or long of a burst.

[00:18:14] Speaker 03:
And the board at Appendix 20 specifically credited that testimony as unrebutted.

[00:18:19] Speaker 03:
And then that's set forth in Foster itself, which is at Appendix 695 at Columns 11

[00:18:25] Speaker 03:
41 to 56, where Foster says that the requests are mapped to the appropriate physical memory, undergo further reordering to enhance efficiency, and then are formatted to the dedicated memory controller.

[00:18:38] Speaker 03:
And then at column 12, 7 to 13, Foster says that the requests are optimized based on the size of the request and destination memory.

[00:18:46] Speaker 03:
And so given this reference, this disclosure in Foster and the expert testimony, the

[00:18:54] Speaker 03:
the board has clear substantial evidence to support its determination.

[00:19:01] Speaker 03:
Now, even setting Foster aside, there's still the combination of C and Foster, and I'm just about to address the other arguments that Broadcoms Council made.

[00:19:11] Speaker 03:
On the waiver argument, it really doesn't make any sense.

[00:19:15] Speaker 03:
There just was no waiver here.

[00:19:18] Speaker 03:
At the hearing, there was

[00:19:20] Speaker 03:
no waiver of any reliance upon C. And I think that the reason why you can just look at the transcript itself at the hearing, at appendix 2328 to 30, at 2333 to 2336, we argued how C satisfied the based on size request.

[00:19:41] Speaker 03:
And this was after the so-called waiver occurred.

[00:19:43] Speaker 03:
And far from saying that we waived anything,

[00:19:46] Speaker 03:
Broadcom joined issue on this, disputing it on the facts at Appendix 2353 to 2354.

[00:19:54] Speaker 03:
If there actually had been some sort of waiver of this combination at all, none of that would have been necessary at the hearing.

[00:20:01] Speaker 03:
So it simply doesn't make any sense.

[00:20:03] Speaker 01:
And notably, Broadcom can know where... I'll just clarify.

[00:20:08] Speaker 01:
You're arguing that you only gave up your own narrow claim destruction, not the grounds to address it.

[00:20:15] Speaker 03:
Exactly, Your Honor.

[00:20:17] Speaker 03:
And we basically said under Broadcom's construction, then Foster basically shows that all the claims would have been obvious.

[00:20:24] Speaker 03:
And that's why at the hearing, we went on and continued to talk about C. Under Broadcom's theory, there would have been no reason at all to talk about C. And in fact, they would have had no reason to engage on that issue at the hearing itself as it continues.

[00:20:38] Speaker 03:
I would just say that on the other limitations with respect to reasonable expectation of success,

[00:20:45] Speaker 03:
Our expert opined that there would be no obstacles for personal boarding skill in the art to combine foster and see the board made a finding at Appendix 30 that we established reasonable expectation of success.

[00:20:57] Speaker 03:
A personal boarding skill would be capable of working within the technical constraints of no memory chips to combine to make this combination.

[00:21:06] Speaker 03:
Our expert at Appendix 2113 to 2114, he said it would be straightforward to perform foster reordering with requests

[00:21:15] Speaker 03:
that each include multiple addresses like C and the board at Appendix 30 credited this testimony.

[00:21:21] Speaker 03:
And our expert cross-referenced paragraph 72 to 73 of his first declaration where he makes clear that Foster and C both relate to memory access for motion compensation and video decoding.

[00:21:35] Speaker 03:
So there's ample evidence here of reasonable expectation of success.

[00:21:39] Speaker 03:
And this court's decision in Samsung didn't

[00:21:42] Speaker 03:
announce any broad rule, it was basically, it was just affirming under the substantial evidence standard a finding of no reasonable expectation of success in which there was actually a finding of incompatible technologies that doesn't exist at all here.

[00:21:57] Speaker 03:
In fact, the parties joined issue on that and it was rejected.

[00:22:02] Speaker 03:
So, and then lastly on C, disclosing access requests based upon the size.

[00:22:08] Speaker 03:
Again, the board found this on the facts at Appendix 27.

[00:22:11] Speaker 03:
Our expert opined that the memory access unit would take that information into account at appendix 21, 18 to 21, 19, paragraphs 14 to 15.

[00:22:23] Speaker 03:
That, again, is substantial evidence.

[00:22:26] Speaker 03:
And then lastly, on claim one, not being two embodiments, on the claim one, there was no combination of multiple embodiments.

[00:22:35] Speaker 03:
Claim one has two requirements, an output port for

[00:22:39] Speaker 03:
providing access requests and a queue for queuing access requests.

[00:22:43] Speaker 03:
Broadcom's fact argument just is taking a narrow reading of Foster, and that's what the board specifically found.

[00:22:50] Speaker 03:
It's not too embodiment.

[00:22:51] Speaker 03:
The memory controller is in dashed lines, which means that it's in phantom, which means it doesn't matter whether or not it's internal or external.

[00:23:01] Speaker 03:
And figure four clearly references

[00:23:05] Speaker 03:
It uses the same number, 28, that's the memory interface, the same number that's used in figures one and two.

[00:23:13] Speaker 03:
So it's all, as our expert explained at appendix 2112, just an iterative process of one embodiment.

[00:23:21] Speaker 03:
So there's no combination that was occurring here of multiple embodiments.

[00:23:27] Speaker 03:
Unless the court has any questions, we would ask that the board's decision be affirmed.

[00:23:34] Speaker 02:
I don't hear any.

[00:23:35] Speaker 02:
So thank you, Mr. Matsui.

[00:23:38] Speaker 02:
We'll hear some repuddle from Mr. Yabranetsky.

[00:23:45] Speaker 00:
Thank you, Your Honors.

[00:23:46] Speaker 00:
So first point I would like to address is that Renaissance acts like they're surprised at the claim construction position.

[00:23:55] Speaker 00:
However, Broadcom made that argument that Foster only discloses transmission of a receipt of lines of pixels, and the claim requires blocks of pixels,

[00:24:05] Speaker 00:
from the very beginning, from its patent owner response, that argument was there, and it was argued throughout.

[00:24:10] Speaker 00:
And every time Renaissance addressed it, they simply said, raise it as a claim construction argument, saying that's not what the claim requires.

[00:24:18] Speaker 00:
And that's how the board handled it.

[00:24:20] Speaker 00:
So it was addressed throughout the proceeding below.

[00:24:22] Speaker 00:
It wasn't just a new argument or a factual argument that was not presented below.

[00:24:28] Speaker 00:
Also, in Foster,

[00:24:31] Speaker 00:
It's important to look at what the disclosure states.

[00:24:33] Speaker 00:
It talks about processing a block of data, which the board found to be a block of pixels.

[00:24:39] Speaker 00:
But the actual request generated from that processing is what is that issue and what we're comparing the claim to.

[00:24:47] Speaker 00:
And that processing generates a series of eight requests.

[00:24:51] Speaker 00:
And it's unrebutted that those eight requests are requests for lines of pixels.

[00:24:56] Speaker 00:
So it's undisputed that Foster is generating requests for lines of pixels.

[00:25:00] Speaker 00:
And you can see Renaissance admission that Foster's only requesting lines of pixels at APPX 1809 and 1810.

[00:25:08] Speaker 00:
That's their reply brief where they admit that Foster's transmitting requests for lines of pixels to the claimed MAU.

[00:25:16] Speaker 00:
And their expert also supports that at APPX 2116 through 2117.

[00:25:20] Speaker 00:
That's paragraph 12 of his declaration where he describes Foster as also transmitting lines of pixels.

[00:25:28] Speaker 00:
So, there's no dispute below that Foster's only transmitting lines of pixels.

[00:25:33] Speaker 00:
And as discussed previously, there's no dispute that a line of pixels is not a block of pixels based on Broadcom's unrebutted expert testimony and the plain language of the claim and the specification.

[00:25:51] Speaker 02:
Barring... Anything further, Council?

[00:25:55] Speaker 00:
No, Your Honor.

[00:25:56] Speaker 00:
Barring any other questions,

[00:25:58] Speaker 00:
Broadcom just asked for the court to reverse the board's determinations as to claims 1, 2, and 5.

[00:26:04] Speaker 02:
Thank you very much.

[00:26:05] Speaker 02:
The case is submitted.