Sun Microsystems, Inc. v. Network Appliance, Inc.

Full title: SUN MICROSYSTEMS, INC., Plaintiff, v. NETWORK APPLIANCE, INC., Defendant

Court: United States District Court, N.D. California

Date published: Dec 23, 2008

591 F. Supp. 2d 1069 (N.D. Cal. 2008)

Opinion

No. C-07-05488 EDL.

December 23, 2008

Carrie Lynne Williamson, David L. Alberti, Eliza Behold, Mark Fowler, Yakov M. Zolotorev, Christine Kerba Corbett, Dla Piper US LLP, East Palo Alto, CA, Clayton W. Thompson, II, Dla Piper US LLP, Reston, VA, Edward Robert Reines, Weil Gotshal Manges LLP, Redwood Shores, CA, for Plaintiff.

Edward Robert Reines, Jeffrey G. Homrig, Aaron Matthew Nathan, Jill Jane Ho, Weil Gotshal Manges LLP, Redwood Shores, CA, Danielle Rosenthal, Elizabeth Stotland Weiswasser, Patricia Young, Weil Gotshal Manges, LLP, New York, NY, for Defendant.

ORDER CONSTRUING CLAIM TERMS OF THE `720 AND `417 PATENTS

ELIZABETH LAPORTE, Magistrate Judge

On November 24, 2008, the Court held a hearing to construe the disputed terms of United States Patent Numbers 7,313,720 (the "'720 patent") and 6,868,417 (the "`417 patent") (collectively, the "NetApp patents") pursuant to Markman v. Westview Instruments, Inc., 517 U.S. 370, 116 S.Ct. 1384, 134 L.Ed.2d 577 (1996). Prior to the hearing, the parties stipulated to construction of the disputed term of United States Patent Number 7,107,385 (the "`385 patent"), as reflected in their November 21, 2008, letter to the Court (docket no. 103). Pursuant to Court order, the parties filed additional briefs following the hearing. Without leave of Court or stipulation, Sun submitted a separate letter brief dated December 3, 2008, concerning the construction of "inode" in the `417 patent (docket no. 109). NetApp objected to the letter as procedurally improper and misstating the record (docket no. 111). The Court hereby grants the motion to strike Sun's letter brief (docket no. 109) pursuant to Civil Local Rule 7-3(d).

The procedural history of this action is summarized in the December 22, 2008 Order, 2008 WL 5384081, construing the Sun patents. Having read the papers and considered the arguments of counsel and the relevant legal authority, the Court hereby rules as follows.

I. LEGAL STANDARD

In construing claims, the court must begin with an examination of the claim language itself. The terms used in the claims are generally given their "ordinary and customary meaning." See Phillips v. AWH Corp., 415 F.3d 1303, 1312-13 (Fed. Cir. 2005); see also Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1248 (Fed. Cir. 1998) ("The claims define the scope of the right to exclude; the claim construction inquiry, therefore, begins and ends in all cases with the actual words of the claim."). This ordinary and customary meaning "is the meaning that the terms would have to a person of ordinary skill in the art in question at the time of the invention. . . ." Phillips, 415 F.3d at 1313. A patentee is presumed to have intended the ordinary meaning of a claim term in the absence of an express intent to the contrary. York Products, Inc. v. Central Tractor Farm Family Ctr., 99 F.3d 1568, 1572 (Fed. Cir. 1996).

Generally speaking, the words in a claim are to be interpreted "in light of the intrinsic evidence of record, including the written description, the drawings, and the prosecution history, if in evidence." Teleflex, Inc. v. Ficosa North Am. Corp., 299 F.3d 1313, 1324-25 (Fed. Cir. 2002) (citations omitted); see also Medrad, Inc. v. MRI Devices Corp., 401 F.3d 1313, 1319 (Fed. Cir. 2005) (court looks at "the ordinary meaning in the context of the written description and the prosecution history"). "Such intrinsic evidence is the most significant source of the legally operative meaning of disputed claim language." Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996).

With regard to the intrinsic evidence, the court's examination begins, first, with the claim language. See id. Specifically, "the context in which a term is used in the asserted claim can be highly instructive." Phillips, 415 F.3d at 1314. As part of that context, the court may also consider the other patent claims, both asserted and unasserted. Id. For example, as claim terms are normally used consistently throughout a patent, the usage of a term in one claim may illuminate the meaning of the same term in other claims. Id. The court may also consider differences between claims as a guide to understanding the meaning of particular claim terms. Id.

Second, the claims "must [also] be read in view of the specification, of which they are a part." Id. at 1315. When the specification reveals a special definition given to a claim term by the patentee that differs from the meaning it would otherwise possess, the inventor's lexicography governs. Id. at 1316. Indeed, the specification is to be viewed as the "best source" for understanding a technical term, informed as needed by the prosecution history. Id. at 1315. As the Federal Circuit stated in Phillips, the specification is "the single best guide to the meaning of a disputed term," and "acts as a dictionary when it expressly defines terms used in the claims or when it defines terms by implication." 415 F.3d at 1321.

Limitations from the specification, however, such as from the preferred embodiment, cannot be read into the claims absent a clear intention by the patentee to do. Altiris v. Symantec Corp., 318 F.3d 1363, 1372 (Fed. Cir. 2003) ("resort to the rest of the specification to define a claim term is only appropriate in limited circumstances"); Teleflex, 299 F.3d at 1326 ("The claims must be read in view of the specification, but limitations from the specification are not to be read into the claims.") (citations omitted); CCS Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1366 (Fed. Cir. 2002) ("a patentee need not describe in the specification every conceivable and possible future embodiment of his invention").

"[T]here is sometimes a fine line between reading a claim in light of the specification, and reading a limitation into the claim from the specification. . . . [A]ttempting to resolve that problem in the context of the particular patent is likely to capture the scope of the actual invention more accurately than either strictly limiting the scope of the claims to the embodiments disclosed in the specification or divorcing the claim language from the specification." Decisioning.com, Inc. v. Federated Dept. Stores, Inc., 527 F.3d 1300, 1307-08 (Fed. Cir. 2008) (quoting Comark Comm'ns, Inc. v. Harris Corp., 156 F.3d 1182, 1186 (Fed. Cir. 1998)). There is therefore "no magic formula or catechism for conducting claim construction," and the court must "read the specification in light of its purposes in order to determine whether the patentee is setting out specific examples of the invention to accomplish those goals, or whether the patentee instead intends for the claims and the embodiments in the specification to be strictly coextensive." Id. (internal citations omitted).

Finally, as part of the intrinsic evidence analysis, the court "should also consider the patent's prosecution history, if it is in evidence." Phillips, 415 F.3d at 1317. The court should take into account, however, that the prosecution history "often lacks the clarity of the specification" and thus is of limited use for claim construction purposes. Id.

In most cases, claims can be resolved based on intrinsic evidence. See Vitronics, 90 F.3d at 1583. Only if an analysis of the intrinsic evidence fails to resolve any ambiguity in the claim language may the court then rely on extrinsic evidence, such as expert and inventor testimony, dictionaries, and learned treatises. See Vitronics, 90 F.3d at 1583 ("In those cases where the public record unambiguously describes the scope of the patented invention, reliance on any extrinsic evidence is improper"). "Within the class of extrinsic evidence, the court has observed that dictionaries and treatises can be useful in claim construction." Phillips, 415 F.3d at 1318. While expert testimony can be useful to a court for a variety of purposes, conclusory assertions by experts are not useful to a court. Id. The court generally views extrinsic evidence as less reliable than the patent and its prosecution history in determining how to read claim terms, even if though consideration is within the court's sound discretion. See id. at 1318-19.

II. DISCUSSION

The parties dispute four terms, two in each of the NetApp patents: (1) "increas[ed/ing] a number of persistent consistency point images" and (2) "file system information (fsinfo) block" in the `720 patent; and (3) "storage layer underlying the block and file level servers" and (4) "mode operations"/"the mode layer operations" in the `417 patent.

A. The `720 Patent

The claimed invention "relates to file systems and, more specifically, to a technique for increasing the number of persistent consistency point images of a file system." `720 patent, col. 1:7-9 (Field of the Invention). The Abstract states:

An on-disk storage arrangement increases the number of persistent consistency point images (PCPIs) that may be maintained for a volume of a storage system. The on-disk storage arrangement comprises a novel volume information (volinfo) block representing a root of the volume; the volinfo block is stored at predefined locations on disk and comprises various system wide configuration data. The volinfo block further comprises a data structure configured to provide a level of indirection that increases the number of PCPIs maintainable by a file system executing on the storage system. To that end, the data structure may be organized as an array of pointers, wherein each pointer references a block containing a snapshot root, thereby enabling efficient access to each PCPI maintained by the file system.

`720 patent, Abstract.

1. "increas[ed/ing] a number of persistent consistency point images"

Disputed Claim Term: Sun's construction NetApp's construction 35 U.S.C. § 112

"increas[ed/ing] a number of persistent consistency point images" Sun contends this phrase is indefinite under No construction necessary, because (I) it ¶ 2. is part of the preamble, and not a limitation; and (ii) its meaning is plain on its face. To the extent the Court deems a construction necessary, the term means "to provide/providing more than a low predefined number of maintainable persistent consistency point images." Sun disputes NetApp's contention that this term is not a claim limitation, and contends that this claim term is indefinite because it does not sufficiently inform the public of the bounds of the protected invention.

The disputed term appears in independent claims 1, 11, 18 and 19 of the `720 patent, which state:

1. A method for increasing a number of persistent consistency point images (PCPIs) maintained for a volume of a storage system, the method comprising the steps of:

providing a file system information (fsinfo) block associated with an active file system executing on the storage system;

providing one or more PCPI fsinfo blocks, each PCPI fsinfo block associated with a PCPI; and

providing a volume information (volinfo) block at a predetermined location on disk of the storage system, the volinfo block comprising a plurality of pointers configured to reference the fsinfo and PCPI fsinfo blocks.

. . .

11. A system adapted to maintain an increased number of persistent consistency point images (PCPI) for a volume of a storage system, the system comprising:

at least one storage device adapted to store a volume information (volinfo) block at a predefined location, the storage device further adapted to store a plurality of file system information (fsinfo) blocks referenced by the volinfo block.

. . .

18. Apparatus for increasing a number of persistent consistency point images (PCPIs) maintained for a volume of a storage system, the apparatus comprising:

means for providing a file system information (fsinfo) block associated with an active file system executing on the storage system;

means for providing one or more PCPI fsinfo blocks, each PCPI fsinfo block associated with a PCPI; and

means for providing a volume information (volinfo) block at a predetermined location on disk of the storage system, the volinfo block comprising a plurality of pointers configured to reference the fsinfo and PCPI fsinfo blocks.

. . .

19. A computer readable medium, including program instructions executing on a storage system, for increasing a number of persistent consistency point images (PCPIs) maintained for a volume of the storage system, the computer readable medium including program instructions for:

providing a file system information (fsinfo) block associated with an active file system executing on the storage system;

providing one or more PCPI fsinfo blocks, each PCPI fsinfo block associated with a PCPI; and

providing a volume information (volinfo) block at a predetermined location on disk of the storage system, the volinfo block comprising a plurality of pointers configured to reference the fsinfo and PCPI fsinfo blocks.

`720 patent, col. 13:59-14:5; 14:32-39; 14:56-15:5 (emphasis added).

a. Preamble

First, Sun argues that the phrase "increasing a number of persistent consistency point images (PCPIs)," which appears in the preamble of claim 1, is a claim limitation. `720 patent, col. 13:59-61. "If the claim preamble, when read in the context of the entire claim, recites limitations of the claim, or, if the claim preamble is `necessary to give life, meaning, and vitality' to the claim, then the claim preamble should be construed as if in the balance of the claim." Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1305 (Fed. Cir. 1999) (citation omitted). "Indeed, when discussing the `claim' in such a circumstance, there is no meaningful distinction to be drawn between the claim preamble and the rest of the claim, for only together do they comprise the `claim.' If, however, the body of the claim fully and intrinsically sets forth the complete invention, including all of its limitations, and the preamble offers no distinct definition of any of the claimed invention's limitations, but rather merely states, for example, the purpose or intended use of the invention, then the preamble is of no significance to claim construction because it cannot be said to constitute or explain a claim limitation." Id. A preamble gives meaning to the claim especially where claim terms in the body of the claim rely upon and derive antecedent basis from it. Eaton Corp. v. Rockwell Int'l Corp., 323 F.3d 1332, 1339 (Fed. Cir. 2003) (claim preamble limited the claimed invention where the preamble recited a particular sequence of events that was not defined elsewhere in the claim).

Sun contends that the preamble of claim 1 defines the term PCPI. This term is then used in the body of the claim, which recites structure in the form of PCPI fsinfo blocks. `720 patent, col. 13:66-67. Sun argues that the preamble provides the only antecedent basis for the term PCPI used in the rest of the claim, and the meaning of this structure would be incomprehensible without the definition provided in the preamble. Sun concludes that for this reason alone, the preamble must be treated as a limitation. See Pitney Bowes, 182 F.3d at 1306 (the preamble statement "is intimately meshed with the ensuing language in the claim").

Citing Pitney Bowes, NetApp responds that the preamble phrase is only an introductory statement of purpose or objective for the claimed invention to explain the way in which it was intended to improve on the prior art. 182 F.3d at 1305. NetApp contends that the preamble language in the `720 patent is always preceded by language that calls for a statement of purpose, i.e., increasing a number of persistent consistency point images (PCPIs): "a method for [statement of purpose]," "a system adapted to [statement of purpose]," "apparatus for [statement of purpose]," or "a computer readable medium . . . for [statement of purpose]." `720 patent at claim 1, 11, 18 19.

NetApp also argues that the preamble is not necessary to define or provide context for the term PCPI fsinfo block: "The `720 patent claims at issue never refer to `said PCPIs' (the classic language in patent claims for referring to an antecedent), the PCPI fsinfo block is initially introduced in the body of the claim (`providing one or more PCPI fsinfo blocks'), and the preamble does not contain a description of any structural characteristics of PCPIs." NetApp Resp. Br. at 11. However, the absence of certain language is not dispositive of whether the preamble gives meaning to the claim. Just calling the preamble a statement of purpose does not automatically preclude it from serving as a claim limitation. This case is similar to Pitney Bowes, where "both independent claims 1 and 3 contain a preamble stating that they claim either a method of, or an apparatus for, "producing on a photoreceptor an image of generated shapes made up of spots. . . ."" 182 F.3d at 1305. The Federal Circuit found that "the term `spots' is initially used in the preamble to refer to the elements that make up the image of generated shapes that are produced on the photoreceptor. The term `spots' then appears twice in each of the independent claims." Id. at 1306. The court held, "That the claim term `spots' refers to the components that together make up the images of generated shapes on the photoreceptor is only discernible from the claim preamble." Id. The Federal Circuit concluded, "it is essential that the court charged with claim construction construe the preamble and the remainder of the claim, as we have done here, as one unified and internally consistent recitation of the claimed invention." Id.

Although the term "PCPI" is not as clearly defined by the preamble here as the term "spots" was defined in the preamble construed in Pitney Bowes, the term "PCPI" as used in the body of the claims 1, 18, and 19 (but not 11) relies on the preamble's explanation of the abbreviation "PCPI." Further, the preamble reinforces the centrality of "increasing a number of persistent consistency point images" to the entire invention. See Boehringer Ingelheim Vetmedica, Inc. v. Schering-Plough Corp., 320 F.3d 1339, 1345 (Fed. Cir. 2003) ("`growing' and `isolating' are not merely circumstances in which the method may be useful, but instead are the raison d'être of the claimed method itself"). However, the Court would not construe the preamble as a limitation on this basis alone.

Sun further argues that the specification touts increasing a number of persistent consistency points as fundamental to the invention: "The present invention overcomes the disadvantages of the prior art by providing an on-disk storage arrangement that increases the number of persistent consistency point images (PCPIs) that may be maintained for a volume of a storage system." `720 patent, col. 5:14-18. Sun relies on On Demand Machine Corp. v. Ingram Indust., Inc., 442 F.3d 1331, 1344 (Fed. Cir. 2006), where the Federal Circuit distinguished mere statements of purpose from limiting preambles that are "`necessary to give life, meaning and vitality to the claims.'" Id. at 1344 (internal citations omitted). In On Demand, the preamble was "a method of high speed manufacture of a single copy of a book." Id. at 1336. In holding that the preamble there was limiting, the Court relied on the specification's teaching that "[t]he high speed manufacture of a single copy is fundamental" to the invention, so that "the entirety of the claim implements the preamble's high speed manufacture of single copy." Id. at 1344. NetApp concedes that the specification uses the phrase "increasing a number of persistent consistency point images (PCPIs)," but contends that the phrase is used as a statement of purpose throughout the specification, rather than a limitation. While not as compellingly as in On Demand, the preamble's emphasis on the increase of PCPIs does "serv[e] to focus the reader on the invention that is being claimed." On Demand, 442 F.3d at 1343.

Significantly, the applicants specifically relied on the preamble to overcome a prior art rejection, as Sun points out. On September 13, 2006, the PTO issued an office action rejecting all pending independent claims "as being unpatentable over [the Cabrera reference]." `720 Patent File History, Sept. 13, 2006 Office Action at 26. In response to the examiner's rejection, the applicants distinguished Cabrera on the ground that it did not teach increasing the number of PCPIs for a volume on a storage system:

Applicant's claimed invention, as defined in illustrative claim 1, is for a "method for increasing a number of persistent consistency point images (PCPIs) maintained for a volume of a storage system." The claimed invention is thus directed to increasing the number of PCPIs for a volume on a storage system.

This is in distinction to Cabrera, which teaches teaches [sic] a system utilizing a plurality of different snapshot service providers, each of which makes a snapshot of a volume.

`720 Patent File History, March 7, 2007 Amendment at 6-7 (emphasis in original).

The applicants further distinguished Cabrera as follows:

Specifically, Cabrera teaches an API [application interface] that "acts as a coordinator/manager of different volume snapshot providers and an administrator of snapshot providers." The Examiner states that the API "performs equivalent operation to that of volume information block since API calls is provided, which is used to coordinate and administer multiple snapshot providers [clearly] requiring plurality of pointers configured to reference the fsinfo and PCPI fsinfo blocks." Applicant respectfully disagrees.

Applicant's claimed invention is directed to increasing the number of PCPI's that may be generated on a storage system. To that end, Applicant's invention, in representative claim 1 states, in part, "providing one or more PCPI fsinfo blocks, each PCPI fsinfo block associated with a PCPI. As noted in Applicants' specification `[e]ach additional fsinfo block [that] is associated with a PCPI includes the inode of the inode file for the PCPI, which in turn includes appropriate inodes for active maps and the like.' [Citation omitted.] On disk, the volinfo block contains pointers to a plurality of fsinfo blocks, including one for the active file system and fsinfo blocks for each PCPI. [Citation omitted.]

`720 Patent File History, March 7, 2007 Amendment at 7-8 (emphasis added).

These statements to the PTO make clear that NetApp viewed the preamble as comprising the critical limitation that distinguished its invention from the prior art. See Halliburton Energy Serv., Inc. v. M-I LLC, 514 F.3d 1244, 1246 (Fed. Cir. 2008) (patentee correctly conceded that the preamble at issue was limiting because the patentee had relied on the preamble to distinguish prior art during prosecution). NetApp's reliance on Intirtool, Ltd. v. Texar Corp., 369 F.3d 1289 (Fed. Cir. 2004) is misplaced because the Federal Circuit held there that the statements in the prosecution history could have been interpreted as referring to the structural limitations in the body of the claim, rather than the preamble. Id. at 1295. Here, by contrast, the teaching of "increasing a number of [PCPI's]" does not appear in the body of the claim and it is apparent from the prosecution history that the applicants relied on the preamble.

NetApp points out that the applicants did not amend the preamble at issue, distinguishing Symantec Corp. v. Computer Associates Int'l, where the applicant added the "as it is being transferred" language in dispute to overcome the prior art. 522 F.3d 1279, 1289 (Fed. Cir. 2008), reh'g and reh'g en banc denied (May 20, 2008). However, an amendment is not the sine qua non for the prosecution history to influence claim construction. NetApp notes that the Examiner at one point in the prosecution history recognized that the claims of the `720 patent were patentable because of the limitations recited in the bodies of the claims, specifically the novel volinfo block `720 Patent File History, Feb. 17, 2005 Notice of Allowability at 2. See also Aug. 10, 2005 Notice of Allowability at 2 (same). However, NetApp concedes that these notices of allowance were issued by the PTO before it considered Cabrera and before the applicants made the statements at issue to distinguish Cabrera. Thus, they have little, if any, relevance. Cf. STX, LLC v. Brine, Inc., 211 F.3d 588, 591 (Fed. Cir. 2000) (examiner rejected the claim for obviousness even after the preamble language was added, suggesting that the phrase was not essential in distinguishing it over the prior art, and was not decisive in securing allowance of the claim during prosecution).

NetApp also argues that the crux of the applicants' arguments consisted of explaining why Cabrera had not disclosed the patentably significant structures of the volinfo block and PCPI fsinfo blocks, and that the applicants never stated that the `720 patent claims were limited by the preamble. In support of this argument, NetApp cites this passage of the prosecution history:

The Examiner states that Cabrera discloses PCPI fsinfo blocks because Cabrera teaches that the VSSC [Volume Snapshot Service Coordinator] is used to coordinate and administer multiple snapshot service providers. Applicants respectfully traverse this characterization. Cabrera does not teach one of [sic] more PCPI fsinfo blocks. In column 5, lines 36-45, Cabrera discusses operations performed by a snapshot provide [sic] (SP), but Cabrera does not disclose any data structures utilized by SPs. Moreover, Cabrera does not disclose any on-disk structures, such as a PCPI fsinfo block that is used by a SP. As noted above, Cabrera is directed to and teaches a system that utilizes one or more SPs, but does not disclose a method for increasing the number of PCPIs for a volume nor does Cabrera disclose PCPI fsinfo blocks.

`720 Patent File History, March 7, 2007 Amendment at 8 (emphasis added). Although this passage shows that the applicants relied in part on the on-disk structures to distinguish Cabrera from the claimed invention, the last sentence of this passage clearly demonstrates that the applicants also relied on the claimed method for increasing the number of PCPIs to distinguish the prior art, thereby "transforming the preamble into a claim limitation." Intirtool, 369 F.3d at 1295.

Accordingly, taken together, the specification, claim language and prosecution history demonstrate that the preamble is a claim limitation, not merely an introduction to the claims. The prosecution history especially contains clear statements by the applicants distinguishing the prior art on the ground that Cabrera did not disclose a method for increasing the number of PCPIs for a volume. Catalina Mktg. Int'l v. Coolsavings.com, Inc., 289 F.3d 801, 808 (Fed. Cir. 2002) ("clear reliance on the preamble during prosecution to distinguish the claimed invention from the prior art transforms the preamble into a claim limitation because such reliance indicates use of the preamble to define, in part, the claimed invention").

b. Indefinite

Sun next contends that the term "increasing a number of consistency point images" is indefinite under section 112, paragraph 2. A claim is indefinite under section 112, ¶ 2 when "its legal scope is not clear enough that a person of ordinary skill in the art could determine whether a particular [product] infringes or not." Geneva Pharms., Inc. v. GlaxoSmithKline PLC, 349 F.3d 1373, 1384 (Fed. Cir. 2003). "It is the applicants' burden to precisely define the invention, not the PTO's," and section 112, ¶ 2 "puts the burden of precise claim drafting squarely on the applicant." In re Morris, 127 F.3d 1048, 1056 (Fed. Cir. 1997). Indefiniteness must be shown by clear and convincing evidence that the claim terms at issue are "not amenable to construction" or are "insolubly ambiguous." Datamize, LLC v. Plumtree Software, Inc., 417 F.3d 1342, 1347-48 (Fed. Cir. 2005). The inquiry "depends on whether those terms can be given any reasonable meaning." Id. at 1347. Unless "reasonable efforts at claim construction prove futile[,]" the claim is not invalid for indefiniteness. Exxon Research Eng'g Co. v. United States, 265 F.3d 1371, 1375 (Fed. Cir. 2001).

Sun contends that the term "increasing" provides one of skill in the art with no measure of the scope of the claims. Sun's expert contends that the term "increasing a number of persistent consistency point images" implies that a storage system was previously capable of storing a certain number of consistency point images and that, as a result of the claimed invention, the system is now able to store more persistent consistency point images. However, the term does not specify the numerical capacity before the invention and therefore does not provide sufficient guidance as to how many consistency point images must be stored in order to infringe upon the claims. Brandt Decl., ¶¶ 19-21. Sun argues that the plain meaning of "increasing" requires that there be some baseline from which the increase occurs.

Sun opposes NetApp's proposed construction ("to provide/providing more than a low predefined number of maintainable persistent consistency point images") as similarly indefinite, point out that the term "low" is subjective and leaves unclear at what point a particular system infringes. Specifically, Sun argues, there is no readily understood meaning in the art for the term "low" as applied to snapshots or persistent consistency point images. Sun concludes that this failure to provide a sufficiently objective standard of measurement renders the claims indefinite, citing Datamize, 417 F.3d at 1351 ("`aesthetically pleasing' does not exactly compare to words of degree such as `substantially equal to,'" but invokes a similar analysis). In Datamize, the court reasoned: "`When a word of degree is used the district court must determine whether the patent's specification provides some standard for measuring that degree.' Seattle Box Co. [v. Industrial Crating Packing, Inc.], 731 F.2d [818] at 826 [(Fed. Cir. 1984)]. Similarly, when faced with a purely subjective phrase like `aesthetically pleasing,' a court must determine whether the patent's specification supplies some standard for measuring the scope of the phrase. Thus, we next consult the written description." 417 F.3d at 1351. The court determined that the written description failed to set forth "an objective way to determine whether an interface screen is `aesthetically pleasing.'" Id. at 1352. "[W]hile the description of an embodiment provides examples of aesthetic features of screen displays that can be controlled by the authoring system, it does not explain what selection of these features would be `aesthetically pleasing.'" Id.

Sun also argues that the claims are indefinite because they do not distinguish the prior art, citing Amgen, Inc. v. Chugai Pharma. Co., Ltd., 927 F.2d 1200, 1217-18 (Fed. Cir. 1991) (affirming district court's determination that claim term "at least about 160,000" was indefinite where no expert testified as to a definite meaning for the term in the context of the close prior art) and Halliburton, 514 F.3d at 1253 (determining that claim term "fragile gel" was indefinite because "the specification does not distinguish how the `fragile gels' claimed in the `832 patent performed differently than the disclosed prior art-how much more quickly the gels broke when stress was imposed or how much more quickly the gels reformed when stress was removed"). Sun contends that because the `720 patent specification offers no guidance for determining what systems meet the "increasing" limitation, under NetApp's construction, the `720 patent claims read on the prior art WAFL system of the `292 patent in the related case, Network Appliance Inc. v. Sun Microsystems Inc., C-07-6053 EDL. See Brandt Reply Decl. ¶¶ 23-25. Sun concludes that because the patent fails to explain what "increase" is sufficient to distinguish the purported invention from the prior art, this claim phrase is indefinite. Amgen, 927 F.2d at 1218 ("When the meaning of claims is in doubt, especially when, as is the case here, there is close prior art, they are properly declared invalid."); Halliburton, 514 F.3d at 1252-53.

NetApp responds that the term is not indefinite because it can, if necessary, be construed. See Invitrogen Corp. v. Biocrest Mfg., L.P., 424 F.3d 1374, 1383-1384 (Fed. Cir. 2005) (having construed the preamble term "improved competence," the Court found the term not indefinite). There, the court reasoned as follows: "`The test for indefiniteness does not depend on a potential infringer's ability to ascertain the nature of its own accused product to determine infringement, but instead on whether the claim delineates to a skilled artisan the bounds of the invention.' SmithKline Beecham Corp. v. Apotex Corp., 403 F.3d 1331, 1341 (Fed. Cir. 2005). This court's and the district court's constructions of the claim showed that it contained no material ambiguities, and therefore was not invalid for indefiniteness." Invitrogen, 424 F.3d at 1384. NetApp contends that should the Court deem it necessary to interpret this term, the construction "to provide/providing more than a low predefined number of maintainable persistent consistency point images" should apply. It argues that this construction captures the intent of the `720 patent to overcome the prior art's low and limited numbers of maintainable snapshots.

Sun counters that the claim would still be indefinite under this construction because a person of ordinary skill in the art would not be able to discern a "meaningfully precise claim scope." Halliburton, 514 F.3d at 1251 ("The fact that Halliburton can articulate a definition supported by the specification, however, does not end the inquiry. Even if a claim term's definition can be reduced to words, the claim is still indefinite if a person of ordinary skill in the art cannot translate that definition into meaningfully precise claim scope."). NetApp offers expert opinion that one of ordinary skill in the art at the time the `720 patent was filed in 2004 would have understood that applying the approach of the `720 patent to a preexisting system or method results in a new system or method that supports an increased number of PCPIs compared to when it did not use the approach of the patent. Ganger Decl. ¶ 29. The specification describes the disadvantage of prior art systems:

A noted disadvantage of such an on-disk storage structure is a limitation on the number PCPIs (e.g., 31) that may be maintained with the file system. As a result, a system administrator (user) may be forced to modify PCPI creation and/or retention schedules to avoid exhausting the available number of maintainable PCPIs. This limitation may prove burdensome and, possibly, costly depending upon the need for additional PCPI capacity. The present invention is directed to alleviating this limitation.

`720 patent, col. 5:4-12. In the section titled "Summary of the Invention," the specification then describes the invention as increasing the number of PCPIs, illustratively, to 255 or up to "any number of PCPIs" by introducing the volinfo data structure to provide a level of indirection that increases the number of PCPIs maintainable by a file system:

SUMMARY OF THE INVENTION

The present invention overcomes the disadvantages of the prior art by providing an on-disk storage arrangement that increases the number of persistent consistency point images (PCPIs) that may be maintained for a volume of a storage system. The on-disk storage arrangement comprises a novel volume information (volinfo) block representing the root of the volume; the volinfo block is stored at predefined locations on disk and comprises various system wide configuration data. According to the invention, the volinfo block further comprises a data structure configured to provide a level of indirection that increases the number of PCPIs maintainable by a file system executing on the storage system. To that end, the data structure may be organized as an array of pointers, wherein each pointer references a data block comprising a snapshot root, thereby enabling efficient access to each PCPI maintained by the file system.

In the illustrative embodiment, the volume comprises data blocks organized within a volume block number (vbn) space maintained by the file system. The array is embodied as a vbn lookup table having a plurality of entries, wherein each entry comprises a vbn pointer configured to point to (reference) a file system information (fsinfo) block within the volume. The fsinfo block contains information that specifies a layout of the file system. Each entry of the vbn lookup table is indexed by an identifier assigned to each PCPI; notably, entry zero holds a vbn pointer to the "active" file system. Thus, one of the fsinfo blocks referenced by the vbn lookup table is associated with the active file system, while the remaining fsinfo blocks are associated with PCPIs of the active file system.

Advantageously, the novel vbn lookup table enables efficient access to information describing the active file system and, illustratively, 255 PCPIs. This feature of the invention permits an illustrative eight-fold increase in the number of PCPIs maintainable by the file system. Additional PCPIs may be maintained in the storage system by configuring the vbn lookup table to provide further levels of indirection. For example, the entries of the vbn lookup table may be configured to reference indirect fsinfo blocks that, in turn, reference "direct" fsinfo blocks. Therefore by expanding the number of levels of indirection, any number of PCPIs may be maintained with the file system.

`720 patent, col. 5:13-55.

Required to make "reasonable efforts at claim construction," Exxon, 265 F.3d at 1375, the Court determines that the disputed claim term is not as subjective as the "aesthetically pleasing" term presented in Datamize, but still needs some basis for interpreting the "increasing" term with meaningful precision. The Court agrees that NetApp's proposed limitation of "more than a low predefined number" is neither sufficiently illuminating nor adequately supported by the specification. However, the specification does support a construction of the term to include an "any number of PCPIs" limitation: "Therefore by expanding the number of levels of indirection, any number of PCPIs may be maintained within the file system." `720 patent, col. 5:53-55 (emphasis added). This construction is consistent with the architecture claimed in the patent that is capable of supporting an unlimited number of snapshots by adding levels of indirection, in contrast to the prior art system which had limited capacity and would require the system operator to modify creation or retention schedules to avoid exhausting the available number of maintainable snapshots. See `720 patent, col. 5:4-12; 5:22-26 ("According to the invention, the volinfo block further comprises a data structure configured to provide a level of indirection that increases the number of PCPIs maintainable by a file system executing on the storage system."). "Any number" is necessarily a larger number than that in the prior art, whose disadvantage was a fixed number, which capacity could be outgrown.

For the reasons set forth above, the Court construes "increas[ed/ing] a number of persistent consistency point images" as "permitting any number of PCPIs to be maintained."

2. "file system information (fsinfo) block"

Disputed Claim Term: Sun's construction NetApp's construction

"file system information (fsinfo) block" A block located at a fixed location on disk A data structure containing information describing the volume, including at least the specifying the layout of a file system. size of the volume, volume level options, and language. The parties primarily disagree whether the claimed fsinfo block is stored in a fixed location on disk, as Sun contends. Sun also proposes that the fsinfo block be construed to include information describing aspects of the volume, such as the size of the volume, volume level options, and language. Sun argues that this term is virtually identical to the term in the `292 patent construed in the related litigation, C-07-6053 EDL, where the Court construed "file system information structure" to mean "data structure that contains the root inode of a file system in a fixed location on disk." NetApp counters that limitations from other patents should not be imported here because the `720 patent discloses a novel volinfo block.

a. Incorporation by Reference

Sun contends that NetApp has assigned a special meaning to the claim term "fsinfo block" by incorporating by reference two earlier patents: U.S. Patent No. 5,819,292 (the "`292 patent") and U.S. Patent Application Publication No. US2002/0083037A1, entitled Instant Snapshot, which issued as U.S. Patent No. 7,072,916 (the "'916 patent"). See Phillips, 415 F.3d at 1316 ("[O]ur cases recognize that the 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."). The `720 specification provides: ("In the example of a WAFL file system, snapshots are described [in the `292 patent] which is hereby incorporated by reference as though full [sic] set forth herein."). `720 patent, col. 3:62-4:2. The `720 specification also states: "Examples of snapshot and block allocation data structures, such as the active map, space map and summary map, are described in [the `916 patent application], which application is hereby incorporated by reference." Id. at 4:20-26. Sun argues that documents incorporated by reference into a patent become part of the patent's intrinsic record, citing AquaTex Indus., Inc. v. Techniche Solutions, 419 F.3d 1374, 1381-82 (Fed. Cir. 2005). In AquaTex, the court held that because "AquaTex chose to incorporate by reference the teachings of three United States Patents to define the scope of the term `fiberfill,' these publications are highly relevant to one of ordinary skill in the art for ascertaining the breadth of the claim term." 419 F.3d at 1381.

Sun points out that the `916 patent contains a special "Lexicography" section that defines fsinfo as located at a fixed location and including data about the volume. The Lexicography section appears in the section of the `916 patent entitled "Detailed Description of the Preferred Embodiment," and defines fsinfo as follows:

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the following description, a preferred embodiment of the invention is described with regard to preferred process steps and data structures. However, those skilled in the art would recognize, after perusal of this application, that embodiments of the invention might be implemented using a variety of other techniques without undue experimentation or further invention, and that such other techniques would be within the scope and spirit of the invention.

Lexicography

As used herein, use of the following terms refer or relate to aspects of the invention as described below. The general meaning of these terms is intended to be illustory and in no way limiting.

. . .

fsinfo (File System Information Block) — In general, the phrase "file system information block" refers to one or more copies of a block known as the "fsinfo block". These blocks are located at fixed locations on the disks. The fsinfo block includes data about the volume including the size of the volume, volume level options, language and more.

. . .

As described herein, the scope and spirit of the invention is not limited to any of the definitions or specific examples shown therein, but is intended to include the most general concepts embodied by these and other terms.

`916 patent, col. 3:42-5:18 (emphasis added). Sun argues that NetApp has recognized that this Lexicography section of the `916 patent is meant to be definitional, referring to NetApp's response to the PTO's Office Action in Inter Partes Reexamination of yet another patent, U.S. Patent No. 6,857,001. This argument is not persuasive. As the `916 specification expressly states, the Lexicography section refers to a preferred embodiment, and also cautions that "the scope and spirit of the invention is not limited to any of the definitions or specific examples shown therein." Id.

Sun also ignores the extent to which the `720 specification's incorporation of the two earlier patents by reference focuses on aspects of the prior invention other than the fsinfo block. The `720 specification refers to the `292 patent to describe snapshots in "the example of a WAFL system," and to the `916 patent to provide "[e]xamples of snapshot and block allocation data structures." `720 patent, col. 3:62, 4:20-26. See also `720 patent, col. 11:13-20 (from the section entitled "Storage Operating System" in the Detailed Description of an Illustrative Embodiment: "The in core and on-disk format structures of the WAFL file system, including the inodes and inode file, are disclosed and described in the previously incorporated ['292 patent]."). Furthermore, the Court's construction of the term "file system information structure" in the `292 patent was based on that patent's specification, which teaches that the fsinfo block is located at a fixed location. See `292 patent, col. 10:58-60 ("The root inode 1510B of a file system is kept in a fixed location on disk so that it can be located during booting of the file system."). That construction is not binding on the `720 patent, which describes a different file system where the novel volinfo block is "at a predetermined location on disk," `720 patent, col. 14:1-2, but nowhere describes the fsinfo block as being in a fixed location. The Court therefore declines to incorporate the definition of fsinfo block from a preferred embodiment of the `916 patent or from the Court's construction of the `292 patent.

b. Fixed Location

Sun contends that the specification supports its construction that the fsinfo block is stored in a fixed location. The specification teaches that the fsinfo block is preferably stored in a fixed location within a RAID group. `720 patent, col. 4:31-35 ("Each logical volume (hereinafter `volume') has a file system information (fsinfo) block that is preferably stored at a fixed location within, e.g., a RAID group."). Moreover, Sun argues, the only embodiment that is disclosed and enabled by the `720 patent requires the fsinfo block to be in a fixed location. Sun relies on the following passages of the Detailed Description of an Illustrative Embodiment in the `720 patent:

SUMMARY OF THE INVENTION

The present invention overcomes the disadvantages of the prior art by providing an on-disk storage arrangement that increases the number of persistent consistency point images (PCPIs) that may be maintained for a volume of a storage system. The on-disk storage arrangement comprises a novel volume information (volinfo) block representing the root of the volume; the volinfo block is stored at predefined locations on disk and comprises various system wide configuration data. According to the invention, the volinfo block further comprises a data structure configured to provide a level of indirection that increases the number of PCPIs maintainable by a file system executing on the storage system. To that end, the data structure may be organized as an array of pointers, wherein each pointer references a data block comprising a snapshot root, thereby enabling efficient access to each PCPI maintained by the file system.

`720 patent, col. 5:13-29 (emphasis added);

C. Increasing the Number of PCPIs in a File System

The present invention is directed to an on-disk storage arrangement that increases the number of persistent consistency point images (PCPIs) that may be maintained by file system 380 for a volume of storage system 220. The storage arrangement comprises a novel volume information (volinfo) block representing a root of the volume; the volinfo block is stored at predefined locations on disk 230 and comprises various system wide configuration data. In particular, the volinfo block contains appropriate fields so that software, including versions of the storage operating system, may recognize that the volinfo block is not a fsinfo block. As noted above, the fsinfo block is typically located at vbns 1 and 2; as described herein, the on-disk storage arrangement of the present invention replaces the fsinfo block with the novel volinfo block at this predefined location.

Id. at col. 11:20-36 (emphasis added);

According to the invention, the volinfo block 600 comprises a data structure configured to provide a level of indirection that increases the number of PCPIs maintainable by file system 380. To that end, the data structure may be organized as an array of pointers, wherein each pointer references a block containing a snapshot root (i.e., inode for the inode file of a PCPI), thereby enabling efficient access to each PCPI maintained by the file system. The array of pointers is contained in the vbn array field 680.

In the illustrative embodiment, the array is preferably embodied as a vbn lookup table 682 having a plurality of entries 684, wherein each entry comprises a vbn pointer 686 configured to point to (reference) a fsinfo block within the volume. As noted, the fsinfo block contains information that specifies the layout of the file system. Each entry 684 of the vbn lookup table 682 is indexed by an identifier (ID) assigned to each PCPI; notably, entry zero holds a vbn pointer 686 to the "active" file system. Thus, one of the fsinfo blocks referenced by the vbn lookup table 682 is associated with the active file system, while the remaining fsinfo blocks are associated with PCPIs of the active file system.

Id. at col. 12:43-64 (emphasis added).

The `720 patent thus teaches that the allegedly novel volinfo block is stored at the locations that were "typically" previously occupied by the fsinfo blocks. `720 patent, col. 11:21-36. The volinfo block comprises an array of pointers to the fsinfo blocks storing the root of the current file system and snapshot roots. Id. at 12:43-64. In the disclosed embodiment, this array is organized in a lookup table, where each entry holds a volume block number pointer to a snapshot fsinfo, and entry 0 holds a pointer to the active file system fsinfo. Id. at 12:52-64.

NetApp argues that while claim 1 recites that the volinfo block is "at a predetermined location on disk," the fsinfo blocks are not. `720 patent, col. 13:59-14:5. NetApp emphasizes that nowhere in the specification is the fsinfo block described as always being in a fixed location, and correctly points out that at most a fixed location is described only as a preferred embodiment. NetApp argues that even when describing prior art systems, such as the system described in the `292 patent, the `720 patent simply states that the fsinfo block "is preferably stored at a fixed location within, e.g., a RAID group." `720 patent, col. 4:33-34. NetApp contends that because the volinfo block replaces the fsinfo block at the "typical" or predefined location, the fsinfo block is not limited to a fixed location.

Sun offers expert opinion that one of ordinary skill in the art would understand this specification to teach that fsinfo blocks are stored at other fixed locations when replaced by the volinfo block, but points to no intrinsic evidence to support this conclusion. See Brandt Reply Decl. ¶ 38. First, Sun argues that the `720 specification does not disclose a mechanism to update the lookup table. Sun contends that under its construction of the term fsinfo block, such a mechanism would not be necessary to enable the invention because the locations of the fsinfo blocks are fixed and do not change, whereas under NetApp's construction, the claims are not enabled because the specification fails to teach how the volinfo lookup table may track fsinfo blocks that are changing locations. Brandt Decl. ¶ 24. Sun also contends that there is no teaching of how the volinfo block and other necessary structures, such as the blockmap file, can keep track of fsinfo blocks, unless they are at a fixed location. Brandt Reply Decl. ¶ 39.

NetApp offers its own expert opinion that the `720 patent need not expressly describe how to update the pointers in the vbn lookup table because one of ordinary skill in the art would know how to update them as the pointers of the vbn lookup table are akin to the block pointers in inodes and indirect blocks and can be updated in the same way. Ganger Decl. ¶ 41. NetApp contends that updating of pointers in the vbn lookup table occurs in the same way as for any other pointer and that one of ordinary skill would be able to infer this from the `720 patent. While Sun is correct that the patent is silent on how to update the pointers, which may perhaps presage an issue of enablement in the future, there is insufficient evidence on this point to support Sun's proposed construction. See Phillips, 415 F.3d at 1327 ("While we have acknowledged the maxim that claims should be construed to preserve their validity, we have not applied that principle broadly, and we have certainly not endorsed a regime in which validity analysis is a regular component of claim construction.").

Sun also offers expert opinion that despite the statement that the fsinfo block is "preferably stored," in a fixed location, one of skill in the art would understand that the fsinfo block must be at a fixed place based on review of the `720 specification and the `292 and `916 patent specifications, which are incorporated by reference. Brandt Reply Decl. ¶ 30. For some of the same reasons discussed above, the Court does not find that argument persuasive. As NetApp points out, the `292 patent was filed in 1995, nearly ten years before the `720 patent application was filed. Furthermore, the fsinfo block disclosed by the `720 patent has different features and need not serve the exact same function as in the `292 patent's preferred embodiment, especially because the volinfo points to the fsinfo blocks and contains system-wide configuration data.

NetApp explains that while the volinfo block is in a fixed, predetermined location, the fsinfo blocks are not limited in this way: "the fsinfo block is typically located at vbns 1 and 2; as described herein, the on-disk storage arrangement of the present invention replaces the fsinfo block with the novel volinfo block at this predefined location." `720 patent at 11:33-36. Elsewhere, the specification states, "The volinfo 600 is illustratively located at vbns 1 and 2 or, in alternate embodiments, at another predetermined location on disk." Id. at 11:46-47. NetApp explains that the `720 patent describes a system where the volinfo block points to the fsinfo blocks: the volinfo block references (i.e., points to direct or indirect) multiple fsinfo blocks, including the fsinfo block for the active file system and PCPI fsinfo blocks for each PCPI that is maintained by the file system. Ganger Decl. ¶ 39. NetApp argues that the use of pointers is a clear mechanism for finding fsinfo blocks that are stored anywhere in the file system; indeed, such flexibility is one of the primary benefits of using pointers in file system architecture. NetApp's expert opines that one of ordinary skill in the art would understand that these fsinfo blocks do not need to be in fixed locations: because the volinfo block points to the fsinfo blocks, the fsinfo blocks can be stored anywhere in the file system space. Ganger Decl. ¶ 39.

The Court determines that NetApp has the more persuasive argument that one of ordinary skill in the art would understand that allocating PCPI fsinfo blocks, as needed, is workable and more space-efficient than pre-allocating an fsinfo block for every possible one of the "any number of PCPIs" that may be maintained with the claimed system. See `720 patent, col. 5:53-55 ("by expanding the number of levels of indirection, any number of PCPIs may be maintained with the file system"). One of ordinary skill in the art would understand how to allocate space for fsinfo blocks, as needed, and update volinfo pointers just like an inode's pointers are updated to point to new data blocks. See Ganger Decl. ¶ 40. The Court therefore declines to adopt Sun's proposed construction requiring fsinfo blocks to be at a fixed location.

c. Volume Information

NetApp challenges Sun's construction requiring the fsinfo block to describe the volume, including at least the size of the volume, volume level options, and language. NetApp argues that the `720 patent never describes the fsinfo block as containing information about the volume as a whole (such as the size of the volume, volume level options, and language). Instead, NetApp argues, it is the novel volinfo block that contains "various system wide configuration data." `720 patent, col. 5:21-22 ("the volinfo block is stored at predefined locations on disk and comprises various system wide configuration data"); 11:28 ("the volinfo block is stored at predefined locations on disk 230 and comprises various system wide configuration data"). NetApp offers expert opinion that a person of ordinary skill in the art reading the `720 patent would understand that there would be no need (and in fact, it would be inefficient and could create inconsistency) for the fsinfo block to also contain the same information. Ganger Decl. ¶ 42.

Sun counters that the `916 patent definition of fsinfo, incorporated by reference in the `720 patent, also teaches that the fsinfo block "includes data about the volume, including the size of the volume, volume level options, and language." `916 patent, col. 4:14-20 [Lexicography section]. Sun challenges the opinion of NetApp's expert that "there would be no need for the fsinfo block to contain the same information" as the volinfo block. See Ganger Decl. ¶ 42. Sun contends that the `720 patent teaches that the fsinfo is still a key volume level structure, even in the presence of the volinfo block: "Each logical volume (hereinafter "volume") has a file system information (fsinfo) block." `720 patent, col. 9:5-10. Thus, Sun contends, it would make sense to store some volume level parameters in the fsinfo. Brandt Reply Decl. ¶ 35. Sun points to Figure 6 in the `720 patent, which lists information stored in the volinfo structure. Because none of the data fields in Fig. 6 correspond to volume size, options, and language data, Sun argues that one of ordinary skill would understand that these fields are in the fsinfo block, in accordance with the teaching of the `916 patent. Brandt Reply Decl. ¶ 34. Sun's construction presumes that the absence of these volume fields in Figure 6 necessarily means that the fields cannot also be in the volinfo block, and argues further that they must therefore reside in the fsinfo block. However, this construction would improperly import a limitation from a single embodiment which the specification clearly disclaims. See `720 patent, col. 11:60-62, 12:5-7 ("FIG. 6 is a schematic block of an exemplary volinfo block 600 in accordance with an embodiment of the present invention. . . . It should be noted that in alternate embodiments additional and/or differing fields may be included in the volinfo block 600.") (emphasis added). Accordingly, the Court agrees with NetApp that the volume data is not contained in the fsinfo block.

For the reasons set forth above, the Court adopts NetApp's construction of "file system information (fsinfo) block" as "a data structure containing information specifying the layout of a file system."

B. The `417 Patent: Mechanism for Handling File Level and Block Level Remote File Accesses Using the Same Server

The `417 patent is directed to an apparatus and method for handling both file level and block level remote file accesses:

An apparatus for handling file level and block level remote file accesses. The apparatus includes a block level server. The apparatus includes a file level server. The apparatus includes a storage layer implementing an inode layer performing inode operations, and storing data accessed by the file level and block level servers. The apparatus includes a management layer connected to the storage layer underlying the block and file level servers, which performs data management operations upon the underlying data. A method of handling file level and block level network file accesses. The method includes the steps of performing management operations by a management layer for a block level server and a file level server. Then there is the step of performing the servers' data accessing and updating operations using a vnode layer implemented on top of an inode layer. Then there is the step of storing data from the block level server or the file level server in a storage layer connected to the management layer.

`417 patent, Abstract.

3. "storage layer underlying the block and file level servers"

Disputed Claim Term: Sun's construction NetApp's construction

"storage layer underlying the block and file level servers" The storage layer is the software level immediatley The block and file level servers use operations below and coupled to [connected to] provided by the storage layer. the block and file level servers and above the management layer. The parties dispute whether the term recites a layered software architecture in which the storage layer is the software layer providing services to the block and file level servers connected to the management layer, as NetApp contends, or is instead the software level immediately below and coupled to the block and file level servers, as Sun contends. The parties also dispute whether the storage layer is above the management layer, as Sun contends, or whether the storage layer is simply connected to the management layer, as NetApp contends.

The disputed term appears in independent claim 1 of the `417 patent, which recites:

1. An apparatus for handling file level and block level remote file accesses comprising:

a block level server for serving block level data;

a file level server for serving file level data and combined with the block level server;

a storage layer implementing an mode layer performing mode operations, and storing data accessed by the file level and block level servers, the block level server and the file level server sharing the storage layer, the block level server providing service through implementation in terms of the mode layer operations; and

a management layer connected to the storage layer underlying the block and file level servers, which performs identical data management operations upon the underlying block level and file level data from either the block level server or the file level server, respectively.

`417 patent, col. 11:21-37 (emphasis added).

a. Storage layer underlying the block and file level servers

Sun proposes that "storage layer underlying the block and file level servers" be construed as "the storage layer is the software level immediately below and coupled to the block and file level servers and above the management layer." At oral argument, Sun agreed that its proposed "coupled to" language did not appear in the specification and could be replaced with "connected to." Nov. 24, 2008 Reporter's Transcript ("RT") at 110, 128. Sun contends that the schematic representation of the apparatus in Figure 11 depicts a layered software architecture where the storage layer 16 resides immediately below the file and block level servers 12 and 14, and above the data management layer 20. Sun also contends that the claim and the specification describe the software components in the relative positions Sun advocates:

"a management layer connected to the storage layer underlying the block and file level servers, which performs identical data management operations upon the underlying block level and file level data." Id. at 11:33-35 (emphasis added) [claim 1].

"a management layer 20 connected to storage layer 16 underlying the block and file level servers 14, which performs data management operations upon the underlying data." `417 patent, col. 2:19-22 (emphasis added) [Detailed Description];

According to Sun, the structural terms "connected" and "underlying" establish that claim 1 recites a layered architecture. Sun argues that claim 1 identifies itself as an apparatus claim, and therefore claims structure, and is not susceptible to any other reading.

While NetApp does not dispute that the claim pertains to a layered architecture, it argues that Sun's construction replaces the word "underlying" in the claim language with an unnecessarily restrictive arrangement of "immediately below and coupled to," contrary to the intrinsic evidence. NetApp offers expert opinion that "underlying," when used to refer to software layers, describes a functional, not a physical, arrangement. Where one software layer is underlying another, the first provides functionality for the second. Ganger Decl. ¶ 51. NetApp points out that claim 1 spells out the functionalities of the "storage layer implementing an [inode] layer" that are used by the file and block level servers, i.e., "storing data accessed by the file level and block level servers, the block level server and the file level server sharing the storage layer, [and] the block level server providing service through implementation in terms of the [inode] layer operations." `417 patent, col. 11:26-31. See Ganger Decl. ¶ 55.

The parties agree that the storage layer is below the servers, but they dispute whether the storage layer must be immediately below the servers. NetApp's expert opines that one software layer can use functionality provided by layers that are more than one level beneath it, and that one of ordinary skill in the art would not understand the claim term to require the storage layer to be "immediately" below the file and block level servers. Ganger Decl. ¶ 55. Referring to the specification, Dr. Ganger opines that the specification confirms that there is no need for the storage layer to be "immediately" below the file and block level servers. Ganger Decl. ¶ 56. NetApp is correct that the specification never uses the word "immediately" or any similar language to describe the relationship between the storage layer and the servers. Furthermore, the specification of the `417 patent, as illustrated in Figure 1, describes at least one embodiment of the invention where a "VNODE OPERATIONS" layer sits between the NFS file level server and the storage layer. `417 patent, col. 3:20-11:12, Fig. 1. This embodiment does not have the file level server "immediately" above the inode layer. Instead, a vnode layer is shown between the network file server and the inode layer. Despite the vnode layer between them, the specification describes the file server as "being implemented on top of inode layer 18 abstraction." Id. at 3:20-30.

Responding to NetApp's argument that the storage layer cannot be immediately below the file server because Figure 1 shows a vnode operations layer 22 between NFS server 14 and the inode layer operations 18, Sun replies that neither Figure 1 nor the description of Figure 1 describes the storage layer or its location with respect to the file server or management layer. Id. at col. 3:21-30, Fig. 1. See Hartman Reply Decl. ¶ 2. Sun contends that Figure 1 shows an inode operations layer 18, which is merely part of the storage layer 16, not the entire storage layer. Sun further argues that Figure 11 clearly shows that vnode operations layer 22 is part of the file server 12 — not an independent layer residing between the file server 12 and the storage layer 16. `417 patent, Fig. 11; Hartman Reply Decl. ¶ 2. Sun contends that the specification and the claims unambiguously state that the vnode operations layer is part of the file server — not an intervening layer. Id. (citing `417 patent, col. 2:31-32 ("The file server preferably includes a vnode operations layer"), col. 11:48-49 ("the file server includes a vnode operations layer")).

With respect to Figure 1, the Court finds no reason to conclude that claim 1 uses "underlying" in a narrower way than the specification uses "on top of," and agrees with NetApp that Figure 1 illustrates an embodiment where the inode operations layer, which claim 1 recites as implemented by the storage layer, is not "immediately" below the network file server. `417 patent, col. 11:26. With respect to Figure 11, Sun's argument that the vnode operations layer is part of the file server, not a separate intervening layer, improperly imports limitations from a preferred embodiment. See `417 patent, col. 2:31-32. Furthermore, Figure 11 and the corresponding text offer no support to indicate that any illustrated component must necessarily be "immediately" above or below any other component. First, in describing Figure 11, the specification describes the management layer functions as implemented "on top of" the inode operations of the storage layer, despite the fact that the management layer is illustrated schematically as vertically beneath the storage layer. Id. at 2:26-30, Fig. 11. Second, the Court agrees with NetApp that one of ordinary skill in the art would understand that a new layer can be interposed between two layers (e.g., to record their interactions or short-circuit some of them) without changing their fundamental relationship. The absence of such interposed layers in the illustration does not preclude their presence. Nor does the English language.¹ Therefore, the Court declines to adopt Sun's proposed limitation requiring the storage layer to be "immediately below and connected to the servers."

1 For example, the offending pea underlay the exquisitely sensitive princess no matter how many layers were interposed between her and the pea, so it is said.

b. Management layer connected to the storage layer

Sun contends that the storage layer must be above the management layer, citing the illustration of the "present invention" in Figure 11 to show that the storage layer is structurally above the management layer. The Detailed Description section states as follows:

The apparatus 10 comprises a storage layer 16 implementing an inode layer 18 performing inode operations, and storing data accessed by the file level and block level servers 12. The apparatus 10 comprises a management layer 20 connected to the storage layer 16 underlying the block and file level servers 14, which performs data management operations upon the underlying data.

`417 patent, col. 2:16-22, Fig. 11. Sun offers extrinsic evidence that one of ordinary skill in the art would understand that the invention as depicted in Figure 11, the description of which tracks the language of claim 1, requires the storage layer to be above the management layer in claim 1. Hartman Reply Decl. ¶ 3. As NetApp correctly points out, however, the term is completely silent with respect to the storage layer's relationship to the management layer, other than being "connected to" each other.

The specification teaches a preferred embodiment in which the management layer performs functions that are implemented "on top of" the inode operations of the storage layer: "Preferably, the management layer 20 implements point in time copies, read-only replication, dynamic data relocation, or disk space virtualization on top of the inode operations performed by the underlying storage layer 16." `417 patent, col. 2:26-30. Sun's proposed construction would exclude this preferred embodiment from the scope of the invention. NetApp also argues that requiring the management layer to be below the storage layer would also read out of the patent claim 4, which teaches an apparatus "wherein the management layer implements [functions] on top of the [inode] operations performed by the underlying storage layer." Id. at 11:43-47 (emphasis added). Sun responds that claims other than claim 1, such as claim 12, could cover an embodiment where the management layer is not required to be below the storage layer. The weight of the intrinsic evidence does not, however, support the limitation proposed by Sun. The Court concludes that the claim language and specification do not require the management layer to be below the storage layer. See Primos Inc. v. Hunter's Specialties Inc., 451 F.3d 841, 848 (Fed. Cir. 2006) ("[W]e . . . should not normally interpret a claim term to exclude a preferred embodiment.").

c. Prosecution History

Sun further argues that NetApp's representations to the PTO about the layered architecture of the `417 patent during its prosecution compel the adoption of Sun's construction. "Arguments and amendments made during the prosecution of a patent application and other aspects of the prosecution history, as well as the specification and other claims, must be examined to determine the meaning of terms in the claims." E.I. du Pont de Nemours Co. v. Phillips Petroleum Co., 849 F.2d 1430, 1438 (Fed. Cir. 1988). "The prosecution history limits the interpretation of claim terms so as to exclude any interpretation that was disclaimed during prosecution. [Citations omitted.]" Southwall Techs., Inc. v. Cardinal IG Co., 54 F.3d 1570, 1576 (Fed. Cir. 1995).

On June 24, 2003, the Examiner rejected claim 1 as well as claims 12, 18 and 19 under 35 U.S.C. § 103 as unpatentable over U.S. Patent No. 6,173,293 to Thekkath et al. ("Thekkath") in view of U.S. Patent No. 5,944,789 to Tzelnic et al. ("Tzelnic"). `417 Patent File History, June 24, 2003 Office Action at 2-3. The applicants responded by arguing that the prior art combination did not teach the specific layered architecture set forth in claim 1, referring to a management layer that is below the storage layer:

It is important that Thekkath teaches the lock server 30 provides some level of management, because one skilled in the art would not look to Tzelnic for the teaching of a management layer below the storage layer since it would require the system taught by Thekkath to be redesigned to lose the lock server 130 and instead have a management layer disposed below the storage layer 102. This is counter intuitive to one skilled in the art.

`417 Patent File History, November 24, 2003 Response at 3 (emphasis added). Sun contends that the applicants relied on the importance of the overall arrangement of software layers in claim 1 — the "combination of all elements together" — to argue that Tzelnic should not be combined with Thekkath in order to provide the missing element of "a management layer can be disposed below the storage layer." Id. at 4 (emphasis added). While this question is a close one, when read in context, this passage does not unequivocally state that the invention always requires a management layer below the storage layer:

The Examiner relies on Tzelnic for the teaching that a management layer can be disposed below the storage layer. However, applicants' claimed invention is the combination of all the elements together, not just components found in different places with certain relationships being identified by the Examiner, and then the Examiner concluding that the applicants' claimed invention is arrived at. In fact, this is contrary to patent law because it relies on hindsight of applicants' claims to arrive at applicants' claims from the prior art. The Examiner cannot use applicants' claims as a road map to find the various elements in the claims, in the different references of the prior art, and having found all the different elements in different references concludes [sic] that applicants' invention is arrived at.

Furthermore, the Examiner cannot take the teachings of the references out [sic] the context in which they are found. Thekkath teaches a management layer that is above the storage layer 102 and in conjunction with the file server 110 and the disk server 120, but no management layer below the file layer 102. Tzelnic teaches a totally different structure where there is a management layer below the storage layer. The Examiner cannot ignore these different contexts in which the teachings are found in combining these references.

Id. at 4 (emphasis added). Sun points out that the applicants further argued that the references should not be combined because the Thekkath architecture with a management layer above the storage layer was "a totally different structure" from an architecture "where there is a management layer below the storage layer." Id.

On December 18, 2003, the PTO issued an Advisory Action rejecting NetApp's response. `417 Patent File History, Dec. 18, 2003 Advisory Action [submitted as Williamson Decl., Ex. G]. As a result, the applicants filed a Request for Continued Examination, including a Preliminary Amendment, arguing:

Accordingly, applicants have amended Claims 1 and 12 to more specifically define the operation of the block level server. That is "the block level server providing service through implementation in terms of the inode layer operations." Thekkath does not teach or suggest this limitation whatsoever.

The Examiner goes on and recognizes that Thekkath does not teach or suggest a management layer connected to the storage layer underlying the block and file level servers, as found in claim 1. This follows, because the very element that the examiner submits is the block level server, the lock server 130, actually provides some level of management, as explained above. It is important that Thekkath teaches the lock server 30 provides some level of management, because one skilled in the art would not look to Tzelnic for the teaching of a management layer below the storage layer since it would require the system taught by Thekkath to be redesigned to lose the lock server 130 and instead have a management layer disposed below the storage layer 102. This is counter intuitive to one skilled in the art.

The Examiner relies on Tzelnic for the teaching that a management layer can be disposed below the storage layer. However, applicants' claimed invention is the combination of all the elements together, not just components found in different places with certain relationships being identified by the Examiner, and then the Examiner concluding that the applicants' claimed invention is arrived at. . . .

Furthermore, the Examiner cannot take the teachings of the references out [sic] the context in which they are found. Thekkath teaches a management layer that is above the storage layer 102 and in conjunction with the file server 110 and the disk server 120, but no management layer below the file layer 102. Tzelnic teaches a totally different structure where there is a management layer below the storage layer. The Examiner cannot ignore these different contexts in which the teachings are found in combining these references.

`417 Patent File History, Jan. 26, 2004 Preliminary Amendment at 9-11 (emphasis added). This passage shows that the applicants amended the patent to gain allowance by distinguishing the prior art on the grounds that Thekkath failed to disclose a block level server. See `417 Patent File History, November 24, 2003 Response at 4 ("Thekkath teaches the lock server 130 has a functionality which is completely distinct and apart from a block level server."). Thus, the amendment did not rely on the disposal of the management layer, although the applicants also repeated this distinction which had not persuaded the Examiner previously.

The Examiner ultimately allowed the claims, including claims 1 and 12, after concluding, "The prior art of record . . . fails to anticipate and/or suggest: a method and an apparatus for handling file level and block level remote file accesses comprising: a block level server providing service through implementation in terms of the inode layer operations as recited in claims 1 and 12." `417 Patent File History, March 2, 2004 Notice of Allowability at 2. Significantly, the Notice of Allowability made no mention of the management layer, or of the position of servers relative to the storage layer, but instead relied on the amendment.

Sun contends that this prosecution history demonstrates that both NetApp and the Examiner interpreted claim 1 as requiring a specific software layer arrangement where the storage layer is above the management layer to gain allowance over the prior art. See Rheox, Inc. v. Entact, Inc., 276 F.3d 1319, 1325 (Fed. Cir. 2002) ("Explicit arguments made during prosecution to overcome prior art can lead to a narrow claim interpretation because `[t]he public has a right to rely on such definitive statements made during prosecution.'") (quoting Digital Biometrics, Inc. v. Identix, Inc., 149 F.3d 1335, 1347 (Fed. Cir. 1998)); Southwall Techs., Inc. v. Cardinal IG Co., 54 F.3d 1570, 1576 (Fed. Cir. 1995) ("Claims may not be construed one way in order to obtain their allowance and in a different way against accused infringers.").

NetApp concedes, as it must, that the prosecuting attorney's argument was inartfully worded at best and notes that it was ultimately unnecessary for allowance. NetApp argues that the real thrust of the applicants' argument was that it would not have been obvious to combine the "management" layer in Tzelnic with the system disclosed in Thekkath, because the "management" functions described in Thekkath and Tzelnic are in different places relative to the storage layer. While the prosecuting attorney did appear to place the management layer under the storage layer, the main focus of his remarks was the contrast between Thekkath and Tzelnic, arguing against the obviousness of combining them. Indeed, the next three paragraphs concern the impropriety of combining these two references. `417 Patent File History, Nov. 24, 2003 Response at 4-5. NetApp further argues that even if the prosecuting attorney's statement were understood as an argument that a management layer above the storage layer is outside the scope of the claims, such a statement would be wrong on its face, citing Elbex Video, Ltd. v. Sensormatic Electronics Corp., 508 F.3d 1366, 1373 (Fed. Cir. 2007).

While the question is a close one, read in context, the prosecuting attorney's remarks concerning the "management layer" do not demonstrate clearly and unambiguously that the applicants considered the language of claim 1 to require the storage layer to be above the management layer, especially when the amendment to claim 1 that gained its allowance had nothing to do with the placement of the management layer. In rejecting the claims, the Examiner explained that, although Thekkath does not disclose a management layer, Tzelnic does, and so the two references in combination render the invention obvious. `417 Patent File History, June 24, 2003 Office Action at 3. To protest the combining of the two references, the prosecuting attorney argued that, first, the lock server disclosed in Thekkath already had some management functions; even though it was not called a management layer, the lock server "actually provides some level of management." `417 Patent File History, Nov. 24, 2003 Response at 3. Second, the prosecuting attorney argued that because the location of the management layer is different between the two references, one of ordinary skill in the art would not have been motivated to combine Thekkath and Tzelnic. Id. Importantly, as noted above, the Notice of Allowability shows that the Examiner allowed the claims over Thekkath and Tzelnic because they failed to disclose a block level server, not because he considered the "management layer" remarks to be a disavowal. `417 Patent File History, Feb. 26, 2004 Notice of Allowability at 2.

Accordingly, taken as a whole, the prosecution history does not constitute the "clear and unmistakable . . . definitive statements" required to effect a disavowal of scope. Elbex, 508 F.3d at 1373; see also Phillips, 415 F.3d at 1317 ("because the prosecution history represents an ongoing negotiation between the PTO and the applicant, rather than the final product of that negotiation, it often lacks the clarity of the specification and thus is less useful for claim construction purposes"). Furthermore, although the prosecuting attorney made statements that indicate that the management layer is below the storage layer in the invention, those statements are contrary to the claim language and the intrinsic evidence, as discussed above. Elbex, 508 F.3d at 1373. See also Internet America, Inc. v. Kee-Vet Labs., Inc., 887 F.2d 1050, 1054 (Fed. Cir. 1989) ("When it comes to the question of which should control, an erroneous remark by an attorney in the course of prosecution of an application or the claims of the patent as finally worded and issued by the Patent and Trademark Office as an official grant, we think the law allows for no choice. The claims themselves control.").

NetApp proposes that the term "storage layer underlying the block and file level servers" be construed as "the block and file level servers use operations provided by the storage layer." The Court agrees that one of ordinary skill in the art would understand the word "underlying" in the context of one software layer underlying another to mean that the first provides functionality for the second. However, the Court agrees with Sun that claim 1 is an apparatus claim defining a layered software architecture, and that NetApp's construction may not adequately capture the structural relationship between the components. To make the relationship of the software layers clear for the jury, the Court proposes the following construction: "The storage layer is a software layer `below' the block and file level servers, that is, the storage layer provides operations that are used by the block and file level servers."

The parties may comment on the precise wording of the Court's tentative construction of this term, in case it could have any unintended consequences, in light of and without rearguing the Court's ruling on the parties' proposed constructions. Each party may submit its comments, without further substantive argument, in a letter brief of no more than two pages by January 12, 2009.

4. "mode operations"/"the mode layer operations"

Disputed Claim Term: Sun's construction NetApp's construction "mode operations"/"the mode layer operations" Sun contends these phrases are indefinite No construction necessary, plain and ordinary under § 112, ¶ 2 because they are unclear meaning. and fail to set forth the subject matter which applicants regard as their invention. To the extent the Court deems a construction necessary, the terms mean "operations performed However, if the Court decides the phrases on inodes." are not indefinite, the phrases should be construed to mean: "operations on inodes, [If the Court construes "inode," NetApp proposes where an inode is a data structure that points "a data structure used to store information to the data blocks of a file and contains about a file."] status information about the file." The parties dispute whether the errors in these claim terms render the claim indefinite. First, they dispute whether the Court can correct a printing error in the patent. Second, if the Court does allow NetApp to correct the error and term is not rendered indefinite, the parties dispute whether the term "inode" should be further construed.

The disputed terms "mode operations" and "the mode layer operations" appear in independent claim 1 and "mode operations" also appears in dependent claim 4:

1. An apparatus for handling file level and block level remote file accesses comprising: a block level server for serving block level data; a file level server for serving file level data and combined with the block level server; a storage layer implementing an mode layer performing mode operations, and storing data accessed by the file level and block level servers, the block level server and the file level server sharing the storage layer, the block level server providing service through implementation in terms of the mode layer operations; and a management layer connected to the storage layer underlying the block and file level servers, which performs identical data management operations upon the underlying block level and file level data from either the block level server or the file level server, respectively.

. . .

4. An apparatus as described in claim 3 wherein the management layer implements point in time copies, read-only replication, dynamic data relocation or disk space virtualization operations on top of the mode operations performed by the underlying storage layer.

`417 patent, col. 11:21-37, 43-47 (emphasis added).

a. Printing Error

NetApp explains that due to a Patent Office error in the printing of the patent, and through no fault of NetApp's, the word "inode" was mistakenly printed as "mode" in several places in the claims and the specification of the `417 patent, see `417 patent, col. 4:45-48, 11:26-31, 11:62-12:2, although it was correctly spelled in others, such as where NetApp provided image copies of the figures, id., Fig. 3. After this action was filed, these and other mistaken printings of "mode" were corrected by the PTO to substitute "inode." Nathan Decl., Ex. 14 (Aug. 26, 2008, Certificate of Correction). However, the PTO's corrections do not apply retroactively to the claims for damages in this lawsuit because it was filed before the corrections were made. Novo Industries, L.P. v. Micro Molds Corp., 350 F.3d 1348, 1355-56 (Fed. Cir. 2003).

District Courts may correct errors 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." Novo Industries, 350 F.3d at 1354. The District Court may only correct minor errors that are "evident on the face of the patent." Group One, Ltd. v. Hallmark Cards, Inc., 407 F.3d 1297, 1303 (Fed. Cir. 2005). If an error is not subject to correction by the Court, the claim is invalid for indefiniteness. Id. For the reasons stated by NetApp in its papers and at the hearing, the Court determines that the "mode" error is plainly evident on the face of the patent, is not subject to reasonable debate and is not contradicted by the prosecution history. The Court did not find the testimony of Sun's expert credible on this issue. The Court therefore corrects the errors to replace the instances of "mode" with inode.

As to construction of "inode operations"/"the inode layer operations," Sun proposes "operations on inodes," and NetApp proposes "operations performed on inodes." Finding no substantive difference between the parties' proposals, the Court determines that NetApp's construction is slightly clearer, and therefore more helpful for the jury.

b. Inode

Sun proposes a construction of "inode" as "a data structure that points to the data blocks of a file and contains status information about the file." Sun contends that its construction conforms to the following definition provided in the specification, and is how one of ordinary skill in the art would understand the term: "An inode points to data blocks by giving their address. An inode also contains information about a file." `417 patent, col. 5:56-57. During oral argument, Sun proposed a modified construction of "inode" as a "file system structure pointing directly or indirectly to data blocks of a file." RT 189.

During oral argument, NetApp proposed that the Court construe "inode" as "a data structure used to store information about a file." NetApp contends that Sun's construction impermissibly restricts "inodes" to exemplary features disclosed in the specification: "Preferably, an inode points to data blocks, directly or indirectly[.]" `417 patent, col. 2:45-46, 12:3-6 (claim 10). Inode pointers can point to data blocks or indirect blocks. Id. at 2:50-51. Writing a file involves "walk[ing] down the indirect block tree towards the data blocks being written." Id. at 7:7-8. NetApp offers expert opinion that a person of ordinary skill in the art would understand that the term "inode" is well-understood in the art as simply a data structure that describes a file, and that direct pointers to data blocks and file status information are implementation details, rather than part of the definition of "inode." Ganger Decl. ¶ 67. NetApp refers to certain implementations of inodes referred to in other patents which allow inodes to directly contain file data rather than point to data stored elsewhere. See `292 patent, col. 6:11-13. NetApp also contends that an inode could point to something other than data blocks, such as to indirect blocks, or point to no data at all (e.g., because the file is empty or because the inode is for a special dataless file type). Ganger Decl. ¶ 67. At oral argument, Sun offered expert testimony that one of ordinary skill in the art would not be confused by the situation where a file was empty. RT 186. Sun also argues persuasively that even accepting NetApp's argument that inodes may point to indirect blocks, that situation is covered by Sun's construction, which includes pointing to data blocks indirectly.

NetApp further argues that an inode can contain a variety of information describing a file, which may or may not include "status information." Ganger Decl. ¶ 67. NetApp cites another patent in suit, the `385 patent, to demonstrate that inodes need not contain status information. `385 patent, col. 9:20-31 ("a xinode field 430 containing a pointer that references another on-disk inode structure containing, e.g., access control list (ACL) information associated with the file or directory"). Responding to NetApp's argument that not all inodes contain status information about a file, Sun points out that NetApp provides no evidence of an inode in the `417 patent that does not include file status information, and even if such an inode may exist elsewhere, it is not contemplated by the `417 patent. Hartman Reply Decl. ¶ 6.

While NetApp is correct that the definition of "inode" cited by Sun appears in a description of a preferred embodiment, `417 patent, col. 1:50-52, the patent does not otherwise teach what an inode is. Sun's proposed construction better conforms to the definition provided in the specification, whereas NetApp's proposed construction is too general. In addition to the definition of inode stated in the patent, id., the specification and claim language support the construction of "inode" as "pointing directly or indirectly to data blocks of a file." See `417 patent, col. 2:45-46, 2:50-51, 12:3-6. Furthermore, at the hearing, both sides' experts and Sun's counsel agreed that inode as used in the patent could be defined as a file system structure for pointing directly and/or indirectly to data blocks, including blocks that only contain metadata, RT 184-195, and NetApp's expert in effect conceded that the phrase "of a file" could be added after "blocks," provided that "file" is interpreted broadly.² RT 196. The Court therefore accepts this construction. However, other than the description of inode in the preferred embodiment, which cannot suffice by itself, there is no support for the limitation "contains status information about the file" that was initially proposed by Sun. The Court therefore declines to adopt that limitation. As the parties did not brief the issue of the meaning of "file," which was raised for the first time at oral argument, the Court declines to construe "file" at this time. Therefore, the Court construes "inode" as "file system structure for pointing directly or indirectly to data blocks of a file, including blocks that only include metadata."

2 The parties had an opportunity to but did not raise any concerns about the precise wording proposed by the Court in the November 25, 2008 Order.

III. CONCLUSION

In accordance with the foregoing, and for the reasons discussed above, the Court construes the disputed terms of the NetApp patents as follows:

1. "Increas[ed/ing] a number of persistent consistency point images" is "permitting any number of PCPI's to be maintained."

2. "File system information (fsinfo) block" is "a data structure containing information specifying the layout of a file system."

3. Tentatively, "storage layer underlying the block and file level servers" is "the storage layer is a software layer `below' the block and file level servers, that is, the storage layer provides operations that are used by the block and file level servers."

4. "Mode operations"/"the mode layer operations" are "operations performed on inodes, where an inode is a file system structure for pointing directly or indirectly to data blocks of a file, including blocks that only include metadata." The Court corrects the misprinted references to "mode" in the patent to substitute "inode."

Pursuant to the parties joint proposed construction of "virtual disk(s)/" "vdisks" in the `385 patent, the Court construes that term as follows: "the vdisk is a multiinode object comprising a special file inode and at least one associated stream inode that are managed as a single `encapsulated' storage object within the file system."

IT IS FURTHER ORDERED that a case management conference is set for January 23, 2009, at 2:00 p.m., to discuss setting further dates in the case. The parties shall file a joint case management statement no later than January 16, 2009. The parties shall propose a schedule for filing summary judgment motions and address whether to limit the number of such motions and whether to stagger and prioritize the motions.

IT IS SO ORDERED.