Broadcom Corporation v. Renesas Electronics

Brian Matsui argues on behalf of Renesas Electronics at the United States Court of Appeals for the Federal Circuit. Brian's argument starts at 12:40.

Transcript

Unofficial transcript for users of mofo.com

Speaker 1 (00:00):

2021-1511 Broadcom Corporation versus Renesas Electronics. Mr. Yebemetsky, please proceed.

Thomas Yebemetsky (00:14):

Thank you, Your Honor. Good morning, Your Honors. Tom Yebemetsky on behalf of appellant Broadcom Corporation. Broadcom challenges the board’s determination that Foster alone discloses each and every limitation of Claims 1, 2, and 5, and that the combination of Foster and Sih renders obvious Claim 5. 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 Sih disclose the limitations of Claims 1, 2, and 5. 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.

Speaker 1 (00:50):

As you wish.

Thomas Yebemetsky (00:53):

Claim two requires the Memory Access Unit, or MAU, to receive requests for blocks of pixels that are whole blocks of pixels. The board wrongly held that Claim 2 does not require request for whole blocks of pixels. And based on that wrong construction, determine that Foster’s request for lines of pixels discloses the limitations of Claim 2. Renesas wrongly dismisses the board’s erroneous construction by arguing that Renesas—that Foster does not need to actually receive the request for whole blocks of pixels. It only needs to have an input port that is capable of receiving the request, which they assert was found below. However, Renesas is wrong for at least two reasons.

Thomas Yebemetsky (01:33):

The first reason is that there is no finding below that the input port is capable of receiving requests for whole blocks of pixels. When addressing Broadcom’s argument that Claim 2’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 requested for any size or configuration of pixels. The board did not find that Foster’s input port was capable of receiving request for whole blocks of pixels. And that’s clear if you look at Appx. 16 and 17. Instead, the board only found that Foster’s input port is capable of receiving pixels generally. Accordingly, there was no finding that Foster’s input port was capable of receiving a request for whole blocks of pixels as Claim 2 requires. The second reason Renesas’s capability argument fails is that the term request for blocks—

Judge Stoll (02:24):

This is Judge Stoll. I noticed that, during your argument, they keep on saying “whole blocks of pixels.” How do you think that changes the meaning of the phrase “request for blocks of pixels?”

Thomas Yebemetsky (02:36):

Your Honor, we don’t believe it changes the meaning of the term. We believe that request for blocks of pixels, the plain and ordinary meaning of that term requires request. And those requests are for whole blocks of pixels. A block—

Judge Stoll (02:49):

What’s whole blocks, versus blocks?

Thomas Yebemetsky (02:54):

Correct. Correct, Your Honor. We believe that the plain language of the claim “request for blocks of pixels” is clear. It’s request for blocks of pixels and those—and that each request has to—

Judge Stoll (03:04):

[inaudible] what a block has to be. That’s what I’m trying to figure out. You, you can say whole blocks and I’m getting confused. So what, what is a block? What’s blocks of pixels? Tell me that. Is it two or more pixels? What is it?

Thomas Yebemetsky (03:16):

As the specification makes clear, they’re a square block of pixels. The specification describes blocks as small as two by two and as large as 21 by 21. And importantly, to the application of what is a block to the Foster limitation, Broadcom’s expert opines that a row of pixels is not a block, and that testimony was unrebutted. And that’s an Appx. 1671, paragraph 54 of her declaration. 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.

Judge Stoll (03:58):

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?

Thomas Yebemetsky (04:15):

No, Your Honor. A fulsome claim construction analysis requires a look at the specification and the claim language. And we believe, as we explained in our briefing, both of those dictate that a block of pixels is a block as small as two by two, as large as 21 by 21. The board didn’t actually conduct a fulsome analysis of the specification to disregard Broadcom’s proposed construction. They simply just concluded, without any citations to the specification, that the claim language of Claim 2, request for blocks of pixels, can be for anything. And there’s no need for a one-to-one correspondence between a request and a block.

Judge Stoll (04:59):

Yeah, their view would be that a block could be one by one.

Thomas Yebemetsky (05:05):

Well, I would disagree with that Your Honor, one by one at that point is just a single pixel. And that would not be a block. 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. But a single pixel—

Judge Stoll (05:23):

[inaudible] Your view is it can’t be a two by one?

Thomas Yebemetsky (05:27):

Correct, Your Honor, because at that point, that is just a line of pixels and that’s not described as a block anywhere in the specification. And the unrebutted testimony of our expert says that a line—a person skilled in the art of reading the specification wouldn’t consider a line of pixels to be a block.

Judge Stoll (05:46):

Okay.

Thomas Yebemetsky (05:49):

Going back to the second reason why the capability argument does not work and fails is because the full scope of Claims 2 and 5 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. Specifically, Claim 2 recites logic for generating the list of addresses from the request for blocks of pixels, and Claim 5 recites wherein the logic generates the access request based on sizes of each of the requests for blocks of pixels. So, both of the requirements of—in the full scope of those claims require the Memory Access Unit to actually receive the request for blocks of pixels.

Thomas Yebemetsky (06:37):

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. All right, any other questions on Claim 2 from Your honors? I’ll move on to Claim 5.

Speaker 1 (07:05):

Please.

Thomas Yebemetsky (07:08):

Claim 5 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 2. The board determined that Claim 5 is rendered obvious by Foster alone and the combination of Foster and Sih, and Broadcom appeals both those determinations. As to the board’s determination that Foster alone discloses Claim 5’s limitations, Broadcom contends that the board confused the input and the output request.

Thomas Yebemetsky (07:35):

The board relied on Foster’s optimizations as disclosing Claim 5 limitations. However, Foster’s optimizations do not use any information related to the input request. 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. As Broadcom 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 for blocks of pixels. And that is actually also what the ALJ found in the co-pending—in the ITC case below.

Thomas Yebemetsky (08:17):

Moving on to the board’s determination that the combination of Foster and Sih renders obvious Claim 5. Broadcom raises three independent reasons why the board’s determination should be reversed. The first is that the board improperly relied on arguments related to the motivation to combine Foster and Sih that Renesas presented for Claim 1 and then waived at the oral argument. For Claim 1, Renesas only presented—only relied on the combination of Foster and Sih to argue that Claim 1 was obvious based on Renesas’s proposed claim construction positions. Then at oral argument, Renesas abandoned their claim construction positions. The board acknowledged that it did not have to address the combination of Foster and Sih for Claim 1 based on petitioner’s waiver. But then in their final written decision when discussing Claim 5, the board reached back to Claim 1 and relied on the arguments that Renesas presented for Claim 1 under their—Renesas’s proposed constructions to find a motivation to combine Foster and Sih, which had nothing to do for the reasons for combining Foster and Sih with respect to Claim 5. Broadcom contends that Renesas firmly waived the Claim 1 arguments, and thus it was improper for the board to rely on them in its final written determination.

Thomas Yebemetsky (09:26):

The second independent reason why the board’s determination should be reversed is that there’s no evidence supporting its determination that there be a reasonable expectation of success in combining Foster and Sih. As Renesas admits, the board’s reasonable expectation of success determination was based solely on the similarities between Foster and Sih. And you can see that in the red brief on page 51. 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. And that’s at page 1382—1381, of that decision.

Thomas Yebemetsky (10:18):

The third and final independent reason why the board’s determination should be reversed is that there’s no evidence supporting the board’s determination that Sih’s input size information is used as a basis for generating the output access request. While it’s true that Sih discloses that size information is provided as an input into the MAU, Sih is silent as to how the size information is used in generating the output request, as Claim 5 requires. Renesas’s experts only testimony is conclusory, stating that the size information is provided for a reason and plays a role. Both conclusory statements and supported by no actual discussion. And you can see those statements at Appx. 2119.

Thomas Yebemetsky (11:00):

And finally, moving on to Claim 1. Claim 1 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. The board determined that Foster alone discloses Claim 1’s MAU, Foster does not disclose such a device. The board took disclosures from figures one and two, which has an external memory controller and from figure four, which is an internal memory controller, and combined them into a single embodiment not disclosed in Foster. Central to the board’s determination was that Foster’s figures all disclosed a single embodiment, and it was its opinion that it didn’t matter where the memory controller was located. Specifically, the board stated whether the memory controller is internal or external, memory requests are output from the memory port to the memory controller. 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. But these statements demonstrate a fundamental flaw in the understanding of the board and the understanding of the evidence by the board. If the memory controller is internal, then the output of the MAU is directly to memory and not a memory controller. Why? Because it is an undisputed fact that Foster would not include both an internal and external memory controller. And we cite that in our blue brief on page 39. Barring any further questions, Your Honor, I will reserve the rest of my time for rebuttal.

Speaker 1 (12:30):

Thank you, Mr. Yebemetsky, we’ll save three minutes for rebuttal. Please, Mr. Matsui.

Brian Matsui (12:38):

Thank you, Your Honor, may it please the court, Brian Matsui for Renesas. Substantial evidence supports the board’s findings that Claims 1, 2 and 5 would’ve been obvious. I’m going to follow Broadcom’s order, unless the court has any additional order it would prefer. So, starting with Claim 2, substantial level—

Judge Stoll (12:58):

Counsel, so, do you agree with Broadcom’s interpretation of “block”? And if so, is it then that your position is more that Foster actually teaches blocks?

Brian Matsui (13:09):

I think there’s two points there, Your Honor. One is that there really was no discussion as to what a block of pixel was because Broadcom never asked for a claim construction, and it just argued that a person of ordinary skill in the art would not consider Foster’s disclosure as a block of pixel. And then the board just found against Broadcom on that issue. I think that the way that we presented the case was that when we have a block of data that’s explicitly disclosed in Foster, our expert said, and it was credited by the board that a person of ordinary skill in the art would understand that to be a block of pixels. And that was a factual finding that was against Broadcom on the issue. And I think that goes—

Judge Stoll (13:55):

Do you agree that, you know, it does say block of data expressly, but, and if it is a block of pixels would that necessarily have to be two by two? Could a two by one be a block?

Brian Matsui (14:09):

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. I think that, you know, the board would only decide what was a claim construction dispute to the extent it’s necessary for the case. 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. But there just was no need to do any claim 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. 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 pixel just in and of itself, regardless of whether or not you look at the way that Broadcom wants to look at the case.

Brian Matsui (15:05):

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. 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. They haven’t challenged that at all in their opening brief. And that’s basically what should be considered to be fatal to this whole claim construction argument, which they never really made at the board at all. And if you look at our expert testimony at Appendix 2115 to 2116, our expert specifically disagreed with the interpretation that Dr. Wolf, Broadcom’s expert, was making with respect to what Foster actually disclosed. And so, you know, given all that, there is this predicate finding that you have Foster disclosing blocks of pixels.

Brian Matsui (16:07):

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. And I think that when you look at the claims themselves, this is an apparatus claim and it’s talking about an input port. And so, what matters is just what can be received that the motion compensation unit can retrieve the desired blocks of reference pixel stored memory. And, and that’s what the board found it found that Dr. Wolf basically says that you would have in Foster an input port that would be capable of receiving those blocks of pixels and under the substantial evidence standard of 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 sort in any sort of claim construction dispute that Broadcom is trying to make with respect to this, this claim limitation.

Brian Matsui (17:07):

So, if I could next turn to Claim 5 again, there are two independent grounds with respect to Claim 5 and reasons to affirm. The first is Foster alone and the second is Foster and Sih. With respect to Foster alone, Foster discloses access requests based on the size. The board explicitly was—the board was not confused, and it didn’t treat request for blocks of pixels as the output request. At Appendix 20, the board found that Foster discloses generating access requests based on the sizes of 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. And our expert testified at Appendix 2117, at paragraph 13, that the request in Foster are optimized according to the destination because an adjustment to the request would be necessary if the request seeks data in a specific memory that is the wrong size for that memory, such as if the memory was shared memory, is too short or long of a burst in the board at Appendix 20, specifically credited that testimony as unrebutted.

Brian Matsui (18:19):

And then that’s set forth in Foster itself, which is at Appendix 695, at columns 1141 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. And then at column 12, seven to 13, Foster says that the requests are optimized based on the size of the request of the destination memory. And so given this reference, this disclosure in Foster and the expert testimony, the board has clear substantial evidence to support its determination. Now, even setting Foster aside, there’s still is also a combination of Sih and Foster. And I just would like to address the other arguments that Broadcom’s counsel made. On the waiver argument, it really doesn’t make any sense. There just was no waiver here.

Brian Matsui (19:18):

At the hearing, there was no waiver of any reliance upon Sih, and I think that the reason why you could just look at the transcript itself at the hearing at Appendix 23, 28 to 30, at 23, 33 to 23 to 36, we argued how Sih satisfied that based on side’s request. And this was after the so-called waiver occurred. And far from saying that we waived anything, Broadcom joined issue on this, disputing it on the facts at Appendix 2353 to 2354, if there actually had been some sort of waiver of this combination at all, none of that would’ve been necessary at the hearing. So, it simply doesn’t make any sense and notably Broadcom can [inaudible]—

Judge Stoll (20:07):

Sir, just to clarify, you only gave—you’re arguing that you only gave up your own narrow claim construction, not the grounds to address it.

Brian Matsui (20:15):

Exactly, Your Honor. And we basically said under Broadcom’s construction, then Foster basically shows that all the claims would’ve been obvious. And, and that’s why at the hearing we went on and continued to talk about Sih under Broadcom’s theory, there would’ve been no reason at all to talk about Sih and, in fact, they would’ve had no reason to engage on that issue at the hearing itself as it continued. I would just say that on the other limitations with respect to reasonable expectation of success, our expert upon that, there will be no obstacles for a person of ordinary skill in the art to combine Foster and C, the board made a finding at Appendix 30 that we establish reasonable expectations of success. A person of ordinary skill will be capable of working within the technical constraints of known memory chips to combine to make this combination.

Brian Matsui (21:07):

Our expert, at Appendix 2113 to 2114, he said it would be straightforward to perform Foster’s reordering with requests that each includes multiple addresses like Sih, and the board at Appendix 30 credited this testimony and our expert cross references paragraph 72 to 73 of this first declaration where he makes clear that Foster and Sih both relate to memory access for motion compensation and video decoding. So, there’s ample evidence here of reasonable expectation of success. And this court’s decision in Samsung didn’t announce any broad rule. 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. In fact, the parties joined issue on that, and it was rejected.

Brian Matsui (22:08):

So, and then lastly on Sih disclosing access request based upon the size, again, the board found this on the facts at Appendix 27, our expert upon that the Memory Access Unit would take that information into account at Appendix 2118 to 2119 paragraphs 14 to 15. That, again, is substantial evidence. And then lastly, on Claim 1 not being two embodiments on the Claim 1, there was no combination of multiple embodiments. Claim 1 has two requirements, an output port for providing access request and the queue for queuing access requests. Broadcom’s fact argument just is taking a narrow reading of Foster, and that’s what the board specifically found. It’s not two embodiments. The memory controller is in dash lines, which means that it’s in phantom, which means it doesn’t matter whether or not it’s internal or external. And figure four clearly references this. It uses the same number, 28, that’s indicating that the memory interface the same number that’s used in figures one and two. So, it’s all, as our expert explained at Appendix 2112, just an iterative process of one embodiment. So, there’s no combination that was occurring here of multiple embodiments. Unless the court has any questions, we would ask that the board’s decision be affirmed.

Speaker 1 (23:33):

I don’t hear any, so thank you, Mr. Matsui. We’ll hear some rebuttal from Mr. Yebemetsky.

Thomas Yebemetsky (23:44):

Thank you, Your Honors. So, first point I would like to address is that Renesas, you know, acts like they’re surprised at the claim construction position. However, Broadcom made that argument that Foster only discloses transmission of or receipt of lines of pixels and the claim requires blocks of pixels from the very beginning. From its patent owner response, that argument was there, and it was argued throughout. And every time Renesas addressed it, they simply said—raised it as a claim construction argument saying that’s not what the claim requires. And that’s how the board handled it. So, it was addressed throughout the proceeding below. It wasn’t just a new argument or a factual argument that was not presented below. Also in Foster, it’s important to look at what the disclosure states. It talks about processing a block of data, which the board found to be a block of pixels, but the actual request generated from that processing is what is that issue and what we’re comparing to Claim 2.

Thomas Yebemetsky (24:47):

And that processing generates a series of eight requests, and it’s unrebutted that those eight requests are requests for lines of pixels. So, it’s undisputed that Fosters generating requests for lines of pixels. And you can see Renesas admission that Fosters only requesting lines of pixels at Appx. 1809 and 1810. That’s their replied brief where they admit that Foster’s transmitting request for lines of pixels to the claimed MAU, and their expert also supports that at Appx. 2116 through 2117. That’s paragraph 12 of his declaration where he describes Foster as also transmitting lines of pixels. So, there’s no dispute below that Foster’s only transmitting lines of pixels. And as discussed previously, there is 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. Barring—

Speaker 1 (25:54):

Anything further, counsel?

Thomas Yebemetsky (25:55):

No, Your Honor. Barring any other questions? Broadcom just asked for the court to reverse the board’s determinations as the Claims 1, 2, and 5.

Speaker 1 (26:04):

Thank you very much. The case is submitted.