AMICUS AI
Citation Codes
Equivalent Citations
citation codes
Docket Number
Motions
Judges
Are you a practicing lawyer?
Enhance your digital presence and reach by creating a Casemine profile.
Upload pleading to use the new AI search
Cites
Cited by
Citation Codes
Equivalent Citations
citation codes
Docket Number
Motions
Judges

SILICON GRAPHICS, INC., Plaintiff, v. ATI TECHNOLOGIES, INC., ATI TECHNOLOGIES ULC, and ADVANCED MICRO DEVICES, INC., Defendants.

OPINION and ORDER

BARBARA CRABB, District Judge

This civil case for patent infringement is before the court for construction of certain claim terms in plaintiff Silicon Graphics, Inc.'s United States Patent Nos. 6,650,327 (the `327 patent), 6,292,200 (the `200 patent) and 6,885,376 (the `376 patent), following a hearing on August 31, 2007. All three patents relate to advanced computer graphics processing technology. The parties dispute the meaning of numerous terms included in each patent.

From the parties' arguments at the hearing, their prehearing briefs and their posthearing supplemental briefs and from the patent claims, patent specification and prosecution history, I conclude that the jury would benefit from having a judicial construction of seven terms each from the `327 and the `200 patents. Therefore, I have construed the following terms from the `327 patent: scan conversion, frame buffer, rasterization, s10e5, per-fragment operations, circuit and coupled to. I have construed the following terms from the `200 patent: host processor, plurality of rendering pipes/plurality of rendering circuits, interface, request, controller, frame buffer and transmission medium. The remaining terms for which the parties seek construction need no construction at this time.

I have not construed any of the terms of the `376 patent because I conclude that the `376 patent is no longer in dispute. The parties were permitted two rounds of summary judgment, the first of which was completed prior to the claims construction hearing. In an opinion and order issued on August 20, 2007, I granted defendants' first motion for summary judgment in part. Plaintiff did not deny that defendants had moved for summary judgment on all asserted claims of the `376 patent and with respect to all accused products, dkt. #197 at 73. In that opinion, I concluded that plaintiff failed to adduce any evidence of infringement with respect to the `376 patent. The parties appear to agree that the `376 patent is no longer in dispute; when defendants took the position at the claims construction hearing that no claims remained with respect to the `376 patent, dkt. #197 at 107, plaintiff neither rebutted defendants' statement, nor addressed any argument to any of the claim terms of the `376 patent.

Whether plaintiff continues to pursue claims related to the `200 patent is more difficult to discern. I granted defendants' motion for summary judgment with respect to the claims and accused products then before the court. However, plaintiff did not concede that defendants had moved for summary judgment with respect to all asserted claims or products, and defendants did not pin them down, dkt. #132 at 56. Out of an abundance of caution, I will construe necessary terms from the `200 patent in this opinion.

One final procedural matter requires resolution before I discuss the claim construction. I allowed the parties to file supplemental claim construction briefs following the hearing on August 31. In its reply supplemental brief, defendants raised a new argument related to rasterization. Plaintiff filed a motion requesting leave to respond to this new argument, dkt. #218; shortly thereafter, defendants filed a motion for leave to file a response to plaintiff's response, dkt. #222. Enough is enough. I have not considered defendants' argument, because it was raised for the first time in a reply brief. Ordinarily, this court follows the lead of the Court of Appeals for the Seventh Circuit, and considers waived arguments or facts raised for the first time in a reply brief. United States v. Adamson, 441 F.3d 513, 521 n. 2 (7th Cir. 2006); Peters v. Astrazeneca, LP, 417 F. Supp. 2d 1051, 1054 (W.D. Wis. 2006); Michaels v. Mr. Heater, Inc., 411 F. Supp. 2d 992, 995-96 (W.D. Wis. 2006). Therefore, I will deny both motions to file additional briefs as moot.

OPINION

When construing claims, the starting point is the so-called intrinsic evidence: the claims themselves, the patent specification and the prosecution history. Teleflex, Inc. v. Ficosa North America Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). Construction of the disputed terms begins with the language of the claims. Claim terms are to receive their ordinary and customary meaning, which is the meaning that a person of ordinary skill in the art would have understood the claim term to have as of the filing date of the patent application. Phillips v. AWH Corp., 415 F.3d 1303, 1313 (Fed. Cir. 2005); Rexnord Corp. v. Laitram Corp., 274 F.3d 1336, 1342 (Fed. Cir. 2001). Moreover, "unless compelled to do otherwise, a court will give a claim term the full range of its ordinary meaning as understood by an artisan of ordinary skill." Rexnord, 274 F.3d at 1342.

In many instances, however, a court must proceed beyond the bare language of the claims and examine the patent specification. The specification serves an important role in arriving at the correct claim construction because it is there that the patentee provides a written description of the invention that allows a person of ordinary skill in the art to make and use the invention. Markman, 52 F.3d at 979. It is useful to consult the specification to understand claim terms because "patent law permits the patentee to choose to be his or her own lexicographer by clearly setting forth an explicit definition for a claim term that could differ in scope from that which would be afforded by its ordinary meaning." Rexnord, 274 F.3d at 1342; Vitronics, 90 F.3d at 1582. Although the patent specification does not broaden or narrow the invention, which is specifically laid out in the patent's claims, the specification may be used to interpret what the patent holder meant by a word or phrase in the claim. E.I. Du Pont de Nemours Co. v. Phillips Petroleum Co., 849 F.2d 1430, 1433 (Fed. Cir. 1988); see also Vitronics, 90 F.3d at 1582 (when term is not specifically defined in claims, it is necessary to review specification to determine whether inventor uses term inconsistently with its ordinary meaning).

After considering the claim language and the specification, a court may consider the final piece of intrinsic evidence, the patent's prosecution history. Vitronics, 90 F.3d at 1582. "[S]tatements made during the prosecution of a patent may affect the scope of the invention." Rexnord, 274 F.3d at 1343. Generally, the prosecution history is relevant if a particular interpretation of the claim was considered and specifically disclaimed during the prosecution of the patent. Warner-Jenkinson Co., Inc. v. Hilton Davis Chemical Co., 520 U.S. 17, 30 (1997);Vitronics, 90 F.3d at 1582-83.

Finally, a court may consult extrinsic evidence, such as dictionaries, treatises and expert testimony for background information and to "shed useful light on relevant art." Phillips, 415 F.3d at 1317 (internal citations omitted). However, the Court of Appeals for the Federal Circuit has cautioned that this type of evidence is "less significant" and not as reliable as intrinsic evidence in determining "the legally operative meaning of claim language." Id. at 1317-18.

A. U.S. Patent No. 6,650,327

The `327 patent discloses graphics rendering hardware and methodology in a computer system that uses floating point rasterization and floating point framebuffering. The disputed claim terms appear throughout the claims, which are reproduced in full below. The parties contend that 15 claim terms in the patent are in dispute and require construction by the court. However, construing many of these terms is unnecessary. For example, as discussed in greater detail below, I have not construed terms such as "rasterization circuit" because its meaning is clear from the construction of other terms. Likewise, I conclude that it is not necessary to construe the terms "operating on" and "operating directly on" because the parties' proposed constructions simply replace one commonly understood phrase with another.

(The parties do not dispute the meaning of "floating point format," which refers to a method for recording numbers. Numbers that are recorded in floating point format typically take the form 1.234 x 10e where "e" is an exponent. As "e" changes, the location of the decimal point "floats." In contrast, fixed point numbers have a fixed decimal point.)

The claims of the `327 patent are as follows:

What is claimed is:

1. A computer system, comprising:
a processor for performing geometric calculations on a plurality of vertices of a primitive;
a rasterization circuit coupled to the processor that rasterizes the primitive according to a rasterization process which operates on a floating point format;
a frame buffer coupled to the rasterization circuit for storing a plurality of color values; and
a display screen coupled to the frame buffer for displaying an image according to the color values stored in the frame buffer;
wherein the rasterization circuit performs scan conversion on vertices having floating point color values.
2. A computer system, comprising:
a processor for performing geometric calculations on a plurality of vertices of a primitive;
a rasterization circuit coupled to the processor that rasterizes the primitive according to a rasterization process which operates on a floating point format;
a frame buffer coupled to the rasterization circuit for storing a plurality of color values;
a display screen coupled to the frame buffer for displaying an image according to the color values stored in the frame buffer;
a texture circuit coupled to the rasterization circuit that applies a texture to the primitive, wherein the texture is specified by floating point values; and
a texture memory coupled to the texture circuit that stores a plurality of textures in floating point values.
3. A computer system, comprising:
a processor for performing geometric calculations on a plurality of vertices of a primitive;
a rasterization circuit coupled to the processor that rasterizes the primitive according to a rasterization process which operates on a floating point format;
a frame buffer coupled to the rasterization circuit for storing a plurality of color values; and
a display screen coupled to the frame buffer for displaying an image according to the color values stored in the frame buffer;
wherein the floating point format is comprised of sixteen bits in a s10e5 format.
4. A computer system, comprising:
a processor for performing geometric calculations on a plurality of vertices of a primitive;
a rasterization circuit coupled to the processor that rasterizes the primitive according to a rasterization process which operates on a floating point format;
a frame buffer coupled to the rasterization circuit for storing a plurality of color values;
a display screen coupled to the frame buffer for displaying an image according to the color values stored in the frame buffer; and
a fog circuit coupled to the rasterization circuit for performing a fog function, wherein the fog function operates on floating point color values.
5. A computer system, comprising:
a processor for performing geometric calculations on a plurality of vertices of a primitive;
a rasterization circuit coupled to the processor that rasterizes the primitive according to a rasterization process which operates on a floating point format;
a frame buffer coupled to the rasterization circuit for storing a plurality of color values;
a display screen coupled to the frame buffer for displaying an image according to the color values stored in the frame buffer; and
a blender coupled to the rasterization circuit which blends floating point color values.
6. A computer system, comprising:
a processor for performing geometric calculations on a plurality of vertices of a primitive;
a rasterization circuit coupled to the processor that rasterizes the primitive according to a rasterization process which operates on a floating point format;
a frame buffer coupled to the rasterization circuit for storing a plurality of color values;
a display screen coupled to the frame buffer for displaying an image according to the color values stored in the frame buffer; and
logic coupled to the rasterization circuit which performs per-fragment operations on floating point color values.
7. A computer system, comprising:
a processor for performing geometric calculations on a plurality of vertices of a primitive;
a rasterization circuit coupled to the processor that rasterizes the primitive according to a rasterization process which operates on a floating point format;
a frame buffer coupled to the rasterization circuit for storing a plurality of color values; and
a display screen coupled to the frame buffer for displaying an image according to the color values stored in the frame buffer;
wherein the processor, the rasterization circuit, and the frame buffer are on a single semiconductor chip.
8. The computer system of claim 7, wherein the processor, the rasterization circuit, and the frame buffer reside on a same substrate of the single semiconductor chip.
9. In a computer system, a method for rendering a three-dimensional image for display, comprising the steps of:
performing geometric calculations on a plurality of vertices of a plurality of polygons;
scan converting a plurality of pixels according to the vertices, wherein scan conversion is performed on floating point color values;
applying a texture to the image by reading floating point texture values stored in a texture memory;
simulating fog effects, wherein fog is simulated by modifying floating point color values;
drawing the image for display on a display screen coupled to the computer system.
10. The method of claim 9, wherein the floating point values are comprised of sixteen bits.
11. The method of claim 10, wherein the floating point values are specified by a s10e5 format.
12. The method of claim 10 further comprising the step of storing the floating point color values in a frame buffer.
13. The method of claim 10 further comprising the step of blending at least two floating point color values.
14. The method of claim 10 further comprising the step of performing antialiasing on floating point color values.
15. The method of claim 10 further comprising the steps of: reading data from the frame buffer; modifying the data; writing modified data back to the frame buffer.
16. The method of claim 10 further comprising the step of modifying color values for lighting, wherein lighting calculations operate on floating point color values.
17. In a computer system, a method for operating on data stored in a frame buffer, comprised of:
storing the data in the frame buffer in a floating point format;
reading the data from the frame buffer in the floating point format;
operating directly on the data in the floating point format; and
writing the data to the frame buffer in the floating point format;
wherein the steps of writing, storing, and reading the data in the frame buffer in the floating point format are further comprised of a specification of the floating point format, wherein the specification corresponds to a level of range and precision.
18. The method of claim 17 wherein the specification is comprised of 16 bits of data and the data are comprised of one sign bit, ten mantissa bits, and five exponent bits.
19. The method of claim 17 wherein the specification is comprised of 17 bits of data and the data are comprised of one sign bit, 11 mantissa bits, and five exponent bits.
20. The method of claim 17 wherein the specification is comprised of 16 bits of data and the data are comprised of ten mantissa bits, and six exponent bits.
21. The method of claim 17 wherein the specification is comprised of 32 bits of data and the data are comprised of one sign bit, 23 mantissa bits, and eight exponent bits.
22. A computer system having a floating point frame buffer for storing a plurality of floating point color values;
wherein the floating point color values are written to, read from, and stored in the frame buffer using a specification of the floating point color values that corresponds to a level of range and precision.
23. The computer system of claim 22, wherein the floating point color values are comprised of 16 bits of data and the data are comprised of one sign bit, ten mantissa bits, and five exponent bits.
24. The computer system of claim 22, wherein the floating point color values are comprised of 17 bits of data and the data are comprised of one sign bit, 11 mantissa bits, and five exponent bits.
25. A computer system, comprising:
a processor for performing geometric calculations on a plurality of vertices of a primitive;
a rasterization circuit coupled to the processor that rasterizes the primitive according to a rasterization process which operates on an s10e5 floating point format;
a frame buffer coupled to the rasterization circuit for storing a plurality of s10e5 floating point color values;
a display screen coupled to the frame buffer for displaying an image according to the s10e5 color values stored in the frame buffer.
26. The computer system of claim 25 further comprising:
a texture circuit coupled to the rasterization circuit that applies a texture to the primitive, wherein the texture is specified by s10e5 floating point values.
27. The computer system of claim 25 further comprising alighting circuit coupled to the rasterization circuit for performing a lighting function, wherein the lighting function executes on s10e5floating point color values.
28. The computer system of claim 25 further comprising a fog circuit coupled to the rasterization circuit for performing a fog function, wherein the fog function operates on s10e5 floating point color values.
29. The computer system of claim 25 further comprising an antialiasing circuit coupled to the rasterization circuit which performs an antialiasing algorithm on s10e5 floating point color values.
30. The computer system of claim 25 further comprising ablender coupled to the rasterization circuit which blends s10e5floating point color values.
31. The computer system of claim 25 further comprising logic coupled to the rasterization circuit which performs per-fragment operations on s 10e5 floating point color values.

1. Scan conversion/scan converting

Plaintiff's construction: Specifying primitives to pixels or fragments.

Defendants' construction: A process which specifies which pixels of the display screen belong to which primitives on an entirely floating point basis.

The terms "scan conversion" and "scan converting" appear in claims 1 and 9 of the `327 patent. The parties disagree about the definition of the terms; their primary disagreement is whether they must include an explicit explanation that they are done on an entirely floating point basis. Plaintiff argues that such a definition would render the language in several claims superfluous, which is contrary to the principle that "[a] claim construction that gives meaning to all the terms of the claim is preferred over one that does not do so." Merck Co, Inc. v. Teva Pharmaceuticals USA, Inc., 395 F.3d 1364, 1372 (Fed. Cir. 2005). Specifically, they argue that, if the term "scan conversion" is replaced with defendants' construction, the claim language would become repetitive. Defendants argue that this addition is necessary and does not render surrounding claim language superfluous.

Defendants have the better argument. The summary of the invention states unequivocally that "scan conversion is done on an entirely floating point basis." Col. 4, lns. 17-19. Although including "on an entirely floating point basis" in the definition of scan conversion does render the claim language somewhat unwieldy, it does not render portions superfluous. For example, claim 1 discloses a computer system, "wherein the rasterization circuit performs scan conversion on vertices having floating point color values." The claim language explains that the vertices on which scan conversion is performed have floating point color values. It is silent about whether the scan conversion process itself operates exclusively on a floating point basis. Likewise, claim 9 discloses a graphics rendering method that includes the step of "scan converting a plurality of pixels according to the vertices, wherein scan conversion is performed on floating point color values." Here, the values on which the scan conversion operates are in floating point. Whether their floating point nature is maintained through the scan conversion process is not explicit in the claim language, but the patent specification makes it clear that "scan conversion" performed in the claimed invention is done "on an entirely floating point basis."

Next, the parties disagree about the nature of scan conversion. Defendants argue that the phrase "a process which specifies which pixels of the display screen belong to which primitives" is more readily understandable by a jury than plaintiff's proposed definition, "specifying primitives to pixels or fragments." Somewhat curiously, both parties suggest that the definition of scan conversion used in column 1, lns. 32-34 of the `327 patent is correct, that is, that scan conversion is a "process" that specifies which "`pixels' of the display screen belong to which of the primitives," but they provide different interpretations of it. I will adopt defendants' proposed construction rather than plaintiff's because plaintiff does not offer a reason for departing from the language of the specification in its briefs and defendants' proposal is an accurate description of the process of scan conversion.

Court's construction: Scan conversion is a process that specifies which pixels of the display screen belong to which primitives on an entirely floating point basis.

2. Frame buffer

Plaintiff's construction: Computer memory for storing fragment and/or pixel color values during or after rasterization.

Defendants' construction: The portion of memory that contains the floating point color values that are scanned out and drawn for display.

The term "frame buffer" is used in claims 1 through 8, 12, 15 and 17 through 31 of the `327 patent. In claims 1 through 8, it is used in the following two clauses: "a frame buffer coupled to the rasterization circuit for storing a plurality of color values;" and "a display screen coupled to the frame buffer for displaying an image according to the color values stored in the frame buffer."

In claim 17, the term is used extensively. Claim 17 discloses:

In a computer system, a method for operating on data stored in a frame buffer, comprised of:
storing the data in the frame buffer in a floating point format;
reading the data from the frame buffer in the floating point format;
operating directly on the data in the floating point format;
and writing the data to the frame buffer in the floating point format;
wherein the steps of writing, storing, and reading the data in the frame buffer in the floating point format are further comprised of a specification of the floating point format, wherein the specification corresponds to a level of range and precision.

The parties' dispute about the appropriate construction centers on two issues. First, whether all color values stored in the frame buffer must be in floating point format and second, whether color values stored in the frame buffer must be scanned out and drawn for display.

a. Use of floating point values vs. fixed point values

Defendants maintain that "frame buffer" should be construed to make clear that all stored values are in floating point because plaintiff disclaimed a frame buffer that stores any fixed point values. The Court of Appeals for the Federal Circuit has recognized that "where the specification makes clear that the invention does not include a particular feature, that feature is deemed to be outside the reach of the claims of the patent, even though the language of the claims, read without reference to the specification, might be considered broad enough to encompass the feature in question." SciMed Life Systems v. Advanced Cardiovascular Systems, Inc., 242 F.3d 1337, 1343 (Fed. Cir. 2001).

Defendants' assertion that plaintiff made an explicit disclaimer of the use of any fixed point values in the frame buffer overstates the facts somewhat. The "Background Art" portion of the `327 patent does describe ways in which the use of floating point values in the frame buffer represents an improvement over the prior art. For example, it states that "[in prior art] data would need to be read from the frame buffer and input into the graphics program at or near the beginning of the program, so that the data could be recalculated in the floating point format to restore the required precision and range," `327 Pat., col. 3, lns. 25-29, and "the use of fixed point formatting in the frame buffer is a drawback in the prior art because of the limitations imposed on the range and precision of the data stored in the frame buffer," Id. at col. 3, lns. 49-52.

Although these statements highlight the improvement of using floating point values in the frame buffer, they do not state explicitly that the values stored in the frame buffer in the claimed invention may be in floating point only. Therefore, they are not the kind of "words or expressions . . . representing a clear disavowal of claim scope" that the Court of Appeals for the Federal Circuit has held to be the equivalent of a disclaimer.Teleflex, Inc., 299 F.3d at 1327.

Without evidence of an unambiguous, explicit disclaimer, it would be inappropriate to incorporate this limitation in the construction of the term "frame buffer." Doing so would render superfluous at least some of the claim language of the `327 patent. For example, claim 22 discloses "A computer system having a floating point frame buffer for storing a plurality of floating point color values . . ." Inserting the limitation that the frame buffer handles values in exclusively floating point format would render much of the claim language redundant. Moreover, many other claims of the `327 patent discuss the frame buffer, but do not include the limitation that it is floating point or that the color values it stores are floating point.

Defendants make one final argument regarding disclaimer. That is that plaintiff limited the scope of several claims in later patent proceedings. See, e.g., Microsoft Corp. v. Multi-Tech Systems, Inc., 357 F.3d 1340, 1349 (Fed. Cir. 2004). Having reviewed the confidential materials filed under seal by both parties, I find the statements included in the continuation to be ambiguous at best. They do not operate as explicit disclaimers. Therefore, as I stated at the claims construction hearing, Tr., dkt. #197 at 35, I have rejected these arguments.

b. Whether stored values must be scanned out and drawn for display

The parties agree, and the claim terms make it clear that in the inventions claimed in the `327 patent, a "frame buffer" stores graphics data and, specifically, graphics data associated with the rasterization process. Defendants argue that a proper construction should make it explicit that the data stored in the frame buffer are "color values" that are scanned out and drawn for display. Defendants' argument appears to be that the frame buffer is associated closely with a display in many of the claims and the figures used in the `327 patent and that, if the construction is not limited, there would be no obvious distinction between the frame buffer and other types of memory. Defendants' arguments have some initial appeal, but they find little support in the actual language of the claim terms or the specification. As a result, I have rejected them.

It is true that in several of the figures included in the `327 patent the frame buffer is connected directly to the display.See, e.g., figs. 1, 5C. However, it is a stretch to assume that, because of their close association, the frame buffer's stored data must be scanned out and drawn for display. In addition, defendants' construction fails to take claim 17 into consideration. Claim 17 does not require the display of the data or disclose a means for doing so. Col. 14, lns. 58-67, col. 15, lns. 1-5. Instead, it discloses a method for operating on the data stored in the frame buffer, where data is read from, operated on and written to the frame buffer in floating point format. Id. Such an operation would make little sense if all stored data were necessarily "scanned out and drawn for display" before the full operation had taken place.

Finally, the claim terms themselves make it clear that the frame buffer stores "color values." It is not clear what advantage is gained by adopting plaintiff's proposed construction that the stored data are "fragment and/or pixel color values." Plaintiff has not explained why it would be proper or even helpful to the jury to add this definition, which appears nowhere in the claim terms, when the terms instead explain simply that "color values" are stored in the frame buffer. Therefore, the court's construction will include only a reference to stored "color values" and not "fragment and/or pixel color values" as plaintiff urges. Court's construction: Frame buffer is the portion of computer memory for storing color values during or after rasterization.

3. Rasterization

Plaintiff's construction: A graphics operation that translates three dimensional primitives into a set of corresponding fragments and/or pixels and fills them in. Rasterization typically includes one or more of the processes of scan conversion, assigning colors, lighting, applying texture, applying fog, blending, shading and antialiasing.

Defendants' construction: Scan converting and assigning base colors.

At the claims construction hearing, I asked the parties what would be wrong with defining rasterization as "a graphics operation that translates three-dimensional primitives into a set of corresponding fragments of pixels or both and fills them in." In their supplemental briefing, the parties respond that this construction of "rasterization" is acceptable, stating that it "is adequate," Plt.'s Supp. Br., dkt. #202 at 8, and "describes what a skilled artisan's understanding of rasterization would have been at the time." Defts.' Supp. Br., dkt. #204 at 6. However, defendants continue to argue that any construction of "rasterization" should make clear that, in the context of the `327 patent, it is performed entirely in floating point format.

The summary of the invention states that "[t]he present invention provides a display system and process whereby the geometry, rasterization, and frame buffer predominantly operate on a floating point format." `327 Pat., col. 4, lns. 8-10. The summary goes on to note that "certain rasterization processes are performed according to a floating point format." Id. at lns. 15-16. This suggests that at least some rasterization processes do not operate according to a floating point format.

Defendants argue that this general statement is governed by specific statements elsewhere in the patent that are associated with preferred embodiments represented graphically in Figures 4 and 5. Defendants' argument is unavailing, for two reasons. First, a description of one preferred embodiment cannot be read into the claim unless the specification makes it clear that the description relates to the invention as a whole rather than to one example. SciMed Life Systems, Inc., 242 F.3d at 1343 (limitation from specification could be read into claim when specification made it clear that limitation applied to all embodiments). That is not the case here.

Next, the statements to which defendants point for support are ambiguous, at best. Specifically, the patent specification states that "[i]t should be noted that one or more of the [steps shown in the figures] can be implemented in a fixed point format without departing from the scope of the present invention." `327 Pat., col. 12, lns. 26-28. It goes on to say "However, the [steps shown in the figures] of particular importance for implementation in a floating point format include the polygon rasterization. . . ." Although this statement offers strong support for the idea that floating point rasterization of polygons is preferable, it does not foreclose the possibility that fixed point could be used and still fall within the scope of the invention. Therefore, I disagree with defendants that this statement "governs" and narrows the broader statement in the patent summary.

Finally, defendants argue that claims 1-8 and 25-31 relate to rasterization of primitives that have a plurality of vertices and that primitives that have a plurality of vertices must undergo scan conversion, which is performed in floating point format, as noted above. As a result, defendants say, when "rasterization" is used in these claims, it must be in floating point format. However, claims 1 through 8 each already state that the "rasterization process [] operates on a floating point format." Therefore, inserting additional language requiring "rasterization" to operate on a floating point format would render superfluous portions of claims 1 through 8. For the reasons discussed above, I decline to give the language this construction

Court's construction: Rasterization is a graphics operation that translates three-dimensional primitives into a set of corresponding fragments of pixels or both and fills them in.

4. s10e5

Plaintiff's construction: A floating point format with one sign bit, a 10-bit mantissa, and a 5-bit exponent.

Defendants' construction: A 16 bit floating point format comprised of one sign bit, ten mantissa bits, and five exponent bits, with an exponent bias of 16, as defined in Fig. 3.

The parties' proposed constructions are nearly identical. However, defendants argue that "s10e5" as used in the `327 patent must include an exponent bias of 16. When used in the claim language itself, s10e5 is not defined. However, the patent specification sheds some light on the matter.

The summary of the invention explains that "one floating point format, known as `s10e5' has been found to be particularly optimal . . .," `327 Pat., col. 4, lns. 27-29, and "this particular's 10e5 floating point format imposes a 16-bit format which provides one sign bit, ten mantissa bits, and five exponent bits." Id., col. 4, lns. 34-37. Plaintiff asserts that this is the only statement in the specification that relates to the term generally, as opposed to setting forth parameters for a preferred embodiment. Not surprisingly, defendants argue that the following statement found later in the specifications controls instead,

The 16-bit floating point format utilized in one embodiment of the present invention is designated using the nomenclature `s10e5,' where `s' specifies one (1) sign bit, `10' specifies ten (10) mantissa bits, and `e5' specifies five (5) exponent bits, with an exponent bias of 16. FIG. 3 defines the represented values for all possible bit combination for the s10e5 format.
Id., col. 8, lns. 45-50.

I am mindful of the court of appeals' caution, echoed by plaintiff, that "importing limitations from the written description into the claims is a `cardinal sin' of claim construction." Plt.'s Resp. Br., dkt. #212 at 33 (quotingTeleflex, Inc., 299 F.3d at 1324). However, the court's construction does not violate the rule because plaintiff defined the meaning of "s10e5" explicitly. Plaintiff stated that it is a nomenclature for a particular 16-bit format, and one that uses an exponent bias of 16. `327 Pat., col. 8, lns. 45-50. The claims include references to other 16-bit formats, but this is one that plaintiff chose to define with greater detail. Although this description appeared in the context of a preferred embodiment of the invention, the surrounding text makes clear that this is the general definition for s10e5 wherever it is used, and not just a preferred embodiment of that particular format. In situations like this, in which the inventors "acted as its own lexicographer" it is appropriate to hold the inventor to the definition provided. Plaintiff cannot now redefine the term to suit its litigation needs.

Court's construction: s10e5 is a 16 bit floating point format composed of one sign bit, ten mantissa bits, and five exponent bits, with an exponent bias of 16.

5. Per-fragment operations

Plaintiff's construction: Graphics processing steps within rasterization including one or more of pixel ownership, scissor test, alpha test, stencil test, depth buffer test, dithering, and logic operations.

Defendants' construction: Operations that alter or throw out fragments.

The term "per-fragment operations" appears in claim 6 and claim 31 of the `327 patent. Claim 6 discloses "A computer system, comprising . . . logic coupled to the rasterization circuit which performs per-fragment operations on floating point color values" (emphasis added). Claim 31 discloses "The computer system of claim 25 further comprising logic couple to the rasterization circuit which performs per-fragment operations on s10e5 floating point color values" (emphasis added).

Neither proposed construction is especially helpful in explaining this term. The Background Art portion of the specification explains that, in more sophisticated computer systems, fragments may be processed on a "per-fragment basis." By this, the specification appears to be saying simply that certain operations are performed on individual fragments. This explanation of the term is supported by the statement later in the specification that "per-fragment operations 139 consist of additional operations that may be enabled to enhance the detail of the fragments." `327 Pat., col. 7, lns. 23-25.

Defendants' construction limits "per-fragment operations" to "alter[ing] or throw[ing] out" fragments. They take this from a discussion of the preferred embodiment, which states that "operations are performed by per-fragment operations block 411 that may alter or even throw out fragments." Clearly, inserting this limitation of what per-fragment operations may do in a preferred embodiment into the claims is both unhelpful and improper.

Plaintiff's construction is better, and is the construction I will adopt. Id. at col. 12, lns. 1-17. It is not my preference to provide a definition of a term by simply listing possible manifestations of the underlying operation, which is what plaintiff's construction does. However, in this case, the patent specification does provide that all of the listed operations are performed on fragments and this information is at least somewhat helpful in identifying which operations are considered "per-fragment operations."

Court's construction: Per-fragment operations are graphics processing steps within rasterization including one or more of pixel ownership, scissor test, alpha test, stencil test, depth buffer test, dithering, and logic operations.

6. Circuit

Plaintiff's construction: Hardware, typically electrical, for performing one or more specified functions.

Defendants' construction: An interconnection of electrical elements.

Neither party points to any intrinsic evidence to support their proposed construction. Instead, they both maintain that the term "circuit" is well understood in the art to have the meaning they propose and not have the meaning proposed by the other party. In support of its construction, plaintiff cites no authority. Defendant cites the IEEE Standard Dictionary of Electrical and Electronics Terms, (6th ed. 1997) at 156. Given the lack of supporting evidence for plaintiff's wordy definition, I will not adopt it. Instead, I will adopt defendants' construction, with one minor change. Massachusetts Institute of Technology v. Abacus Software, 462 F.3d 1344, 1351 (Fed. Cir. 2006) (endorsing use of technical dictionary definition in limited circumstances). The term "circuit" appears in claims 1 through 8 and 25 through 31, all of which refer to computer systems and graphics processing hardware. Therefore, it is clear that any circuit described in this context is "hardware" and I have altered defendants' proposed construction accordingly. Court's construction: A circuit is an interconnection of electrical hardware.

7. Coupled to

Plaintiff's construction: Associated with.

Defendants' construction: Associated in such a way that power or signal information may be transferred from one to another.

Again, neither the claims nor the specification of the `327 patent shed light on any definition of "coupled to" that departs from the ordinary meaning of the term. However, the parties suggest that the term has a different meaning in the context of the `327 patent from its common usage. Therefore, it is likely that a jury would benefit from a construction that reflects its common understanding in the art, as opposed to among laypeople. In its opening claims construction brief, plaintiff does not cite a source for its argument that "coupled to" means "associated with." Plt.'s Br., dkt. #167 at 34. In its supplemental claims construction brief, plaintiff cites a general purpose dictionary. Plt.'s Supp. Br., dkt. #202 at 15. If "coupled to" is widely understood by laypeople to mean "associated with" and this is the proper definition, then there is little need for the court to construe the term at all. In this event, it is not clear why plaintiff did not use the term "associated with" in the claim language itself. Defendants maintain that the proper definition is a technical one that can be found in the IEEE Standard Dictionary of Electrical and Electronics Terms and I agree.

Court's construction: Coupled to is associated in such a way that power or signal information may be transferred from one to another.

8. Terms not requiring additional construction

Several terms that the parties propose for construction do not require any additional construction at this time. They fall into three categories. First, I find that the terms "Rasterization Circuit," "Rasterization Process" and "Rasterizes the Primitive According to the Rasterization Process which Operates on a Floating Point Format" do not require additional construction because the court has construed the terms "rasterization" and "circuit" already and the parties do not appear to dispute the meaning of the terms "primitive" and "floating point format." Therefore, there would be little additional value in the court's providing a construction of these terms.

Next, the terms "operates on," "operating directly on," "performed on" and "drawing the image for display" may be easily understood by a lay jury. The parties have not demonstrated that these terms have specific or technical meanings as used in the `327 patent. I find little value in replacing the language actually used in the claim terms with close synonyms that do not appear anywhere in the claims.

Finally, the parties agree that the proper construction of the term "comprising" is "including, but not limited to." I will adopt this construction with no further discussion, other than to note that this is the widely accepted definition of the term.

B. U.S. Patent No. 6,292,200

The `200 patent discloses a computer graphics apparatus and method that uses multiple rendering pipes to create a single three dimensional display.

What is claimed is:

1. A computer system comprising:
a plurality of rendering pipes for rendering pixels of an image, wherein each of the rendering pipes comprises a host processor having an application program issuing graphics commands, a geometry circuit coupled to the host processor for processing primitives, a rasterizer coupled to the geometry circuit for generating pixel data, a frame buffer coupled to the rasterizer which stores the pixel data, an interface coupled to the rasterizer that accepts requests from the transmission medium and outputs pixel data;
a transmission medium coupling together each of the plurality of rendering pipes;
a controller coupled to one of the rendering pipes which coordinates pixel information of the image between each of the plurality of rendering pipes, wherein each of the rendering pipes is capable of rendering pixels for an entire frame or portions thereof;
a memory coupled to the controller for storing the pixel information;
a display coupled to the memory for displaying the image.
2. The computer system of claim 1, wherein the transmission medium comprises a uni-directional ring topology.
3. The computer system of claim 2, wherein the transmission medium comprises a point-to-point connection.
4. The computer system of claim 1, wherein the rendering circuit includes a local memory for storing pixel data generated locally.
5. The computer system of claim 4, wherein the controller requests the pixel data stored in the local memory.
6. The computer system of claim 5, wherein the controller merges pixel data received from a plurality of rendering circuits before drawing the image for display.
7. The computer system of claim 1 wherein the rendering circuit is further comprised of a router which examines packets from the transmission medium and routes the packets according to address information contained in the packets.
8. The computer system of claim 1 further comprising a single display driver which drives the display.
9. The computer system of claim 1, wherein the controller generates requests a pre-determined amount of clock cycles ahead of when pixel data is actually needed.
10. The computer system of claim 9, wherein the pre-determined amount of clock cycles is approximately equal to a fixed latency.
11. In a computer system, a method of rendering a three-dimensional image for display comprising the computer-implemented steps of:
rendering pixels of a three-dimensional image, wherein a plurality of rendering circuits are used to render portions of a single frame and each of the rendering pipes is capable of rendering pixels for an entire frame or portions thereof;
executing an application program on a host processor which issues graphics commands; processing vertices by a geometry circuit coupled to the host processor; generating pixel data through a rasterizer coupled to the geometry circuit; storing the pixel data in a frame buffer coupled to the rasterizer;
accepting requests from the transmission medium for the pixel data;
outputting the pixel data onto the transmission medium;
storing pixel data in a plurality of memories, each rendering circuit storing pixel data generated in a local memory;
transmitting a request through a transmission medium coupling together each of the plurality of rendering circuits;
transmitting pixel data from one of the rendering circuits through the transmission medium to a frame buffer in response to the request;
merging pixel data received from a plurality of the rendering circuits into a frame;
driving a display coupled to the frame buffer to display the three-dimensional image.
12. The method of claim 11, wherein the transmission medium comprises a uni-directional ring topology.
13. The method of claim 12, wherein the transmission medium comprises a point-to-point connection.
14. The method of claim 11, wherein each of the rendering circuits performs the executing, processing, generating, storing, accepting, and outputting steps.
15. The method of claim 11, further comprising the step of routing packets from the transmission medium according to address information contained in the packets.
16. The method of claim 11 further comprising the step of driving the display with a single driver.
17. The method of claim 11 further comprising the step of generating requests at a pre-determined number of clock cycles ahead of when pixel data is actually needed.
18. The method of claim 17, wherein the pre-determined number of clock cycles is approximately equal to a fixed latency corresponding to the computer system.

1. Host processor

Plaintiff's construction: A processor for generating and sending commands for graphics rendering.

Defendants' construction: A main CPU that runs the application program and directs the rendering process.

In the summary judgment opinion, I construed "host processor" as "a processor that runs a graphics program and issues high-level commands." I based this construction on the language of the claims themselves and the patent specification.

Plaintiff's proposed construction of "host processor" suggests that any processor could be a "host processor." This is inconsistent with the patent specifications, which make it clear that the host processor issues high-level commands. It is also inconsistent with the claims' use of the term "host processor" instead of "processor." The inclusion of the term "host" suggests that there is something that differentiates it from other processors. Defendants' construction is also problematic. They assert that a host processor must be a CPU, something that is not contemplated by the specification or any other intrinsic evidence. Instead, defendants rely on extrinsic evidence of limited value in the form of a vague statement by their expert and a generous reading of a dictionary definition.

The parties' claims construction briefs do not change my opinion at the time of summary judgment that the following construction accurately describes the role of a host processor as used in the `200 patent.

Court's construction: A host processor is a processor that runs a graphics program and issues high-level commands.

2. Plurality of rendering pipes/plurality of rendering circuits

Plaintiff's construction:

Rendering Pipe: A data path for graphics rendering comprising geometry processing, rasterization and a frame buffer.

Rendering circuit: Hardware, typically electrical, for performing one or more specified graphics rendering functions.

Defendants' construction: Two or more graphics subsystems where each includes a host processor, a geometry engine, a rasterizer, a frame buffer, and a display [interface] unit.

The parties agree that "plurality" means "more than one" in the context of the claims of the `200 patent. They further agree the terms "rendering pipe" and "rendering circuit" are interchangeable. Plt.'s Supp. R. Br., dkt. #212 at 18. Therefore, the only remaining dispute relates to the meaning of the terms, which are used in claims 1, 4, 6, 7, 11 and 14 of the `200 patent. It is somewhat difficult to discern the specific construction plaintiff now supports, after having agreed that the terms rendering pipe and rendering circuit are interchangeable.

Plaintiff takes the position that nothing in the claim language or specification requires that each rendering pipe contains a separate host processor and that no such requirement should be read into the claims. However, the prosecution history indicates otherwise. As the Court of Appeals for the Federal Circuit has held repeatedly, a patentee may limit the scope of its claim by express statements of disclaimer during the patent prosecution process. Norian Corp. v. Stryker Corp., 432 F.3d 1356, 1362 (Fed. Cir. 2005); Springs Window Fashions LP v. Novo Industries, LP, 323 F.3d 989, 995 (Fed. Cir. 2003).

In this case, the patent examiner initially rejected independent claims 1 and 14 (now claim 11) of the `200 patent, on the ground that the claims were obvious in light of the prior art, which disclosed multiple rendering pipes that included a separate geometry engine, rasterizer, frame buffer and interface, but not separate host processors. Fahrenkrog Decl., dkt. #172, exh. P. In response, the applicants amended the claims and informed the examiner that they had "amended Independent Claims 1 and 14 [now claim 11] to include the limitations wherein each of the rendering pipes comprises a host processor, a geometry engine, a rasterizer, a frame buffer and a display unit." This is a disclaimer of rendering pipes that do not each contain a host processor. Id. at exh. Q.

Plaintiff argues, weakly, that this statement does not foreclose the possibility that rendering pipes could share a host processor, but this reading is incompatible with the claim language, the patent specification and, perhaps most important, common sense.

The asserted improvement associated with the invention disclosed in the `200 patent is that "multiple rendering circuits can operate in parallel on generating a frame's worth of pixel data. In the meantime, other rendering pipes can optionally be used to generate subsequent frames. This increases the system's overall rendering power and speed." `200 Pat., col. 2, lns. 54-59. It makes little sense to tout the improvement in power and speed associated with multiple individual pipelines if those pipelines share fundamental elements. In addition, if plaintiff is correct that the claims would read on products that included rendering pipelines that shared the element of a host processor, it is not clear why rendering pipes that shared all elements would not also infringe the claims. Such a result is incompatible with the stated scope of the `200 patent and highlights the problems with plaintiff's construction.

Court's construction: Plurality of rendering pipes and plurality of rendering circuits mean two or more graphics subsystems each of which includes a host processor, a geometry engine, a rasterizer, a frame buffer, and a display [interface] unit.

3. Interface

Plaintiff's construction: A hardware or software component that connects two or more other components for the purposes of passing information from one to the other. Defendants' construction: A shared electrical boundary between parts of a computer system, through which information is conveyed.

This term appears only once, in claim 1 of the `200 patent, and does not appear at all in the patent specification. Therefore, both parties agree that it is appropriate to turn to a technical dictionary for assistance in understanding this technical term.Massachusetts Institute of Technology, 462 F.3d at 1351. Both proposed constructions come from the IEEE Standard Dictionary of Electrical and Electronics Terms. The parties agree that they are similar in meaning. I will adopt plaintiff's construction because it is more straightforward. However, I will make one minor alteration. Claim 1 discloses a computer system and hardware therein. Therefore, the "interface" described in claim 1 must be hardware, rather than software. I will alter the construction provided by plaintiff accordingly.

Court's construction: Interface means a hardware component that connects two or more other components for the purposes of passing information from one to the other.

4. "Application program issuing graphics commands" and "application program on a host processor which issues graphics commands"

Plaintiff's construction: (a) software for performing graphics rendering; (b) software on a processor for generating and sending commands for graphics rendering.

Defendants' construction: A graphics application that directs the rendering process by providing high-level instructions and graphics data to a geometry engine.

Plaintiff urges the court to construe two terms "Application Program Issuing Graphics Commands" and "Application Program on a Host Processor Which Issues Graphics Commands," but defendants contend that they have the same meaning. Neither side is able to cite the claim language or the patent specification in support of its construction. It is not clear that the jury would benefit from replacing the relatively straightforward terms of the claims themselves with equally technical phrases. Therefore, I find that no construction is needed at this time.

Court's construction: No construction needed.

5. Request

Plaintiff's construction: Form of communication between sender and recipient directing the receiver to perform a task.

Defendants' construction: A signal that causes a rendering pipe to respond by sending pixel data.

Both sides contend that their construction of the term "request" is consistent with the context of the claims of the `200 patent. The patent specification explains that "[a] controller coordinates the multiple rendering pipes by sending requests to the appropriate rendering pipes to retrieve pixel data generated by a particular pipe." `200 Pat., col. 2, lns. 48-51. Defendants' construction is problematic; if the rendering pipe fails to respond, no "request" has taken place. This is backwards and defines the action by its outcome. A request that is refused is still a "request." Plaintiff's construction is rather broad, but better comports with the plain meaning of the term and the context of the claim language.

Court's construction: Request is a communication between sender and recipient directing the receiver to perform a task.

6. Controller

Plaintiff's construction: A component of a system that sends messages to and receive response messages from another component.

Defendants' construction: A circuit that coordinates the multiple rendering pipes by sending requests, and merges pixel data received for display.

The term controller is inherently vague. However, the summary of the `200 patent describes the function of a "controller" in the context of this patent. It states that "[a] controller coordinates the multiple rendering pipes by sending requests to the appropriate rendering pipes to retrieve pixel data generated by that particular pipe. It then merges the pixel data received from the various rendering pipes into a frame's worth of data." `200 Pat., col. 2, lns. 48-53. Defendants' construction is taken almost directly from the summary and specifies the role of the controller as used in the claim terms. Plaintiff's definition does nothing to reduce the ambiguity about the meaning of the term and relies on extrinsic sources. Therefore, I will adopt defendants' construction, with one minor change. Nothing in the patent appears to require that a controller is a circuit. Therefore, I have replaced "circuit" with "component" in defendants' construction.

Court's construction: A controller is a component that coordinates the multiple rendering pipes by sending requests, and merges pixel data received for display.

7. Frame buffer

Plaintiff's construction: Computer memory for storing fragment and pixel values during and after rasterization.

Defendants' construction: A portion of memory that holds the color values that are scanned out and drawn for display.

For the reasons discussed in greater detail in the discussion of the `327 patent, I will adopt plaintiff's construction of "frame buffer" in large part. As in the `327 patent, there is no intrinsic evidence in the `200 patent supporting defendants' argument that information stored in the frame buffer must be scanned out and drawn for display. Moreover, as plaintiff points out, the specification for the `200 patent explains that, at least in one embodiment, a "local" frame buffer may hold interim data that is not itself scanned and drawn for display. `200 Pat., col. 3, lns. 11-13 ("the rasterizer then fills the primitives and stores the resulting pixel data in its local buffer memory"). Therefore, reading in such a limitation to the patent claims would be improper.

Court's construction: Frame buffer is the portion of computer memory for storing color values during or after rasterization.

8. Transmission medium

Plaintiff's construction: Any material that can be used to send or receive signals.

Defendants' construction: Any high bandwidth bus or network for transmission or digital data.

Claim 1 of the `200 patent discloses a computer system including "a transmission medium coupling together each of the plurality of rendering pipes." Claim 11 discloses a method for rendering computer graphics that includes "a transmission medium coupling together each of the plurality of rendering circuits." Defendants contend that the term "transmission medium" as used in the `200 patent is presented in a means-plus-function format and must be construed according to 35 U.S.C. § 112, ¶ 6, in other words, it must describe a structure.

According to the Court of Appeals for the Federal Circuit, the presumption is that means-plus-function treatment is inappropriate when the limitation lacks the word "means."Massachusetts Institute of Technology, 462 F.3d at 1353. However, this presumption may be rebutted when "it is shown that the claim term fails to recite sufficiently definite structure." Id. Here, the patent terms do not provide either a context for the structure of a transmission medium or a description of it. Plaintiff asserts that "transmission medium" has a particular meaning to those skilled in the art but it has adduced no evidence to support its assertion.

On its face, the term "transmission medium" is similar to indefinite terms such as "element" and "device" that could mean practically anything. As defendants point out, it could even mean "air," which is clearly incompatible with the invention claimed in the `200 patent. I conclude that defendants have shown the lack of a sufficiently definite structure and have rebutted the presumption that § 112, ¶ 6 does not apply with respect to the term "transmission medium" as used in the `200 patent.

The next question is what the structure is. The parties appear to agree that, if § 112, ¶ 6 applies, the structure is that of "Bus/network 106" described in the patent specification, `200 Pat., col. 4, lns. 13-15, which is "any high-bandwidth bus or network for transmission of digital data. . . ." Id. This is the construction I will adopt.

Court's construction: Transmission medium is any high bandwidth bus or network for transmission or digital data.

ORDER

IT IS ORDERED that the following terms are construed as follows:

(1) U.S. Patent No. 6,650,327:
• "Scan conversion/scan converting" means "a process that specifies which pixels of the display screen belong to which primitives on an entirely floating point basis";
• "Frame buffer" means "the portion of computer memory for storing color values during or after rasterization";
• "Rasterization" means "a graphics operation that translates three-dimensional primitives into a set of corresponding fragments of pixels or both and fills them in";
• "s10e5" means "a 16 bit floating point format composed of one sign bit, ten mantissa bits, and five exponent bits, with an exponent bias of 16";
• "Per-fragment operations" means "graphics processing steps within rasterization including one or more of pixel ownership, scissor test, alpha test, stencil test, depth buffer test, dithering, and logic operations";
• "Circuit" means "an interconnection of electrical hardware";
• "Coupled to" means "associated in such a way that power or signal information may be transferred from one to another";
(2) U.S. Patent No. 6,292,200:
• "Host processor" means "a processor that runs a graphics program and issues high-level commands";
• "Plurality of rendering pipes/plurality of rendering circuits" means "two or more graphics subsystems, each of includes a host processor, a geometry engine, a rasterizer, a frame buffer, and a display [interface] unit";
• "Interface" means "a hardware component that connects two or more other components for the purposes of passing information from one to the other";
• "Request" means "communication between sender and recipient directing the receiver to perform a task";
• "Controller" means "a component that coordinates the multiple rendering pipes by sending requests, and merges pixel data received for display";
• "Frame buffer" means "the portion of computer memory for storing color values during or after rasterization";
• "Transmission medium" means "any high bandwidth bus or network for transmission or digital data."
(3) the following terms from the `327 patent do not require additional construction: "rasterization circuit," "rasterization process," "rasterizes the primitive according to the rasterization process which operates on a floating point format," "operates on," "operating directly on," "performed on," "drawing the image for display" and "comprising";
(4) the following terms from the `200 patent do not require additional construction: "application program issuing graphics commands" and "application program on a host processor which issues graphics commands";
(5) terms from U.S. Patent No. 6,885,376 do not require construction because all of plaintiff's claims related to this patent have been dismissed from this lawsuit.

IT IS FURTHER ORDERED that the motion of plaintiff Silicon Graphics, Inc. to file a brief in opposition to defendants ATI Technologies, Inc., ATI Technologies ULC, and Advanced Micro Devices, Inc. new claim construction argument is DENIED as moot. Dkt. #218. In addition, defendants' motion to file a reply to plaintiff's opposition to its new claim construction argument is DENIED as moot. Dkt. #222.

Use AI to get other relevant cases.

Comments

SILICON GRAPHICS, INC. v. ATI TECHNOLOGIES, INC. (W.D.Wis. 10-15-2007)
(Oct 15, 2007)