Summary
holding that the presumption against means-plus-function treatment was not overcome as to claims reciting “computer readable program code configured to cause a computer to”
Summary of this case from Smartflash LLC v. Apple Inc.Opinion
CIVIL ACTION NO. 2:06-CV-358.
August 19, 2008
MEMORANDUM OPINION AND ORDER
After considering the submissions and the arguments of counsel, the court issues the following order concerning the claim construction issues:
I. Introduction
II. Background of the Technology
Versata's suit against SAP is Versata Software, Inc., et al. v. SAP America, Inc. and SAP, AG (2:07-cv-153-CE), whereas its suit against Sun is Versata Software, Inc., et al. v. Sun Microsystems, Inc. (2:06-cv-358). These actions were consolidated for claim construction purposes with respect the Versata patents, only.
The `524 patent is not asserted against SAP.
The Versata patents are directed to a computer-based configuration system. The abstract of the patents states:
The present invention employs a generative approach for configuring systems such that a system may be configured based on component or resource requests, or input in the form of need. The present invention provides a constraint-based configuration system using a structural model hierarchy. The structural aspects of the model provide the ability to define a model element as being contained in, or by, another model element. In addition, the structural model provides the ability to identify logical datatype and physical interconnections between elements and establish connections between elements. To configure a system, the present invention accepts input in the form of requests (e.g., component or resource) or needs, such as an expression of a need for a desktop computer system to be used in a CAD (i.e., computer-aided design) environment. Using this information, the present invention configures a system by identifying the resource and component needs, constraints imposed on or by the resources or components identified, and the structural aspects of the system.
`524 Patent at Abstract.
III. General Principles Governing Claim Construction
"A claim in a patent provides the metes and bounds of the right which the patent confers on the patentee to exclude others from making, using or selling the protected invention." Burke, Inc. v. Bruno Indep. Living Aids, Inc., 183 F.3d 1334, 1340 (Fed. Cir. 1999). Claim construction is an issue of law for the court to decide. Markman v. Westview Instruments, Inc., 52 F.3d 967, 970-71 (Fed. Cir. 1995) (en banc), aff'd, 517 U.S. 370 (1996).
To ascertain the meaning of claims, the court looks to three primary sources: the claims, the specification, and the prosecution history. Markman, 52 F.3d at 979. Under the patent law, the specification must contain a written description of the invention that enables one of ordinary skill in the art to make and use the invention. A patent's claims must be read in view of the specification, of which they are a part. Id. For claim construction purposes, the description may act as a sort of dictionary, which explains the invention and may define terms used in the claims. Id. "One purpose for examining the specification is to determine if the patentee has limited the scope of the claims." Watts v. XL Sys., Inc., 232 F.3d 877, 882 (Fed. Cir. 2000).
Nonetheless, it is the function of the claims, not the specification, to set forth the limits of the patentee's claims. Otherwise, there would be no need for claims. SRI Int'l v. Matsushita Elec. Corp., 775 F.2d 1107, 1121 (Fed. Cir. 1985) (en banc). The patentee is free to be his own lexicographer, but any special definition given to a word must be clearly set forth in the specification. Intellicall, Inc. v. Phonometrics, 952 F.2d 1384, 1388 (Fed. Cir. 1992). And, although the specification may indicate that certain embodiments are preferred, particular embodiments appearing in the specification will not be read into the claims when the claim language is broader than the embodiments. Electro Med. Sys., S.A. v. Cooper Life Sciences, Inc., 34 F.3d 1048, 1054 (Fed. Cir. 1994).
This court's claim construction decision must be informed by the Federal Circuit's decision in Phillips v. A WH Corporation, 415 F.3d 1303 (Fed. Cir. 2005) (en banc). In Phillips, the court set forth several guideposts that courts should follow when construing claims. In particular, the court reiterated that "the claims of a patent define the invention to which the patentee is entitled the right to exclude." 415 F.3d at 1312 (emphasis added) ( quoting Innova/Pure Water, Inc. v. Safari Water Filtration Systems, Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). To that end, the words used in a claim are generally given their ordinary and customary meaning. Id. The ordinary and customary meaning of a claim term "is the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention, i.e., as of the effective filing date of the patent application." Id. at 1313. This principle of patent law flows naturally from the recognition that inventors are usually persons who are skilled in the field of the invention. The patent is addressed to and intended to be read by others skilled in the particular art. Id.
The primacy of claim terms notwithstanding, Phillips made clear that "the person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification." Id. Although the claims themselves may provide guidance as to the meaning of particular terms, those terms are part of "a fully integrated written instrument." Id. at 1315 ( quoting Markman, 52 F.3d at 978). Thus, the Phillips court emphasized the specification as being the primary basis for construing the claims. Id. at 13-14-17. As the Supreme Court stated long ago, "in case of doubt or ambiguity it is proper in all cases to refer back to the descriptive portions of the specification to aid in solving the doubt or in ascertaining the true intent and meaning of the language employed in the claims." Bates v. Coe, 98 U.S. 31, 38 (1878). In addressing the role of the specification, the Phillips court quoted with approval its earlier observations from Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998):
Ultimately, the interpretation to be given a term can only be determined and confirmed with a full understanding of what the inventors actually invented and intended to envelop with the claim. The construction that stays true to the claim language and most naturally aligns with the patent's description of the invention will be, in the end, the correct construction.
Consequently, Phillips emphasized the important role the specification plays in the claim construction process.
The prosecution history also continues to play an important role in claim interpretation. The prosecution history helps to demonstrate how the inventor and the PTO understood the patent. Phillips, 415 F.3d at 1317. Because the file history, however, "represents an ongoing negotiation between the PTO and the applicant," it may lack the clarity of the specification and thus be less useful in claim construction proceedings. Id. Nevertheless, the prosecution history is intrinsic evidence. That evidence is relevant to the determination of how the inventor understood the invention and whether the inventor limited the invention during prosecution by narrowing the scope of the claims.
Phillips rejected any claim construction approach that sacrificed the intrinsic record in favor of extrinsic evidence, such as dictionary definitions or expert testimony. The en banc court condemned the suggestion made by Texas Digital Systems, Inc. v. Telegenix, Inc., 308 F.3d 1193 (Fed. Cir. 2002), that a court should discern the ordinary meaning of the claim terms (through dictionaries or otherwise) before resorting to the specification for certain limited purposes. Id. at 1319-24. The approach suggested by Texas Digital — the assignment of a limited role to the specification — was rejected as inconsistent with decisions holding the specification to be the best guide to the meaning of a disputed term. Id. at 1320-21. According to Phillips, reliance on dictionary definitions at the expense of the specification had the effect of "focus[ing] the inquiry on the abstract meaning of words rather than on the meaning of the claim terms within the context of the patent." Id. at 1321. Phillips emphasized that the patent system is based on the proposition that the claims cover only the invented subject matter. Id. What is described in the claims flows from the statutory requirement imposed on the patentee to describe and particularly claim what he or she has invented. Id. The definitions found in dictionaries, however, often flow from the editors' objective of assembling all of the possible definitions for a word. Id. at 1321-22. Phillips does not preclude all uses of dictionaries in claim construction proceedings. Instead, the court assigned dictionaries a role subordinate to the intrinsic record. In doing so, the court emphasized that claim construction issues are not resolved by any magic formula. The court did not impose any particular sequence of steps for a court to follow when it considers disputed claim language. Id. at 1323-25. Rather, Phillips held that a court must attach the appropriate weight to the intrinsic sources offered in support of a proposed claim construction, bearing in mind the general rule that the claims measure the scope of the patent grant.
IV. Terms in Dispute
A. Agreed Constructions
The parties agree to the following constructions:
• " port(s)" means "a location(s) for interfacing or connecting one or more components;"
• " instantiating" means "creating;"
• " constraint" means "a restriction or requirement;"
• " constrained by" means "restricted by or required by;"
• " physical type" means "physical attributes;"
• " logical datatype"/" logical type" means "logical attributes;" and
• "transfer path" means "a route."
B. Disputed Constructions
1. "structural model hierarchy"
Plaintiffs propose "a representation of physical or spatial, and optionally logical, relationships of model elements with respect to other model elements." Defendants propose "a hierarchical representation of component, composite, container, port, and connector base classes, derived classes, and composite hierarchies, container hierarchies, and port relationship substructures."
Sun's proposal adds the parenthetical "(as in Figs. 3 4)."
The plaintiffs argue that the defendants' construction is incorrect because it would exclude a preferred embodiment. Specifically, the defendants' construction requires substructure relationships (i.e. composite, container, and port hierarchies) which are not present in the embodiment shown in Fig. 3. The plaintiffs further argue that the defendants' construction would render some of the claim terms superfluous. They point to claim 2 of the `798 patent which recites: "defining a structural model hierarchy comprised of composite and container hierarchies and port relationships substructures." `798 Patent at 30:14-16. If the term "structural model hierarchy" is construed to include the hierarchies and relationship substructures, the plaintiffs argue this would render this claim passage meaningless.
With respect to the plaintiffs' argument that the defendants' construction would render some of the claim language superfluous, the specification and prosecution history control this dispute notwithstanding the doctrine of claim differentiation. See Andersen Corp. v. Fiber Composites, LLC, 474 F.3d 1361, 1370 (Fed. Cir. 2007) ("the written description and prosecution history overcome any presumption arising from the doctrine of claim differentiation").
The defendants argue that the "specification defines the structural model hierarchy of the invention as having two core features." SAP's Resp. Br. at 14 (these features are the five intrinsic base classes and the three substructures). They cite numerous passages in the specification that contain the phrase "the present invention." See, e.g., '524 Patent at 6:54-60 ("In the present invention, a modeling language is used to define a model hierarchy. The model hierarchy is structural and functional. The modeling language provides the ability to define a Product Base that may be grouped into Product Lines. The structural hierarchy model includes the Component, Composite, Container, Port, and Connector base classes"); id. at 9:51-58 ("The Configuration System of the present invention is a constraint-based scheme using a functional, structural hierarchy. . . . The functional, structural hierarchy contains a class hierarchy comprised of five intrinsic base classes 70 that define the basic types of model objects. These five base classes are: Component 60, Composite 62, Connector 64, Container 66, and Port 68"); id. at 10:13-17 ("The present invention provides the ability to represent within a structural hierarchy how components of a particular system exists spatially and physically. Within the structural hierarchy, there are three type of substructures: composite hierarchies, container hierarchies, and port relationships").
The defendants further argue that the plaintiffs' construction conspicuously fails to address the term "hierarchy." According to the defendants, "Versata's definition relies on a single sentence observing what the structural model hierarchy does and ignores the plentiful language in the specification stating what a structural model hierarchy is." Sun's Resp. Br. at 11-12 (emphasis in original).
In addition to the specification, the prosecution history provides guidance as to the meaning of this term. During the prosecution of the `524 patent (which is the parent patent to the other patents-in-suit) the examiner rejected all pending claims in light of U.S. Patent No. 5,257,387 ("the Richek reference"). To overcome this rejection, the applicants made the following statements:
The configuration file [of Richek] is not a structural model hierarchy that defines base classes, derived classes, and composite hierarchy, container hierarchy, and port relationship substructures as is described in the present invention.
SAP's Resp. Br. at Ex. B, Doc. No. 6 (Dec. 14, 1994 Amendment) at 5, and
Further, the configuration file in Richek does not teach or suggest the use of a structural model hierarchy that defines base classes, derived classes, and composite hierarchy, container hierarchy, and port relationship substructures.Id. at 7.
In response to the defendants' arguments related to the prosecution history, the plaintiffs contend that the "ambiguous statements" made to overcome the Richek reference do not rise to the level of a clear and unambiguous disavowal of claim scope. Pls.' Reply Br. at 2. Rather, both the statements in the prosecution history and specification merely refer to a preferred embodiment and should not operate to limit the scope of the asserted claims. This argument is unpersuasive.
At the hearing, the plaintiffs argued that the statements made in response to the examiner's rejection in light of Richek were directed to only particular pending claims. The language of the applicants' response, however, does not support the plaintiffs' position.
For these reasons, the term "structural model hierarchy" means "a hierarchical representation of component, composite, container, port, and connector base classes, derived classes, and composite hierarchies, container hierarchies, and port relationship substructures."
2. "composite hierarchies"/ "composite hierarchies substructure"/ "composite hierarchy substructure"/ "composite hierarchy"
Plaintiffs propose "a representation that identifies components as part of other components." Sun agrees with the plaintiffs. SAP proposes "hierarchical relationships expressed (such as by a keyword) between two components, which identify one component as part of another component that is descended from the composite base class."
SAP argues that the plaintiffs' construction, with which Sun agrees, does not adequately describe that the structural relationships "must be `expressed' by the model." SAP's Resp. Br. at 16. To support this position, SAP relies on the discussion of structural hierarchy. See '524 Patent at 10:13-39. In particular, SAP highlights the passage that discloses "[t]he relationships between generations within these substructures are expressed by the keywords `childOf,' `containedBy,' and `connectsWith.'" Id.
The plaintiffs argue that SAP's proposed construction is an "attempt to impose extraneous structure and functional limitations from the preferred embodiment." Pls.' Opening Br. at 7. Sun also argues that SAP's constructions are "unnecessarily complicated since they contain extraneous limitations not required by the intrinsic record." Sun's Resp. Br. at 14. Specifically, they point out that SAP's construction looks to the portions of the specification that teach how these substructures can be expressed by the various keywords described, such as childOf, containedBy, connectsWith. See '524 Patent at 10:30-36.
SAP responds that the keyword argument is a red herring because SAP's inclusion of the phrase "such as by a keyword" in its construction does not require the use of keywords to express these structural relationships. Rather, SAP contends the issue it that the plaintiffs' proposal does not require that these relationships be expressed at all.
The plaintiffs and Sun correctly characterize this as an attempt to read unnecessary limitations from the preferred embodiment into the claims. See id. at 10:30-36 (describing how these substructures are expressed using the modeling language of a preferred embodiment). The specification teaches that "[c]omposite hierarchies identify components as part of other components." `524 Patent 10:18-19. Nothing more is required of these terms. Therefore, these terms mean "a representation that identifies components as part of other components." 3. "container hierarchies"/ "container hierarchies substructure"/ "container hierarchy substructure"/ "container hierarchy"
Plaintiffs propose "a representation that identifies components as being contained in other components." Sun agrees with the plaintiffs. SAP proposes "hierarchical relationships expressed (such as by a keyword) between two components, which identify one component as physically housed within another component that is descended from the container base class."
The parties briefed this term with "composite hierarchies," etc. above. The reasoning provided for "composite hierarchies," etc. applies equally here. For example, the specification teaches that "[c]ontainer hierarchies identify components as being contained in other components." `524 Patent at 10:20-21. Therefore, these terms mean "a representation that identifies components as being contained in other components."
4. "port relationship(s)"/ "port relationship(s) substructure"/ "connection hierarchy"
Plaintiffs propose "a representation that identifies components that connect to other components." Sun agrees with the plaintiffs. SAP proposes "hierarchical relationships expressed (such as by a keyword) between two components, which identify one component as connecting to another component that is descended from the port base class."
The parties briefed this term with "composite hierarchies," etc. above. The reasoning provided for "composite hierarchies," etc. applies equally here. For example, the specification teaches that "[p]ort relationships identify components that connect to other components" `524 Patent at 10:24-25. Therefore, these terms mean "a representation that identifies components that connect to other components."
5. "class"
Plaintiffs propose "a category that describes a group of more specific items it contains." SAP proposes "a named set of elements each of which is said to be of the class's named type, which may branch into derived classes and terminate at leaf descendants, such that each derived class and leaf descendant has the properties of the class from which it derived or descended." Sun proposes "a group defined by common properties, operations, and behavior from which subgroups and elements derive and inherit those common properties, operations, and behavior."
The main dispute between the parties is whether this term must include the concepts of inheritance and derivation. Both SAP and Sun argue for a construction which incorporates the concept that "[o]bjects can inherit properties from other objects. That is, one class of objects acts as the parent of another class, and the child class exhibits all of the properties of the parent class in addition to others." `524 Patent at 38-41.
As an initial matter, the specification uses the permissive term `can' in describing an object inheriting properties from other objects. Id. at 15:38; see also id. at 15:59-61 ("[a]ttributes can be assigned at the class level, and descendants of that class inherit the class attributes"); id. at 6:60-62 (from the Summary of the Invention: "[t]hese base classes may branch into derived classes (i.e., system-specific classes) and terminate at leaf-descendants"); id. at 9:65-66 ("[m]ultiple generations of derived classes can descend from the base classes"). The defendants' constructions are not permissive, but rather would exclude from the term "class" a grouping of objects that may share common properties but were not derived from the class. In a way, the defendants would impose a one-way limitation that a grouping of objects can only constitute a class if those objects were derived from that class. The specification does not support this: "[A] property categorizes an object. That is, objects with similar properties are called a class of objects." `524 Patent at 15:36-37.
SAP's construction overly restricts the term `class.' Its proposed construction improperly encompasses teaching from the specification related to "derived classes." Such a construction would improperly limit the term `class,' and render meaningless the additional modifiers used to describe classes, i.e. `derived,' `base,' etc.
The plaintiffs do not directly respond to Sun's proposed construction in either of its briefs. Rather, in a footnote, the plaintiffs note that "Sun's proposed construction is incomplete at best, because the specification does not refer to `operations' or `behavior.'" Pls.' Opening Br. at 8 n. 13. The plaintiffs are correct that the specification is silent to these terms, and Sun reaches to extrinsic evidence to support the inclusion of `operations' or `behavior.' The remainder of Sun's proposed construction, however, accurately captures the meaning of this term in light of the specification's teaching.
A class is something more narrow that the plaintiffs' construction of "a category that describes a group of more specific items it contains." See '524 Patent at 15:36-41. The plaintiffs' construction does not incorporate the specification's teaching that the items, or objects, contain within the class share common properties. It is not so narrow, however, as to not include a class which has no derivative subclasses or elements as a plain reading of Sun's construction would indicate.
Therefore, the term "class" means "a group defined by common properties from which subgroups and elements can derive and inherit those common properties."
6. "component base class"/ "component class"
Plaintiffs propose "a base class from which all other classes and component types are derived." SAP agrees with the plaintiffs. Sun proposes "the class from which all other classes (including the other four base classes, i.e., the composite, container, port, and connector base classes) and all component types are derived."
Although SAP's brief reflects a different construction than the plaintiffs', their construction in the subsequent Joint Claim Construction Chart of the parties is identical to the plaintiffs'.
The only difference in the parties' proposals in the recitation of the other four base classes disclosed in the patent. None of the parties dispute that the patent clearly defines the component class as "the base class from which all other classes and component types are derived." `524 Patent at 9:58-60. The court concludes that this term means "a base class from which all other classes and component types are derived."
7. "composite base class"/ "composite class"
Plaintiffs propose "a base class from which composite model elements (model elements which have subcomponents or are themselves subcomponents of a composition) are derived." SAP agrees with the plaintiffs. Sun proposes "the class, derived from the component base class, defined as elements that have subcomponents or are themselves subcomponents of a composition."
The conflicting proposals differ in only one key aspect: Sun's proposal would define a class as elements by requiring "the class . . . defined as elements. . . ." This is an unsupportable conflation of classes and elements. See e.g. '524 Patent at 6:60-7:15 ("These bases classes may branch into derived classes (i.e., system-specific classes) and terminate at leaf-descendants. Leaf-descendants define the type of components in the functional, structural hierarchy model. . . . An interactive interface provides the ability to express a configuration in terms of a model element (i.e., components)").
For this reason, the construction proposed by the plaintiffs and SAP is correct. These terms mean "a base class from which composite model elements (model elements which have subcomponents or are themselves subcomponents of a composition) are derived."
8. "container base class"/ "container class"
Plaintiffs propose "a base class from which container model elements (model elements that may contain other model elements) are derived." SAP proposes "a base class of elements that may be defined to physically house other elements." Sun proposes "the class derived from the component base class, defined as elements that contains other elements."
As with the previous term, Sun's proposal would make the container base class be defined as elements rather than having elements derived from it. Both the plaintiffs and Sun note that SAP's construction includes a term, `physically house,' that does not appear anywhere in the intrinsic record. SAP's brief does not explain nor support the inclusion of this phrase. Consistent with the previous constructions relating to the intrinsic classes, these terms mean "a base class from which container model elements (model elements that may contain other model elements) are derived."
9. "port base class"/ "port class"
Plaintiffs propose "a base class from which port model elements (model elements that connect to other model elements derived from the port class) are derived." SAP proposes "a base class of elements providing the available ports that can be physically connected with other components derived from the port base class." Sun proposes "the class, derived from the component base class, defined as elements that connect with other components derived from the port class."
Consistent with the previous constructions relating to the intrinsic classes, these terms mean "a base class from which port model elements (model elements that connect to other model elements derived from the port class) are derived."
10. "connector base class"/ "connector class"
Plaintiffs propose "a base class from which connector model elements (model elements that connect other model elements to each other) are derived." SAP proposes "a base class that branches from the composite base class and defines the model elements (such as a cable) that connect other elements to each other." Sun proposes "the class, derived from the component base class and the composite base class, that defines model elements that connect elements."
Consistent with the previous constructions relating to the intrinsic classes, these terms mean "a base class from which connector model elements (model elements that connect other model elements to each other) are derived."
11. "model element(s)"/ "element(s)"
Plaintiffs propose "a representation of one or more components that may be considered for inclusion in a configured system, i.e., a component type." SAP agrees with the plaintiffs. Sun proposes "a representation of a component(s) capable of being included in a configured system."
For the most part, there is little disagreement as to this term. The parties agree that the proper construction of this term would not "require `model elements' to be included in `each and every' configured system." Pls.' Reply Br. at 6. The plaintiffs, however, argue that Sun's construction "ignores the situation in which a model element is not capable of being included in a configured system." Id. While this might be true, the plaintiffs provide no support for the proposition that such a situation is described in the patent.
The specification states that "[a] model consists of all of the elements that may be included in a configured system." `524 Patent at 3:26-27. In light of this statement in the specification, Sun's proposed construction more accurately captures this concept. In fact, the plaintiffs' and SAP's proposed construction would not be helpful as the phrase "that may be considered for inclusion" is vague and provides little to no guidance as to the scope of this term.
The plaintiffs argue that Sun's proposed construction "uses the confusing phrase `capable of being included.'" Pls.' Reply Br. at 14. The court disagrees. Sun's use of "capable of" does not have any meaningful difference from the specification's use of the term "may," and will not be confusing for a jury.
Therefore, these terms mean "a representation of a component(s) capable of being included in a configured system."
12. "said elements"
Plaintiffs propose that this term carry the meaning proposed for "model element(s)" above. SAP proposes "all the elements of the element model." Sun agrees with the plaintiffs that this term carry the meaning proposed for "model element(s)" above.
SAP argues that "the phrase `said elements' refers back to the antecedent phrase `an element model consisting of elements,' and therefore refers to `all of the elements of the element model.'" SAP Resp. Br. at 20. While this argument appears correct, it is hyper-logical to the extent of missing the meaning of this term when the claim is read as a whole. The plaintiffs' and Sun are correct that this term does not require any further construction than the terms "model element(s)" and "element(s)," above. For the reasons given as to the definition of those terms, "said elements" means "a representation of a component(s) capable of being included in a configured system."
13. "element model"/ "model"
Plaintiffs propose "a representation that defines all of the model elements (i.e., components) that may be considered to be included in a configured system and physical or spatial, and optionally logical, relationships of model elements with respect to other model elements." SAP proposes "a representation, organized as a structural model hierarchy, of the elements available to configure a system." Sun proposes "a representation, organized as a structural model hierarchy, that defines elements."
The plaintiffs argue, similar to the term "structural model hierarchy," that the defendants are attempting to read limitations of the preferred embodiment into this term. The defendants argue that the plaintiffs are trying to recapture subject matter surrendered in prosecution to overcome the Richek reference.
The patents teach that the element model consists of "all of the elements that may be included in a configured system." `524 Patent at 3:26-27, see also id. at 29:39-42 ("an element model consisting of elements used to configure said system and structural relationships between said elements in said model").
The plaintiffs are correct that "[n]either the claim language nor specification limits the model to a `structural model hierarchy.'" Pls.' Opening Br. at 16. The issue for the court, however, is whether the applicants made a clear disclaimer of scope during the prosecution. For the reasons given in the `structural model hierarchy' section above, such a disclaimer was made. Therefore, these terms mean "a representation, organized as a structural model hierarchy, of the elements available to configure a system."
14. "structural relationships between said elements"
Plaintiffs propose "the spatial or physical relationships of model elements with respect to other model elements." SAP proposes "the spatial and/or physical relationships between model elements descended from the base classes of the structural model hierarchy, expressed by the composite hierarchies, container hierarchies, and port relationships substructures." Sun proposes "the spatial or physical relationships among model elements in the structural model hierarchy."
All parties agree that this phrase refers to spatial and physical relationships, but disagree as to the context in which these relationships can exist and still fall within the scope of this limitation. Again, the issue is the scope of disclaimer, if any, in the prosecution history in light of the Richek reference. The plaintiffs proposal continues to reflect their belief that no disclaimer was made. SAP's construction not only limits this term to the "structural model hierarchy" of the invention, but further incorporates and restricts this term to the three specific structural relationships described in the specification. Sun's proposed construction does not limit the relationships so narrowly, but does reflect the prosecution history and specification's teachings that these relationship exist within the invention's structural model hierarchy.
Sun's proposed construction accurately provides the meaning of this term. Therefore, this term means "the spatial or physical relationships among model elements in the structural model hierarchy."
15. "an element model consisting of elements used to configure said system and structural relationships between said elements in said model"
Plaintiffs propose that this term does not require construction, in view of the terms therein. Sun agrees with the plaintiffs. SAP proposes "[An element model] consisting only of: 1) elements used to configure said system; and 2) structural relationships between said elements in said model."
SAP argues that "in patent law, the term `consisting of' is a legal construct with a well-established legal meaning" and that meaning is of a closed set. SAP's Resp. Br. at 22 (citing CIAS, Inc. v. Alliance Gaming Corp., 504 F.3d 1356, 1361 (Fed. Cir. 2007) ("It is equally well understood in patent usage that `consisting of' is closed-ended and conveys limitation and exclusion."); Norian Corp. v. Stryker Corp., 363 F.3d 1321, 1331 (Fed. Cir. 2004) ("`Consisting of' is a term of patent convention meaning that the claimed invention contains only what is expressly set forth in the claim."). The plaintiffs simply state that Sun agrees with their position that this phrase does not require construction. Sun's briefing is silent as to this dispute.
SAP is correct that the meaning of the phrase "consisting of" is well-established in patent lexicography. Therefore, this phrase means "an element model consisting only of: 1) elements used to configure said system; and 2) structural relationships between said elements in said model."
16. "instance"
Plaintiffs propose "a specific data representation of a member of a class." SAP agrees with the plaintiffs. Sun proposes "a specific embodiment."
Sun argues that the plaintiffs' proposal would be "unquestionably inconsistent" with the use of the term in the specification. Sun's Response Br. at 23. Specifically when the patent discusses the creation of a "blank system instance." See '524 Patent at 9:14-19. Sun's construction, however, finds no support in the intrinsic record.
To one of skill in the art, and "instance" is an occurrence of a member of a class. This is supported by the dictionary definition provided by the plaintiffs: "an object myList that belongs to a class List is an instance of the class List." Microsoft Computer Dictionary 254 (3d ed. 1997).
The patent discloses that "a member of [a] class [is] called an object instance." `524 Patent at 13:15-18. And, "[d]ata representations of individual system parts are known as objects." `524 Patent at 15:29-30. Therefore, this term means "a specific data representation of a member of a class."
17. "configuration instance"
Plaintiffs propose "a data set for representing a specific system that will be or has been configured, which set may be empty or populated." SAP agrees with the plaintiffs. Sun proposes "a specific embodiment of a configuration."
The court concludes that this term means "a data set for representing a specific system that will be or has been configured, which set may be empty or populated."
18. "resource(s)"
Plaintiffs propose "a system commodity that is capable of being supplied or consumed by one or more components." Sun agrees with the plaintiffs. SAP proposes "an incrementally consumable system commodity, such as power or memory, supplied and capable of being consumed by components of the system."
The only real dispute as to this term is SAP's inclusion of the phrase `incrementally consumable.' As the plaintiffs and Sun point out, this phrase appears nowhere in the intrinsic record. To support its argument, SAP cites the following passage of the patent: "To account for electrical power consumption and the requirement that no power supply is overloaded, the model must comprehend the specific cabinet in which each component is placed and update the consumed power for each cabinet." `524 Patent at 2:24-37. This passage fails to support SAP's position that the term resourse(s) should be limited to requiring incremental consumption. Therefore, this term means "a system commodity that is capable of being supplied or consumed by one or more components."
19. "resource request"/ "request for a resource"
Plaintiffs propose "input that is a request for a resource." Sun agrees with the plaintiffs. SAP proposes "a request that is input by the user of the configuration system for the supply of a specified resource."
The key dispute between the parties is whether a resource request must come from the user. While the preferred embodiment discusses these requests in terms of "user-specified requests," there is no support to limit this term in the manner proposed by SAP. `524 Patent 9:10-11. The plaintiffs and Sun argue that the requests can come from the configuration engine itself. Pls.' Opening Br. at 21 (citing `524 Patent at 22-25). The court concludes that these terms mean "input that is a request for a resource."
20. "(b) selecting said element when said resource has not been previously consumed; (c) selecting newly created element instance that offers said resource if no existing elements satisfy said resource request"
Plaintiffs propose that this term does not require construction, in view of the terms therein. Sun agrees with the plaintiffs. SAP proposes that "step (c) must occur if step (b) does not."
SAP's briefing on this point cites to the preferred embodiment, and would read those limitations into the claims. SAP's Resp. Br. 24 (citing `524 Patent at 14:37-55). The plaintiffs provide a persuasive example of a system that SAP's proposal would unsupportably read-out of the claims. See Pls.' Opening Br. at 22 ("Suppose a 100 Watt resource request has been made, and that an existing element in a configuration can provide half of the requested wattage requested. Thereafter a second model element could be created (i.e., selected) to provide the remaining 50 Watts requested."). This term, given its context in the claim(s) and the construction of the terms it contains, does not require construction.
21. "computer readable program code configured to cause a computer"
Plaintiffs propose "computer program instructions directing a computer system." SAP proposes "computer program instructions that, without modification or supplementation, direct the computer to perform the recited operation." Sun proposes "software or program instructions to cause a computer."
The plaintiffs argue that SAP's proposal would exclude one of the preferred embodiments. Pls.' Opening Br. at 28 (citing `524 Patent at 7:11-17). Sun agrees that SAP's proposal to include the phrase `without modification or supplementation' finds no support in the intrinsic record.
The plaintiffs note that "Sun's proposed construction is essentially correct" except for the inclusion of the term `software.' Pls.' Opening Br. at 27 n. 40. Neither Sun nor the plaintiffs provide briefing regarding each other's construction. The court concludes that this term means "program instructions to cause a computer" and that nothing in the intrinsic record would limit `program instructions' to exclude software providing those instructions.
22. "computer readable program code configured to cause a computer to . . ."
SAP identified 27 claim phrases within 23 claims that it seeks to construe as means-plus-function elements under 35 U.S.C. § 112 ¶ 6. Each identified claim limitation includes the phrase "computer readable program code configured to cause a computer to" followed by a purportedly functional operation. Sun and the plaintiffs contend that none of the asserted claims include means-plus-function limitations requiring construction under 35 U.S.C. § 112 ¶ 6 and that those SAP identifies do not require separate claim construction. They are correct.
None of the elements SAP identifies contain the term "means" and therefore are presumptively not subject to means-plus-function construction under § 112 ¶ 6. See CCS Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1369 (Fed. Cir. 2002)); see also Watts v. XL Sys., Inc., 232 F. 3d 877, 880-81 (Fed. Cir. 2000). This presumption against means-plus-function treatment is not readily overcome. See Lighting World, Inc. v. Birchwood Lighting, Inc., 382 F.3d 1354, 1358 (Fed. Cir. 2004). SAP has not overcome the presumption in this case. Therefore, the court declines to construe these terms as means-plus-function limitations.
V. Conclusion
The court adopts the constructions set forth in this opinion for the disputed terms of the Versata patents. The parties are ordered that they may not refer, directly or indirectly, to each other's claim construction positions in the presence of the jury. Likewise, the parties are ordered to refrain from mentioning any portion of this opinion, other than the actual definitions adopted by the court, in the presence of the jury. Any reference to claim construction proceedings is limited to informing the jury of the definitions adopted by the court.