Free Declaration in Support - District Court of California - California

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 1 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 -1SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

UNITED STATES DISTRICT COURT NORTHERN DISTRICT OF CALIFORNIA SAN FRANCISCO DIVISION NETWORK APPLIANCE, INC., Plaintiff-Counterclaim Defendant, v. SUN MICROSYSTEMS, INC., Defendant-Counterclaim Plaintiff. CASE NO. C-07-06053-EDL SUPPLEMENTAL DECLARATION OF DR. SCOTT BRANDT IN SUPPORT OF SUN MICROSYSTEMS, INC.'S REPLY CLAIM CONSTRUCTION BRIEF

I, Scott Brandt, Ph.D., declare as follows: I. '292 PATENT A. 1. "non-volatile storage means" The term "non-volatile storage" describes a function, and not a specific physical

structure or class of structures that performs the function. 2. Although many structures are capable of performing the function of non-volatile

storage, including those discussed in my previous declaration, in NetApp's brief, and in the declaration of Dr. Ganger, no structure is mentioned in the relevant claim(s) to explain how this function is accomplished. 3. It has been explained to me that in these circumstances, one must look to the

specification of the patent to determine the intended structure. Based on my reading of the patent,

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 2 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

it is my opinion that the intended structure is "one or more disks with a block-based format (i.e., 4KB blocks that have no fragments), where the disk storage blocks are the same as the data blocks of the file system" 4. Both NetApp and Dr. Ganger state that the storage means is a passive target of

"writing and storing." (See, e.g., Ganger Declaration, paragraph 11.) That is incorrect. Hard drives, the intended targets of the writing and storing, are active components of a storage system. They execute firmware, actively read and write data to their internal storage, and perform other operations independent of the requests from the host computer. 5. NetApp's definition of the term "non-volatile storage means" is too broad to be

correct. It includes types of non-volatile data storage--such as EPROM--that are clearly beyond what is intended by the patent's authors. Dr. Ganger admits as much in his declaration (Paragraph 17), stating, I do agree that the term "non-volatile storage" should be understood broadly to include, in addition to disks, other components on which file systems may be maintained, such as flash memory drives, disk arrays, battery backed RAM devices, and the like. But, I believe Sun and Dr. Brandt go too far in suggesting that relevant "nonvolatile storage" includes things like "paper" and "film" simply because they retain data in the absence of power. One of ordinary skill in the art would understand that, in the context of the patent, which focuses on maintaining consistent states and read-only copies of active file systems, the term "non-volatile storage" does not refer to things like "paper" and "film," which are not used for maintaining active (computer) file systems. Thus, by Dr. Ganger's admission, paper-based non-volatile computer storage devices such as paper tape readers and punch-card systems--both of which clearly fit NetApp's proposed

21 definition--are not referred to by term "non-volatile storage" as it is used in the patent and 22 therefore "non-volatile storage means" cannot mean "A storage device that can retain information 23 in the absence of power," as NetApp argues. 24 6. 25 "non-volatile storage" generally refers to a hard disk drive. This is inconsistent with NetApp's 26 definition of "non-volatile storage means" as "storage device[s] that can retain information in the 27 absence of power," as that definition includes many other types of many other types of "storage 28 -2SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

In Section A.1.c of its brief (NetApp Responsive Brief), NetApp argues that term

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 3 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

device[s] that can retain information in the absence of power," including those that are not intended by the patent's authors (per Ganger's Declaration, paragraph 17). The argument is, however, consistent with Sun's definition. 7. Fundamental to the operation of WAFL is "a disk format system that is block

based (i.e. 4 KB blocks that have no fragments)." ('292 patent, col. 5:48-53). WAFL formats the disk so that it is prepared to store 4KB storage blocks corresponding to the 4KB data blocks. NetApp criticizes Sun's construction because it does not identify all the requirements of WAFL-- such as WAFL inodes and directories--as corresponding structure. However, inodes and directories are not inherently structural aspects of the storage means and are, therefore, not included in the minimally necessary structure. In contrast, the block-based disk format is inherently structural because it describes how the underlying disk stores the data. 8. In my opinion, if one of ordinary skill in the art were to read the patent, Sun's

definition is the understanding that they would take away from it, that "non-volatile storage means" refers to "one or more disks with a block-based format (i.e., 4KB blocks that have no fragments), where the disk storage blocks are the same as the data blocks of the file system." B. 9. "metadata for successive states of said file system" As I discussed in my declaration at paragraphs 68-76, from the perspective of one

18 of ordinary skill in the art, the language of claim 8 reciting "meta-data for successive states of the 19 file system" means "a block map file recording snapshots of the file system." 20 10. 21 recited as "read-only copies of the file system." ('292 patent, claim 8, col. 26:1-2.) The first step 22 of "storing meta-data for successive states of the file system" enables the creation of the snapshot. 23 ('292 patent, col. 18:21-23.) The second and third steps are directed to the creation of the 24 snapshot. (`292 patent, col. 26:5-15.) 25 11. 26 meta-data for successive states of the file system." It is the structure that uniquely stores metadata 27 for successive snapshots. 28 -3SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Claim 8 recites a single, three-step process for creating a plurality of snapshots,

The block map is the unique element described within the '292 patent for "storing

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 4 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

12.

NetApp construes the term "metadata for successive states of a file system" as

meaning "Information that describes successive `states of a file system'." NetApp's construction replaces the word "metadata" with the broader term "information." The word "information" is generic and is not synonymous with the narrower term "metadata" in any file system context. To substitute "information" for "metadata" causes the use of the term "metadata" to have no bearing on the scope of the claim. 13. The term "information" broadly includes many things that are not "metadata,"

including file data itself. Dr. Ganger's explanation indicates that "metadata," even in the broad sense he adopts, should not include the "corresponding data." (Ganger paragraph 29). Dr. Ganger's explanation is inconsistent with the specification which states, for example, that the "[f]ile system information structure 1510 is not a meta-data file..." ('292 patent, col. 10:60-62). NetApp's construction fails to define the phrase as it would be understood by one of ordinary skill in the art. 14. The patent is very clear about what is meant by the term "metadata", saying,

"WAFL uses files to store meta-data that describes the layout of the file system. WAFL meta-data files include: an inode file, a block map (blkmap) file, and an inode map (inomap) file." ('292 patent, col. 5:53-56). Of these, the only file that describes successive states of the file system is the block map file. The other two, the inode file and the inode map, are unique to a specific state of the file system. 15. Dr. Ganger states that "`metadata' is commonly understood to include many

structures that contain information about the corresponding data." (Ganger paragraph 29). This observation is misplaced because it ignores the language of the Claim, which identifies the term being defined as "metadata for successive states of said file system." Specifically, none of the examples provided by Dr. Ganger, such as "an inode file, a root inode, an inode map file, inode tables, directories, bitmaps, and indirect block" are associated with "storing metadata for successive states of the file system." The phrase itself significantly identifies the metadata that is required, i.e., the metadata for successive states of the file system. 16. The word "successive" informs and confirms that "states of the file system" refers -4SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 5 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

to the current state of the file system and past states of the file system that may be recorded snapshots. 17. "State of a file system" means "a set of storage blocks for a file system that

includes all blocks required for the data and structure of the file system." (Brandt decl., paragraph 131). A person of ordinary skill in the art recognizes that the plural "states" refers to more than one set of storage blocks for the file system that include all blocks required for the data and structure of the file system. In addition to indicating more than one state of the file system, the claim language includes the word "successive," further indicating that multiple states are intended. 18. The '292 patent is clear in describing the succession from a past state of the file

system to a current state of the file system in Figure 18C. The '292 patent explains that a snapshot is created as the past state of the file system and subsequently the file system enters the current state. ('292 patent col. 19:20-23). The '292 patent refers to the current state of the file system as the most recent consistency point written to disk. ('292 patent, col. 11:60-12:1, col. 14:42-44, col. 17:60-64). 19. The block map file is copied at each successive state of the file system. ('292

patent col. 13:45-46.) Each snapshot will create a copy of the block map file. ('292 patent, col. 21:51-52). Additionally, the block map disclosed in the specification of the '292 patent includes "planes" that correspond to the active file system and each snapshot. ('292 patent, col. 10:7-15). At the creation of a snapshot, the active file system bits are copied into the plane corresponding to the snapshot. ('292 patent, col. 20:40-41). By copying the active file system plane, the bit map file ensures that new data would not overwrite old data that was being saved in a snapshot. ('292 patent, col. 21:9-11). The '292 patent consistently states that the block map file is updated by this type of copying. ('292 patent, col. 13:41-44, col. 21:53-56). 20. Claim 8 has a broader scope than claims 9 and 10 under Sun's construction. A

block map in the file system literature does not have a universally agreed upon arrangement. Claim 8 discusses operation of the block map file in general. 21. NetApp argues that claim differentiation with Claims 9 and 10 means that claim 8 -5SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 6 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

cannot refer specifically to the block map. I disagree. In my opinion, claims 9 and 10 describe specific aspects of a block map and the ways in which the block map functions. 22. Claim 9 explains that the block map includes multiple usage bits per block. Claim

9 also has the additional requirement of "the marking of said blocks" by requiring that the marking occur through placing entries in the block map. ('292 patent, col. 26:16-21). This further narrows the scope of claim 8 by requiring the relationship between these claimed features. 23. Claim 10 is different from Claim 9 in that it further requires "multiple usage bits

per block" ('292 patent, col. 26:23) (as opposed to, for instance, a single multi-bit entry per block). This language further limits the use and arrangement of the block map file of claim 8 by designating the entries of the block map. 24. Claims 11-13 and 18-19 also further narrow the scope of claim 8 by requiring

additional structure within the scope of the claim. Sun's construction of claim 8 is consistent with the addition of structures as are recited in these claims. The additional structures work in addition to the required block map file. With claim 11, the block map file and pointers are required, and thus claim 11 is narrower. Similarly for claims 12, 13, 18, and 19, the "structures," "inodes," "root structure," and narrower "root inode" are present in addition to the block map file of claim 8. C. 25. "file system information structure" As I discussed in my first declaration in paragraphs 77-86 and as I stated therein,

the phrase "file system information structure" does not have an established meaning in the file system art (Brandt Declaration paragraph 82). As such, this term is defined by reference to the claims and the specification, beginning with the Abstract. 26. NetApp's construction of the term "file system information structure" as "a data

structure containing information about the layout of a file system" causes the claim language to be repetitive of other claim language by causing claim 4 to read as follows: "...said first data structure containing information about the layout of a file system comprising data describing a layout of said file system ...". 27. More generally, NetApp's definition is too broad when viewed from the level of -6SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 7 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

ordinary skill in the file system art based on the '292 patent. Under NetApp's construction the phrase may include the block map that is explicitly excluded from the phrase by the specification ('292 patent col. 5:54-56, col. 10:60-62). 28. The patent support's Sun's definition of "file system information structure" as a

"data structure that contains the root inode of a file system in a fixed location on disk," saying: "FIG. 15 is a diagram illustrating a file system information (fsinfo) structure 1510. 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. File system information structure 1510 is not a meta-data file but is part of the WAFL system. The root inode 1510B is an inode referencing the inode file 1210. It is part of the file system information (fsinfo) structure ..." ('292 patent, col. 10:57-64). In other words, the file system information (fsinfo) structure contains the root inode and is kept at a fixed location on disk. 29. The fsinfo structure and the root inode it contains are kept at a fixed location on

disk for a very important reason: the WAFL file system will not function properly if it is not. Because the WAFL file system--the Write Anywhere File Layout (WAFL) file system--stores all files, including the metadata files, at arbitrary locations on disk, it must store some root data structure at a known location in order to enable the file system to start up after the system has been powered down. One of ordinary skill in the art would understand that that data structure is the file system information structure and the root inode it contains, which are stored at a fixed location on disk. The patent makes this very clear and teaches no alternative. 30. NetApp argues that differentiation from Claim 6 requires that the fsinfo structure

described in claim 4 must not be defined to be at a fixed location on disk. That is incorrect. 31. Claim 4 describes writing an fsinfo structure at a fixed location on disk and then

writing a second fsinfo structure. Claim 5 is narrower than Claim 4 and recites storing copies of the fsinfo structure to a first and a second location. 32. Claim 6 recites that both the first and second locations for the copies of the file

system information (fsinfo) structure are fixed and predetermined. This further limits claim 5 in at least by requiring both of the copies to be stored at predetermined fixed locations. -7SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 8 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

33.

A person of ordinary skill in the art would recognize from viewing claim 4-7

together that no dependent claim from claim 4 (claiming the single file system information (fsinfo) structure) recites the requirement of storing the single copy in a fixed location. The absence of a dependent claim with that requirement is consistent with the requirement of claim 4 that recites the "file system information structure" that means "a data structure that contains the root inode of a file system in a fixed location on disk." 34. NetApp further argues that the file system would work just as well if the fsinfo

structure and root inode were not stored at a fixed location on disk. That is incorrect. Any scenario for storing the fsinfo structure requires that it be at a fixed location, as shown in three hypothetical examples below: a) The fsinfo structure and its root inode could be stored at a second fixed location, with a pointer to it stored at a first fixed location. That leaves the fsinfo structure at a fixed location, obviating the need for the pointer and remaining consistent with Sun's definition. b) The fsinfo structure and its root inode could be stored in the inode file. This results in an impossible circular situation in which one cannot locate the inode file without first locating the root inode and one cannot locate the root inode without first locating the inode file. c) The fsinfo and its root inode could be stored in an arbitrary location other than the inode file, with a pointer to that location stored in a fixed location. In that case, the block map would have to be updated to reflect the use of the block or blocks to store the fsinfo structure. However, the block map file cannot be updated when the fsinfo structure is written because the patent makes clear that at the time that the fsinfo structure and its root inode are written to disk, the block map has already been written to disk, saying "referring to FIG. 16, a new consistency point is written 10 by first flushing all file system blocks to new locations on disk (including the blocks in meta-data files such as the inode file 1620, blkmap file 1630, and inomap file 1640). A new root inode 1610B and 1612B for the file system 1670 is then written to disk." ('292 patent, col. 12:9-14). Thus the fsinfo and its root inode must be written to a fixed location on disk. 35. As explained above, I disagree with NetApp's argument that one of ordinary skill

26 in the art would understand that the fsinfo structure and its root inode were not at a fixed location 27 on disk. 28 -8SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 9 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 39. II. '211 PATENT

A. "Pointing directly and indirectly to buffers in said memory and a second set of blocks on said storage system" 36. The term "pointing directly and indirectly to buffers in said memory and a second

set of blocks of said storage system" is clear and unambiguous and one of ordinary skill in the art would understand that it means "pointing directly and indirectly to buffers in said memory and pointing directly and indirectly to a second set of blocks on said storage system." 37. The word "and" has a very specific meaning in computer science that is well

understood by one of ordinary skill in the art that is explicitly distinct from the meaning of "or" and its informal equivalent "and/or". "A and B" always means "both A and B." It never means "either A or B." Thus "pointing directly and indirectly" means "pointing both directly and indirectly" or "pointing directly and pointing indirectly" while "to buffers and blocks" means "to both buffers and blocks" or "to buffers and to blocks." Thus "pointing directly and indirectly to buffers in said memory and a second set of blocks of said storage system" would be unambiguously understood to mean "pointing directly and pointing indirectly to buffers in said memory and pointing directly and pointing indirectly to a second set of blocks of said storage system" or, more concisely, "pointing directly and indirectly to buffers in said memory and pointing directly and indirectly to a second set of blocks on said storage system." 38. Some consequences of the above are that: a) b) c) d) e) f) system The plain language of this claim term makes clear that this is what is intended and -9SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

The root inode must point directly to blocks The root inode must point indirectly to blocks The root inode must point directly to buffers The root inode must point indirectly to buffers The root inode must point to both blocks and buffers The blocks and buffers together store the second consistent state of the file

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 10 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

these facts would have been apparent to one of ordinary skill in the art. For these reasons, I disagree with Dr. Ganger's view that the fact that each individual block is not pointed to both directly and indirectly somehow requires that the "and" be read as an "or." To the contrary, to meet this claim limitation, even a minimal file system must have at least one block pointed to directly and at least one other block pointed to indirectly as well as at least one buffer pointed to directly and one pointed to indirectly. Any other way of reading the claim language is inconsistent with its plain meaning and the knowledge of one of ordinary skill. 40. The surrounding claim language confirms this understanding. The claims require

that the second consistent state referenced by the incore root inode be stored in "said buffers and said second set of blocks." ('211 patent, col. 24:2-6). This means that both blocks and buffers must be present to together comprise the second consistent state. Dr. Ganger recognizes that these buffers and blocks together comprise one group, but somehow concludes that the preceding "pointing directly and indirectly" language does not need to apply to both buffers and blocks. I disagree. If both buffers and blocks are required to store the second consistent state, the other "ands" in the claim must be interpreted in the conjunctive for the claim to make sense. 41. Dr. Ganger provides two examples that he believes show situations where the root

inode would not point directly and indirectly to blocks and to buffers. Neither example is disclosed in the specification. Furthermore, both examples are actually counter to the teachings of the specification and the claim language, as I discuss below. Dr. Ganger's first example of "not pointing directly to any blocks" (Ganger Declaration, paragraph 64) is inconsistent with the language of the claim. Dr. Ganger envisions a situation in which all 16 blocks pointed to directly by the root inode have changed, such that "the incore root inode for the second consistent state will not point directly to any blocks in the second consistent state." (Ganger Declaration, paragraph 64). Claim 1 says, "...said incore root inode pointing directly and indirectly to buffers in said memory and a second set of blocks on said storage system, said buffers and said second set of blocks storing data and metadata for a second consistent state of said file system... ." Dr. Ganger incorrectly infers from this that the incore inode cannot also point "directly" to blocks from the first consistent state, even though the claim goes on to say, "... said second set of blocks -10SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 11 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

including at least some blocks in said first set of blocks..." and the specification makes clear that the root inode includes a copy of the on-disk inode, which points directly (and indirectly) to the blocks comprising the first consistent state ('211 patent, element 1010D in Fig. 10, col. 7:58-60). The copy of the on-disk root inode in the incore root inode continues pointing to blocks in the first consistent state even when all such blocks have undergone changes and are represented by dirty incore buffers. Therefore, consistent with the plain claim language, the incore root inode always points directly and indirectly to blocks and buffers. 42. Dr. Ganger also envisions a situation in which an impossibly tiny file system may

not point indirectly to any buffers (Ganger Declaration, paragraph 65). This example is also incorrect, for three reasons. First, Dr. Ganger incorrectly assumes that the in-core inodes are the same size and have the same structure as the on-disk inodes. This is contradicted by the specification, which says: "The incore WAFL inode 1010 has a size of approximately 300 bytes. The on-disk inode is 128 bytes in size." ('211 patent, col. 7:12-14). Second, a minimal inode file needs space for at least 23 inodes for the block map file, the inode map file, 20 snapshots, and a root directory (see, for example, '211 patent, Figure 22). 23 inodes of 300 bytes each would require 6900 bytes of storage and will not fit in a single 4K buffer, as described by Dr. Ganger. Therefore, storing a file system in one buffer is not possible even under the unrealistic conditions of Dr. Ganger's example. Third, the patent says "pointing directly and indirectly to buffers..." while Dr. Ganger's example includes only a single buffer and thus cannot be what was envisioned by the claim. B. 43. "root inode" NetApp construes this term to mean "An inode that points directly and/or

indirectly to all the blocks in a consistent state of a `file system' (as construed herein)." This definition is incorrect for two reasons. First, the claim language makes very clear that the root inode points "directly and indirectly." Second, it falls short as a definition as it fails to capture a critical aspect of the root inode that is necessary for the correct operation of the file system. Namely, that it must be stored in a fixed location on disk. 44. One of ordinary skill in the art would look to the specification, in addition to the -11SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 12 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

claims, in order to understand the significance of the root inode. The specification distinguishes the claimed file system from prior art file systems on the ground that the allegedly novel inode file can be stored anywhere on disk, unlike prior art inode tables that were stored in a fixed location. ('211 patent, col. 9:27-36). The specification makes clear that this write-anywhere property of the inode file (the file that contains all file system inodes except for its own inode-- the root inode) necessitates that its root be in a fixed location. This is further evidenced by its name, root inode, which one of ordinary skill in the art would understand to indicate that it roots, or anchors, the file system by virtue of being stored in a fixed, known location. 45. NetApp and Dr. Ganger seem to believe that the incore and on-disk root inodes are

two unrelated things. In fact, the root inode is a temporary copy of the on-disk root inode stored in memory. The specification teaches that incore inodes are stored in memory buffers ('211 patent, col. 6:55-61). The inode buffers structure shown in Figure 8 includes a copy of the on disk inode 820 as well as buffer-specific elements such as flags and buffer pointers. While the root inode resides in memory, the buffer pointers point directly and indirectly to other buffers, including those with changed data ('211 patent, Figure 17L). At the same time, the incore copy of the root inode continues to point to the same blocks as the original root inode stored on disk. The incore copy of the root inode is periodically written to a fixed location on disk where it overwrites the on-disk copy, synchronizing the two copies and transitioning the file system to the next consistency point. Sun's construction is consistent with the operation of the root inode laid out in the specification and described here. One of ordinary skill in the art would understand that the claimed incore root inode is an in-memory copy of the root inode stored at a fixed location. The fact that the incore copy has some additional structures and is not stored in a fixed location in memory is simply not relevant to this understanding. 46. Dr. Ganger asserts in paragraph 79 that "One of ordinary skill in the art would

understand that there are other mechanisms for ensuring that the root inode for the active file system can be located" and offers two examples of purported solutions for locating the root inode without storing it in a fixed location. The first example is incorrect, and the second is irrelevant. 47. Dr. Ganger's first example says "rather than storing the root inode itself in a fixed -12SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 13 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

location, the file system could instead store a pointer to the root inode in a fixed location." (Ganger Declaration paragraph 79). This example has problems similar to those discussed with reference to the file system information (fsinfo) structure in paragraph 34 above. If the root inode is not stored in a fixed location, then storage for it must be allocated via the block map. However, the specification makes clear that the block map is always written before the root inode, saying "Referring to FIG. 16, a new consistency point is written by first flushing all file system blocks to new locations on disk (including the blocks in meta-data files such as the inode file 1620, blkmap file 1630, and inomap file 1640). A new root inode 1610B and 1612B for the file system 1670 is then written to disk." ('211 patent, col. 12:8-13). Allocating space for the root inode would thus require changing the block map after it has already been written to disk for the current consistency point, contradicting the teachings of the specification and potentially leading to an inconsistency in the file system. This is made clear by the discussion of what the specification refers to as the "single ordering constraint" of the claimed file system ('211 patent, col. 14:1828), which says in part, "The present invention, as illustrated in FIGS, 20A-20C, has a single ordering constraint. The single ordering constraint is that the fsinfo block 1810 is written to disk only after all the other blocks are written to disk." Thus, one cannot update the block map to write the root inode. 48. Dr. Ganger's second example says that "the file system could have a set of

predetermined locations that might hold the root inode ­ to find the root inode, it would then read all locations in the set to determine which actually held the root inode." (Ganger Declaration paragraph 79). In my opinion, this example is consistent with Sun's definition, which requires that the root inode be written to at least one fixed location. In fact, the specification teaches that the root inode is stored in a set of fixed locations, namely two, ('211 patent, col. 11:3-5), which must be scanned to determine which is the most recent in case of a file system crash. ('211 patent, col. 14:54-15:5). In other words, Dr. Ganger's second example is not an example of something other than storing the root inode in a fixed location. 49. In its brief, NetApp confuses root inodes and snapshot inodes, saying, "In any

event, the specification clearly indicates--and one of ordinary skill in the art would understand-- -13SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 14 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

that copies of the root inodes for previously saved consistency points (i.e., snapshot inodes) can be stored anywhere in the file system." (NetApp Responsive Brief, page 29, lines 22-24). While it is true that snapshot inodes may be stored anywhere, snapshot inodes and root inodes are different, as indicated by the specification, which distinguishes the two, saying, "Each snapshot is represented by a snapshot inode that is similar to the representation of the active file system by a root inode." ('211 patent, col. 18:3-5) and explaining how they differ (see, for example, col. 22:813). 50. In fact, Figure 22 shows that snapshot inodes reside in the inode file alongside all

of the other regular inodes. The inode file is pointed to by the root inode. This means that the file system must be able to find the root inode--through having it stored in a fixed location--in order to access any of the snapshot inodes. If the root inode is lost, the snapshots are lost with it. Because snapshot inodes are located in the inode file, they are part of the claimed "metadata" pointed to directly and indirectly by the root inode. As can be seen, snapshot inodes are not themselves the root inode and are irrelevant to the proper construction of "root inode." 51. The distinction between the root inode and snapshot inodes is clearly intended by

the claims, which indicate that the root inode points to a consistent state of a file system, and not to a "read-only copy of a file system at a given instant when the snapshot is created" ('211 patent, col. 17:59-61). Therefore, while the root inode roots the active, evolving file system, snapshot inodes root only a read-only copy of how the file system looked in the past. The two inodes thus have a different purpose. For this reason, one of ordinary skill in the art would have understood that the properties of a snapshot inode are irrelevant to the definition of a root inode. C. 52. "consistent state"/"state of a file system" I understand that NetApp maintains that the term "consistency point" and the term

"consistent state" should be given the same construction, "A set of blocks on disk, rooted by a root inode, that includes all the blocks required for the data and file structure of a file system." I do not agree that these two terms are equivalent. 53. The term consistency point does not appear in the claims of the '211 patent but -14SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 15 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

appears in claim 4 of the '292 patent, which describes a file system that transitions from one consistency point to another. The specification defines consistency point as "the set of selfconsistent blocks on disk that is rooted by the root inode." ('211 patent, col. 4:17-19). The specification further teaches that "A new consistency point occurs when the fsinfo block is updated by writing a new root inode for the inode file into it. Thus, as long as the root inode is not updated, the state of the file system represented on disk does not change." ('211 patent, col. 4:2125). A consistency point is therefore an on-disk state of a file system that occurs when the file system on disk is rooted by the on-disk root inode. This can be seen in '292 claim 4, where the file system remains at the first consistency point all the way until a new fsinfo structure (containing the root inode) is written out to disk. 54. The term "consistent state" appears in the claims of the '211 patent. Claim 1

makes clear that a consistent state may include only disk blocks (the claimed "first consistent state"), or may include both in-memory buffers and disk blocks (the claimed "second consistent state"). This is the moment between the first and second consistency points of Claim 4 of the '292 patent, before the second consistency point has been written to disk. In the language of the '211 patent, the "on-disk root inode pointing directly and indirectly to a first set of blocks on said storage system that store a first consistent state of said file system" is the "first consistency point". 55. However, even though the in-core root inode roots a second consistent state, it

does not root a second consistency point because it has not yet been written to disk. In other words, for the duration of the operation described in the claims of the '211 patent, the file system remains at the first consistency point. Thus, the terms "consistent state" and "consistency point", although related, are not synonymous and cannot be defined as such. "Consistent state" is a general characteristic of the set of all blocks comprising the data and structure of the file system, as reflected in Sun's construction. NetApp's attempt to narrow the meaning to an on-disk structure rooted by the root inode (i.e., a consistency point) creates confusion and is at odds with the teaching of the specification. -15SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 16 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

III.

'715 PATENT

A. "Associating the data blocks with one or more storage blocks across the plurality of stripes as an association," (Claims 21 and 52), and "The association to associate the data blocks with one or more storage blocks across the plurality of stripes" (Claim 39) 56. U.S. Patent No. 7,200,715 ("the '715 patent") discusses a system and method for

controlling storage of data over arrays of disk drives. ('715 patent, col. 1:7-9.) In file systems, data is organized into files. A file is a unit of storage that distinguishes one set of information from another. For example, a file can be a document, a sound recording, a movie, or a computer application. In dealing with files most computers systems treat them as logically contiguous sets of data blocks much like a book is a contiguous set of pages. In the system described in the '715 patent, the data blocks of a file are all fixed in length and are the same size as storage blocks on disk. This allows the system to map each data block to a respective storage block on disk. 57. As described in the '715 patent and as is well known in the art, multiple disk

drives can be used together in parallel to form a "redundant array of inexpensive/independent disks," called a "RAID" system. ('715 patent, col. 1:27-36.) RAID systems provide improved reliability and/or high data transfer rates relative to single disk drive systems because in a RAID system data can be written across many disk drives in parallel and stored redundantly. ('715 patent, col. 1:32-36.) In some RAID systems, if a disk drive fails, it can be replaced without shutting down the entire system. ('715 patent, col. 1:43-45.) 58. In a RAID system, data blocks are written in to "one storage block on each disk

drive in an array of drives in the system." ('715 patent, col. 1:37-39.) Blocks of data are written across the disk drives of a RAID system in the form of "stripes." The '715 patent defines a "stripe" as being "one storage block on each disk drive in an array of drives in the system." ('715 patent, col. 1:37-39.) This definition is consistent with the definition of the term as it is understood by those of ordinary skill in the art. 59. The '715 patent provides an example of a RAID array including four disk drives,

90A, 90A', 90A" and 92A. ('715 patent, Fig. 1A.) Data blocks are written across the disk drives "as a series of stripes, 94A, 94A', 94A" (generally 94)." ('715 patent, col. 5:8) In practice a single -16SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 17 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

disk drive may have millions of storage blocks with stripes that may be on the order of 5 to 10 storage blocks in length, that is, 5 to 10 disk drives wide. 60. In some RAID systems, parity information can be used to reconstruct data from a

failed disk. For example, if a file contains three data blocks of information, it could be written across stripe 94A with a single data block residing in a respective storage block of each of disks 90A, 90A' and 90A". Parity would then be calculated for the stripe and stored in a corresponding storage block of parity disk 92A. If, for instance, disk 90A' failed, the RAID system could still retrieve the file by accessing the corresponding storage blocks of data disks 90A and 90A" and the parity block on disk 92A. The parity information in disk 92A would be used together with the data from disks 90A and 90A" to recreate the data on failed disk 90A'. 61. For a number of reasons, the data blocks in a write request or set of write requests

might not be contiguously stored in the disk array but rather, scattered about. As part of the claimed invention, the computer system uses a map to represent the one-to-one correspondence between each data block being written and its corresponding storage block on the storage device. The '715 patent's map is called an "association" in the claims and variously called a "map", an "association," and/or "block layout information" in the specification. One example is illustrated in Figure 8, reproduced below:

62.

Figure 7 illustrates four write requests for data blocks that are part or all of four

files, i.e., contiguous data blocks A1 through A6 from File A, blocks B1 through B4 from File B, -17SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 18 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

etc. Figure 8 is a representation of the mapping of the data blocks in Figure 7 to physical drives in a RAID system; compare, for example, Figure 8 with Figure 1A. Particularly, Figure 8 is the map, "an association 15A" ('715 patent, col. 15:35), that pictorially shows the one-to-one correspondence between the data blocks to be written and the storage blocks into which the data blocks will be written. Of course, the internal computer representation of this map will be different than this figure. 63. A parity device is not shown in Figure 8. However, under the RAID 4 system

described in the '715 patent, a fifth device (the "parity" device) would be used to store parity information. Parity information would be written to the parity device for each of the stripes (1-6) of the array, one set of parity information generated for each of the six stripes. 64. The invention claims to be an improvement over prior arrays of drives that

performed individual stripe writes by writing more than one stripe at a time, that is, a "plurality of stripes" ('715 patent, Claim 21, col. 21:47) in a "single write request [sic, transaction]" (`'715 patent, Claim 21, col. 21:51-52). The '715 patent claims that all prior art systems wrote a single stripe at a time. ('715 patent, col. 9:28-31.) Thus, a key distinction that the patent claims over the prior art is that the one-to-one association described traverses multiple stripes. 65. In the context of Figures 7 and 8, and in accordance with the claimed invention,

there is only one write transaction to the array including all of the data blocks. A write transaction decision is made when a sufficient quantity of data blocks are available as determined by a number of criteria. ('715 patent, col. 10:55-58). For example, the write transaction might be delayed until an optimal number of storage blocks per device are ready to be written. ('715 patent, col. 10:61-2). Thus, if the criterion were four storage blocks per device, then the map of Figure 8 would meet this criterion and there would be one write transaction to the array. In such a write transaction, each drive would write up to six storage blocks, all five devices (devices 1-4 and the parity device) writing in parallel. In the context of Figure 8, for example, device 1 would write data blocks A1 thru A6 into its storage blocks, device 3 would write data blocks B4, C1, C2, D1, D2 and D3 into its storage blocks, etc. 66. I have reviewed the claims of the '715 patent, and in my opinion, claims 21, 39 -18SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 19 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

and 52 are indefinite because the terms "associating the data blocks with one or more storage blocks across the plurality of stripes as an association" and "the association to associate the data blocks with one or more storage blocks across the plurality of stripes" (the "associating limitations") are inherently inconsistent, one of ordinary skill in the art could not determine whether a product practices the claims, and the claims fail to capture the key feature that the '715 patent explains makes the invention different from the prior art. 67. When the words of the associating limitations are given their full range of plain

and ordinary meaning, the claims purport to cover at least two situations: (i) associating the data blocks with a single storage block across multiple stripes as an association; or (ii) associating the data blocks with more than one storage block across a plurality of stripes as an association. Because the claim uses the term "or," satisfying either situation would meet the limitation. However, because a stripe consists of multiple storage blocks and any one storage block cannot exist across multiple stripes, the first situation states an impossibility. Therefore, in my opinion, one of ordinary skill in the art would not be able to determine whether a particular product satisfies the first situation and thus cannot reasonably determine whether a product infringes the claim. 68. NetApp argues that the invention "strictly requires" an association of multiple

storage blocks across multiple stripes of an array, which distinguishes the '715 patent from the prior art (NetApp Response Brief, 35-38). This argument is also made repeatedly throughout the file history where NetApp urged the patent office to allow the claims because the prior art did not teach mapping or associating "each data block with a respective one of the storage blocks across a plurality of stripes." (See Sun's Op. Brief, pages 35-37). This critical "requirement", however, is missing from claims 21, 39 and 52. Instead, claims 21, 39 and 52 were all written to cover what NetApp refers to as a "degenerate" case where the association consists of only a single storage block that cannot exist across multiple stripes. Therefore, the claims as written cover subject matter that does not include a critical feature of the patent and that is not distinguishable from the prior art. 69. If the Court were to determine that claims 21, 39 and 52 are not indefinite, in my -19SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 20 of 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

opinion, the only construction for the terms "associating the data blocks with one or more storage blocks across the plurality of stripes as an association" and "the association to associate the data blocks with one or more storage blocks across the plurality of stripes" that is consistent with the specification and file history is the construction proposed by Sun (i.e., "associating each data block with a respective one of the storage blocks across the plurality of stripes as an association"). The specification repeatedly describes the invention as associating data blocks to storage blocks in a one-to-one correspondence, i.e., each data block is associated with a respective one of the storage blocks. ('715 patent, Abstract, 9:16-19, 13:37-39, 13:20-22, 13:2-5). This one-to-one association is the only type of association described in the '715 patent. Sun's proposed construction captures this inherent feature of the association as set forth in the '715 specification, while NetApp's proposed construction does not. 70. Furthermore, in my opinion, NetApp's construction, which replaces the claim term

"storage blocks" with the more general term "locations" has no basis in the specification, file history, or in the art. Both the specification and the prosecution history clearly define stripes in terms of storage blocks and require a one-to-one mapping of data blocks to storage blocks. 71. In my opinion, Sun's construction is consistent with the disclaimers NetApp made

in the prosecution history of the '715 patent, while NetApp's construction contradicts its own disclaimers in the prosecution history and therefore cannot be correct. 72. Consistent with the teachings of the '715 patent specification, NetApp argued

during prosecution of the '715 patent that the novel "association" required a one-to-one mapping of data blocks to storage blocks over a plurality of stripes. In at least three different amendments, NetApp urged the Patent Office to allow the claims because the prior art did not teach "mapping" or associating "each data block with a respective one of the storage blocks" across a plurality of stripes. Sun's Opening Brief at 35-37. NetApp made this argument with respect to all of the claims, including claims 21, 39 and 52. Furthermore, the Examiner agreed and allowed claims 21, 39 and 52 for this very reason--i.e., because the prior art allegedly lacked "associating each [of the] data blocks to be stored with a respective one of the storage blocks across the plurality of stripes for a single write operation." Sun's Opening Brief at 35-37; see also, May 17, 2005 Office -20SUPP. DECL. OF DR. SCOTT BRANDT ISO SUN'S REPLY CLAIM CONSTRUCTION BRIEF CASE NO. C 07-06053 EDL

Case 3:07-cv-06053-EDL

Document 126

Filed 08/01/2008

Page 21 of 21