160 F. Supp. 2d 1274 | D. Utah | 2001
ALTIRIS, INC., a Utah corporation, Plaintiff,
v.
SYMANTEC CORPORATION, a Delaware corporation, Defendant.
United States District Court, D. Utah, Central Division.
*1275 *1276 *1277 *1278 Jon C. Christiansen, Michael L. Larsen, C. Kevin Speirs, Catherine Agnoli, Lara A. Reymann, Parsons Behle & Latimer, Salt Lake City, UT, Wesley L. Austin L. Austin, Madson & Metcalf, Salt Lake City, UT, for Plaintiff.
Mark O. Morris, Snell & Wilmer LLP, Salt Lake City, UT, Bruce A. Kugler, Benjamin B. Lieb, Robert R. Brunelli, Sheridan Ross PC, Denver, CO, Lillian C. Henry, Heller Ehrman White & McAuliffe, San Francisco, CA, Mark F. James, Heather A. McDougald, Hatch James & Dodge, Salt Lake City, James L. Warlaumont, Appel & Warlaumont, Salt Lake City, Robert D. Fram, Robert Haslam, S. Elizabeth Mitchell, Heller Ehrman White & McAuliffe, Menlo Park, CA, Joshua Masur, Heller Ehrman White & McAuliffe, Menlo Park, CA, for Defendant.
ORDER
KIMBALL, District Judge.
Plaintiff, Altiris, Inc., filed this action against Symantec Corporation, claiming that Symantec has infringed Altiris' United States Patent Number 5,764,593 ("the '593 Patent"). On July 16 and 17, 2001, the court conducted a hearing pursuant to Markman v. Westview Instruments, Inc., 52 F.3d 967 (Fed.Cir.1995), aff'd, 517 U.S. 370, 116 S. Ct. 1384, 134 L. Ed. 2d 577 (1996), for the purpose of construing or interpreting the claims comprising the '593 patent. The court has considered the parties' written submissions on these matters, as well as the arguments made at the hearing, and finds as follows.
I. BACKGROUND
Altiris owns the '593 Patent which generally concerns a method and a system that intercepts and controls the computer boot process. The software technology in the '593 Patent allows a network administrator working from the network server to remotely access individual network computers for various reasons, such as to update or install software. Prior to the '593 Patent, this could only be accomplished through the installation of hardware on each individual computer in the network.
When a computer is first turned on, it goes through a series of tests to ensure its components are functioning properly and then transfers control to a software program in the Master Boot Record (MBR) that will load the operating system. The software invented in the '593 Patent interrupts the normal booting process through a customized MBR code which contains a special flag system that tells the computer to transfer control to an automation partition on the MBR rather than to one of the normal operating systems. Once the computer is controlled by the automation partition *1279 code, the computer is linked to the network server computer and a specialized "Bootwork routine" runs.
The Bootwork routine examines a database on the server to determine whether there are any automation commands to be executed on the individual (also referred to as client or digital) computer. If there are automation commands to be executed, such commands are executed on the individual computer and then the computer reboots itself using the normal booting process. If there are no automation commands specified on the server, the individual computer is directed to proceed with the normal booting procedure. Under either scenario, before the normal booting procedure occurs, the customized MBR code resets the special flag so that the next time the computer boots, it will boot from the automation partition. As a result, the automation partition always gains control of the normal operating system when the computer is turned on or rebooted.
There are twelve claims involved with the technology in the '593 patent. However, most of the disputes between the parties center around Claims 1 and 8.
A. Claim 1
Claim 1 requires a digital computer having at least five components and utilizes at least six method steps, as follows:
A method for gaining control of a computer prior to the normal boot sequence operating on a digital computer system, said digital computer system including:
means for storing data;
means for processing data;
means for connecting said digital computer system to an external source of commands;
means for displaying data; and means for inputting data;
the method comprising:
testing automatically for automation boot sequence data, said test including reading a boot selection flag and comparing said boot flag with a known flag setting;
transferring control of said computer system to automation code, if said testing automatically step indicates an automation boot sequence;
executing a control process for said means for connecting said digital computer system to an external source of commands, if said testing automatically step indicates an automation boot sequence;
performing said external commands, if said testing automatically step indicates an automation boot sequence; setting said boot selection flag; and booting normally, if said testing automatically step indicates a normal boot sequence.
B. Claims 2 through 7
Claims 2 through 7 are dependent on claim 1, meaning that they incorporate the language from claim 1 but then add or modify the steps in claim 1. Claim 2 adds the requirement of "creating an automation partition in said means for storing data." Claim 3 adds the requirement of "resetting said digital computer system to a known state." Claim 4 adds that the "executing a control process" step in claim 1 requires "loading an operating system; loading a set of interface drivers; executing said operating system; executing said interface drivers; and accessing a set of externally stored commands." Claim 5 alters the "performing said external commands" step in claim 1 to require "searching for valid commands; executing said valid commands; and setting said boot selection flag." Claim 6 adds the step of "booting said digital computer system normally if said testing automatically step indicates *1280 that said computer system's boot selection flag is set to boot normally." Claim 7 requires that "wherein said external source of commands originates on a second computer system connected to said digital computer system via a network interface."
C. Claim 8
Claim 8 provides as follows:
A digital computer system programmed to perform the method of gaining control of the boot procedure of a digital computer, said digital computer comprising:
(A) a central processing unit;
(B) a memory unit;
(C) a long term storage device; and
(D) a means of booting said computer, said means of booting including a first set of commands resident on said storage device of said digital computer for booting said digital computer, and a second set of commands, said second set of commands resident on a storage device external to said digital computer for booting said digital computer,
the method comprising:
testing automatically for source of said means of booting; said testing including reading a boot selection flag and comparing said boot selection flag with a known flag setting;
transferring control of said computer system to said source of said means of booting;
performing said external commands, if said testing automatically step indicates a boot sequence stored externally to said digital computer;
setting said boot selection flag; and
booting normally, if said testing automatically step indicates a boot sequence stored internal to said digital computer.
D. Claims 9 through 12
Claim 9 is dependent on claim 8 and claims 10 through 12 are dependent on claim 9. Claim 9 requires a "network interface; a network interface driver; and a server computer." Claim 10 modifies claim 9, stating "wherein said transferring control includes transferring control of said digital computer to said server computer." Claim 11 adds the requirements that "wherein said external commands are stored on said server computer." Claim 12 adds the step of "initializing said digital computer system to a known initial state."
The parties' disputes focus on: (1) whether the steps of claims 1 and 8 must be performed in the order in which they are stated in the claim; (2) whether the preambles of claims 1 and 8 are claim limitations; (3) the proper interpretation of certain claim terms, including "boot selection flag" in claims 1 and 8, "automation boot sequence data" in claim 1, "automation code" in claim 1, "means of booting" in claim 8, "means for connection" in claim 1, "accessing" in claim 4, and "searching" in claim 5; and (4) whether the terms of claims 3 and 12 are so vague as to be fatally indefinite.
II. DISCUSSION
A. Claim Interpretation
A patent infringement case involves a two-step analysis. First, the claim must be properly construed to determine its scope and meaning. Second, a comparison must be made between the claim, as properly construed, and the accused device or process. See IMS Technology, Inc., v. Haas Automation, Inc., 206 F.3d 1422, 1429 (Fed.Cir.2000); Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1581-82 (Fed.Cir.1996). The first step of claim construction or claim interpretation is strictly a question of law for *1281 the court. Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed.Cir. 1995), aff'd, 517 U.S. 370, 116 S. Ct. 1384, 134 L. Ed. 2d 577 (1996).
When performing claim construction, the court should first "look to the intrinsic evidence of the record, i.e., the patent itself, including the claims, the specification, and if in evidence, the prosecution history." CVI/Beta Ventures, Inc. v. Tura LP, 112 F.3d 1146, 1152 (Fed.Cir. 1997) (quoting Vitronics, 90 F.3d at 1582). Such intrinsic evidence is the most significant source of the meaning of disputed claim language. Vitronics, 90 F.3d at 1582. Extrinsic evidence, such as expert testimony, inventor testimony, dictionaries, and technical treatises, should not be relied upon unless an analysis of the intrinsic evidence alone will not resolve all the ambiguity in a disputed claim term. Id. at 1583-84.
The court must first look to the words of the claims themselves to define the scope of the patent. Id. at 1582; Markman, 52 F.3d at 979. "Although words in a claim are generally given their ordinary and customary meaning, a patentee may choose to be his own lexicographer and use terms in a manner other than their ordinary meaning, as long as the special definition of the term is clearly stated in the patent specification or file history." Vitronics, 90 F.3d at 1582. The focus in construing disputed terms is "on the objective test of what one of ordinary skill in the art at the time of the invention would have understood the term to mean." Solomon v. Kimberly-Clark Corp., 216 F.3d 1372, 1380 (2000); see also Hoechst Celanese Corp. v. BP Chems. Ltd., 78 F.3d 1575, 1578 (Fed.Cir.1996) ("A technical term used in a patent document is interpreted as having the meaning it would be given by persons experienced in the field of the invention, unless it is apparent from the patent and the prosecution history that the inventor used the term with a different meaning.") (citations omitted).
The specification also plays an important role in claim construction. "It is always necessary to review the specification to determine whether the inventor has used any terms in a manner inconsistent with their ordinary meaning." Vitronics, 90 F.3d at 1582. "The specification acts as a dictionary when it expressly defines terms used in the claims or when it defines terms by implication." Id.; Markman, 52 F.3d at 979 ("For claim construction purposes, the specification may act as a sort of dictionary, which explains the invention and may define terms used in the claims."). "`[C]laims must be read in view of the specification of which they are a part.'" Vitronics, 90 F.3d at 1582 (citation omitted); Netword LLC v. Centraal Corp., 242 F.3d 1347, 1352 (Fed.Cir.2001) ("The claims are directed to the invention that is described in the specification; they do not have meaning removed from the context in which they arose."). "Thus, the specification is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term." Vitronics, 90 F.3d at 1582.
Next, the court may also consider the prosecution history of the patent. Id. "This history contains the complete record of all the proceedings before the Patent and Trademark Office, including any express representations made by the applicant regarding the scope of the claims. As such, the record before the Patent and Trademark Office is often of critical significance in determining the meaning of claims." Id.; see also Southwall Technologies, Inc. v. Cardinal IG Co., 54 F.3d 1570, 1576 (Fed.Cir.1995). The court may also examine the prior art cited within the file history to obtain a general *1282 idea of what the claims do not cover. See Vitronics, 90 F.3d at 1583.
A court may consider extrinsic evidence for background and education on the technology, but such evidence "may not be used to vary or contradict the claim language." Interactive Gift Express, Inc. v. Compuserve Inc., 231 F.3d 859, 865 (Fed.Cir.2000). "[I]f the meaning of a disputed claim term is clear from the intrinsic evidence-the written record-that meaning, and no other, must prevail; it cannot be altered or superseded by witness testimony or other external sources simply because one of the parties wishes it were otherwise." Key Pharmaceuticals v. Hercon Laboratories Corp., 161 F.3d 709, 716 (Fed.Cir.1998).
With these guidelines in mind, the court now turns to the construction of the disputed issues and terms in the claims of the '593 Patent.
B. Order of Steps in Claims 1 and 8
The parties dispute whether the steps detailed in claims 1 and 8 must occur in the order listed in the claim. The disagreement arises in the context of how the software operates. Specifically, the parties dispute whether the "setting said boot selection flag" step must occur before the "booting normally" step in both claims. Symantec argues that the "setting" step must occur after the "testing" step and before the "booting normally" step, whereas Altiris claims that the "setting" step can occur before, after, simultaneously with, or between any of the other steps.
Altiris asserts the plain language of claims 1 and 8 does not impose any conditions on the sequence in which the "setting" step must be performed and that generally there is a presumption that method steps do not need to be performed in the listed order unless the claim specifically provides for such, citing Interactive Gift Express, Inc. v. Compuserve Inc., 231 F.3d 859, 875 (Fed.Cir.2000). Symantec disputes that Interactive Gift established any such presumption and claims that based on the plain language of claims 1 and 8 and a review of the specification, one of ordinary skill in the field of the invention would assume that the steps must be performed in the order in which they appear.
The Interactive Gift court stated: "Unless the steps of a method actually recite an order, the steps are not ordinarily construed to require one. However, such a result can ensue when the method steps implicitly require that they be performed in the order written. In this case, nothing in the claim or the specification directly or implicitly requires such a narrow construction." 231 F.3d at 875-76. In construing claims 1 and 8, therefore, this court must determine whether the claim language or specification directs or logically implies a sequential order of the method steps. See id.; Mantech Envtl. Corp. v. Hudson Envtl. Serv., 152 F.3d 1368, 1376 (Fed.Cir. 1998) ("[T]he sequential nature of the claim steps is apparent from the plain meaning of the claim language and nothing in the specification suggests otherwise.")
Although the setting step does not contain conditional language like the other steps in claims 1 and 8, the lack of conditional language only demonstrates that the step must always be performed, whether the testing automatically step indicates an automation boot or a normal boot. The claim language itself states that it is a method for gaining control of a computer prior to the normal boot sequence. Therefore, although the claim language does not specifically state that the method steps must be performed in order, the preamble suggests that the steps occur before the normal boot process.
In addition, a review of the specification consistently indicates that the "setting" *1283 step must precede the "booting normally" step. The specification specifically provides:
Before booting the "normal" operating system, the MBR code resets the special flag so that the next time the computer boots it will be directed to again boot from the automation partition. In this manner, the automation partition always gains control before the "normal" operating system, thus providing a method of controlling the computer system before it boots "normally."
U.S. Patent No. 5,764,593 ("`593 Patent") at col. 4, lines 40-46. The specification also states that the boot selection flag is set to "ensure that the next boot should go through the automation partition." Id. at col. 6, lines 40-43. This language indicates, consistent with the claim language, that the intention of the invention is to gain control of the computer before the computer's normal boot process and setting the boot selection flag before booting normally is what allows the computer to gain control the next time the computer is booted. If the "setting" step occurred after the "booting normally" step, the claimed invention would not be in control of the computer when the step occurred. The claim language clearly intends for the method steps to occur while the technology is in control of the computer.
Nothing in the claim language, specification, patent figures, or source code submitted with the patent indicates that the "setting" step could occur after the "booting normally" step. Furthermore, a person of ordinary skill in the field of the invention would not learn anything from the claim language, specification, figures, or source code of Patent `593 that would enable them to place the "setting" step at the same time or after the "booting normally" step. See Hoganas AB v. Dresser Indus., 9 F.3d 948, 951 (Fed.Cir.1993) (noting that the function of claims is "putting competitors on notice of the scope of the claimed invention"). Therefore, this court concludes that the "setting" step must occur after the "testing automatically" step and before the "booting normally" step.
C. Preambles of Claims 1 and 8
The parties dispute whether the preambles of claims 1 and 8 should be construed as part of the claim or constitute a limitation of the claim. If "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." Pitney Bowes Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1305 (Fed.Cir.1999). However, "if the claim preamble, when read in the context of the entire claim, recites limitations to 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." Id. "Whether a preamble stating the purpose and context of the invention constitutes a limitation of the claimed process is determined on the facts of each case in light of the overall form of the claim, and the invention as described in the specification and illuminated in the prosecution history." Applied Materials, Inc. v. Advanced Semiconductor Materials America, Inc., 98 F.3d 1563, 1572-73 (Fed. Cir.1996); see also Bell Communications Research, Inc. v. Vitalink Communications Corp., 55 F.3d 615, 621 (Fed.Cir. 1995) ("We have long eschewed the use of an absolute rule according or denying all preambles limiting effect, having recognized that one cannot determine a preamble's effect except by reference to the specific claim of which it is a component.").
*1284 The preamble in claim 1 states: "a method for gaining control of a computer prior to the normal boot sequence operating on a digital computer system." The preamble in claim 8 states: "a digital computer system programmed to perform the method of gaining control of the boot procedure of a digital computer." Altiris asserts that the preamble language merely summarizes the steps of the claimed methods, whereas Symantec claims that the preamble language is necessary for a complete understanding of the claimed invention.
1. Claim 1
With respect to claim 1, the dispute focuses on whether the preamble's use of the terms "gaining control ... prior to the normal boot sequence" contains anything in addition to any of the claim language and whether it serves to limit the scope of the claim. The language provides information about when the method steps are to be performed in accordance with the invention that is not otherwise described in the method steps of the claim. The fact that the claimed invention requires the interception of a computer's boot sequence, followed by an automation boot sequence, before a normal boot sequence is allowed to take place is only apparent from reading the preamble in conjunction with the method steps. The language in the preamble is the only clear indication in the claim itself that the method steps listed before the "booting normally" step must actually be performed prior to the "booting normally" step.
Although the specification states that the technology interrupts, modifies or controls the normal boot process, the specification always states that such interruption, modification, or control happens prior to the normal boot process. In the claim itself, only the preamble states that the method steps must occur before the computer boots normally. Because it is necessary to consider both the preamble and the body of the claim in order to define the complete invention as disclosed in the specifications, including all the limitations, the preamble is necessary to give life and meaning to the claim. Therefore, this court concludes that the preamble must be construed as part of the patent.
In order to determine whether the phrase "gaining control ... prior to the normal boot sequence" is a limitation to the claim, it is necessary to understand the sequence a computer goes through during the booting process. The boot sequence entails the following steps: 1) the computer is turned on; 2) the BIOS code stored in the computers read only memory is executed, 3) the standard boot loader is loaded and executed, and 4) the operating system is loaded and executed.
In the '593 Patent the specification defines the "normal boot sequence" as "the sequence of booting events that the computer would go through in the absence of this invention." '593 Patent, at col. 4, lines 49-50. Both parties agree that the normal boot sequence customarily begins when the computer turns on and that the preamble's language cannot be construed to mean that the technology gains control of the computer before the computer is turned on. Because the literal claim language is illogical, it is necessary to turn to the specification in order to construe the meaning of the language.
The embodiment of the invention in the specification gains control of the computer by replacing the standard boot loader in the MBR with customized boot loader code. The specification clarifies that the technology gains control "during system boot" rather than before. '593 Patent, at col.3, lines 63-64. The specification states that the customized MBR code "is used, during system boot, to force a transfer of control to the programming in the automation *1285 partition. At this point, a determination is made regarding the automation commands to be executed by the computer." Id. at lines 63-67. Therefore, the patent uses the phase "normal boot sequence" to refer to the operation of the standard boot loader and the loading of an operating system. Therefore, the phrase "gaining control of a computer prior to the normal boot sequence" refers to the act of interrupting the computer's boot sequence during system boot and causing the computer to execute instructions before the standard boot loader or an operating system is loaded and executed.
2. Claim 8
With respect to claim 8, the preamble does not contain the language "prior to" or "normal boot sequence," but only states "gaining control of the boot procedure." Therefore, in contrast to claim 1, it does not contain language that gives life or meaning to the claim as a whole. Therefore, this court declines to construe the preamble of Claim 8 as part of the claim. See Pitney Bowes, 182 F.3d at 1305.
D. Construction of Certain Claim Terms
1. "Boot Selection Flag" and "Automation Boot Sequence Data"
The first method step of claim 1 is "testing for automation boot sequence data, said test including reading a boot selection flag and comparing said boot selection flag with a known flag setting." (Emphasis added.) The phrase "boot selection flag" is also contained in claim 8's first method step, which provides: "testing automatically for source of said means of booting; said testing including reading a boot selection flag and comparing said boot selection flag with a known flag setting." (Emphasis added.)
Symantec argues that the terms "boot selection flag" and "automatic boot sequence data" do not have plain meanings in the art and, therefore, must be defined by reference to the patent specification. Altiris attempts to define the phrases by using computer industry dictionaries to define each of the words. Altiris argues that although those phrases as a whole are not commonly used, the individual words are familiar in the industry, and, thus, the phrases would not be unclear to one of ordinary skill in the field given the full context of the patent in which they are used. Symantec contends that the patent does not teach anything more than what is disclosed in the specification and the construction of these phrases should be limited to the disclosed embodiment in the specification. Altiris denies that the inventors acted as their own "lexicographers" and the phrases should not be limited to the embodiment in the patent specification.
Although each of the individual words have meanings that may be commonly understood in the computer industry, the claims' combination of familiar terms into unfamiliar or unique phrases does not necessary make the phrase commonly understood.
a.) Boot Selection Flag
The parties dispute as to the meaning of the phrase "boot selection flag" centers around whether the phrase "boot selection flag" encompasses several different values in the partition table or is limited to the system ID byte of the first partition. The method step provides for the test to determine an automation or normal boot sequence to read a boot selection flag and comparing it with a known flag setting. "Boot selection flag" is not a phrase commonly used in the computer industry. However, in the embodiment of *1286 the invention in the specification the system ID byte is used as the boot selection flag.
Symantec relies on the claim language's use of the singular form of flag to assert that the boot selection flag must be one value. On the other hand, Altiris claims that a flag is commonly known as one or more bits of data used as a signal. Therefore the claim language's use of the singular form for "boot selection flag" could still be consistent with an interpretation that the "boot selection flag" is several values in the partition table. Because both interpretations are possible from the language used in the claim, this court must refer to the specification for guidance.
Symantec relies on the fact that the system ID byte of the first partition is used in the embodiment to assert that such a limitation would be consistent with the claim's use of the singular form for "boot selection flag" and should be imposed on the claim. Symantec also claims that nothing in the specification indicates that the "boot selection flag" was intended to encompass anything else. Altiris argues that the patent specification explicitly discloses that other entries in the partition table can be used as a boot selection flag. Altiris relies upon language from two places in the specification stating: "The customized MBR code examines the partition table flags (a small database contained within the MBR which specifies the location and type of partitions on the disk) to determine which of the four partitions to load and execute;" and "The custom MBR code examines the flags in the partition table to determine which partition is to be loaded and executed. This step of the process of the invention is a test of whether an automation boot or normal boot should be implemented." '593 Patent at col. 4, lines 7-10; col. 6, lines 1-5. Altiris claims that this language supports its position that the boot selection flag can be the collection of the bootable/non-bootable entries in the partition table that indicate what boot sequence will occur (referred to as bootable flags).
However, the specification also refers several times to a "special flag" in the singular. The specification states that "when the MBR code again gains control, it recognizes the special flag and causes the `normal' operating system to boot. Before booting the `normal' operating system, the MBR code resets the special flag, so that next time the computer boots, it will be directed to again boot from the automation partition." Id. at col. 4, lines 39-43.
Although it appears that the specification refers to both flags and a flag, this court concludes that because the singular form of flag is used in both the claim and the specification and the embodiment in the specification uses single value of the system ID byte of the first partition as the boot selection flag, the claim should be limited to the singular boot selection flag identified in the embodiment. See Wang Labs., Inc. v. America Online, Inc., 197 F.3d 1377, 1381-83 (Fed.Cir.1999) (limiting term to system used in the specification because it was the "only system that is described and enabled in the specification and drawings"); Toro Co. v. White Consol. Indus., Inc., 199 F.3d 1295, 1301-02 (Fed. Cir.1999) (limiting term to its consistent description in the sole embodiment). The patent does not give a clear indication that anything other than the system ID byte could be used as the boot selection flag. The portions of the specification relied on by Altiris do not constitute additional embodiments of the invention and the patent does not teach one of ordinary skill in the art to use anything other than the system ID byte. Therefore, defining the boot selection flag as a collection of the bootable/non-bootable entries in the partition *1287 table is too broad. Reviewing this phrase in the full context of the patent, this court concludes that the phrase "boot selection flag" should be construed to mean the system ID byte of the first partition.
b.) Automation Boot Sequence Data
The first method step of claim 1 provides that the technology will test for "automation boot sequence data" by examining a boot selection flag. Altiris claims that "automation boot sequence data" is data or computer code from which the computer can be booted up that is separate from the "normal" boot sequence data. Symantec claims that the plain language of the claim suggests that the "automation boot sequence data" must be a particular "known value" of the boot selection flag. The phrase "automation boot sequence data" does not have a customary meaning in the art. As a result of the parties' competing interpretations of the phrase, it would generally be useful to review the specification, however, the phrase "automation boot sequence" does not appear in the specification.
Altiris concludes that because the testing for "automation boot sequence data" is a test for whether an "automation boot" will be implemented instead of a "normal boot," that data is the data or code that will be used to implement the automation boot sequence. However, reviewing the claim language in the context of the entire claim indicates that the "automation boot sequence data" cannot be the automation data or code itself, but something that indicates that the computer should boot in automation mode. Therefore, the court concludes that the proper construction of the phrase "automation boot sequence data" is a particular value assigned to the system ID byte of the first partition which indicates to the custom boot loader that the computer should boot in automation mode.
2. "Automation Code" in Claim 1
The second step of claim 1 requires the "transferring of said computer system to automation code." (Emphasis added.) Similar to the other disputed terms, Symantec argues that this term does not have a clear meaning in the software industry and must be construed by reference to the specification. Symantec claims that according to the specification, the automation code clearly consists of a common operating system, Local Area Network drivers for the Network Interface Card and a program for reading a database on the network server to ascertain the automation commands to be executed.
Altiris rejects Symantec's limitation of "automation code" and argues that the claim language defines "automation code" as any booting code separate from the normal booting code. Altiris further asserts that the specification does not ever expressly "define" automation code in the manner Symantec asserts and, in fact, confirms its interpretation of the claim language by referring to computer code in the automation partition as code from which the computer is "booted up" separate from the "normal" booting. See '593 Patent at col. 6, lines 1-9, 19-21, 47-50, 55-56, 59-61; col. 4, lines 37-41.
The specification provides that "[t]he Installation Utility creates an automation partition on the hard disk populated with a common operating system (such as PC DOS), Local Area Network (LAN) drivers for the Network Interface Card (NIC), and a program for reading a database on the network server to ascertain the automation commands to be executed." Id at col. 3, lines 50-55. The specification also explains that if the testing step indicates that an automation boot should occur, "then the MBR code finds the automation partition on the hard disk, transfers control *1288 of the boot process to the code in the automation partition, which then loads the computer operating system. When the operating system has been loaded, the LAN drivers for the resident NIC are loaded, also from the automation partition, and a connection is established across the network to the network server." Id. at col. 6, lines 6-13.
This court concludes that because this phrase is not commonly used in the industry and the claim language is not clear, the phrase should be construed according to what an ordinary person in the field would understand the phrase to mean based upon the information and embodiment contained in the claim specification. This court concludes that "automation code" means the code in the automation partition which loads an operating system, LAN drivers for the resident NIC, and a program for reading a database on the network server to ascertain the automation commands to be executed.
3. Means-Plus-Function Limitations
Symantec argues that the claim language "means for booting" in the fourth method step of claim 8 and "means for connecting" in the third method step of claim 1 are means-plus-function limitations that must be construed pursuant to 35 U.S.C. Section 112, Paragraph 6 and limited to the software components disclosed in the specification for performing the function. An element is construed under Section 112, Paragraph 6 when it recites a means for performing a function without setting forth sufficient structure for performing that function. See IMS Technology, Inc. v. Haas Automation, Inc., 206 F.3d 1422, 1432 (Fed.Cir.2000); Rodime PLC v. Seagate Tech., Inc., 174 F.3d 1294, 1302 (Fed.Cir.1999). "[W]here a claim recites a function, but then goes on to elaborate sufficient structure, material, or acts within the claim itself to perform entirely the recited function, the claim is not in means-plus-function format." Sage Prods., Inc. v. Devon Indus., Inc., 126 F.3d 1420, 1427-28 (Fed.Cir.1997).
To construe a means-plus-function claim element, the court must first identify the "function." Chiuminatta Concrete Concepts, Inc. v. Cardinal Indus., Inc., 145 F.3d 1303, 1308 (Fed.Cir.1998). Then, for construing the "means" portion, the court must identify the "corresponding structure, material, or acts described in the specification and equivalents thereof." 35 U.S.C. § 112, ¶ 6.
The parties' dispute focuses on whether there is sufficient structure identified to explain how the function is to be performed.
a.) Means for Booting in Claim 8
The fourth step of claim 8 states: "a means of booting said digital computer, said means of booting including a first set of commands, said first set of commands resident on said storage device of said digital computer for booting said digital computer, and a second set of commands resident on a storage devise external to said digital computer for booting said digital computer." The function in this claim element is clearly the process of booting. However, the language referring to two sets of commands states only the location of the commands and is insufficient to define the structure that performs the function of booting. Therefore, the means must be limited to the corresponding structure and equivalents disclosed in the specification that perform the booting process.
The structure in the specification corresponding to the means of booting are software programs for booting. Therefore, the court construes the first set of commands to include the normal operating system on the computer and the customized *1289 MBR or equivalent, two operating systems, and communications software. The court construes the second set of commands to include batch files, commands, or instructions on the server.
b.) Means for Connecting
The third step of claim 1 provides: "means for connecting said digital computer to an external source of commands." Although Altiris concedes that this is written in means-plus-function form and that the structure for performing this function must come from the specification, which provides for a NIC and computer network, Symantec argues that Altiris improperly attempts to impose an additional limitation on this corresponding structure by asserting that the NIC must be a standard or common NIC that does not include a boot ROM. Symantec argues that although the specification characterizes the parts of the computer as "common hardware components," that description does not exclude NICs with boot ROMs because boot ROMs can be bought off the shelf. This court concludes that a boot ROM is not a common hardware component as contemplated by the specification language.
4. "Accessing" in Claim 4 and "Searching" in Claim 5
The parties also dispute whether the "accessing" step in Claim 4 and the "searching" step in claim 5 must occur on the individual client computer or can also occur on the network server. Dependent claim 4 includes a step of "accessing a set of externally stored commands" and is part of claim 1's step of "executing a control process for said means for connecting said digital computer to an external source of commands." Dependent claim 5 includes a step of "searching for valid commands" and is part of claim 1's step of "performing said external commands." Symantec argues that these steps must be performed by the individual client computer, whereas Altiris claims that such steps could be performed by either the server or client computer.
Symantec argues that the use of the language "externally stored commands" in claim 4 logically implies that the step is performed by the individual client computer because the commands are stored on the server and, thus, only "external" to the client computer. Altiris argues that the ordinary meaning of the word "access" is "to communicate with" and "to get at; gain access to," and in a computer sense this includes "connection to other network or system" and "act of reading data from ... memory." Altiris contends that because the purpose of accessing commands is to allow the computer to perform such commands, the plain meaning of accessing is that the computer implements a communication process through which the computer receives and can make use of commands. Therefore, nothing in the language limits the client computer from requesting the server computer to find any commands and send them to the client computer. However, the court concludes that even under Altiris' interpretation the client computer's request to the server to find commands would constitute accessing a set of externally stored commands on the part of the client computer.
Symantec claims that because claim 5's "searching for valid commands" is a part of claim 1's step of "performing external commands," the same logic limiting claim 4 to being performed by the client computer would also limit this claim. Altiris claims that the act of "searching" for external commands in claim 5 does not have to be performed on the client computer because the meaning of search is to examine, uncover or find and such searching can be done by the server at the request of the client computer.
*1290 Symantec claims that the specification further supports its interpretation of these claims because the only embodiment in the specification demonstrates an approach initiated and performed by the client computer. Because there is no disclosure of a system in which the server computer searches for or accesses commands, Symantec asserts that the steps should be limited to what is disclosed in the specification. In contrast, Altiris argues that the specification demonstrates that this step could occur on the server computer when it states that the method is "performed by one or more software programs, which reside on the networked personal computer and/or the server computer." '593 Patent at col. 8, lines 6-8.
The specification describes the client computer running a program called the Bootwork routine. The Bootwork routine program is located on a partition of the hard disk of the client computer. It is the Bootwork routine program that examines a database on the network server to determine whether the network has any specified automation commands to execute and then accesses and executes the batch commands stored on the server computer. See '593 Patent at col. 3, lines 50-55; col. 4, lines 13-27.
This court concludes that the claim language logically provides for the steps in claims 4 and 5 to be performed on the client computer and the specification clearly limits its discussion of how those steps are accomplished to performance on the client computer. Although the specification states that the method steps could be performed by software contained on the client or server computer, this reference is not made in the context of the Bootwork routine program. Therefore, this mention of software contained on the server computer does not constitute additional embodiments of the invention and does not give notice to someone of ordinary skill in the art that such steps could occur on the server computer. Therefore, the court finds that the proper construction of claims 4 and 5 is that they be limited to performance by the client computer.
E. Claims 3 and 12
Symantec claims that dependent claims 3 and 12 cannot be construed because they are fatally vague. Dependent claim 3 is "resetting said digital computer system to a known state" and dependent claim 12 is "initializing said digital computer system to a known initial state."
Symantec argues that these claims do not have a clear meaning in the art, are not defined in the specification in a way that would enable one of ordinary skill in the art to implement them, and their meaning and role in the patent are not commonly understood by the three inventors. Accordingly, it asserts that the phrase is fatally vague and cannot be construed.
Altiris asserts that "resetting" and "state" in Claim 3 indicates that there must be an additional step in which the computer is placed into, or returned to, a known or specified state, condition, stage, mode, or situation. The specification supports Altiris' plain language interpretation when it discusses such examples as placing the computer in another state by causing a "reboot" of the computer after the automation commands have been performed and placing the computer back in a normal mode by setting the boot selection flag to the "normal" setting.
Altiris also recognizes that claim 12 is very similar to claim 3 except for the differences between the terms "resetting" *1291 and "initializing." Altiris relies on a dictionary definition to define "initializing" as "to prepare for use" or "to start up a computer" and "initialization" as "the operations required for setting a device to a starting state" or "preparation of a system, device, or program for operation." Therefore, Altiris asserts that the plain meaning of claim 12 is placing the computer into a known or specified state, condition, stage, mode or situation that the computer is in when it is at or near the beginning of its starting up or booting up stage.
The specification supports Altiris' plain language interpretation of claim 12 when it discusses placing the computer at its initial state or stage by causing a reboot of the computer after the automation commands have been performed, which thus initializes the computer.
Therefore, this court concludes that in the context of the entire patent claims 3 and 12 are not indefinitely vague and are properly construed in the manner proposed by Altiris.
CONCLUSION
Having relied on the claims themselves and the specification, and extrinsic evidence for a general understanding of the patent, the claims of the '593 Patent is construed by the court as set forth above.
