itc markman ruling in patent case against samsung, qualcomm

UNITED STATES INTERNATIONAL TRADE COMMISSION WASHINGTON, D.C.

In the Matter of

CERTAIN CONSUMER ELECTRONICS AND DISPLAY DEVICES WITH GRAPHICS PROCESSING AND GRAPHICS PROCESSING UNITS THEREIN

Investigation No. 337-TA-932

ORDER NO. 20: CONSTRUING TERMS OF THE ASSERTED PATENTS

(April 2, 2015)

The claim terms construed in this Order are done so for the purposes of this Investigation.

Hereafter, discovery and briefing in this Investigation shall be governed by the construction of the

claim terms in this Order. Those terms not in dispute need not be construed. See Vanderlande

Indus. Nederland BV v. Int’l Trade Comm’n, 366 F.3d 1311, 1323 (Fed. Cir. 2004) (noting that the

administrative law judge need only construe disputed claim terms)

Table of Abbreviations

CMIB Complainant’s Initial Markman Brief CMRB Complainant’s Reply Markman Brief CMSB Complainant’s Supplemental Markman Brief RMIB Respondents’ Initial Markman Brief RMRB Respondents’ Reply Markman Brief RMSB Respondents’ Supplemental Markman Brief SMIB Staff’s Initial Markman Brief SMSB Staff’s Supplemental Markman Brief

Tr. Transcript of the Markman Hearing

ii

Table of Contents I. INTRODUCTION .............................................................................................................. 1

II. RELEVANT LAW ............................................................................................................. 1

III. COMPLAINANT NVIDIA CORPORATION’S MOTION TO STRIKE DECLARATIONS OF DR. DINESH MANOCHA AND DR. JOHN VILLASENOR .... 4

IV. U.S. PATENT NO. 6,198,488 & U.S. PATENT NO. 6,992,667 ....................................... 8

A. Overview ................................................................................................................. 8

B. Level of Ordinary Skill in the Art ........................................................................... 9

C. Disputed Term – “single semiconductor platform” .............................................. 10

V. U.S. Patent No. 7,209,140................................................................................................. 16

A. Overview ............................................................................................................... 16

B. Level of Ordinary Skill in the Art ......................................................................... 17

C. Disputed Claim Terms .......................................................................................... 18

1. “operation” ................................................................................................ 19

2. “instructions from a predetermined instruction set” ................................. 25

VI. U.S. Patent No. 6,697,063................................................................................................. 32

A. Overview ............................................................................................................... 32


C. Disputed Terms ..................................................................................................... 33

1. “scan/z engine” ......................................................................................... 35

a. Must the scan/z engine be implemented as circuitry in “a graphics processor”? .................................................................................... 43

b. Must the scan/z engine perform the double-z algorithm? Must the scan/z engine be capable of performing the double-algorithm? ... 44

c. Conclusion .................................................................................... 50

2. “output a fragment/outputting a plurality of fragments” .......................... 50

3. “the memory” ............................................................................................ 56

VII. U.S. Patent No. 6,690,372................................................................................................. 61

A. Overview ............................................................................................................... 61


C. Agreed Upon Construction – “shading calculation” ............................................. 62

D. Disputed Term – “a combiner module…for combining the output” .................... 63

1

I. INTRODUCTION

By publication of a notice in the Federal Register on October 10, 2014, the U.S.

International Trade Commission ordered that:

Pursuant to subsection (b) of section 337 of the Tariff Act of 1930, as amended, an investigation be instituted to determine whether there is a violation of subsection (a)(1)(B) of section 337 in the importation into the United States, the sale for importation, or the sale within the United States after importation of certain consumer electronics and display devices with graphics processing and graphics processing units therein by reason of infringement of one or more of claims 1, 19, and 20 of the ‘488 patent; claims 1-29 of the ‘667 patent; claims 1-5, 7-19, 21-23, 25-30, 34-36, 38, 41-43 of the ‘685 patent; claims 5-8, 10, 12-20 and 24-27 of the ‘913 patent; claims 7, 8, 11-13, 16-21, 23, 24, 28, and 29 of the ‘063 patent; claims 1-10, 12, and 14 of the ‘140 patent; and claims 1-6, 9-16, and 19-25 of the ‘372 patent, and whether an industry in the United States exists as required by subsection (a)(2) of section 337;

79 F.R. 61338 (October 10, 2014).

Pursuant to the Commission’s notice, the Complainant in this Investigation is NVIDIA

Corporation of Santa Clara, CA. The named Respondents are Samsung Electronics Co., Ltd. of

Seoul, Republic of Korea; Samsung Electronics America, Inc. of Ridgefield Park, NJ; Samsung

Telecommunications America, LLC of Richardson, TX; Samsung Semiconductor, Inc. of San

Jose, CA; and Qualcomm, Inc. of San Diego, CA. The Office of Unfair Import Investigations is

also a party in this Investigation. Id.

II. RELEVANT LAW

“An infringement analysis entails two steps. The first step is determining the meaning and

scope of the patent claims asserted to be infringed. The second step is comparing the properly

construed claims to the device accused of infringing.” Markman v. Westview Instruments, Inc., 52

F.3d 967, 976 (Fed. Cir. 1995) (en banc) (internal citations omitted), aff'd, 517 U.S. 370 (1996).

Claim construction is a “matter of law exclusively for the court.” Id. at 970-71. “The construction

2

of claims is simply a way of elaborating the normally terse claim language in order to understand

and explain, but not to change, the scope of the claims.” Embrex, Inc. v. Serv. Eng'g Corp., 216

F.3d 1343, 1347 (Fed. Cir. 2000).

Claim construction focuses on the intrinsic evidence, which consists of the claims

themselves, the specification, and the prosecution history. See Phillips v. AWH Corp., 415 F.3d

1303, 1314 (Fed. Cir. 2005) (en banc); see also Markman, 52 F.3d at 979. As the Federal Circuit

in Phillips explained, courts must analyze each of these components to determine the “ordinary

and customary meaning of a claim term” as understood by a person of ordinary skill in art at the

time of the invention. 415 F.3d at 1313. “Such intrinsic evidence is the most significant source of

the legally operative meaning of disputed claim language.” Bell Atl. Network Servs., Inc. v. Covad

Commc'ns Grp., Inc., 262 F.3d 1258, 1267 (Fed. Cir. 2001).

“It is a ‘bedrock principle’ of patent law that ‘the claims of a patent define the invention to

which the patentee is entitled the right to exclude.”’ Phillips, 415 F.3d at 1312 (quoting

Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir.

2004)). “Quite apart from the written description and the prosecution history, the claims

themselves provide substantial guidance as to the meaning of particular claims terms.”

Id. at 1314; see also Interactive Gift Express, Inc. v. Compuserve Inc., 256 F.3d 1323, 1331 (Fed.

Cir. 2001) (“In construing claims, the analytical focus must begin and remain centered on the

language of the claims themselves, for it is that language that the patentee chose to use to

‘particularly point [ ] out and distinctly claim [ ] the subject matter which the patentee regards as

his invention.”). The context in which a term is used in an asserted claim can be ““highly

instructive.” Phillips, 415 F.3d at 1314. Additionally, other claims in the same patent, asserted or

unasserted, may also provide guidance as to the meaning of a claim term. Id.

3

The specification “is always highly relevant to the claim construction analysis. Usually it

is dispositive; it is the single best guide to the meaning of a disputed term.” Id. at 1315 (quoting

Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)). “[T]he specification

may reveal a special definition given to a claim term by the patentee that differs from the meaning

it would otherwise possess. In such cases, the inventor’s lexicography governs.” Id. at 1316. “In

other cases, the specification may reveal an intentional disclaimer, or disavowal, of claim scope by

the inventor.” Id. As a general rule, however, the particular examples or embodiments discussed

in the specification are not to be read into the claims as limitations. Id. at 1323. In the end, “[t]he

construction that stays true to the claim language and most naturally aligns with the patent’s

description of the invention will be ... the correct construction.” Id. at 1316 (quoting Renishaw

PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998)).

In addition to the claims and the specification, the prosecution history should be examined,

if in evidence. Id. at 1317; see also Liebel-Flarsheim Co. v. Medrad, Inc., 358 F.3d 898, 913

(Fed. Cir. 2004). The prosecution history can “often inform the meaning of the claim language by

demonstrating how the inventor understood the invention and whether the inventor limited the

invention in the course of prosecution, making the claim scope narrower than it would otherwise

be.” Phillips, 415 F.3d at 1317; see also Chimie v. PPG Indus. Inc., 402 F.3d 1371, 1384 (Fed.

Cir. 2005) (“The purpose of consulting the prosecution history in construing a claim is to exclude

any interpretation that was disclaimed during prosecution.”).

When the intrinsic evidence does not establish the meaning of a claim, then extrinsic

evidence (i.e., all evidence external to the patent and the prosecution history, including

dictionaries, inventor testimony, expert testimony, and learned treatises) may be considered.

Phillips, 415 F.3d at 1317. Extrinsic evidence is generally viewed as less reliable than the patent

itself and its prosecution history in determining how to define claim terms. Id. at 1317. “The

4

court may receive extrinsic evidence to educate itself about the invention and the relevant

technology, but the court may not use extrinsic evidence to arrive at a claim construction that is

clearly at odds with the construction mandated by the intrinsic evidence.” Elkay Mfg. Co. v. Ebco

Mfg. Co., 192 F.3d 973, 977 (Fed. Cir. 1999).

If, after a review of the intrinsic and extrinsic evidence, a claim term remains ambiguous,

the claim should be construed so as to maintain its validity. Phillips, 415 F.3d at 1327. Claims,

however, cannot be judicially rewritten in order to fulfill the axiom of preserving their validity.

See Rhine v. Casio, Inc., 183 F.3d 1342, 1345 (Fed. Cir. 1999). Thus, “if the only claim

construction that is consistent with the claim’s language and the written description renders the

claim invalid, then the axiom does not apply and the claim is simply invalid.” Id.

III. COMPLAINANT NVIDIA CORPORATION’S MOTION TO STRIKE DECLARATIONS OF DR. DINESH MANOCHA AND DR. JOHN VILLASENOR

On January 23, 2015, NVIDIA filed a motion seeking to strike the declarations of Dr.

Manocha and Dr. Villasenor. (Motion Docket No. 932-015.) Specifically, NVIDIA seeks to

strike the two expert Declarations submitted by Respondents with their reply claims construction

briefs, or, at a minimum, strike ¶¶ 32-37 of Dr. Villasenor’s Declaration and ¶¶ 57-60 of

Dr. Manocha’s Declaration, which address indefiniteness. On January 29, 2015, Respondents

filed an opposition to the motion. On February 4, 2015, the Staff filed its response in partially

support of the motion to strike. On February 5, 2015, NVIDIA filed a motion for leave, which is

hereby DENIED, to file a reply in support of its motion to strike. (Motion Docket No. 932-017.)

NVIDIA contends that the declarations of Dr. Dinesh Manocha (“Manocha Decl.”) and

Dr. John Villasenor (“Villasenor Decl.”) appended to Respondent’s reply claims construction brief

(collectively, “Declarations”) should be stricken in their entirety for failure to comply with Ground

Rule 8.2., or alternatively, to the extent that they contain improper rebuttal testimony on the issue

of indefiniteness.

5

In pertinent part Ground Rule 8.2 states:

Not later than the date set forth in the procedural schedule, the parties shall simultaneously exchange proposed constructions of each term identified by any party for claim construction. Each such proposed construction shall also, for each term which any party contends is governed by 35 U.S.C. § 112 ¶ 6, identify the structure(s), act(s), or material(s) corresponding to that term’s function.

Additionally, each party shall identify all references from the specification

or prosecution history that support each proposed construction. Each party shall also designate any supporting extrinsic evidence including, without limitation, dictionary definitions, citations to learned treatises and prior art, and testimony of percipient and expert witnesses. Extrinsic evidence shall be identified by production number or by producing a copy of the evidence if not previously produced. With respect to any supporting witness, percipient or expert, a party shall also provide a description of the substance of that witness’ proposed testimony that includes a listing of any opinions to be rendered in connection with claim construction.

(See Order No. 2 Ground Rule 8.2 (emphasis added).) At the time when the parties

simultaneously exchange proposed constructions, the parties cannot know whether they will need

to offer evidence in rebuttal. Thus failure to identify rebuttal testimony or rebuttal experts at the

time of the simultaneous exchange of proposed constructions cannot be a violation of Ground

Rule 8.2.

Respondents allege certain terms to be indefinite. The burden to prove indefiniteness rests

squarely with Respondents. Thus, pursuant to Ground Rule 8.2 Respondents were required to

disclosure any expert testimony or opinions they would be relying on to support their initial claims

construction brief. In their Ground Rule 8.2 disclosures, Respondents did not provide notice that

they would be offering any expert testimony in support of their claims construction. Thus,

Respondents are precluded from offering expert testimony in support of their opening claim

construction brief.

At the time of the Ground Rule 8.2 disclosures, Respondents were not aware of the expert

testimony that NVIDIA would offer in support of its initial claims construction brief. Thus,

Respondents could not have known at the time the substance of rebuttal testimony that

6

Respondents would offer. Accordingly, I do not find Respondents precluded from offering

rebuttal expert testimony in support of their reply claims construction brief.

Respondents’ Declarations, however, are not limited to rebuttal testimony to support the

reply brief, but also include testimony supporting arguments raised by Respondents in their

opening claim construction brief. For example, Dr. Manocha and Dr. Villasenor offer opinions

regarding the level of ordinary skill in the art. (See Manocha Decl. at ¶¶ 18, 19; Villasenor Decl.

at ¶¶ 22-24). But this testimony was not identified in Respondents’ Ground Rule 8.2 disclosures,

and would more properly have been offered in support of Respondents’ opening claim

construction brief. Thus, I find such testimony is not proper rebuttal testimony and should be

stricken. Similarly, paragraphs 22-24, 28, 29, and 35-37 of Dr. Manocha’s Declaration (regarding

the plain and ordinary meanings of the terms “instruction” and “operation”) and paragraph 28

(regarding the proper construction of the phrase “single semiconductor platform”) of

Dr. Villasenor’s Declaration are not proper rebuttal testimony. Thus, I find those paragraphs

should also be stricken.

With regard to paragraphs 17 and 20 of Dr. Manocha’s Declaration (rebutting Dr. Aliaga’s

and Dr. Pfister’s testimony regarding the level of ordinary skill in the art), and paragraphs 42-43

of Dr. Manocha’s Declaration (rebutting Dr. Pfister’s explanation of traditional rendering) and

paragraph 21 of Dr. Villasenor’s Declaration (rebutting Dr. Aliaga’s and Dr. Pfister’s testimony

regarding the level of ordinary skill in the art) I disagree with NVIDIA that these paragraphs

primarily constitute improper rebuttal testimony. For example, paragraph 17 of Dr. Manocha’s

Declaration states, in part:

While I agree that a person of ordinary skill in the relevant fields of the '063 and '140 patent would have at least two years of experience in computer graphics, I disagree with Dr. Aliaga’s and Dr. Pfister’s described educational level.

7

(Manocha Dec. at ¶ 17). This paragraph primarily rebuts the testimony of Drs. Aliaga and

Pfister, and thus I find it to be proper rebuttal. Similarly, I find the other paragraphs

discussed above may be fairly categorized as rebuttal testimony. Thus, I find this testimony

need not be struck.

With regard to paragraphs 57-60 of Dr. Manocha’s Declaration, in those paragraphs

Dr. Manocha explains why he disagrees with Dr. Pfister’s opinion that the term “memory”

is not indefinite. Thus, I find Dr. Manocha’s testimony to be proper rebuttal. Accordingly,

paragraphs 57-60 need not be struck.

With regard to paragraphs 32-37 of Dr. Villasenor’s Declaration, in those

paragraphs Dr. Villasenor explains why he disagrees with Dr. Aliaga’s opinion that the

phrase “a combiner module … for combining the output generated by the shading module”

has a definite meaning in the context of the claims. Respondents no longer assert that

phrase is indefinite. Rather, Respondents now argue that properly construed the phrase

means “circuitry for combining the output of step (a) with the further output of step (c).”

(See RMSB at 16.) Accordingly, NVIDIA’s motion with regard to paragraphs 32-37 of

Dr. Villasenor’s Declaration is now moot.

Accordingly, for at least the reasons above, I am GRANTING-IN-PART

NVIDIA’s motion and I am striking paragraphs 18, 19, 22-24, 28, 29, and 35-37 of Dr.

Manocha’s Declaration and paragraphs 22-24 and 28 of Dr. Villasenor’s Declaration as

improper rebuttal testimony in violation of Ground Rule 8.2. The remainder of the motion

is hereby DENIED.

8

IV. U.S. PATENT NO. 6,198,488 & U.S. PATENT NO. 6,992,667

A. Overview

U.S. Patent No. 6,198,488 (“the '488 patent”) is titled “Transform, Lighting and

Rasterization System Embodied on a Single Semiconductor Platform.” The '488 patent issued on

March 6, 2001 and lists the following individuals as inventors: John Erik Lindholm; Simon Moy;

Kevin Dawallu; Mingjian Yang; John Montrym; David B. Kirk; Paolo E. Sabella; Matthew N.

Papakipos; Douglas A. Voorhies; and Nicholas J. Foskett. There are 26 claims. In this

investigation, NVIDIA is asserting independent claims 1, 19, and 20 of the '488 patent. See 79

Fed. Reg. 61338 (Oct. 10, 2014).

U.S. Patent No. 6,992,667 (“the '667 patent”) is titled “Single Semiconductor Graphics

Platform System and Method With Skinning, Swizzling, and Masking Capabilities.” The '667

patent issued on January 31, 2006 and lists the same inventors as the '488 patent. The '667 patent

claims priority to the '488 patent through a series of continuation applications. The '488 patent

and the '667 patent are thus based on a common specification. The ‘667 patent has 29 claims, of

which claims 1, 7, 10, 17, 20, 26, and 29 are independent. In this investigation, NVIDIA is

asserting all 29 claims. See 79 Fed. Reg. 61338 (Oct. 10, 2014).

The ‘488 and ‘667 patents generally relate to computer graphics processors for rendering

three-dimensional (“3D”) graphics for display on two-dimensional (“2D”) computer screens. (See

e.g., ‘488 patent at 1:32-54). Prior to the ‘488 and ‘667 patents, computer graphics processing

systems typically used pipelined architectures. According to the ‘488 and ‘667 patents, there was

“a general need to increase the speed of the various graphics processing components, while

minimizing costs.” (Id. at 2:40-42). The patents purport to describe “a transform, lighting, and

rasterization module having a design that allows cost-effective integration.” (Id. at 2:65-68).

9

B. Level of Ordinary Skill in the Art

The Parties’ Positions

Respondents contend that a person of ordinary skill in the art would have “at least a Ph.D.

degree in electrical engineering, computer engineering, computer science, or mathematics with a

minimum of two years of academic work experience in graphics, including hardware for

processing graphics; or at least a Master’s degree in electrical engineering, computer engineering,

computer science, or mathematics with a minimum of four years of academic or work experience

in graphics, including hardware for processing graphics.” (RBr. at 42.)

NVIDIA does not address the level of ordinary skill in the art in its brief. However,

NVIDIA submitted as an exhibit to its brief a declaration by Dr. Hanspeter Pfister that states: “a

person of skill in the art of these patents would have a four-year degree in Electrical Engineering

or Computer Science, or an equivalent technical degree, as well as at least two years of experience

in graphics processing, including developing, designing or programming software or hardware for

graphics processing units, hardware graphics accelerators or other graphics processing systems.”

(See CMIB, Ex. A (Pfister Dec.) at ¶ 4.)

The Staff asserts that the difference between the private parties’ proposals with respect to

the level of ordinary skill in the art does not appear to be dispositive as to the construction that

should be adopted for the disputed term. (SIB at 7.) However, the Staff argues that should a

decision be made as to the level of ordinary skill in the art, then the Staff agrees with the opinion

of NVIDIA’s expert, Dr. Pfister. The Staff notes that insofar as expert and fact discovery is not

yet complete, it may become necessary for the Staff to modify its contention regarding the level of

ordinary skill in the art in light of future discovery.

10

Discussion

Having considered the parties positions, I find a person of ordinary skill in the art would

have at least a four-year degree in Electrical Engineering. Computer Engineering, Computer

Science, or equivalent, as well as at least two years of experience in graphics processing including

developing, designing or programming software or hardware for graphics processing units,

hardware graphics accelerators or other graphics processing systems. I reserve the right to amend

this determination in my final initial determination if any new, persuasive information on this

issue is presented during the course of the evidentiary hearing in this investigation.

C. Disputed Term – “single semiconductor platform”

The parties dispute the meaning of the phrase “single semiconductor platform” in claims 1,

19, and 20 of the ‘488 patent and in claims 1, 5, 7, 10, 15, 17, 20, 24, 26, and 29 of the ‘667

patent. Illustrative claim 1 of the ‘667 patent and claim 20 of the ‘488 patent read as follows:

Claim 1. A hardware graphics system capable of performing a skinning operation, comprising:

a single semiconductor platform for transforming graphics data, lighting the graphics data, and rasterizing the graphics data, the single semiconductor platform adapted to operate in conjunction with a central processing unit;

wherein the single semiconductor platform is further capable of performing a skinning operation involving the graphics data.

Claim 20. A method for graphics processing, comprising:

(a) transforming vertex data from object space to screen space; (b) lighting the vertex data; (c) executing multiple threads of operation in parallel through a plurality of logic units while at least one of transforming and lighting the vertex data; and (d) rendering the vertex data, wherein the vertex data is transformed, lighted, and rendered on a single semiconductor platform.

(‘667 patent at 36:16-25; ‘488 patent at 37:43-53) (emphasis added).

11


Term Proposed Constructions

Complainant Respondents Staff “single semiconductor platform”

Plain and ordinary meaning. But if construed: sole unitary semiconductor-based integrated circuit or chip

sole unitary semiconductor-based integrated circuit or chip incorporating separate hardware dedicated to each of transform, lighting, and rasterizing/rendering

sole unitary semiconductor-based integrated circuit or chip

NVIDIA

NVIDIA asserts that the core dispute between the parties is whether the limitations

“incorporating separate hardware dedicated to each of transform, lighting and

rasterizing/rendering” should be included in the construction of the term “single semiconductor

platform.” (CMIB at 11.) NVIDIA argues that respondent’s position is inconsistent with the

claim language, the summary of the invention, and the specification. (Id.) In fact, NVIDIA

argues that Respondent’s construction contradicts the basic purposes of the invention and the

description of the invention. (Id.)

NVIDIA argues the term “single semiconductor platform” of the ‘488 and ‘667 Patents

does not require construction and should be given its plain and ordinary meaning as the inventors

did not give any special meaning to the term. (Id. at 12.) NVIDIA argues that Respondents have

not argued that the term “single semiconductor platform” is coined, unclear or ambiguous and thus

the plain meaning of this term should govern. (Id.) NVIDIA argues that construction of the

“single semiconductor platform” falls squarely in the category of a term that is “readily apparent

even to lay judges,” such that its construction should involve “little more than the application of

the widely accepted meaning.” (Id. (quoting Phillips, 415 F.3d at 1314).)

12

NVIDIA argues that should I decide that construction of “single semiconductor platform”

is necessary, the term is properly construed as a “sole unitary semiconductor-based integrated

circuit or chip.” (Id. at 13.) NVIDIA argues that this construction is identical to its ordinary

meaning and its description in the specification. (Id.)

Respondents

Respondents argue that the claim language and specification demonstrate that the “single

semiconductor platform” incorporates separate dedicated hardware for performing the claimed

transform, lighting, and rasterizing/rendering operations and cannot merely be a single integrated

circuit or chip. (RMIB at 42.) Respondents argue the claims themselves confirm that “single

semiconductor platform” requires dedicated hardware. (Id. at 43.) For example, Respondents

argue the “single semiconductor platform” of every asserted claim of the ’667 and ’488 patents is

not a generic integrated circuit or chip, but rather a “single semiconductor platform” that

transforms graphics data, lights graphics data, and rasterizes/renders graphics data. (Id.) Thus,

Respondents argue, the claim language confirms that the “single semiconductor platform” must

include at least hardware to transform, light, and rasterize. (Id.) Respondents also argue that

claim 1 of the ’488 patent and claim 29 of the ’667 patent specify that the “single semiconductor

platform” includes a “transform module,” a “lighting module,” and a “rasterizer/render module.”

(Id.) Respondents argue that because each of these modules is “coupled” to at least one other

module, the claim language confirms that the claimed transform, lighting, and

rasterizing/rendering operations are performed by separate hardware units (i.e., modules)

incorporated within the “single semiconductor platform.” (Id.) Respondents further argue that the

remaining asserted apparatus claims of the ’667 patent (claims 1, 10, and 20) support their

construction in that they require a “single semiconductor platform for transforming . . . lighting . . .

and rasterizing the graphics data”—i.e., the “single semiconductor platform” itself contains

13

hardware for performing these claimed operations. (Id.) Respondents argue the asserted method

claims (claim 20 of the ’488 patent and claims 7, 17, and 26 of the ’667 patent) likewise require

that the transform, lighting, and rasterizing operations “are performed on a single semiconductor

platform.” (Id.) Respondents argue that this confirms that each claimed operation is performed

via hardware units on the “single semiconductor platform” itself. (Id.)

Respondents also argue that the specification supports their position. (Id. at 44.)

Respondents argue that the specification repeatedly confirms that the alleged invention is an

integrated circuit or chip that incorporates separate hardware modules for each of the claimed

transform, lighting, and rasterizing operations. (Id. (citing ‘667 Abstract, Field of Invention,

Disclosure of Invention).) Respondents argue that the specification states that the modules are

separate dedicated hardware—“the present invention is divided into four main modules including

transform module 52, a lighting module 54, and a rasterization module 56.” (Id. at 44-45 (citing

‘667 patent at 6:43-44).) Respondents argue that these modules are coupled to other modules,

further confirming that the modules are separate dedicated hardware. (Id. at 45.) Respondents

argue that additional evidence that the claimed “single semiconductor platform” incorporates

separate dedicated hardware modules can be found in the specification’s description of the

problem allegedly solved by the invention—integrating separate modules. (Id.) Respondents

argue that the patents’ solution to this problem was to provide “a design that allows cost-effective

integration”—i.e., “incorporation of different processing modules on a single integrated circuit,”

by redesigning each of the modules with less circuitry so that all of the modules could be

“squeezed” onto a single platform. (Id. at 46.) Respondents argue the only modules described in

the specification are dedicated modules—“a transform module 52, a lighting module 54, and a

rasterization module 56 with a set-up module 57.” (Id. at 46.) Respondents argue that nothing in

the specification describes, for example, a transform module capable of lighting, or a lighting

14

module capable of transforming (nor would such modules be consistent with the stated purpose of

the patent). (Id.) Thus, Respondents argue, in these patents, transforming, lighting, and

rasterizing are performed by separate hardware modules, each dedicated to performing one of

those functions, as illustrated above. (Id.) Respondents argue that because the construction of

“single semiconductor platform” must specify that separate graphics processing modules are

integrated together on a single integrated circuit, it follows that the proper construction of “single

semiconductor platform” is a “sole unitary semiconductor-based integrated circuit or chip

incorporating separate hardware dedicated to each of transform, lighting, and

rasterizing/rendering.” (Id. at 49.) Respondents argue this construction agrees with the

specification and makes sense of the “single semiconductor platform” described in each of the

asserted claims. (Id.)

The Staff

The Staff argues that its proposed construction is consistent with the plain language of the

claims and the intrinsic record of the ‘488 and ‘667 patents. (SMIB at 8.) The Staff argues that

the specification explicitly contemplates that a “single semiconductor platform” may be embodied

as a “sole unitary semiconductor-based integrated circuit or chip.” (Id. at 9.) The Staff also

argues that NVIDIA’s expert, Dr. Pfister, agrees that one of ordinary skill in the art would

understand the term “single semiconductor platform” to refer to a “sole unitary semiconductor-

based integrated circuit or chip.” (Id.) The Staff argues the Respondents’ construction, in

contrast, attempts to import limitations from disclosed embodiments into the claims. (Id.)

Discussion

The specifications of the ‘488 and ‘667 patents state that the “single semiconductor

platform may refer to a sole unitary semiconductor-based integrated circuit or chip.” (‘667 patent

at 6:5-7; ‘488 patent at 6:49-51). The parties appear to generally agree that in light of this

15

statement a “single semiconductor platform” requires a “sole unitary semiconductor-based

integrated circuit or chip.” Respondents, however, contend that this phrase should be further

construed so as to require “separate hardware dedicated to each of transform, lighting, and

rasterizing/rendering.” NVIDIA and the Staff disagree.

In keeping with the plain language of the claims, the specification states:

As shown, the present invention is divided into four main modules including a vertex attribute buffer (VAB) 50, a transform module 52, a lighting module 54, and a rasterization module 56 with a set-up module 57. In one embodiment, each of the foregoing modules is situated on a single semiconductor platform in a manner that will be described hereinafter in greater detail. In the present description, the single semiconductor platform may refer to a sole unitary semiconductor-based integrated circuit or chip.

(‘667 patent at 5:65-6:7; ‘488 patent at 6:42-51) (emphasis added). Thus, the specification

explicitly contemplates that a “single semiconductor platform” may be embodied as a “sole

unitary semiconductor-based integrated circuit or chip.”

Respondents’ proposed construction goes too far by requiring the single semiconductor

platform to incorporate separate hardware dedicated to each of transform, lighting, and

rasterizing/rendering. There simply is no basis in the claims for adding a limitation requiring

separate, dedicated hardware to perform these various claimed functions. While it is true that the

specification does teach that dedicated hardware “might” be used to perform each of the

transform, lighting, and rasterizing/rendering functions, it would be improper to incorporate that

limitation from the specification into the claims when, as here, there is no clear expression of

intent on the part of the applicant to do so. (See the ‘488 patent at 14:65-66 (“Such processes

might be executed with any desired dedicated hardware”) (emphasis added).) See also Intel Corp.

v. U.S. International Trade Commission, 946 F.2d at 836 (“Where a specification does not require

a limitation, that limitation should not be read from the specification into the claims.”); Thorner v.

Sony Computer Entertainment America, LLC, 669 F.3d 1362, 1368 (Fed. Cir. 2012) (“It is … not

16

enough that the only embodiments, or all of the embodiments, contain a particular limitation. We

do not read limitations from the specification into claims; we do not redefine words.”).

Additionally, contrary to Respondents’ argument, neither the claims nor the specification ever uses

the term “separate” in reference to any of the hardware on the single semiconductor platform.

Further, I find it redundant to refer to the transform, lighting, and rasterizing/rendering functions

in the construction of the term “single semiconductor platform” because those functions are

already separately and specifically claimed. (See ‘667 patent, claim 1 (“a single semiconductor

platform for transforming graphics data, lighting the graphics data, and rasterizing the graphics

data …”); ‘488 patent, claim 20 (“… wherein the vertex data is transformed, lighted, and

rendered on a single semiconductor platform.”). Accordingly, I find Respondents’ proposed

construction not persuasive.

Thus, in keeping with the specification and the language of the claims I find for at least the

reasons above that one of ordinary skill in the art at the time of the invention would construe the

term “single semiconductor platform” as a “sole unitary semiconductor-based integrated circuit or

chip.”

V. U.S. Patent No. 7,209,140

A. Overview

U.S. Patent No. 7,209,140 (“the ‘140 patent”) is titled “System, Method and Article of

Manufacture for a Programmable Vertex Processing Model With Instruction Set.” The ‘140

patent issued on April 24, 2007, and lists John Erik Lindholm, David B. Kirk, Henry P. Moreton,

and Simon Moy as inventors. The ‘140 patent has five figures and 14 claims. Independent claims

1, 5-7, 12, and 14, and dependent claims 2-4 and 8-10 are asserted in this investigation. See 79

Fed. Reg. 61338 (Oct. 10, 2014).

17








in graphics, including hardware for processing graphics.” (RMIB at 14.)


NVIDIA submitted a declaration by Dr. Daniel G. Aliaga that states: “a person of skill in the art of

these two patents would have a four-year degree in Electrical Engineering or Computer Science,

or an equivalent technical degree, as well as at least two years of experience in graphics

processing, including developing, designing or programming software or hardware for graphics

processing units (‘GPUs’), hardware graphics accelerators or other graphics processing systems.”

(CMIB, Ex. B (Aliaga Dec.) at ¶ 3.)


the level of ordinary skill in the art does not appear to be dispositive as to the constructions that

should be adopted for the terms in dispute. Nonetheless, the staff argues that should a decision be

made as to the level of ordinary skill in the art, the Staff presently agrees with the opinion of

NVIDIA’s expert, Dr. Aliaga. The Staff notes that insofar as expert and fact discovery is not yet

complete, it may become necessary for the Staff to modify its contention regarding the level of


18

Discussion








C. Disputed Claim Terms

The parties have sought construction of two terms found in the claims of the ‘140 patent:

“instruction” and “operation.” During the Markman hearing, however, it became clear that the

parties’ arguments regarding the term “instruction” really turned on the proper construction of the

term “instruction set.” The parties had not discussed the term “instruction set” in their claims

construction briefs, so I ordered the parties to provide supplemental briefing on that issue. On

February 11, 2015, NVIDIA and Respondents filed their supplemental briefs. On February 13,

2015, the Staff filed its supplemental brief,

Illustrative claims 1 and 14 of the ‘140 patent read as follows:

Claim 1. A method for programmable processing in a hardware graphics accelerator, comprising:

receiving graphics data including lighting information in a hardware graphics accelerator; and performing programmable operations on the graphics data utilizing the hardware graphics accelerator in order to generate output to be displayed, wherein the operations are programmable by a user utilizing instructions from a predetermined instruction set capable of being executed by the hardware graphics accelerator;

wherein the operations include a set on less operation, a move operation, a multiply operation, an addition operation, a multiply and

19

addition operation, a reciprocal operation, a reciprocal square root operation, a three component dot product operation, a four component dot product operation, a distance operation, a minimum operation, a maximum operation, a set on greater or equal than operation, an exponential operation, a logarithm operation, and a lighting operation.

Claim 14. A system, comprising:

a central processing unit; and a hardware graphics accelerator for receiving graphics data, and performing programmable operations on the graphics data in order to generate output;

wherein the operations are programmable by a user utilizing instructions from a predetermined instruction set capable of being executed by the hardware graphics accelerator, the predetermined instruction set including a reciprocal instruction, a reciprocal square root instruction, a three component dot product instruction, a four component dot product instruction, a distance instruction, a minimum instruction, a maximum instruction, an exponential instruction, and a logarithm instruction.

(‘140 patent at claim 1, 24:23-38) (emphasis added).

1. “operation”



Complainant Respondents Staff “operation” action or process process corresponding

to a particular opcode process corresponding to a particular opcode

NVIDIA

NVIDIA argues the ‘140 Patent uses the term “operation” consistent with the ordinary

usage of the term to generally refer to actions or processes. (CMIB at 43.) NVIDIA argues that

neither the claims nor the specification restricts the meaning of “operation” any further. (Id.)

NVIDIA argues that according to the plain language of the claims, the operations are

programmable by a user. (Id.) NVIDIA asserts that this allows application writers to create

20

graphics effects that are executed by the hardware graphics accelerator by using instructions from

an instruction set to specify desired graphics “operations,” which may involve a step, i.e., an

action, or a series of steps, i.e., a process. (Id.)

NVIDIA argues that in addition to the plain language of the claims, the specification

confirms that the ‘140 Patent uses the term “operation” to refer to any action or process, including

high-level functions in the graphics pipeline. (Id.) In support, NVIDIA notes that the patent states

that “During use, the graphics pipeline 100 is adapted to carry out numerous operations for the

purpose of processing computer graphics.” (Id. (quoting ʼ140 Patent at 3:32-34).) NVIDIA also

contends that the patent teaches that vertex processing may include numerous “operations,”

including “texgen operations, lighting operations, transform operations, and/or any other

operations that involve vertices…” (Id. (quoting (‘140 Patent at 3:40-50).) NVIDIA argues that

specification also teaches that each of these high-level “operations” may include multiple sub-

steps to complete the process specified by the instructions of the operation. (Id. (citing ‘140

Patent at 1:35-42, 1:43-45, 1:51).) Moreover, NVIDIA argues that when specific types of

operations are illustrated, the specification is clear to identify those operations as “exemplary.”

(Id. at 44.)

NVIDIA argues that because the meaning of “operation” as an “action or process” is

unambiguous in view of the intrinsic record, there is no need to refer to extrinsic evidence.

Nevertheless, NVIDIA contends the extrinsic record also supports its construction. (Id. (citing Ex.

C-1 (The American Heritage Dictionary of the English Language, 4th ed. (2000)), Ex. C-4

(Webster’s Encyclopedic Unabridged Dictionary of the English Language (1996)).)

Respondents

Respondents contend that the claims tie “operations” to particular “instructions” of the

graphic accelerator’s “instruction set.” (RMIB at 19.) Thus, Respondents argue, the plain

21

language of the claims shows that the operations cover a process of using the specific instructions

from the instruction set. (Id.) Respondents argue that it is tellingly that each specific operation

corresponds to a specific instruction. (Id.at 20.) Respondents assert that their construction

properly captures this linkage between “instructions” and “operations” by using the term “opcode”

in each construction. (Id.) Respondents argue that by seeking to divorce the “opcode” from the

“operation,” NVIDIA advances an illogical construction that is inconsistent with the plain

language of the claims. (Id.)

Respondents argue the prosecution history also confirms that an “operation” is the process

corresponding to a particular associated opcode, which can be executed by the graphics

accelerator. (Id. at 21.) Specifically, Respondents contend the applicants referred to the recited

specific instructions and specific operations of the same type (e.g., “set on less”) interchangeably,

arguing that the claimed “operations/instructions” are “carried out by the hardware graphics

accelerator.” (Id. (citing Ex. 18 (’140 patent FH, 3/24/03 Amendment) at 6-7).) Respondents note

that the only thing a graphics accelerator carries out are opcodes. (Id.) Respondents also argue

that both the Examiner and applicants recognized that each operation has a corresponding

instruction in the graphics accelerator’s instruction set. (Id.) Respondents contend that their

construction correctly captures the applicant’s use of these terms interchangeably, with the

“instruction” referring to the opcode and the “operation” referring to the process corresponding to

a particular opcode. (Id.) Respondents argue that having limited the scope of “operation” during

prosecution to avoid prior art, NVIDIA must now abide by that scope. (Id.) Respondents further

argue the extrinsic evidence supports its proposed construction. (Id. at 22.)

The Staff

The Staff argues that the term “operation” should be construed as a “process corresponding

to a particular opcode.” (SMIB at 16.) The Staff argues this construction is consistent with the

22

plain language of the claims, and the intrinsic record of the '140 patent. (Id.) The Staff contends

that in the context of the claims, the term “operation” refers to those processes implemented by the

hardware graphics accelerator that correspond to particular opcodes in the instruction set. (Id.)

The Staff reasons that it is telling the ’140 patent specification associates operations to

instructions, stating: “[t]his way, the operation associated with the instruction at hand may be

performed on the retrieved data in order to generate output.” (Id. (quoting '140 patent at 8:55-59).)

Thus, the Staff argues it is clear that the claims at issue use the term “operation” to refer to

particular processes corresponding to opcodes that can be specified by instructions in a defined

instruction set. (Id.)

Discussion

Respondents and the Staff contend that the claimed “operation” must be hardware-

dependent. That is, the operation must be specific to the hardware graphics accelerator.1 In

contrast, NVIDIA argues the patent requires no such limitation and that an “operation” may be

hardware-independent. That is, the operation need not be specific to the hardware graphic

accelerator, but may be an operation of, for example, a higher-level graphics API (e.g., OpenGL,

DirectX).

Method claim 1 includes the step of “performing programmable operations … utilizing the

hardware graphics accelerator …” System claim 14 includes “a hardware graphics accelerator

for … performing programmable operations …” NVIDIA’s interpretation of this language allows

a level of abstraction between the operation and the hardware graphics accelerator that I find runs 1 Respondents and the Staff argue that properly construed the term “operation” refers to “a process corresponding to a particular opcode.” (emphasis added.) An opcode is the portion of a machine language instruction that specifies the operation to be performed. Thus, by tying the construction of “operation” to “a particular opcode” Respondents and the Staff are requiring the operation to be a machine language operation of the hardware graphics accelerator (i.e., a hardware-dependent operation).

23

contrary to the language’s plain and ordinary meaning. I read these statements from the claims to

require a direct relationship between the performance of the operation and the hardware graphics

accelerator.2 That is, I find a plain reading of the claim language requires the hardware graphics

accelerator to actually perform the claimed “operations.”

Other language in the claims further supports this conclusion. Claims 1 and 14 require the

hardware graphics accelerator to receive graphics data. Thus, by the express teaching of the

claims, the graphics data must reside with the hardware graphics accelerator. Claims 1 and 14 also

require the hardware graphics accelerator to perform “operations on the graphics data.” Because

the graphics data resides with the hardware graphics accelerator, the only way the hardware

graphics accelerator can perform operations “on the graphics data” is if those operations are

operations executable by the hardware graphics accelerator. The hardware graphics accelerator

can only perform those operations that are native to its chipset. Thus, based on the language of the

claims, an “operation” must a hardware-dependent operation of the hardware graphics accelerator.

NVIDIA’s proposed construction does not withstand scrutiny. The claims require the

hardware graphics accelerator perform the “operations” on the graphics data received by the

hardware graphics accelerator. Under NVIDIA’s proposed construction, the claimed “operations”

may include the operations of a high-level graphics API, such as DirectX. To execute a high-level

operation on the hardware graphics accelerator, the high-level operation must first be compiled

into machine code that the hardware graphics accelerator can understand. It is this compiled code

that the hardware graphics accelerator performs on the graphics data. Because the compiled code

consists of machine operations that differ from the “operations” of the high-level graphics API, it

2 In contrast, when the applicant intended a less direct relationship between the claimed “instructions” and the hardware graphics accelerator, the applicant clearly indicated so by requiring only that the instructions “be capable of being executed by the hardware graphics accelerator.” (emphasis added).

24

cannot be said that the “operations” of the high-level graphics API are performed on the graphics

data received by the hardware graphics accelerator—a requirement of both claims 1 and 14.3 (See

‘140 patent, 1:67-2:2 (“Thereafter, programmable operations are performed on the data in order to

generate output.”), 9:11-13 (“Further, the particular operation is performed on the retrieved data in

order to generate output.”).) Thus, I find NVIDIA’s proposed construction fails to comport with

the language of the claims. Accordingly, I find NVIDIA’s proposed construction not persuasive.

Likewise, I am not persuaded by Respondents and the Staff’s argument that the

construction of the term “operation” should be tied to “a particular opcode.” I can find no support

in the claims for adding such a limitation. Nor do I find support in the specification. The

specification only uses the word “opcode” twice and only in the context of an exemplary

embodiment using assembly language. (See ‘140 patent at 6:57-59 (“An exemplary assembly

language that may be used in one implementation of the present invention will now be set forth.”),

7:54 (“An exemplary assembler format is as follows:”).)

Respondents and the Staff’s requirement of “a particular opcode” as part of the

construction of the term “operation” stems from Respondents and the Staff’s contention that the

phrase “instructions from a predetermined instruction set” must be limited to the native instruction

set of the hardware graphics accelerator. However, as discussed in more detail below, I am not

convinced the phrase “instructions from a predetermined instruction set” needs to be so limited.

The language of the claims clearly specifies the relationship between an “operation” and an

“instruction.” (See id. at 21:64-66 (“wherein the operations are programmable by a user utilizing

instructions from a predetermined instruction set”), 24:29-30 (“wherein the operations are

3 For example, a multiply operation in a high-level graphics API may be implemented in machine code as a series of addition operations (i.e., 2 x 3 = (2 + 2 + 2)) performed on the graphics data. Under NVIDIA’s proposed construction, the “operation” is the multiply operation, but the operation performed on the graphics data is a series of addition operations.

25

programmable by a user utilizing instructions from a predetermined instruction set”).) Thus, I find

Respondents and the Staff’s attempt to capture that relationship as part of the construction of the

term “operation” unnecessary. Moreover, I find that the inclusion of the language “a particular

opcode” in Respondents and the Staff’s proposed construction brings confusion, not clarity, to the

claim construction.

Accordingly, for at least the reasons discussed above, I find that one of ordinary skill in the

art at the time of the invention would construe the term “operation” as an “action or process

recognized by the hardware graphics accelerator.”

2. “instructions from a predetermined instruction set”



Complainant Respondents Staff “instruction set” the complete set of

instructions recognized by a given processor or provided by a given programming language

a processor’s native commands

“the complete set of instructions recognized by the hardware graphics accelerator”

NVIDIA

NVIDIA argues that both “native” and “platform independent” instructions fall within the

scope of the claims because: (1) the claim language “instruction set capable of being executed by

the hardware graphics accelerator” is inconsistent with a construction limited to “native”

instructions, (2) the specification teaches that the invention can be carried out with “instructions of

an instruction set using any type of programming language,” (3) the prosecution history teaches

that vendor-independent graphics APIs had “instruction sets,” and (4) the IEEE Dictionary defines

“instruction set” as “The complete set of instructions recognized by a given computer or provided

by a given programming language.” (CMSB at 1.)

26

NVIDIA asserts that every claim of the ʼ140 Patent claims an “instruction set capable of

being executed by the hardware graphics accelerator.” (Id. at 2.) NVIDIA contends that if

“instruction set” is limited to the “native” instructions that a vendor provides with its GPU, the

clause “capable of being executed” would be superfluous. (Id.) NVIDIA asserts that “Native”

instructions are by definition capable of execution by the chip they are supplied with. Thus,

NVIDIA reasons, the “capable of” clause necessarily requires a broader construction. (Id.)

NVIDIA also argues that limiting “instruction set” to “native” instructions would contradict the

plain and ordinary meaning of the phrase “capable of.” (Id.) Accordingly, NVIDIA argues the

claims dictate that “instruction set” must encompass higher-level languages capable of working

with different vendors’ GPUs. (Id.)

NVIDIA also argues that the phrase “capable of being executed” does not restrict the

claimed “instruction set” only to machine code. (Id. at 3.) NVIDIA argues that any instructions

that can be translated or compiled into machine code that can execute on a particular GPU are

instructions “capable of being executed” by the GPU or “recognized” by the GPU. (Id.) NVIDIA

contends that Respondents provide no evidence of a special meaning or a disclaimer that warrants

changing this straightforward definition. (Id.)

NVIDIA further argues that the specification and prosecution history support its proposed

construction. (See id. at 4.) Additionally, NVIDIA argues the extrinsic evidence supports the

inclusion of high-level programming languages. Specifically, NVIDIA asserts that the IEEE

dictionaries from 2000 and earlier define instruction set as “The complete set of instructions

recognized by a given computer or provided by a given programming language.” (Id. at 5.)

Respondents

Respondents asserts the ‘140 patent claims require that the “instructions” be from a

“predetermined instruction set capable of being executed by the hardware graphics accelerator.”

27

(RMSB at 6.) Respondents contend this statement refers to the set of instructions that exist at the

chip-level, i.e., at the hardware graphics accelerator level, not un-executable, high-level

programming statements. (Id.) Respondents argue that this construction is confirmed by

numerous dictionaries, including from the IEEE, discussed below. (Id.)

Respondents contend that claiming separate instructions for “multiply,” “addition,” and

“multiply and addition” further indicates that the claims are directed to processor commands. (Id.)

Respondents assert that at the chip-level, a “multiply and addition” is advantageous because it

executes in less clock cycles than separate “multiply” and “addition” instructions. (Id.)

Respondents argue NVIDIA’s construction renders “multiply and addition” superfluous because it

allows the separately claimed “multiply” and “addition” operations to be used at a higher level to

perform “multiply and addition.” (Id.) Respondents also argue that the surrounding claim

language supports its construction. (Id. at 7.) Specifically, Respondents assert that the

surrounding claim language requires the “operations” be “perform[ed]” at the chip-level “utilizing

instructions” from the instruction set. (Id.) Respondents argue that a processor can only “utilize”

its native commands to “perform[] operations” on “data” in the chip. (Id.)

Respondents contend the specification confirms their construction of “instruction set” by

consistently and repeatedly referring only to the native commands a processor executes. (Id.)

First, Respondents argue the “Disclosure of the Invention” refers to chip-level instructions by

explaining that the hardware operates on the data in a “source buffer” “utiliz[ing] instructions,”

and stores the “output” in a register. (Id.) Second, Respondents argue the preferred embodiment

distinguishes between “instructions of an instruction set” and “using any type of programming

language” to “carry[]” out instructions. (Id.) Respondents also contend the file history supports

their construction. (See id. at 7-8.)

28

Respondents further maintain that the extrinsic evidence supports their construction. (Id.

at 8.) Respondents argue that numerous technical dictionary definitions of “instruction set,”

including the IEEE’s dictionary definition, show the phrase refers to native chip-level commands.

Respondents also assert that their expert opined that the phrase “instruction of an instruction set”

has a well-defined meaning in the field and that Respondents’ construction captures that meaning.

(Id.)

The Staff

The Staff argues that properly construed the term “instruction set” means “the complete set

of instructions recognized by the hardware graphics accelerator.” (SMSB at 1.) The Staff argues

that its construction is dictated by the plain language of the claim, and is supported by the

specification and prosecution history, as well as the extrinsic evidence. (Id.) The Staff contends

the plain language of the claims limits the term “instruction set” to the set of instructions “capable

of being executed by the hardware graphics accelerator.” (Id.) Thus, the Staff argues, “instruction

set” refers to the native instructions of the hardware graphics accelerator. (Id.) The Staff asserts

that while programmers may access the capabilities of the hardware graphics accelerator using

OpenGL or other graphics programming API, only the native instructions of the hardware

graphics accelerator are capable of being executed by the hardware graphics accelerator. (Id. at 1-

2.)

The Staff notes that the specification states that “one major drawback of this approach is

that changes to the graphics API are difficult and slow to be implemented. (Id. at 2 (quoting (‘140

patent at 1:47-49).) According to the staff, the '140 patent proposes an alternative to the

predefined set of commands enabled by traditional graphics APIs. (Id. (citing ‘140 patent at 1:65-

2:16).) The Staffa argues that by exposing the instruction set of a hardware graphics accelerator,

the device allows a user to directly access the instruction set of the hardware graphics accelerator

29

to efficiently execute custom code directly on the hardware graphics accelerator without waiting

possibly years for graphics APIs to add desired support. (Id.) Thus, the Staff argues the

specification is consistent with the plain language of the claims. (Id.)

The Staff argues that its proposed construction is also consistent with the extrinsic

evidence offered by the private parties. (Id.) For example, The Staff asserts that the IEEE defines

the term “instruction set” as “[t]he complete set of instructions recognized by a given computer or

provided by a given programming language.” (Id.) The Staff argues that because the claims recite

an instruction set “capable of being executed by the hardware graphics accelerator” (as opposed

to a central processing unit or programming language), the term “instruction set” must mean “the

complete set of instructions recognized by the hardware graphics accelerator.” (Id.)

Discussion

Respondents and the Staff argue the claimed “instruction set” refers to the hardware-

dependent set of instructions native to the graphics accelerator chip. NVIDIA seeks a broader

construction of the term “instruction set” that would not only include the set of instructions native

to the chip, but also those “provided by a given programming language,” including high-level

graphics APIs, such as OpenGL and DirectX.

The plain language of the claims requires that the “instructions of the … instruction set”

must be “capable of being executed by the hardware graphics accelerator.” Each of the parties cite

to this language in support of their proposed constructions. NVIDIA contends that because the

“instructions” from an instruction set of a hardware independent language, such as DirectX or

OpenGL, are compiled into machine code that is executed by the hardware graphics accelerator,

such “instructions” must be capable of being executed by the hardware graphics accelerator.

Respondents and the Staff on the other hand contend that only the native instructions of the

hardware graphics accelerator are capable of being executed by the hardware graphics accelerator.

30

I agree with NVIDIA that the plain and ordinary meaning of the phrase “capable of being

executed by the hardware graphics accelerator” has a broader meaning than something designed or

configured to accomplish a specific purpose. I find, as NVIDIA argues, the claim language is

broad enough to encompass the native instruction set of the hardware graphics accelerator, as well

as the instructions of an instruction set of a given programming language that is compiled into

machine code that is executable by the hardware graphics accelerator. I find Respondents and the

Staff’s reading of “capable of” to be overly narrow and inconsistent with that phrase’s plain and

ordinary meaning. Because Respondents and the Staff’s construction is contrary to the plain and

ordinary meaning of the claim language it cannot be correct absent some evidence the applicant

acted as his/her own lexicographer or disclaimed or disavowed claim scope. Aventis

Pharmaceuticals Inc. v. Amino Chemicals Ltd., 715 F.3d 1363, 1373 (Fed. Cir. 2013) (“The

written description and other parts of the specification, for example, may shed contextual light on

the plain and ordinary meaning; however, they cannot be used to narrow a claim term to deviate

from the plain and ordinary meaning unless the inventor acted as his own lexicographer or

intentionally disclaimed or disavowed claim scope.”) Here, I find evidence of neither in the

specification and prosecution history.

Moreover, Respondents’ and the Staff’s constructions render the claim language “capable

of being” in the phrase “capable of being executed by the hardware graphics accelerator”

superfluous. Respondents’ and the Staff’s proposed constructions limit the “instruction set” to the

set of native commands of the hardware graphics accelerator. Commands that are native to the

hardware graphics accelerator are directly executable by the hardware graphics accelerator.

Therefore, under Respondents’ and the Staff’s proposed constructions the “instructions of the

predetermined instruction set” are, by definition, executable by the hardware graphics accelerator.

Thus, if I were to adopt Respondents’ or the Staff’s proposed construction, the phrase “capable of

31

being executed” loses all meaning. This is impermissible. See Cat Tech LLC v. TubeMaster, Inc.,

528 F.3d 871, 885 (Fed. Cir. 2008) (refusing to adopt a claim construction which would render a

claim limitation meaningless); Power Mosfet Techs., L.L.C. v. Siemens AG, 378 F.3d 1396, 1410

(Fed. Cir. 2004) (explaining that a claim construction which renders claim terms superfluous is

generally disfavored); Elekta Instrument S.A. v. O.U.R. Scientific Int'l, Inc., 214 F.3d 1302, 1305-

07 (Fed. Cir. 2000) (refusing to adopt a claim construction which would render claim language

superfluous).

Consistent with NVIDIA’s proposed construction, the specification of the ‘140 patent

describes the invention as “a new computer graphics programming model and instruction set that

allows convenient implementation of changes to the graphics API.” (‘140 patent at 1:55-61

(emphasis added).) Thus, the specification teaches that the instruction set of the invention can

work with graphics APIs to address the disadvantages of the prior art APIs. The specification also

explains that the programmable vertex processing of the invention is carried out with “an

instruction set using any type of programming language.” (Id. at 8:1-4.) This again insinuates the

instruction set need not be hardware-dependent. Contrary to Respondents and the Staff’s

arguments, the only references to “opcodes” in the specification are qualified as being part of an

exemplary embodiment. (Id. at 6:57-58, 7:54-55, 8:3-4, 9:24-25.)

The prosecution history also supports NVIDIA’s proposed construction. During

prosecution, the applicant argued that the “instruction set” of the invention was “different from an

instruction set of a standard graphics application program interface” because the invention

provided “increased flexibility in programming.” (CMIB, Ex. D at 2, 5-6.) Thus, the patentee

expressly considered the term “instruction set” to apply to graphics APIs.

The extrinsic evidence further supports NVIDIA’s construction. In particular, the IEEE

dictionary, to which the Staff also cites in its supplemental brief, defines “instruction set” as “the

32

complete set of instructions recognized by a given computer or provided by a given programming

language.” (CMSB, Ex. A (emphasis added.).) Thus, the IEEE recognizes that an instruction set

need not be confined to the native instructions of a given computer, but may also be the instruction

set of a given programming language.

Accordingly, for at least the reasons above, I find one of ordinary skill in the art at the time

of the invention would construe the term “instruction set” as “the complete set of instructions

recognized by a given computer or provided by a given programming language.”

VI. U.S. Patent No. 6,697,063

A. Overview

U.S. Patent No. 6,697,063 (“the ‘063 patent”) is titled “Rendering Pipeline.” The ‘063

patent issued on February 24, 2004 and lists Ming Benjamin Zhu as the inventor. There are 29

claims. In this investigation, NVIDIA is asserting independent claims 7, 13, 18, and 21, and

dependent claims 8, 11, 12, 16, 17, 19, 20, 23, 24, 28, and 29 of the ‘063 patent. See 79 Fed. Reg.

61338 (Oct. 10, 2014).








in graphics, including hardware for processing graphics.” (RMIB at 25-26.)


NVIDIA submitted a declaration by Dr. Hanspeter Pfister that states: “a person of skill in the art

33

of these patents would have a four-year degree in Electrical Engineering or Computer Science, or

an equivalent technical degree, as well as at least two years of experience in graphics processing,

including developing, designing or programming software or hardware for graphics processing

units, hardware graphics accelerators or other graphics processing systems.” (CMIB, Ex. A

(Pfister Dec.) at ¶ 4.)





NVIDIA’s expert, Dr. Pfister. The Staff notes that insofar as expert and fact discovery is not yet



Discussion








C. Disputed Terms

The parties have sought construction of three limitations found in the claims of the ‘063

patent: “scan/z engine”; “output a fragment/outputting a plurality of fragments”; and “the

memory”. The term “scan/z engine” appears in claims 7, 21, and 23, the phrase “output a

34

fragment/outputting a plurality of fragments” in claims 13 and 18; and the term “the memory” in

claim 23.

Illustrative claims 13, 21 and 23 of the ‘063 patent read as follows:

Claim 13. A method of rendering geometries comprising: [1] performing a first rendering function comprising:

receiving a plurality of geometries including a plurality of vertices and vertices connectivity information, each vertex including x, y, and z coordinates;

determining z values for each x and y location in a screen space for each geometry in the plurality of geometries;

comparing z values for each geometry in the plurality of geometries at each x and y location; and

storing a z value for each x and y location;

[2] performing a second rendering function comprising: [a] receiving the plurality of geometries; [b] determining z values for each x and y location in a screen space for

each geometry in the plurality of geometries; and [c] comparing the determined z values to the stored z value at each x

and y location; and

[3] output a fragment if any subsample of the fragment is determined to be visible, wherein the fragment comprises a fragment coverage.

Claim 21. An integrated circuit including a rendering pipeline comprising: a screen space tiler; a memory interface coupled to the screen space tiler; a scan/z engine coupled to the memory interface; a rasterizer coupled to the memory interface; and a shader coupled to the rasterizer.

35

Claim 23. The integrated circuit of claim 21 wherein the memory is configured to receive

screen x, y, and z coordinates from a first portion of a memory and to provide the screen x,

y, and z coordinates to the scan/z engine, and the memory interface is further configured

to receive surface parameters from a second portion of the memory and to provide the

surface parameters to the rasterizer.

(‘063 patent at claims 13 (annotated for ease of discussion), 21, 23.)

1. “scan/z engine”



Complainant Respondents Staff “scan/z engine” circuitry in a graphics

processor for performing scan conversion and visibility determination prior to pixel/fragment shading

circuitry that resolves visibility of screen geometries using the double-z algorithm to generate visible fragments for shading

circuitry that resolves visibility of screen geometries using the double-z algorithm to generate visible fragments for shading

NVIDIA

NVIDIA argues that the Parties’ proposed claim constructions differ in at least three

substantive respects: whether the scan/z engine should be construed to encompass either the one-

pass or two-pass embodiments disclosed in the specification (Complainant) or if it should be

limited to use of the “double-Z algorithm” (Respondents); whether the construction of “scan/z

engine” should specify “circuitry in a graphics processor”; and whether the scan/z engine performs

“scan conversion” in addition to determining the visibility of screen geometries. (CMIB at 23-24.)

NVIDIA asserts that the primary dispute between the Parties is whether the “scan/z engine” should

be limited to circuitry that determines the visibility of primitives “using the double-z algorithm,”

as proposed by Respondents, or whether it should cover circuitry that implements either of the two

embodiments of the scan/z engine disclosed in the specification: an embodiment “that generates

36

visibility through two passes” or a second embodiment that determines visibility through a “one-

pass” depth-testing operation. (Id. at 24.)

NVIDIA argues that the term “scan/z engine” was not a term ordinarily used in the field of

graphics processing at the time of the invention. (Id.) NVIDIA argues that the patent

specification makes clear that the “scan/z engine” may consist of circuitry that performs either a

two-pass early visibility test or a one-pass early visibility test – not just a “double z algorithm.”

(Id.) NVIDIA argues that the specification teaches that the scan/z engine can perform scan

conversion and visibility determination in one pass, using the “one-pass raster/shading-after-z”

process. (Id. at 25.) NVIDIA argues that Respondents’ construction by contrast requires that the

scan/z engine “resolve[] visibility . . . using the double-z algorithm” and thus excludes the

embodiment that uses the “one-pass raster/shading-after-z.” (Id.) NVIDIA argues that in doing so

Respondents improperly propose a definition contrary to the inventor’s own lexicography. (Id.)

NVIDIA argues that in the ʼ063 Patent, the patentee created a new term to describe a part of his

invention (“scan/z engine”) and expressly disclosed that it may be implemented as a two-pass

visibility test or as a “one-pass shading-after-z.” (Id.) NVIDIA argues that circuitry that performs

scan conversion (“scan”) and either type of visibility test (“z” test) is a “scan/z engine” and within

the scope of claims 7 and 21. (Id.) Accordingly, NVIDIA argues the inventor’s definition

controls and Respondents’ effort to rewrite that definition or limit its scope to a feature of one

embodiment must be rejected. (Id.)

NVIDIA argues that the claims of the ‘063 patent demonstrate that the scan/z engine can

be implemented as using either a one pass or a two pass approach. (Id.) NVIDIA argues that

claims 1-6, and 13-20 are directed to the two pass approach used by the “double z algorithm” and

that these method claims do not recite a “scan/z engine” as a limitation, whereas claims 7-12 and

21-29 use the term “scan/z engine” but do not require a two-pass visibility test, as they combine

37

the scan/z engine with other novel elements. (Id.) NVIDIA argues that under principles of claim

differentiation, in view of the inventor’s choice to not use the term “scan/z engine” in the claims

that describe a two-pass methodology for determining the visibility of fragments, there is a

presumption that the inventor did not intend to limit “scan/z engine” to a two pass approach. (Id.

at 25-26.)

NVIDIA also argues that the prosecution history confirms that the “scan/z engine” is not

limited to a double pass approach. (Id. at 26.) NVIDIA argues that during prosecution, the

patentee was clear that the term “scan/z engine” – which was first introduced during prosecution

with application claims 77 and 91 (issued claims 7 and 21) – was not limited to a two-pass

approach. (Id.) NVIDIA argues that the different ways in which claims were distinguished over

identical prior art confirms that the two-pass visibility test reflected in claims 1 and 13 does not

limit the “scan/z engine” recited in claims 7 and 21 to an embodiment that only performs a

“double z algorithm.” (Id. at 28.) Specifically, NVIDIA argues that on February 28, 2003, the

examiner rejected as unpatentable over the same prior art, Carpenter, all of the following claims:

claims 1 and 13 (prosecution claims 71 and 83, respectively), which describe a two-pass rendering

method but do not use the term “scan/z engine,” and claims 7 and 21 (prosecution claims 77 and

91, respectively), which use the term “scan/z engine” but do not otherwise describe a two-pass

visibility test. (Id.) NVIDIA asserts that the patentee argued that Carpenter did not render claim 1

unpatentable because the claim “provides a method of determining visibility using double-z

sorting….” (Id.) NVIDIA asserts the patentee likewise argued that Carpenter did not render claim

13 unpatentable because the claim “provides a double-z sort method for determining visibility.”

(Id.) In contrast, NVIDIA asserts the patentee argued that Carpenter did not render claim 7

unpatentable because “Carpenter does not teach a scan/z engine configured to receive the screen x,

y, and z coordinates from the memory interface without receiving other surface parameters….”

38

(Id.) Thus, NVIDIA argues, although claim 7 recited the “scan/z engine,” its novelty was argued

based on the ability of the scan/z engine to receive x-y-z positional coordinates from memory

without receiving other information not needed for scan conversion or visibility testing. (Id. at 28-

29.) NVIDIA argues that the “double z algorithm” was not argued to distinguish the prior art, and

the scan/z engine was not limited to such an embodiment. (Id. at 29.) NVIDIA asserts that the

patentee similarly argued that Carpenter did not render claim 21 unpatentable because Carpenter

did not provide the feature of an “integrated circuit including a rendering pipeline comprising: a

screen space tiler.” (Id.) NVDIA argues that the novelty of claim 21 was argued on the basis that

the “screen space tiler eliminates a memory bandwidth bottleneck that would otherwise exist,” and

this “bottleneck is removed by reading visible fragments that overlap a portion of tile.” (Id.)

NVIDIA argues the patentee did not distinguish claim 21 from the prior art based on a “double z

algorithm” – and raised no arguments to limit the scan/z engine to such an embodiment – but

argued novelty based on the combination of the visibility testing of the scan/z engine with the

screen space tiler. (Id.) NVIDIA contends that if the patentee and the examiner believed that the

term “scan/z engine” was restricted to a two pass approach, then the patentee would have made the

same argument to overcome Carpenter for claims 7 and 21 (i.e., that Carpenter does not disclose

the “double-z algorithm”) as it did for claims 1 and 13. (Id.) NVIDIA argues that the different

arguments made by the patentee, and accepted by the examiner, to overcome Carpenter for claims

1 and 13, on the one hand (the failure of Carpenter to disclose the “double-z algorithm”), and

claims 7 and 21, on the other hand (the failure of Carpenter to disclose data splitting or a screen

space tiler), is strong evidence that the term “scan/z engine” in claims 7 and 21 is not restricted to

a double pass approach. (Id.)

NVIDIA also contends that the Respondents’ proposed construction fails to recognize that

the “scan/z engine” performs scan conversion as well as the visibility determination. (Id. at 31.)

39

NVIDIA maintains that scan conversion is inherent in the term “scan/z engine” itself, where

“scan” is a reference to scan conversion and “z” is a reference to the z-values that are used for

depth testing, i.e., the visibility determination. (Id.) NVIDIA claims that the specification makes

this explicit. (Id. (quoting ʼ063 Patent at 10:12-20).) NVIDIA reasons that the patent similarly

describes the scan/z engine as performing “scan conversion and depth operations” and as

“decoupling” the “scan conversion/depth-buffer processing” from later rasterization and shading

processes “through a scan/z engine.” (Id.) NVIDIA argues that the specification’s description of

the one-pass embodiment of the scan/z engine also includes both scan conversion and visibility

testing. (Id. at 32.) Thus, NVIDIA maintains, a complete definition of the “scan/z engine” of the

patent should include reference to both scan conversion and the visibility determination, the two

basic operations performed by the “scan/z engine” of the patent. (Id.)

NVIDIA further argues that the language of the claims makes clear that the “scan/z

engine” is circuitry in a graphics processor, not a general purpose processor. (Id.) NVIDIA

argues this is supported both by the preambles of the only independent claims that use the term,

claims 7 and 21, and the manner in which the claims differentiate between a general processor and

the graphics pipeline of claims 7 and 21. (Id.) NVIDIA notes that both of these claims recite the

scan/z engine as being part of an integrated circuit that includes a graphics or rendering pipeline––

i.e., a graphics processor. (Id.) NVIDIA also claims that its construction is supported by the

specification. (Id.) NVIDIA argues that claim 21 recites an “integrated circuit including a

rendering pipeline comprising: a screen space tiler … a scan/z engine …” and that in the

specification, the patentee expressly discloses that the “screen space tiler” is a “hardwired screen

space tiler” and distinguishes a processor with circuitry specialized for performing such graphics

operations from a “general purpose” processor. (Id. at 32-33.) NVIDIA next maintains its

construction is also supported by the language of certain claims dependent on claims 7 and 21.

40

(Id. at 33.) Specifically, NVIDIA argues that claims 11, 12, 28 and 29 all distinguish the

“integrated circuit including a [graphics/rendering] pipeline” of claims 7 and 21 from a general

purpose “processor.” (Id.)

Respondents

Respondents argue that the intrinsic and extrinsic evidence support its proposed construction that a

“scan/z engine” is “circuitry that resolves visibility of screen geometries using the double-z

algorithm to generate visible fragments for shading.” (RMIB at 26.) Respondents claim that in

the patent and prosecution history, the applicant repeatedly proclaimed that the scan/z engine

resolves visibility in two passes—i.e., it implements the double-z algorithm. (Id.) Respondents

reason that NVIDIA’s present construction, in contrast, seeks to improperly broaden the claims to

cover single-pass prior art that the applicant expressly distinguished from the invention. (Id.)

Respondents contend that NVIDIA cannot now change the meaning of “scan/z engine” in an

attempt to establish infringement. (Id.)

Respondents note the asserted claims recite that the “scan/z engine” “determine[s]

visibility information” and is coupled to other circuitry, including a “rasterizer” (claim 7) and a

“memory interface” (claim 21). Respondents point out the term “scan/z engine” is not a term of

art, but rather a term coined by the inventor to describe the purportedly improved circuitry for

resolving visibility. (Id.) Thus, Respondents argue, the meaning the inventor ascribed to the term

in the intrinsic record is controlling. (Id. at 27.) Respondents assert the specification describes

that the “scan/z engine” performs scan conversion and z-buffering in a particular way with

purportedly novel circuitry. (Id.) Specifically, Respondents claim the patent defines the scan/z

engine as the circuitry that uses the double-z algorithm to perform two passes of scan conversion

and z-buffering to resolve visibility. (Id.) Respondents argue that the patent emphasizes that

“scan/z has to be performed in two passes[.]” (Id.) Thus, Respondents maintain, one of ordinary

41

skill would understand the term “scan/z engine” in light of these descriptions as requiring two

passes through a set of geometries, i.e., requiring use of the double-z algorithm. (Id.)

Respondents also argue that its proposed construction is correct because the purported

invention was designed to overcome the problems of single-pass algorithms, including “one-pass

shading-after-z” buffering and “deferred shading.” (Id. at 28.) Specifically, Respondents argue

that according to the patent, the scan/z engine solves the problem in single-pass shading-after-z

buffering that geometries have to be sorted from “front-to-back.” (Id.) Respondents also argue

that the scan/z engine allegedly resolves the issue of “break[ing] shading coherence” associated

with single-pass “deferred shading.” (Id.) Thus, Respondents argue, one of ordinary skill would

understand the purportedly improved scan/z engine to exclude the deficient single-pass prior art.

Respondents argue that the prosecution history further supports its proposed construction

as the applicant made multiple representations during prosecution that the invention requires two

passes. (Id. at 29.) For example, Respondents point out the applicant expressly told the Patent

Office that “One unique aspect of the invention’s visibility determination is that the binned

geometries are traversed multiple times. Without this feature, the level of efficiency in visibility

determination cannot be achieved.” (Id. (quoting RMIB, Ex. 31 (1/3/00 Amendment) at 7).)

Respondents explain similar representations were made throughout prosecution. (Id.) Thus,

Respondents contend the applicant told the Patent Office that it is the two-pass double-z algorithm

of the invention that distinguishes it from the prior art single-pass approaches, including z-

buffering and deferred shading. (Id.) Respondents contend it is on this same basis that the

applicant distinguished the invention from other prior art references cited by the examiner. (Id. at

30.) Respondents reason the applicant expressly distinguished single-pass algorithms as “very

different” and “completely different” from the invention and that in in light of the applicant’s

42

representations, NVIDIA cannot now broaden the meaning of the term to cover single-pass

algorithms. (Id. at 30-31.)

The Staff

The Staff asserts that the parties disagree as to whether the claimed “scan/z engine” must

use the double-z algorithm disclosed by the patent. (SMIB at 19.) The Staff argues that the

“scan/z engine” is not a term of art, and thus has no plain and ordinary meaning. (Id.) Thus, the

Staff contends, one must look to the language of the claim and the specification to determine the

meaning of that term. (Id.) According to the Staff, the '063 patent states that “[t]he invention uses

a double-z scheme that decouples the scan conversion depth-buffer processing from the more

general rasterization and shading processing” and that “[t]he core of double-z is the scan/z engine,

which externally looks like a fragment generator but internally resolves visibility. (Id. (quoting

4:4-10).) Thus, the Staff maintains, the claimed “scan/z engine” uses the disclosed double-z

algorithm to determine visibility. (Id.) Consistent with the use of double-z, the Staff argues that

the ‘063 patent states that “the two passes in the scan/z engine only require vertex screen x, y, z

coordinates in the primitive form.” (Id. (citing '063 patent at 10:25-26).)

The Staff reasons that while the ‘063 patent contemplates that the scan/z engine can be

operated in a prior art single-pass mode, the '063 patent does not describe a second embodiment of

the claimed scan/z engine. (Id. at 20.) Instead, the Staff claims, the specification describes

modifying using the double-z scan/z engine in a single-pass configuration to implement a less

desirable prior art approach. (Id.) Thus, the Staff argues the specification of the ‘063 patent

teaches away from this one-pass approach, setting forth many advantages of the double-z approach

implemented by the scan/z engine. (Id.) The Staff further argues that in addition to touting the

advantages of double-z, the patentee clearly distinguished one-pass algorithms from the claimed

double-z during prosecution. (Id. at 21.) Accordingly, the Staff maintainsboth the specification of

43

the ‘063 patent and its prosecution history make it clear to one skilled in the art that the claimed

“scan/z engine” performs the described double-z algorithm. (Id.)

Discussion

The parties’ have several disagreements with regard to this limitation. NVIDIA’s

proposed construction requires only that the scan/z engine perform scan conversion and visibility

determination prior to shading. Under NVIDIA’s proposed construction, the scan/z engine need

not perform the double-z algorithm nor even necessarily be capable of performing the double-

algorithm. By contrast, Respondents and the Staff’s proposed construction require not only that

the scan-z engine include circuitry for performing the double-z algorithm, but also that the scan-z

engine must perform the double-z algorithm.4 Further, NIVIDIA’s proposed construction requires

the scan/z engine be implemented as circuitry “in a graphics processor,” where neither

Respondents nor the Staff require such limitation.

a. Must the scan/z engine be implemented as circuitry in “a graphics processor”?

NVIDIA’s proposed construction also differs from that of Respondents and the Staff in

that NVIDIA’s construction requires the scan/z engine to not only be circuitry, as Respondents

and Staff contend, but “circuitry in a graphic processor.” I find no support in the language of the

claims, specification or prosecution history for including a limitation requiring the scan/z engine

to be circuitry implemented “in a graphics processor.”

4 The Staff in its supplemental briefing on this term concludes by stating, “In sum, both the specification of the '063 patent and its prosecution history make it clear to one skilled in the art that the claimed ‘scan/z engine’ includes circuitry for performing the described double-z algorithm.” Although not entirely clear, this statement appears to indicate that the Staff is no longer calling for a construction of the term “scan/z engine” that would necessarily require the scan/z engine to perform the double-z algorithm as long as the scan/z engine includes circuitry capable of performing the double-z algorithm.

44

NVIDIA contends that the preamble language of claims 7 and 21 reciting “an integrated

circuit including a graphics [rendering] pipeline” supports limiting the claims to circuitry in a

“graphics processor.” NVIDIA’s argument assumes that these preambles limit the claims-- an

issue that has not been raised by the parties for resolution in this claims construction order. But

even if the preambles of claims 7 and 21 were limiting, I do not find such language excludes the

scan/z engine from being implemented on a general purpose processor. The evidence shows that

both special-purpose and general-purpose processors are implemented using an “integrated

circuit.” Ex. 47, Manocha Decl. ¶ 56. Moreover, the evidence shows that by 1997, it was known

in the art that a general purpose processor could include a “graphics pipeline” or “rendering

pipeline.” Ex. 47, Manocha Decl. ¶ 56. Contrary to NVIDIA’s argument, I also do not find

dependent claims 11, 12, 28, and 29 support its proposed construction. Those claims recite that the

“integrated circuit” is included in a “graphics card” and coupled to a “processor,” but they do not

limit the “integrated circuit” to a special purpose graphics processor.

NVIDIA’s construction is also not supported by the specification. NVIDIA relies on the

specification’s description of a “hard-wired” screen space tiler, but that is a different claim limitation

in claim 21 and provides no basis for reading a “graphics processor” into the “scan/z engine” term.

NVIDIA cites to nothing from the specification relating to the type of processor for implementing the

scan/z engine.

Accordingly, for at least the reasons above, I find NVIDIA’s argument that the scan/z

engine must be in a graphics processor not persuasive.

b. Must the scan/z engine perform the double-z algorithm? Must the scan/z engine be capable of performing the double-algorithm?

The claimed “scan/z engine” is not a term of art and has no plain and ordinary meaning.

Therefore, I must look to the language of the claims and specification to discern its meaning. The

45

plain language of the claims of the ‘063 patent do not inform the proper construction of the term

“scan/z engine.” Thus, I must turn to the specification to determine its meaning. I do note though

that the claims of the ‘063 patent that include the limitation “scan-z engine” make no mention of

the double-z algorithm or multiple passes, while the claims that specifically require performing a

first and second rendering function (i.e., multiple pass/double-z algorithm) make no mention of a

“scan/z engine.”

The specification states:

The invention uses a double-z scheme that decouples the scan conversion depth-buffer processing from the more general rasterization and shading processing. The core of double-z is the scan/z engine, which externally looks like a fragment generator but internally resolves visibility. It allows the rest of the rendering pipeline to rasterize only visible primitives and shade only visible fragments. Consequently, the raster/shading rate is decoupled from the scan/z rate.

(‘063 patent at 4:4-10). Both Staff and Respondents rely on this passage to support their argument

that the claimed “scan/z engine” uses the disclosed double-z algorithm to determine visibility. I

disagree that the substance of this passage provides such support. While the language “the core of

the double-z is the scan/ engine” certainly indicates that in order to perform a double-z scheme

you need a scan/z engine it does not imply that the scan/z engine must perform the double-z

scheme.

Likewise I do not view the applicant’s statement that “the invention uses a double-z

scheme” as a statement of express intent by the applicant to limit the invention, and by extension

the claimed scan/z engine, to always performing the double-z algorithm. Any disclaimer must be

clear and unmistakable and here the specification teaches that the scan/z engine need not always

perform the double-z algorithm. Specifically, the specification states:

One-pass raster/shading-after-z scan converts and depth-buffers screen geometries only once. It performs set-up computations for only primitives that have fragments passing the depth test, and rasterizes and shades fragments passing the depth test. As previously mentioned, this scheme relies heavily on the fact that geometries are rendered from front-to-back and there are little dynamics in the scene. The scan/z

46

engine permits this operating mode by skipping the first pass of double-z, and allowing the second pass to update the depth buffer. Externally, double-z and one-pass shading-after-z behave virtually identical except that in the case of one-pass shading-after-z it may generate a lot more primitives and fragments passing the depth test.

(ʼ063 patent at 12:40-52 (emphasis added).) This passage explains that the scan/z engine can

operate in a mode that allows for just a single pass through the scan/z engine. Thus, this passage

teaches that the scan/z engine need not always perform the double-z algorithm. The specification

also states:

Referring to FIG. 18, the new proposed architecture decouples pixel-generation 1808/z-computation 1802 from computation of all other planar polygon parameters (through the use of z-buffering 1807). By applying certain schemes (e.g. the one specified in the double-z-buffering section), the system operates at a substantially lower frequency for computation of other attributes than screen-space z's. The implication is that much less hardware and more interesting functionalities can be achieved for the same level of pixel fill performance.

(‘063 patent at 37:30-36.) This passage teaches that the double-z algorithm is just an example of

one scheme that may be employed by the system, thereby reinforcing the notion that the scan/z

engine need not always perform the double-z algorithm. In light of the above two passages from

the specification, I cannot find the statements elsewhere in the specification that “[t]he invention

uses a double-z scheme” and “[t]he invention uses a double-z method” to be a clear and

unmistakable disclaimer of claim scope limiting the invention, and by extension the scan/z engine,

to always performing the double-z algorithm.

Although I have found nothing in the specification that requires the scan/z engine to

always perform the double-z algorithm, I do conclude from the specification that the scan/z engine

must at least be capable of performing the double-z algorithm. That is, the scan/z engine must at

least include circuitry capable of implementing the double-z algorithm. Consistent with the

specification, including the statements in the specification that “[t]he invention uses a double-z

scheme,” “[t]he invention uses a double-z method,” “the core of the double-z is the scan/z engine,

47

and “the double-z engine relies on a scan/z engine” it is clear that the preferred embodiment of the

invention implements the double-z algorithm. Even the passage in the specification that teaches

that the scan-z engine permits one-pass raster/shading-after-z makes clear such “operating mode”

uses the double-z algorithm-- only that it skips the first pass and allows the second pass to update

the depth buffer. (‘063 patent at 12:40-52 (“The scan/z engine permits this operating mode by

skipping the first pass of double-z, and allowing the second pass to update the depth buffer.”).)

Because the preferred embodiment of the invention uses the scan/z engine to implement the

double-z algorithm the scan/z engine must be capable of performing the double-z algorithm. To

find otherwise would be to improperly read the preferred embodiment of the invention out of the

claims. See Anchor Wall Sys., Inc. v. Rockwood Retaining Walls, Inc., 340 F.3d 1298, 1308 (Fed.

Cir. 2003) (citations omitted) (“[A] claim construction that excludes a preferred embodiment ... is

rarely, if ever correct and would require highly persuasive evidentiary support.”).

The prosecution history has been raised with respect to this term and thus I must consider

its impact on the proper construction of the “scan/z engine.” The prosecution history shows the

application that would later mature into the ‘063 patent was filed on November 25, 1997, and

included claims 1-61. On October 6, 1999, the PTO issued a non-final office action rejecting

pending claims 1-61. (See CMRB, Ex. G at 1840.) On January 3, 2000, the applicant filed a

response to the October 1999 office action canceling claims 2, 20, 33, and 51; amending claims 1,

3, 6, 7, 9, 14, 21-24, 31, 32, 34, 37, 38, 40, 45, and 52-55; and adding claims 62 and 63. (See id. at

1890.) On March 28, 2000, the PTO issued a final office action rejecting claims 1, 3-8, 10-19, 21-

32, 34-39, 41-50, and 52-63, and objecting to claims 9 and 40. (See id. at 1903.) On June 27,

2000, the applicant filed a response to the PTO’s March 2000 final office action cancelling

pending claims 1-63 and adding claims 64-70. (See id. at 1915; see also id. at 1921.) On July 17,

2000, the PTO issued an advisory action advising the applicant that new claims 64-70 would not

48

be entered because the new claims did not place the application in condition for allowance, but

instead included new subject matter that would require further consideration by the examiner. (Id.

at 1930.) In response to the advisory action, the applicant filed on August 4, 2000, a continued

prosecution application (CPA) that included a preliminary amendment canceling pending claims

1-63 and adding new claims 64-70. New claim 64 read as follows:

Claim 64. A video-image rendering pipeline, comprising:

an engine for rendering only a set of video-imaged geometries that will ultimately be visible and not obscured by any overlaying geometries in a three-dimensional scene by virtue of their z-depths; and an on-chip tile buffer memory that uses image tile sizes such that off-chip frame memory accesses are minimalized.

(Id. at 1935-36 (emphasis added).) The preliminary amendment included a “REMARKS” section

in which the applicant stated:

Claims 64-70 are presented to focus on what is the subject matter of the invention. Base Claim 64 recites the minimum combination needed, and can readily be differentiated from the prior art. Each of Claims 64-70 draw directly and entirely from the originally filed specifications and drawings. … Paragraph 11(a) of the Office Action commented that “Applicant argues that the multiple traversal of the geometries results in enhanced efficiencies, while the claims provide no definition of the multiple traversal process.” Claims 64-70 clearly recite such multiple traversal, which actually comprises two passes. This element differentiates the claimed invention from the prior art.

(Id. at 1939.) On November 11, 2000, the PTO issued an office action rejecting claims 64-70 as

unpatentable under 35 U.S.C 103(a). (Id. at 1943.) On May 4, 2001, the applicant filed a

response to the November 2000 office action cancelling claim 64 and amending claim 65. (Id. at

1954.) In traversing the patent examiner’s rejection of claims 64-70, the applicant stated

“Applicant has pointed out in previous correspondence that Applicant’s technique is a multiple

traversal process.” (Id. at 1955.) On July 17, 2001, the PTO issued a final office action rejecting

49

pending claims 65-70 as unpatentable under 35 U.S.C 103(a). In response to the July 2001 final

office action, the applicant on October 10, 2002, filed a request for continued examination (RCE),

which included an amendment cancelling claims 65-70 and adding claims 71-99. (Id. at 1982,

1988.) On December 4, 2002, the applicant had a telephone interview with the patent examiner.

(Id. at 1997.) Thereafter, on December 5, 2002, the applicant filed a preliminary amendment

amending claims 71 and 77. (Id. at 2001.) On February 28, 2003, the PTO issued an office action

rejecting claims 71-99 as unpatentable under 35 U.S.C. 103(a). (Id. at 2007.) In response, on

May 28, 2003, the applicant filed an amendment to the claims along with a traversal of the

rejection. (Id. at 2015.) Thereafter, the claims were allowed. (Id. at 2026.)

The applicant’s August 2000 remarks, which were made in an attempt to overcome the

examiner’s previous rejection of claims 1-63, clearly state that claim 64 is the minimum

combination needed to practice the invention and that claim 64 includes “multiple traversal, which

actually comprises two passes.” NVIDIA admits that the term “an engine” in claim 64 refers to

the scan/z engine. (See CMRB at 24.) Thus, based on the applicant’s clear and unmistakable

remarks I find there can be no doubt that the “engine” must perform “multiple traversal, which

actually comprises two passes” (i.e., the double-z algorithm). SanDisk Corp. v. Memorex

Products, Inc., 415 F.3d 1278, 1286 -1287 (Fe.d Cir. 2005) (“The doctrine of prosecution

disclaimer [precludes] ... patentees from recapturing through claim interpretation specific

meanings disclaimed during prosecution.”). The applicant confirmed this in his November 2000

response reiterating, “Applicant has pointed out in previous correspondence that Applicant’s

technique is a multiple traversal process.”

NVIDIA appears to argue in its brief that because claim 64 was cancelled and replaced by

new claims 71-99 that I need pay no mind to the applicant’s remarks regarding claim 64. I

disagree. I find both the patent examiner and the public at large are entitled to rely on those clear

50

and unmistakable representations. See ScaDisk Corp., 415 F.3d. at 1287 (“As a basic principle of

claim interpretation, prosecution disclaimer promotes the public notice function of the intrinsic

evidence and protects the public's reliance on definitive statements made during prosecution.”)

(quoting Omega Engineering, Inc, v. Raytek Corp., 334 F.3d 1314, 1323-24 (Fed. Cir. 2003));

Schriber–Schroth Co. v. Cleveland Trust Co., 311 U.S. 211, 220–21 (1940) (“It is a rule of patent

construction consistently observed that a claim in a patent as allowed must be read and interpreted

with reference to claims that have been cancelled or rejected, and the claims allowed cannot by

construction be read to cover what was thus eliminated from the patent.”)

c. Conclusion

For at least the reasons discussed above, I find one of ordinary skill in the art at the time of

the invention would have construed the term “scan/z engine” as “circuitry that resolves visibility

of screen geometries using the double-z algorithm to generate visible fragments for shading.”,

wherein “using the double-z algorithm” includes

2. “output a fragment/outputting a plurality of fragments”



Complainant Respondents Staff “output a fragment/outputting a plurality of fragments”

“outputting a fragment after a particular z-value associated with a fragment is determined to be visible.”

visibility must be determined for all fragments within all of “the plurality of geometries” that are subject to the second rendering function before any fragment can be output (i.e., all of Step [1] and Step [2] must be complete before Step [3] can occur)

Step [3] occurs after Step [2] has been completed with respect to a particular x and y location (i.e., after step [2][c] has been completed for a particular x and y location).

51

NVIDIA

NVIDIA claimsthe grammar and logic of the claim language, coupled with the intrinsic

evidence, reflects that claims 13 and 18 of the ’063 Patent may be construed so that the “output a

fragment” steps mean “outputting a fragment after a particular z-value associated with a fragment

is determined to be visible.” (CMSB at 11.) NVIDIA asserts that contrary to Respondents’

proposed construction the claim language and the specification do not require the second

rendering function to complete comparisons of z-values for all x and y locations before outputting

a visible fragment at a particular x and y location. (Id.) NVIDIA contendsclaim 13 has specific

language referring to prior steps, such as the use of “first” and “second” in conjunction with the

rendering functions. (Id. at 13.) NVIDIA argues that inside each rendering function, specific

steps are also articulated, such as “storing.” (Id.) However, NVIDIA maintains, there is no clear

statement that all x and y locations must be received, determined or compared before the next sub-

step is performed. (Id.) The claim merely requires that the rendering function be conducted as to

“each” x and y location. (Id.) The patent does not specify when each step needs to be performed

for “each” x and y location. (Id.)

NVIDIA asserts that this claim construction dispute centers on whether sub-step (B)(iii)

needs to be completed for all of the “geometries” whose values are compared, or for just z-values

for a particular x,y location before the outputting a fragment step (C) can commence. (Id. at 14.)

NVIDIA argues that the claim language covers both situations. (Id.) NVIDIA argues that element

(C) does not refer to the “first” or the “second” rendering functions at all. (Id.) Instead, NVIDIA

argues, it stands on its own and merely requires outputting “a fragment” if “any” subsample of a

fragment is visible. (Id.) NVIDIA argues the word “any” in the outputting step shows that each z-

value calculation at each x,y location can occur independently, since any fragment can be output if

visible. (Id.)

52

NVIDIA argues that the specification also supports this position. (Id.) NVIDIA asserts

that one of the goals of the ‘063 patent is to minimize memory bandwidth. (Id.) NVIDIA reasons

that its construction minimizes use of memory resources by allowing multiple operations to occur

in parallel without consuming too much memory in the pipeline. (Id.) NVIDIA argues that

Respondent’s construction consumes memory and requires a step-by-step approach without any

parallel action. (Id.) NVIDIA also asserts that the specification cites a “fragment merging”

embodiment, in which fragments of similar visible shading are merged and output. (Id.) NVIDIA

argues that this architecture demonstrates that visible fragments are not delivered together, as

Respondents suggest. (Id.) Rather, NVIDIA contends, visible fragments arrive when visibility of

a particular x, y location is resolved – consistent with the claim language’s outputting when “any

subsample” of a fragment is visible. (Id.) NVIDIA further asserts that the ‘063 Patent discloses

employing “raster/shading-after-z” in which “a preliminary visibility computation has been

performed to throw away invisible geometries/fragments.” (Id. at 15 (quoting ‘063 Patent at

15:25-29).) NVIDIA argues that the input to the raster/shader may consist of two streams, one of

which is a geometry stream from memory and the other of which is a visibility stream from the

scan/z engine, and these streams are synchronized. (Id.) NVIDIA maintains that the existence of

this embodiment reflects that the comparison step in the second rendering function of claims 13

and 18 can be satisfied if it is performed simultaneously with outputting a visible fragment, since

the visibility and geometry streams are synchronized. (Id.)

Respondents

Respondents asserts that all parties agree that method claims 13 and 18 recite the double-z

algorithm and that both the first and second rendering functions of double-z must occur before any

output. (RMSB at 11.) Respondents argue claim 13 requires a first rendering function [1],

followed by a second rendering function [2], followed by output [3]. (Id.) Respondents claim the

53

dispute between the parties relates to whether the double-z algorithm [1]-[2] must occur as a

whole before output [3], or whether the algorithm can be broken apart during sub-steps [2b] or

[2c] of the second rendering function and interrupted by output [3]. (Id.at 12.) Respondents

maintain that the “grammar,” “logic,” and the intrinsic record support its proposed construction

requiring all the sub-steps of [2] to be performed sequentially before outputting. (Id.)

Respondents argue that by its plain language, the second pass [2] of the double-z algorithm is

defined as “comprising” three steps, which are performed on “each” x and y location (or fragment)

in each of a plurality of geometries. (Id.) Respondents claim each sub-step thus expressly and

logically depends on the prior step and requires the processing of each fragment in the received

geometries. (Id. at 13.) Respondents argue NVIDIA’s and Staff’s construction would improperly

break this flow of the double-z algorithm and interject outputting steps for any individual fragment

before the second rendering function is finished. (Id.) Respondents reason that it is for that very

reason that there is no dispute that all sub-steps of the first pass [1] must be completed before the

second pass [2] begins. (Id.) Respondents note that because the language of the second pass

mimics the language of the first pass and its processing of “each” x and y location of “each”

geometry, that further confirms that the second pass must be completed before outputting [3]. (Id.

at 13-14.)

Respondents also argue that the specification supports its construction. (Id. at 14.)

Respondents argue that the specification describes double-z as requiring two passes through a set

of geometries, where “fragments” are output only after the second pass. (Id.) Respondents argue

that the specification explains that the sequence of sub-steps ensures that fragments “of adjacent

pixels” can be “packed together to form a fragment group when the second-pass of double-z for a

primitive is done.” (Id. (quoting ‘063 patent, 22:16-21).) Respondents assert this allows the

raster/shading unit to take advantage of coherence between adjacent fragments, one of the primary

54

purported benefits of double-z. (Id.) Respondents further claim that during prosecution the

applicant emphasized that double-z requires both passes to be applied before any output. (Id.)

Moreover, Respondents assert the applicant repeatedly distinguished prior art references on this

basis. (Id.)

The Staff

The Staff asserts that the parties now agree that the first rendering step must be performed

before the second rendering step, but that a dispute remains concerning the last step of

“output[ing] a fragment if any subsample of the fragment is determined to be visible.” (SMSB at

6-7.) The Staff reasons that by the plain language of the claim, this step cannot be performed until

a visibility determination has been made because before that time it is not possible to “output a

fragment if any subsample of the fragment is determined to be visible.” (Id. at 7.) The Staff

claims a visibility determination can be made for a particular x and y location immediately after

step [2][c] is completed for a particular x and y location. (Id.) The Staff argues that at that time

all z values have been calculated, step [2][c] completes the visibility determination on a location

by location basis. (Id.) Thus, the Staff argues, when step [2][c] is performed for a particular x and

y location, step [2] is complete for that location and step [3] can then be performed for that

location before step [2][c] has been completed for the remaining x and y locations. (Id. at 8.) .

The Staff maintains that neither the claim language, specification, nor prosecution history

evidence an intent by the patentee to disclaim outputting visible fragments when they are

determined to be visible, as opposed to after a visibility determination has been completed for all

fragments as Respondents suggest. (Id.)

Discussion

The parties agree that the first rendering step must be performed before the second

rendering step in claim 13. However, a dispute remains concerning the last step of “output[ing] a

55

fragment if any subsample of the fragment is determined to be visible.” NVIDIA argues that

“outputting” (i.e., step [3]) may occur either during or after the second rendering function (i.e.,

step [2]). Specifically, NVIDIA argues that step [3] can be performed before step [2][b] has been

completed. The Respondents contend that “outputting” (i.e., step [3]) cannot occur until step

[2][c] is complete for all x and y locations. The Staff argues that “outputting” (i.e., step [3])

cannot occur until after step [2][c] is completed for a particular x and y location.

The third step of claim 13 requires “output[ing] a fragment if any subsample of the

fragment is determined to be visible.” (emphasis added.) Thus, by the plain language of the

claim, this step cannot be performed until a visibility determination has been made. Consequently,

the proper construction turns on when a visibility determination can be made. A visibility

determination can be made for a particular x and y location immediately after step [2][c] is

completed for a particular x and y location. At that time, all z values have been calculated for the

plurality of geometries and step [2][c] completes the visibility determination on a location by

location basis.

The language of the claims quickly disposes of NVIDIA’s proposed construction. Step

2[b] states, “determining z values for each x and y location in a screen space for each geometry in

the plurality of geometries.” Thus, by its very terms, the claim language requires this determining

step to be performed for each x and y location “for each geometry in the plurality of geometries”,

not just a single geometry or some geometries.

Moreover, because the claim uses a two-pass visibility determination that calculates z-

values in each pass (i.e., the double-z algorithm), it is necessary to perform, at least with regard to

a particular fragment, the first rendering function and the second rendering function entirely. Until

all geometries have been processed in step [2][b], the z-values are not complete and the desired

visibility determination cannot be made. Thus, step [3] cannot logically be performed before step

56

[2][b] (i.e., the second pass) has been completed. Furthermore, NVIDIA’s proposed construction

would encompass a one-pass visibility determination, which is in clear conflict with the plain

language of the claim and the prosecution history as discussed, supra, with respect to the disputed

“scan/z engine” term. Thus, I find NVIDIA’s proposed construction is not persuasive.

Respondents contend that step [3] cannot occur until step [2][c] is complete for all x and y

locations. However, unlike step [2][b], which expressly requires the step be performed for each x

and y location “for each geometry in the plurality of geometries,” there is no such limiting

language in step [2][c]. As taught by the specification, a visibility determination can be made as

soon as the z values for all the geometries are calculated for a particular x and y location (i.e.,

upon completion of step [2][b]). Thus, when step [2][c] is performed for a particular x and y

location, step [2] is complete for that location and step [3] can then be performed. Contrary to

Respondents’ argument, I find nothing requiring step [2][c] to be completed for all the remaining

x and y locations before step [3] can be performed. Accordingly, I find Respondents’ argument is

not persuasive.

3. “the memory”



Complainant Respondents Staff “the memory” the memory interface Indefinite the memory interface

NVIDIA

NVIDIA maintains the term “memory” as used in claim 23 is not indefinite. (CMIB at

36.) NVIDIA argues that read within the context of the claims, this situation reflects the

quintessential example of an obvious typographical error which the ALJ has the power to correct

through claim construction. (Id. at 36-37.) NVIDIA contends that correction is permitted

57

when ”(1) the correction is not subject to reasonable debate based on consideration of the claim

language and the specification and (2) the prosecution history does not suggest a different

interpretation of the claims” (Id. at 37-38 (quoting Novo Indus., L.P. v. Micro Molds Corp., 350

F. 3d 1348, 1357 (Fed. Cir. 2003)).) NVIDIA argues that the typographical error in claim 23 is

obvious for several reasons. (Id. at 38.) First, NVIDIA argues the patentee’s use of the word

“the” before “memory” in claim 23 shows that the patentee intended to refer to an earlier

introduced element. (Id.) NVIDIA notes that patent claims use the words “the” or “said” before

earlier introduced elements and the word “a” before introducing a new element. (Id.at 39.)

NVIDIA reasons that because claim 23 uses the term “the memory” in the very beginning of the

claim and since there is no memory element earlier in claim 23, “the memory” must refer to an

element in claim 21, from which claim 23 depends. (Id.) NVIDIA claims that claim 21 does not

include a “memory” element but does include three references to a “memory interface” element.

(Id.) NVIDIA exolains that following the normal patent claim drafting rules, the first use of

“memory interface” in claim 21 is preceded by “a” and the second and third use of “memory

interface” in claim 21 is preceded by the word “the” to show that it is referring to the earlier

introduced “memory interface” element. (Id.) NVIDIA also asserts that claim 23 also says the

“memory” “is configured” and later says “the memory interface” is “further configured.” (Id.)

NVIDIA claims the use of the term “further” in claim 23 would make no sense unless the first

reference to “memory” in the claim was meant to refer to “the memory interface.” (Id.)

NVIDIA further argues that the use of “memory” in the later part of claim 23 also shows

that “the memory” in the beginning of claim 23 is a typo which should be understood as “the

memory interface.” (Id.) NVIDIA asserts that the later part of claim 23 includes the elements “a

first portion of a memory” and “a second portion of the memory.” (Id.) NVIDIA contendsthis

introduces a “memory” element which has a “first portion” and a “second portion.” (Id.) NVIDIA

58

argues that a reader of the claim would know that the memory is a newly introduced element

because following the normal claim drafting rules, the phrase uses the word “a” before memory.

(Id.) Thus, NVIDIA argues this use of memory in claim 23 “a first portion of a memory,” is the

introduction of the memory element. (Id.) NVIDIA claims that if the patentee intended that the

initial phrase of claim 23 introduce a memory element then the phrase “a first portion of a

memory” would have been “a first portion of the memory” in the later part of claim 23. (Id. at 39-

40.) NVIDIA maintains this is further proof that the initial memory element in claim 23 should be

understood as “memory interface.” (Id. at 40.)

Respondents

Respondents contend that the term “the memory” is indefinite. Specifically, Respondents

argues that because the phrase “the memory” “fail[s] to inform, with reasonable certainty, those

skilled in the art about the scope of the invention,” claim 23 is indefinite. (RMIB at 35 (quoting

Nautilus, 134 S. Ct. at 2124).) Respondents argue that claim 23 fails to provide the requisite

antecedent basis for the term “the memory.” (Id.) Instead, Respondents argue the claim

improperly assumes the memory has already been defined in the claim, leaving one skilled in the

art guessing what “the memory” should be understood to encompass. (Id.) Respondents assert the

claim states that “the memory” must receive certain data from “a first portion of a memory.”

Respondents argue that this acknowledges “the memory” recited in claim 23 is distinct from “a

memory” such that data can be received by one from the other. (Id.) Further, Respondents argue,

there is no mention anywhere in the claim (including within claim 21 from which claim 23

depends) indicating the presence of any such memories. (Id.) Respondents argue this ambiguity

of claim 23 is not resolved by the specification or prosecution history. (Id. at 36.) Respondents

allege that neither of these sources explains in what way the inventor contemplated data being

received by “the memory” from “a memory” or identifies a relative relationship of these two

59

claimed memories. (Id.) Thus, Respondents claim the meaning and scope of the term “the

memory” in claim 23 is indeterminate. (Id.)

The Staff

The Staff argues that the meaning of this limitation can be discerned from the language of

the claim. (SMIB at 23.) Specifically, the Staff claimsit is clear from the language of the claim

that the word “interface” was inadvertently omitted. (Id.) The Staff asserts that claim 23 further

limits independent claim 21 by reciting the following: “wherein the memory is configured to

receive screen x, y, and z coordinates.” (Id.) The Staff notes that independent claim 21does not

recite “a memory,” but instead recites “a memory interface.” (Id.) Thus, the Staff argues that it

appears the patentee intended to say “the memory interface” instead of “the memory.” (Id.) The

Staff maintains its construction is confirmed by the remainder of claim 23, which further limits the

memory interface, stating: “the memory interface is further configured to receive surface

parameters.” (Id.) The Staff argues that based on this claim language, it is clear that the term “the

memory” refers to “the memory interface” recited in claim 21. (Id.) Thus, the Staff contends the

term “the memory” is not indefinite, and should be construed to mean “the memory interface.”

(Id. at 24.)

Discussion

Contrary to Respondents’ argument I do not find this term to be indefinite. I find the

meaning of this limitation can be readily discerned from the language of the claims. The term “the

memory” in the beginning of claim 23 is an obvious typographical error that a person of ordinary

skill in the art reading claim 23 in the context of the other claims of the patent would understand to

mean “the memory interface.” (CMIB, Pfister Decl. ¶¶ 48-49.)

Claim 23 seeks to further limit independent claim 21 by reciting the following: “wherein

the memory is configured to receive screen x, y, and z coordinates.” In accordance with normal

60

patent parlance, the applicant’s use of the signal “the” in the term “the memory” indicates that

antecedent basis for the limitation can be found earlier in the claim. Claim 23 uses the term “the

memory” in the very beginning of the claim (“The integrated circuit of claim 21, wherein ‘the

memory’…”). Since there is no memory element earlier in claim 23, “the memory” must refer to

an element in independent claim 21, from which claim 23 depends. Claim 21, however, does not

recite “a memory.” Instead it recites “a memory interface.” Accordingly, it appears when the

applicant wrote “the memory” in claim 23 the applicant intended “the memory interface.”

This interpretation is confirmed by the language of claim 23, which states that “the

memory” is “configured to receive … and to provide” and later says “the memory interface” is

“further configured to receive … and to provide.” The use of the term “further” in claim 23 would

make no sense unless the reference to “the memory” referred to “the memory interface.”

Additional evidence that this is the correct interpretation can also be teased from the

language of the claim. The later part of claim 23 includes the elements “a first portion of a

memory” and “a second portion of the memory.” This introduces a “memory” element which has

a “first portion” and a “second portion.” If the patentee intended that the initial phrase of claim 23

(“The integrated circuit of claim 21, wherein the memory…”) introduce a memory element then

the phrase “a first portion of a memory” would have been drafted to read “a first portion of the

memory” in the later part of claim 23.

Accordingly, for at least the reasons above, I find the term “the memory” in claim 23 is not

indefinite. Moreover, based on the language of the claims as supported by the specification, I find

one of ordinary skill in the art at the time of the invention would construe the term “the memory”

to mean “the memory interface.”

61

VII. U.S. Patent No. 6,690,372

A. Overview

U.S. Patent No. 6,690,372 (“the ‘372 patent”) is titled “System, Method and Article of

Manufacture for Shadow Mapping.” The ‘372 patent issued on February 10, 2004 and lists Walter

E. Donovan and Liang Peng as inventors. There are 25 claims. In this investigation, NVIDIA is

asserting independent claims 1, 9, 10, 11, 19, 20, and 21, and dependent claims 2-6, 12-16, and

22-25 of the ‘372 patent. See 79 Fed. Reg. 61338 (Oct. 10, 2014).




NVIDIA submitted a declaration by Dr. Daniel G. Aliaga that states: “a person of skill in the art of

these two patents would have a four-year degree in Electrical Engineering or Computer Science,

or an equivalent technical degree, as well as at least two years of experience in graphics

processing, including developing, designing or programming software or hardware for graphics

processing units (‘GPUs’), hardware graphics accelerators or other graphics processing systems.”

(CMIB, Ex. B (Aliaga Dec.) at ¶ 3.)






in graphics, including hardware for processing graphics.” (RMIB at 53.)



62



NVIDIA’s expert, Dr. Aliaga. The Staff notes that insofar as expert and fact discovery is not yet



Discussion





hardware graphics accelerators or other graphics processing systems.

C. Agreed Upon Construction – “shading calculation”

The parties originally disputed the meaning of the term “shading calculation” in claims 1,

9, 11, 20, and 21, but after initial claims construction briefs were filed reached an agreed upon

construction. The parties now agree that the term “shading calculation” is properly construed to

mean “a computation of a value concerning the appearance of a surface.”

The plain language of claim 1 broadly recites performing a first/second “shading

calculation,” without limiting those calculations to any particular type of shading calculation. (See

‘372 patent at claims 1, 9, 11, 20, and 21). Nothing in the claims or specification indicates that the

claimed “shading calculation” should be afforded a narrower construction.

The phrase “shading calculation” is used throughout the specification to broadly denote

computations of a value concerning the appearance (e.g. color, texture, shadow, and fog) of any

part of a surface. For example, the patent identifies a series of shading calculations that may be

performed to generate “output,” and then lists specific examples of such shading calculations that

63

compute values based on appearance-related variables such as “s” (a shadow variable),

“Color_diff” (a diffuse color variable), “Color_spec” (a specular color variable), and “Color_amb”

(an ambient color variable). (Id. at 5:1-43.) Similarly, the specification explains that, “[a]s a

function of the shading calculations, various texture look-up operations may be carried out

utilizing the texture lookup module 408 in order to obtain output having appropriate texture map

colors,” and that the texture information received from the texture look-up module for use in the

shading calculations “may take any form including but not limited to filtered texture color, etc.”

(Id. at 7:23-30; see also id. at 7:31-51.) Additionally, the patent discusses the shader module as

generating output as a result of shading calculations, and explains that such “output may include,

but are not limited to diffuse output colors, fog output values, specular output colors, depth output

values, texture color output values, a level of detail . . . value, and/or a Z slope value.” (Id. at

8:12-15.)

Accordingly, for at least the reasons above, I agree with the parties and find that one of

ordinary skill in the art at the time of the invention would have construed the term “shading

calculation” to mean “a computation of a value concerning the appearance of a surface.”

D. Disputed Term – “a combiner module…for combining the output”

The parties dispute the meaning of the phrase “a combiner module…for combining the

output” in claims 10, 20, and 25 of the ‘372 patent.

Claims 10 and 20-25 of the ‘372 patent read as follows:

Claim 10. A method for performing shading calculations in a graphics pipeline, comprising:

performing a first shading calculation in order to generate output;

saving the output; and

performing a second shading calculation using the output in order to generate further output;

64

wherein the method is carried out with a system comprising:

(a) a shading module for performing the first shading calculation in order to generate the output;

(b) a texture look-up module coupled to the shading module for retrieving texture information using texture coordinates associated with the output;

(c) a feedback loop coupled between an input and an output of the shading module for performing the second shading calculation using the texture information from the texture look-up module in order to generate further output; and

(d) a combiner module coupled to the output of the shading module for combining the output generated by the shading module.

Claim 20. A computer program embodied on a computer readable medium for performing shading calculations in a graphics pipeline, comprising:

a code segment for performing a first shading calculation in order to generate output;

a code segment for saving the output; and

a code segment for performing a second shading calculation using the output in order to generate further output;

wherein the code segments are carried out with a system comprising:

(a) a shading module for performing the first shading calculation in order to generate the output;

(b) a texture look-up module coupled to the shading module for retrieving texture information using texture coordinates associated with the output;

(c) a feedback loop coupled between an input and an output of the shading module for performing the second shading calculation using the texture information from the texture look-up module in order to generate further output; and

(d) a combiner module coupled to the output of the shading module for combining the output generated by the shading module.

Claim 21. A system for performing shading calculations in a graphics pipeline, comprising:

(a) logic for performing a first shading calculation in order to generate output;

(b) logic for saving the output; and

65

(c) logic for performing a second shading calculation using the output in order to generate further outputs;

wherein the first and second shading calculations together include a plurality of decoupled variables.

Claim 22. The system as recited in claim 21, wherein the system includes a shading module for performing the first shading calculation in order to generate the output.

Claim 23. The system as recited in claim 22, wherein the system includes a texture look-up module coupled to the shading module for retrieving texture information using texture coordinates associated with the output.

Claim 24. The system as recited in claim 23, wherein the system includes a feedback loop coupled between an input and an output of the shading module for performing the second shading calculation using the texture information from the texture look-up module in order to generate further output.

Claim 25. The system as recited in claim 24, wherein the system includes a combiner module coupled to the output of the shading module for combining the output generated by the shading module.

(‘372 patent, claims 10, 20-25) (emphasis added).



Complainant Respondents Staff “a combiner module…for combining the output”

Plain and ordinary meaning: circuitry for combining the output generated by the shading module

circuitry for combining the output of step (a) with the further output of step (c)5

circuitry for combining the output generated by the shading module

NVIDIA

NVIDIA maintains this term should be given its plain and ordinary meaning, which is

“circuitry for combining the output generated by the shading module.” NVIDIA reasons that its

5 At the Markman hearing I requested the parties file supplemental briefing regarding this limitation. While Respondents initially argued in its claims construction briefs that this limitation was indefinite for failing to precisely identify what is being combined, in its supplemental briefing Respondents proposed that the term be construed as “circuitry for combining the output of step (a) with the further output of step (c).”

66

proposed construction recognizes that the heart of the invention is the claimed feedback loop of

the shading module that enables iterative, programmable shading calculations that involve as

many passes through the shading module as desired by the user, ultimately generating an output

from the shading module to the combiner module. (CMSB at 6.) NVIDIA asserts that the

relevant claims are directed to a flexible pixel shader that could perform “repeated texture

information retrieval and shading calculations in an iterative, programmable manner” within the

graphics pipeline. (Id. at 7 (quoting ’372 patent at 7:31-44).) NVIDIA argues that an exemplary

embodiment in the ’372 patent shown in Figure 4 performs these iterative calculations. (Id.)

NVIDIA notes that the specification discloses that the set-up module 402, rasterizer 404 and

combiner 410 “operate in a conventional manner” as depicted in the prior art and represented in

Fig. 1. (Id.)

Using the feedback loop and texture look-up module depicted in Figure 4, NVIDIA

explains the iterative shader module operates in the following manner:

“[1] First, a shading calculation is performed in order to generate output, i.e., colors or texture coordinates. “[2] Next, texture information is retrieved and another shading calculation is performed using the texture information in order to generate additional output. “[3] Texture information may be retrieved and shading calculations may then be repeated as desired. “[4] Thereafter, the generated output may be combined. As such, the repeated texture information retrieval and shading calculations may be carried out in an iterative, programmable manner.”

(Id. at 7-8 (quoting U.S. Patent No. 6,532,013 at 2:59-3:5 (parent patent incorporated by reference

into the ‘372 patent)).) NVIDIA argues the invention enables flexibility in performing additional,

iterative shading calculations and texture look-ups after the first and second shading calculations

are completed. (Id. at 8.) NVIDIA argues that claims 10, 20 and 25 are carefully drafted to

capture this invention by requiring that at least two shading calculations be performed using the

67

inventive shading module and texture look-up module, and then providing for a prior art combiner

module to combine the output it receives from the shading module. (Id.) NVIIA claims this is

intentional, because the results of the first and second shading calculations may be used as inputs

to subsequent shading calculations as part of the iterative shading approach. What is combined is

the output generated by the shading module to the combiner module. (Id.)

NVIDIA asserts that claim 10 of the ʼ372 Patent illustrates that there are three different

types of “output” referenced in the claim: (1) “the output” of the first shading calculation; (2) the

“further output” of the second shading calculation”; and (3) “the output generated by the shading

module” and sent to the combiner module. (Id.) NVIDIA argues the “output generated by the

shading module” and sent to the combiner is distinct from the other types of output referenced

earlier in the claim. (Id.) NVIDIA argues “the output generated by the shading module” does not

have any antecedent basis and can therefore include subsequent calculations and output as enabled

by the invention. (Id.) Thus, NVIDIA argues the combiner only needs to be capable of

combining the final “output generated by the shading module” and sent to the combiner, which

may – or may not –include the results of the first and second shading calculations, as such

calculations may be superseded by subsequent calculations. (Id. at 9.)

NVIDIA claims that as a result of its programmability, the shading module of the invention

can generate many different types of output, often involving multiple calculations per pixel. (Id. at

10.) NVIDIA argues that the specification further teaches that “[a]s a function of the shading

calculations, various texture look-up operations may be carried out utilizing the texture look-up

module 408 in order to obtain output having appropriate texture map colors.” (Id., quoting ‘372

patent at 7:22-25).) NVIDIA argues Respondents’ proposed construction is inconsistent with the

specification, as it would improperly exclude from the scope of the claims the preferred

68

embodiment of the patent, which provides the combiner module with “output of various types” not

just two specific calculations. (Id.)

Respondents

Respondents argue that properly construed the term “a combiner module … for combining

the output” means “circuitry for combining the output of step (a) with the further output of step

(c).” Respondents argue that its construction should be adopted because, unlike the other

proposed constructions, it resolves the question of what “output” is combined by the claimed

combiner module, thereby providing necessary guidance for the preparation of expert opinions on

infringement and invalidity. (RMSB at 16.) Respondents assert that the “combiner module . . .

for combining the output generated by the shading module” is part of the system which carries out

the claimed method for performing shading calculations. (Id.) Respondents assert that one of the

things combined by the combiner module must be “the output” from the first shading calculation

identified in subpart (a). (Id. at 17.) Respondents argue that the antecedent basis for the phrase

“the output” is “the output” referred to in subparts (a) and (b) of representative claim 10. (Id.)

Accordingly, Respondents maintain the patentee’s specific reference to “the output” in identifying

what is combined by the combiner module (as set forth in subpart (d)) means that the items

combined by that module must at least include “the output” from the first shading calculation.

(Id.) With regard to the second thing that must be combined by the combiner module,

Respondents argue that a natural reading of the claim language, read as a whole, shows that it

must be the “further output” from subpart (c). (Id. at 18.) Respondents assert the language of

representative Claim 10 states that the shading module generates “the output” from the first

shading calculation (subpart (a)) and then has a feedback loop which uses additional texture

information to perform a second shading calculation in order to generate further output. (Id.)

Respondents argue the only other output mentioned in the claim that could be combined with “the

69

output” of subpart (a) is the “further output” of subpart (c). (Id.) Thus, Respondents claim their

construction is consistent with the claim language because it provides that the combiner module is

combining “the output” of subpart (a) with the “further output” of subpart (c). (Id.) Respondent

argue that nothing in the specification contradicts their construction. (Id.) Respondents argue that

their construction in no way precludes the combiner module from also being capable of combining

iterative outputs from step (c). (Id. at 19.) Respondents allege that if a combiner module has

circuitry that combines the output of step (a) with the further output of step (c), it would satisfy

that limitation even if it went on to combine multiple additional outputs from step (c). (Id.)

The Staff

The Staff asserts the ‘372 patent discloses a technique for performing shading calculations

in a graphics pipeline. (SMSB at 4.) The Staff argues that the claims at issue recite a combiner

coupled to the output of a shader that corresponds to an embodiment depicted in Figure 4. (Id.) In

that figure, the Staff asserts the combiner 410 is coupled to the output of the shader 406. (Id.) The

Staff argues that using the feedback loop 409, the device can iteratively perform shading

operations, with outputs of the shader 408 available to the combiner 410. (Id. at 4-5.) The Staff

reasons that the combiner 410 then optionally combines the current output of the shader 408 with

selected graphics data. (Id. at 5.) The Staff claims that according to the specification of the ‘372

patent, the combiner 410 “may be implemented in any desired manner,” such as by using the

combiner described in U.S. Patent No. 6,333,744 (“the '744 patent”). (Id.) The Staff argues that

‘744 patent discloses a combiner that can be used to combine selectable input values including

“diffuse color values, texture values furnished by a plurality of texture stages, and proportions for

combination of the selectable input values.” (Id. (quoting ‘744 patent, Abstract).) Thus, the Staff

contends the combiner contemplated by the ‘372 patent must also be capable of combining an

output of the shader with a variety of graphics data, including texture and color values. (Id.) The

70

Staff argues that contrary to Respondents argument the patent does not require that the combiner

include circuitry to combine the output of step (a) with the output of step (c). (Id.) Instead, the

Staff says it would be sufficient for the combiner to simply combine color values with the output

of step (a) or the output of step (c). (Id.) The Staff argues that there is nothing in the claims that

specifies or limits the operation of the claimed combiner module. (Id.) Rather, the Staff argues,

the claims broadly recite a combiner that is coupled to the output of the shading module. (Id.)

Thus, the Staff argues the “combiner module” properly encompasses “circuitry for combining the

output generated by the shading module.” (Id.)

Discussion

The term “combiner module” appears in independent claims 10 and 20, and dependent

claim 25. Claim 10 is directed to a method for performing shading calculations in a graphics

pipeline. Claim 20 is directed to a computer program for performing shading calculations in a

graphics pipeline. Claim 21, from which claim 25 depends, is directed to a system for performing

shading calculations in a graphics pipeline. Of the claims in which the term “combiner module”

appears, only claim 10 is a method claim. Thus, Respondents proposed construction of the term

“combiner module” as “circuitry for combining the output of step (a) with the further output of

step (c)” (emphasis added), while at least potentially plausible with respect to method claim 10, is

nonsensical with respect to software claim 20 and system claim 25. Thus, Respondents’ proposed

construction cannot be proper.

Moreover, even with regard to method claim 10, I find Respondents proposed construction

not persuasive. The method of claim 10 includes only three steps: performing a first shading

calculation in order to generate output; saving the output; and performing a second shading

calculation using the output in order to generate further output. The remainder of the claim is

directed to a system for performing the method. It is that claimed system that includes the

71

disputed term “combiner module”. The combiner module is not claimed as part of the method. In

keeping with this fact, the claims place no limit on how the “combiner module” is used. The plain

language of the claims requires only that the “combiner module” be coupled to the output of the

shading module and that to the extent the combiner module is used, its purpose is “for combining

the output generated by the shading module.”

Respondents proposed construction is also contrary to the specification of the ‘372 patent.

As shown in Figure 4, below, the patent teaches that the claimed shading module can perform

“repeated texture information retrieval and shading calculations in an iterative, programmable

manner” within the graphics pipeline. (See ’372 patent at 6:27-37, 7:31-44.) The iterative shading

module, texture look-up module and feedback loop are highlighted in the diagram below:

(Id. at Fig. 4.) The specification discloses that the set-up module 402, rasterizer 404 and

combiner 410 “operate in a conventional manner” as depicted in the prior art and represented in

Fig. 1. (Id. at 6:34-38.) Respondents’ proposed construction requires that the combiner module

always combine the results of the first and second shading calculations. This construction,

however, contradicts the teachings of the specification that the shading module may produce

72

“output of various types” after performing as many iterative shading and texture operations as are

programmed by the user:

During the course of use, the feedback loop 409 may be used for performing another shading calculation … The present invention thus allows repeated texture information retrieval and shading calculations in an iterative, programmable manner. In other words, each iteration may be programmed to do a desired shading calculation with or without a texture look-up, where each subsequent iteration may use results of previous texture look-ups for generating further results.

(Id. at 7:31-44 (emphasis added).) As the specification makes clear, “[d]uring use, the number of

iterations may vary per the desires of the user.” (Id. at 7:66-67 (emphasis added).) Thus, in the

embodiment described with respect to Figure 4 of the ‘372 patent, the output of step (a) can either

be sent “to the combiner 410, or back around for another pass at the shader module 406.” (Id. at

7:1-14). In the case where the feedback loop is used, the output of step (a) is not sent to the

combiner 410. Therefore, in at least that embodiment, the combiner 410 would be unable to

combine the output of step (a) with the output of step (c), as Respondents propose, because the

combiner would only have the output of step (c).

Accordingly, for at least the reasons above, I find one of ordinary skill in the art at the time

of the invention would construe the phrase “a combiner module…for combining the output” as

“circuitry for combining the output generated by the shading module.”

SO ORDERED.

________________________________ Thomas B. Pender Administrative Law Judge

itc markman ruling in patent case against samsung, qualcomm

Law

disputed terms

markman hearing

construing terms

level of ordinary skill

graphics processing

table of contents

relevant law

intl trade commn