Opinion
07-C-158-C.
November 9, 2007
OPINION and ORDER
This civil case for patent infringement is before the court for construction of certain claim terms in plaintiff Taurus IP, LLC's United States Patent No. 6,141,658 (the `658 patent), a patent directed to a computer system and method for managing sales information. A claims construction hearing was held on September 21, 2007. The parties dispute the meaning of a handful of terms in the patent, including whether two of the terms are indefinite as uncorrectable mistakes or insolubly ambiguous.
From the parties' arguments at the hearing, their prehearing briefs and their posthearing supplemental briefs and from the patent claims, patent specification and prosecution history, I conclude that the jury would benefit from having a judicial construction of the disputed terms, that no term is indefinite and that the terms should have the following construction:
1. "Data items" means "items of information related to products offered for sale by a selling entity."
2. "User-defined relationship information" means "the set of rules specified by the user that governs the relationship between data items within the data model."
3. "User" means "a person who is capable of creating and editing user-defined relationship information."
4. "Data instance items" means "a group of one or more data items and one or more user-defined relationship items."
5. "User-defined relationship items" means "individual rules specified by the user that belong to and interconnect data instance items."
OPINION
The construction of the claims at issue in a patent infringement case is a legal determination to be made by the court. Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996); Markman v. Westview Instruments, 52 F.3d 967, 979 (Fed. Cir. 1995) (en banc), aff'd, 517 U.S. 370 (1996). In interpreting an asserted claim, the court should look first to the so-called intrinsic evidence of record: the claims themselves, the patent specification and the prosecution history.Teleflex, Inc. v. Ficosa North America Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). Construction of the disputed terms begins with the language of the claims. Generally, claim terms are given their "ordinary and customary" meaning, which is the meaning the term would have to a person of ordinary skill in the art as of the filing date of the patent application. Phillips v. AWH Corp., 415 F.3d 1303, 1313 (Fed. Cir. 2005); Rexnord Corp. v. Laitram Corp., 274 F.3d 1336, 1342 (Fed. Cir. 2001). In addition to considering the ordinary meaning of a claim term, court must consider the context of the surrounding words of the claim when construing the term. ACTV, Inc. v. Walt Disney Co., 346 F.3d 1082, 1088 (Fed. Cir. 2003).
Although in some cases the "ordinary and customary" meaning of claim language may be readily apparent even to lay judges, in many instances, a court must proceed beyond the bare language of the claims and examine the patent specification. Phillips, 415 F.3d at 1314-15. The specification has been called "the single best guide to the meaning of a disputed term." Vitronics, 90 F.3d at 1582. It is in the specification that the patentee provides a written description of the invention that allows a person of ordinary skill in the art to make and use the invention, Markman, 52 F.3d at 979, and at times even "set forth an explicit definition for a claim term that could differ in scope from that which would be afforded by its ordinary meaning." Rexnord, 274 F.3d at 1342; Vitronics, 90 F.3d at 1582. The patent specification may be used to give meaning to claim terms, but it should not be used to broaden or narrow the invention, which is specifically laid out in the patent's claims. E.I. Du Pont de Nemours Co. v. Phillips Petroleum Co., 849 F.2d 1430, 1433 (Fed. Cir. 1988); see also Vitronics, 90 F.3d at 1582 (when term is not specifically defined in claims, it is necessary to review specification to determine whether inventor uses term inconsistently with its ordinary meaning).
After considering the claim language and the specification, a court may consider the final piece of intrinsic evidence, the patent's prosecution history. Vitronics, 90 F.3d at 1582. "[S]tatements made during the prosecution of a patent may affect the scope of the invention." Rexnord, 274 F.3d at 1343. Generally, the prosecution history is relevant if a particular interpretation of the claim was considered and specifically disclaimed during the prosecution of the patent. Warner-Jenkinson Co., Inc. v. Hilton Davis Chemical Co., 520 U.S. 17, 30 (1997); Vitronics, 90 F.3d at 1582-83.
Finally, a court may consult extrinsic evidence, such as dictionaries, treatises and expert testimony for background information and to "shed useful light on relevant art." Phillips, 415 F.3d at 1317 (internal citations omitted). In general this type of evidence is less reliable than intrinsic evidence in determining the meaning of claim terms, and is "unlikely to result in a reliable interpretation of patent claim scope unless considered in the context of the intrinsic evidence." Id. at 1318-19.
All of the terms the parties dispute appear in independent claim 16 of the `658 patent, which states:
What is claimed is:. . . .
16. A computer system implemented method for managing product knowledge comprising a plurality of data items related to products offered for sale by a selling entity, the computer system including a memory arrangement and at least one processing unit, the method comprising:
defining a data model of data categories, the data model establishing relationships between data categories;
receiving in the computer system one or more particular data items corresponding to one or more of the data categories;
receiving user-defined relationship information for the particular data item, the relationship information relating the particular data item to one or more other data items; and
presenting the product knowledge, including information about the particular data item, to a user of the system in a manner established by the data model and the user-defined relationship;
wherein the data model is constructed from one or more data instance items interconnected using the user-defined relationship items for each data instance item.
(Emphasis added to highlight disputed terms).
A. Data Items
Plaintiff's construction: units of information in binary digital form that the computer system can recognize as distinct from other units of information.
Defendants' construction: items of information relating to products offered for sale by a selling entity.
Although plaintiff disputed the term "data items" initially, it has since agreed to defendants' construction of the term, suggesting only that the phrase "relating to" be changed to "related to" to reflect the language in the preamble of the patent that defendants rely upon for their construction. I will adopt defendants' construction and incorporate plaintiff's minor change.
Court's construction: items of information related to products offered for sale by a selling entity.
B. User-Defined Relationship Information
Plaintiff's construction: input from a user of the computer system that is used by the system to define a rule between two or more instance items.
Defendants' construction: rules specified by the user that govern the hierarchy and relationship between data items within the data model.
Both parties agree that the term "user-defined relationship information" involves defining a rule. The parties dispute what the role of a user is in defining the rule, whether the term refers to data items or data instance items and whether the rule must be hierarchical.
1. The role of a user in defining the rule
Plaintiff contends that the construction should reflect the fact that a user may define a rule simply by making a "connection" between data instance items using pre-defined relationships available through a Graphical User Interface. Plaintiff points to an example of a Graphical User Interface discussed in the specification and displayed in Figure 17 of the `658 patent that permits users to click on pre-existing buttons to define relationships between data items. According to plaintiff, the rule specified by a user need not be "made out of whole cloth" or unknown to the computer system before the user entered the information. Defendants contend that the construction should reflect the user's direct role in defining the relationship information.
I agree with defendants. The term "user-defined relationship information" requires the user to define the rule. In plaintiff's construction, the computer system defines the rule, the user merely "inputs" information. There is nothing about the discussion of Figure 17 in the specification that subordinates the user to the computer system for rule-definition. In the discussion plaintiff points to, the Graphical User Interface does not provide users with "pre-defined" rules, but merely provides shortcuts for generating rule pieces that may be used in combination with text entry to form complete rules. `658 Pat., col. 11, lns. 39-43 ("A text entry box 1702 allows the user to enter rules in textual form. Alternatively, the user can use a variety of active screen regions to reduce the number of keystrokes involved in defining a rule."); `658 Pat., col. 11, lns. 51-52 ("The dialog box 1700 also includes a variety of buttons that can be used in place of keystrokes in defining rules.").
Moreover, plaintiff's contention that the user may use an interface to specify rules and need not make a rule out of "whole cloth" is not in conflict with defendants' proposed construction that requires the rule to be "specified" by a user. A user may "specify" a rule from pre-existing pieces.
2. Relating data items or data instance items
Plaintiff propose that the rules relate "data instance items" as opposed to "data items." However, it supports its proposal only tepidly, conceding at the claim construction hearing that which phrase is used it is not a "huge deal" because data items are necessarily included in plaintiff's proposed construction of "data instance items." Even though the specification discusses the user's ability to relate "instances," the claim language itself describes "user-defined relationship information" as "relating the particular data item to one or more other data items." Thus, plaintiff's proposal must be rejected.
3. Necessarily hierarchical
Although the parties agree that "user-defined relationship information" involves a rule, they disagree about what type of rule must be involved. The claim states only that the information must "relat[e]" particular data items. Defendants contend that the rules must govern not only the "relationship" but also the "hierarchy" between data items.
Defendants clarified their position during the claim construction hearing, stating that the term requires not that every rule specified be hierarchical, only that the whole data model itself be hierarchical and, at a minimum, its elements must be related hierarchically. Defendants cite several discussions in the specification emphasizing hierarchical relationships. `658 Pat., col. 5, lns. 30-35 ("hierarchical relationships between objects can be represented using pointers. . . . FIG. 18 conceptually illustrates an example [of a] hierarchy of objects."); col. 6, lns. 2-4 ("For example, hierarchical relationships can be represented using a tree-like structure."); col. 8, lns. 16-21 ("A tree-like structure 702 displays the hierarchy of instances of data objects."); col. 9, lns. 26-28 ("A navigational path list 1202 and a navigational grid 1204 are used to navigate through the hierarchy of instances of data objects based on a user-selected view."); col. 11, lns. 37-45 ("The relationships between instances of data objects, in combination with the instances themselves, are used in defining the hierarchy of instances of data objects. . . . a tree-like structure 1704 representing the hierarchy of instances can be used to select objects . . .").
Defendants have pointed to nothing more than a preferred embodiment. The specification makes clear that the apparently hierarchical structure of the data may be organized according to non-hierarchical rules, if the user so desires:
For example, hierarchical relationships can be represented using levels in a tree-like structure. Instances of an object type can be illustrated similarly using the tree-like structure. It should be understood that other types of rules can be used to construct the GUI. For example, business rules, such as rules describing the compatibility between types of components, can be used to determine the placement of instances within the tree-like structure.
`658 Pat., col. 6, lns. 2-10. Although this language suggests that even when non-hierarchical, the data model may be structured in a "tree-like" format, this is not the same as "hierarchical."
The claim language requires the user to define the relationship and requires the relationship to be between data items as opposed to data instance items. Neither the claim language nor the specification demonstrates that the rules specified must be "hierarchical." In light of this, defendants' proposed construction requires some modification. Another minor change is worth making. Defendants propose that the "information" be described as "rules . . ." This would make "information" necessarily plural. In place of "rules" I define the term as "the set of rules" to address this concern.
Court's construction: the set of rules specified by the user that governs the relationship between data items within the data model.
C. User
Plaintiff's construction: either no construction is needed or user is a person who uses the claimed computer system
Defendants' construction: a person who has access rights to define relationships among data items to construct the data model.
Defendants contend that a "user" must have access rights to define relationship information. Plaintiff contends that defendants' proposal reads an unintended limitation into the claim and that the term user either needs no construction or should be construed to mean any person who uses the claimed computer system.
The language of claim 16 makes no mention of "access rights." The term "user" appears once in the context of having "product knowledge, including information about the particular data item," presented to the user. In addition, the claim mentions the user indirectly, referring to "user-defined relationship information." The claim language makes it clear that, at least, the user is expected to define relationship information and receive "product knowledge."
However, defendants contend that a user must have "access rights" as well, pointing to discussions in the specification of the user's "access rights." The background of the invention discusses the lack of access rights as a weakness of earlier attempts to manage product knowledge. `658 Pat., col. 2, lns. 40-42. In addition, the specification describes the present invention's ability to grant access rights:
In accordance with another aspect of the present invention, the system can assign access rights to various users of the system. The system recognizes several types of users with differentiated access rights. Examples of types of users include, but are not limited to, system administrators, data model owners, product managers, product experts, and data entry clerks. Each type of user is responsible for certain goals of the system.
`658 Pat., col. 11, ln. 66-col. 12, ln. 6. The specification then discusses the differing access rights assignable to the user types mentioned and the respective role of each user type, `658 Pat., col. 12, ln. 12-col. 13, ln. 44, and concludes: "By recognizing different types of users with different access rights defined on an instance basis, the system can ensure that each type of user can perform the tasks assigned to him or her," `658 Pat., col. 12., lns. 45-48.
However, defendant's contentions fail because "access rights" are a alternate embodiment, not a necessary limitation to "user." Dependent claim 30 states, "A method, according to claim 16, further comprising selectively granting differentiated access rights to respective data instances corresponding to one or more of the data categories." Although defendants point out that the selectively granted access rights in claim 30 are granted to data instances as opposed to users, it is implicit in the claim that it is "users" whose access will be restricted to the particular data instances. Moreover, as quoted above, the specification takes "access rights" into account as "another aspect" of the invention and that access rights are to be "defined on an instance basis." The claims and specification make it explicit that the term "access rights" is not an inherent limitation to claim 16, but is instead incorporated in dependent claim 30.
Although a "user" does not require "access rights," defendants are correct that the term "user" must be limited in light of its context in claim 16 and its use in the specification. The claim itself requires the user to have the capability to define relationship information. The specification emphasizes this requirement. `658 Pat., col. 4, lns. 49-50 ("Users can also define and understand relationships between information in the data warehouse."); col. 11, lns. 32-36 ("FIG. 17 illustrates an example dialog box 1700 for use in defining rules that describe relationships between information. . . . For example, using the dialog box, the user can define a relationship between one type of data object. . . . and another . . ."). The specification consistently describes the role of the user as using the system to view and manipulate database information, for example by organizing data, addding new instances, attaching existing instances and defining relationships. `658 Pat., cols. 7-10, col. 11, lns. 32-65. Second, the specification distinguishes "users" from "customers," "salespersons," "information producers" and "consumers":
Exporting processes typically do not allow the user to define the purposes for which an individual instance of information can be used or to specify applications to which the instance . . . is available. . . . In one system, designed for customers, it might be desirable to grant access to the Retail instance only. By contrast, in the other system, designed for salespersons, access should be granted to both the Retail and Cost instances.
`658 Pat., col. 2, lns. 16-26. Also:
users of a data warehouse can control access rights of various information producers and consumers in the system and can distribute content and control of individual instances of the information to other users.
`658 Pat., col. 4, lns. 39-43. In spite of these apparent limitations, plaintiff contends that "user" should be read broadly to include "customers." In support of its construction, plaintiff submits a press release of the patentee's product. The same product was used as an example in figures 3-17 of the `658 patent. The press release described the product as one allowing "customers" to configure and price products through a website. This press release is not reliable information for understanding the scope of the claim terms, and I will not consider it. AquaTex Industries, Inc. v. Techniche Solutions, 479 F.3d 1320, 1327-28 (Fed. Cir. 2007) (holding that it was error to rely on characteristics of patentee's product for claim construction purposes).
This leaves the court with the issue of determining what language most properly construes the scope of "user" in light of its use in the claim and the specification. Because the specification uses the term "user" in a specialized manner and distinguishes the term from "customers," "salespersons" and "consumers," it would be inappropriate to define the term to include those groups or leave construction of the term to the jury, as plaintiff proposes. The court's construction of "data items" and "user-defined relationship information" is relevant to the construction of "user." For the user to have the capability to define relationship information, the user must be capable of "specify[ing] rules that govern the hierarchy and relationship" of "items of information related to products offered for sale by a selling entity." Rather than construe the term "user" in such a wordy way, given the definition of these terms elsewhere, it is sufficient that a "user" be a person who is capable of creating and editing user-defined relationship information.
Court's construction: a person who is capable of creating and editing user-defined relationship information.
D. "Wherein" Clause: Data Instance Items and User-Defined Relationship Items
The last two disputed terms, "data instance items" and "user-defined relationship items" appear in a "wherein" clause at the end of claim 16: "wherein the data model is constructed from one or more data instance items interconnected using the user-defined relationship items for each data instance item." (Emphasis added).
Defendants advance two theories in support of their contention that these terms cannot be construed because they are indefinite. First, the use of these terms was an error that cannot be corrected by the district court. Second, the terms are insolubly ambiguous. Plaintiff contends that the terms can be construed, and should be construed to reflect their approximation to similar terms found in the claim and specification.
1. Mistake
Where an error exists in a patent, a district court may correct the error "only if (1) the correction is not subject to reasonable debate based on consideration of the claim language and the specification and (2) the prosecution history does not suggest a different interpretation of the claims." Novo Industries, L.P. v. Micro Molds Corp., 350 F.3d 1348, 1357 (Fed. Cir. 2003). Because the parties dispute whether the "wherein clause" even contains errors, I must determine whether errors exist before I turn to the Novo test.
Case law does not lay out a clear test for determining whether an error exists in a patent. In many of the cases cited by defendants, there was no real dispute that the patent contained an error. Id. (word missing; patentee offered multiple corrections); STMicroelectronics, Inc. v. Motorola, Inc., 327 F. Supp. 2d 687, 701 (E.D. Tex. 2004) (patentee had filed certificate of correction). Error may be found where the claim language is incoherent. Fargo Electronics, Inc. v. Iris Ltd., Inc., 2005 WL 3241851, 3 (D. Minn. 2005) (error in phrase "the second supports other than the"). Likewise, error may be found where the patent examiner's remarks and surrounding claim language demonstrate clearly that an error exists in claim language. I.T.S. Rubber Co. v. Essex Rubber Co., 272 U.S. 429 (1926). In Essex, the Court found an error in a single claim where the claim described an "upper edge" and the surrounding claims described a "rear upper edge."Id. at 441. During prosecution the patent examiner had stated that "`each of the claims 5, 6, 7, 8, and 9' specified a plane tangent to `the rear upper edge and the breast corners.'" Id. The court noted that if applicant's counsel had intended to differentiate this claim from the others by omitting the word `rear,' he would have spoken up instead of allowing the examiner "to pass upon the claim under a misapprehension as to its language." Id.
Defendants contend that the disputed terms in the "wherein clause" were added to claim 16 as the result of a mistake, likely because the patentee "cut and pasted" the language from the wherein clause in claim 1 into claim 16 without making changes to reflect the language of claim 16. The prosecution history shows the patentee added identical "wherein" clauses to claim 1 and claim 16, containing the disputed terms "data instance items" and "user-defined relationship items." Claim 1 contained the term "data instance items" before the "wherein" clause was added. Claim 16 did not. In claim 16, the disputed terms appear for the first and last time in the "wherein" clause.
Defendants' theory of error is not convincing. Unlike Essex, in which the patent examiner made a statement about the claim language that did not coincide with the actual claim language, the prosecution history in this case indicates the examiner was aware of and accepted the "wherein" language because he rejected the patent application until the "wherein" language was added to both claims. As defendants themselves concede, "the wherein clause was a material and critical part of the claim," and was what distinguished the claims from prior art from the patent office's viewpoint. Defs. Resp. Br., dkt. #179 at 3.
Although the language added in the "wherein" clause was distinct from earlier claim language and "introduced new concepts," this appears to be an intentional move. The patentee distinguished prior art by including the "wherein" clause and explaining that
the present application permits a user of the invention to specifically define the relationships which are to exist between data categories within a user-specified model. The Applicants have amended the two independent claims to further emphasize this distinction. This process of creating a custom data model based upon user-specified relationships between data categories is recited within the identified limitations in claims 1 and 16, as amended. [The prior art] simply does not teach or disclose any process for permitting a user to create such a data model as required by the claims.
Decl. of Cynthia B. Carter, Dkt. #171, Ex. M (emphasis modified from original). Figure 18 of the `658 patent, which defendants concede would represent "data categories," is discussed in the specification as "conceptually illustrat[ing] an example [of a] hierarchy of objects" in object-oriented programming. `658 Pat., col. 5, lns. 33-34. As I discuss in detail below, the term "data instance items" is used in the claims and specification to mean "instance" that is, a specific example of "object," which includes more information than data items. Thus, the patent examiner may have accepted the wherein clause, which referred to the new concepts of "data instance items" and "user-defined relationship items," because it added a limitation requiring relationships at a "higher level" than data items.
Defendants contend that the placement of "limitations" in the "wherein" clause is problematic. Even though a "wherein" clause is generally used to "relate back to and clarify" the scope of a claim, Griffin v. Bertina, 285 F.3d 1029, 1033-34 (Fed. Cir. 2002), this does not mean that a "wherein" clause may not introduce new concepts related to the claim that effectively limit a claim. Id. (wherein clause may limit claim when necessary part of claim). Defendants have not established that an error occurred during patent prosecution in this case. Thus, Novo, 350 F.3d 1348, does not apply to this case.
2. Insolubly ambiguous
Defendants' next contention is that, even if the disputed terms of the "wherein" clause were not added in error, they cannot be construed because they are insolubly ambiguous.
The claims of a patent must "particularly point out and distinctly claim the subject matter which the applicant regards as his invention." 35 U.S.C. § 112, ¶ 2. This basic requirement is not met if the meaning of a claim is indefinite. The standard for indefiniteness is high. "If the meaning of the claim is discernible, even though the task may be formidable and the conclusion may be one over which reasonable persons will disagree," the claim is sufficiently clear to avoid invalidity on indefiniteness grounds. Exxon Research and Engineering Co. v. United States, 265 F.3d 1371, 1375 (Fed. Cir. 2001). Further, a claim is not "insolubly ambiguous" if a "narrowing construction" may properly be adopted. Id.
The reason for the high standard can be found in the statutory presumption of patent validity. 35 U.S.C. § 282; see also Exxon, 265 F.3d at 1375 ("we protect the inventive contribution of patentees, even when the drafting of their patents has been less than ideal."). Therefore, "close questions of indefiniteness" in ligitation must be resolved in favor of the patent holder. Exxon, 265 F.3d at 1380. Arising from the court's role as construer of patent claims, determinations of definiteness are questions of law, Atmel Corp. v. Info. Storage Devices, Inc., 198 F.3d 1374, 1378 (Fed. Cir. 1999), and general principles of claim construction apply. Datamize, LLC v. Plumtree Software, Inc., 417 F.3d 1342, 1347-48 (Fed. Cir. 2005).
The crux of defendants' insolubly ambiguous argument is that the terms "data instance items" and "user-defined relationship items" are not found in the claim previous to the "wherein" clause, are not discussed in the specification and are not terms of ordinary usage by persons of ordinary skill in the art. Defendants cite Datamize, LLC v. Plumtree Software, Inc., 417 F.3d at 1355 ("aesthetically pleasing" found indefinite), andUnion Pacific Resources Co. v. Chesapeake Energy Corp., 236 F.3d 684, 692 (Fed. Cir. 2001) ("comparing" found indefinite). However, the terms in those cases could not be defined without guessing as to their meaning. For the reasons discussed below, I conclude that the claims and specification shed sufficient light on the meaning of the terms to allow a construction. Although the claim language is certainly "less than ideal," it is not insolubly ambiguous.
a. Data instance items
Plaintiff's construction: either an instantiation of a class in an object-oriented program or one particular data object from a class of data objects.
Defendants' construction: term is indefinite.
The term "data instance items" appears in two claims: the "wherein" clause in claim 16 and in the body of claim 1, where the claim addresses "means for inputting one or more data instance item corresponding to one or more of the data categories, the data instance item representing at least part of the product knowledge."
Plaintiff suggests that "data instance item" is synonymous with "data instance" and "instance." Although "in the absence of evidence to the contrary" it is generally presumed that different terms have different meanings, CAE Screenplates Inc. v. Heinrich Fiedler GmbH Co. KG, 224 F.3d 1308, 1317 (Fed. Cir. 2000), the specification provides the necessary "evidence to the contrary" to consider the terms "data instance item," "data instance" and "instance" synonymous.
The specification's reference to the term "data instance" is similar to the way claim 1 refers to "data instance item." For example, the specification says that "[a] data instance can be input that corresponds to one or more of the data categories. The data instance represents at least part of the product knowledge." `658 Pat., col. 2, lns. 59-60. Moreover, the specification appears to equate "data instance" with "instance": "These structures or views are based on a data-driven data model and are derived from the hierarchy of data instances within the data model and from the ralationships between the instances." `658 Pat., col. 7, lns. 11-14. In addition, the specification makes it clear that the data model uses an "object-oriented programming," `658 Pat., col. 5, lns. 28-29, and refers to "instances" and "objects" on countless occasions. The specification uses the term "instance" as a specific example of a general "object." See,e.g., `658 Pat. col. 5, lns. 32-33 ("objects can be defined as instances of object types"); col. 6, lns. 50-51 ("hierarchy of instances of data objects"); col. 7, ln. 35 ("relationships between the instances of the data objects"); col. 7, lns. 42-43 ("children objects or instances of the selected object"); col. 7, lns. 54 ("If an instance has children objects of its own").
The next step is to determine the meaning of "data instance items." At the claims construction hearing, plaintiff stated that a definition should make it plain that "data instance" items are at a "higher level" than data items because each "data instance item" includes a set of one or more "data items" and one or more rules that govern those data items. I agree. First, data instance items must contain "rules." The "wherein" clause requires "data instance items" to be interconnected using "user-defined relationship items." As I explain below, the similarity of "user-defined relationship items" and "user-defined relationship information" supports a construction of "user-defined relationship items" that involves "rules."
Second, data instance items must contain data items. The specification uses the term "instances" to describe something that contains "attributes," `658 Pat., col. 9, ln. 42 ("instance and its attributes"), col. 9, lns. 62-63 ("modifying the individual attributes of an instance"). At the least, these "attributes" include "descriptions" or "names." `658 Pat., col. 7, lns 49-50 ("If an instance has pointers, but has no attributes flagged as a description or name . . ."). Product "descriptions" or "names" would be "items of information related to products offered for sale by a selling entity." Because the specification uses the term "instance" as a synonym for "data instance item," and describes "instance" as something that contains "user defined relationship items" and "data items," the term has sufficient meaning to be construed.
Because a viable construction exists, defendants have failed to show the term is insolubly ambiguous. The term has a definite meaning in light of the claim, the specification and the patent prosecution. The term "data instance items" should be construed to reflect its relationship with data items and user-defined relationship items.
Court's construction: a group of one or more data items and one or more user-defined relationship items.
b. User-defined relationship items
Plaintiff's construction: particular user-defined relationships from the group of user-defined relationships that were received in the system for particular data items.
Defendants' construction: term is indefinite.
The term "user-defined relationship items" appears in the "wherein" clauses in claims 1 and 16. The similarity between "user-defined relationship information" and "user-defined relationship items" is apparent. Plaintiff suggests the two terms should be nearly equated.
I agree with plaintiff that, inasmuch as "user-define relationship information" should involve "rules," so should the nearly identical term "user-defined relationship items." However, there are some important differences between the terms. First, the word "information" implies conglomeration, while "items" suggests discrete items. Where "user-defined relationship information" is "the set of rules," "user-defined relationship items" should be "individual rules."
However, there are bigger problems with equating the two terms because they are used in different contexts. "User-define relationship items" is used in the context of the "wherein clause," which describes "data instance items interconnected using the user-defined relationship items for each data instance items." The claim language makes it clear that user-defined relationship items must "belong to" data instance items ("for each data instance item") and "interconnect" data instance items.
The specification contains clues to the meaning of "interconnection." The specification notes that "objects" and "instances" are interconnected by "pointers." `658 Pat., col. 5, lns. 34-36 ("FIG. 18 conceptually illustrates an example hierarchy 1800 of objects. The arrows represent pointers connecting related objects."); col. 5, lns. 41-43 ("The object 1804 that represents configuration information is in turn connected by pointers to various instances 1806 of configuration information."). However, the computer-programming term "pointer" is not informative to a lay jury. Instead, the construction should describe the pointer's role as "interconnecting" data instance items.
An appropriate construction should incorporate the apparent similarity between the disputed term and "user-defined relationship information," the context of the term in the surrounding claim language and the term's relationship with object-based "instances." In light of these considerations, the proper definition is as follows.
Court's construction: individual rules specified by the user that belong to and interconnect data instance items.
ORDER
IT IS ORDERED that the disputed terms of plaintiff's U.S. Patent No. 6,141,658 shall have the following constructions:1. "Data items" means "items of information related to products offered for sale by a selling entity."
2. "User-defined relationship information" means "the set of rules specified by the user that governs the relationship between data items within the data model."
3. "User" means "a person who is capable of creating and editing user-defined relationship information."
4. "Data instance items" means "a group of one or more data items and one or more user-defined relationship items."
5. "User-defined relationship items" means "individual rules specified by the user that belong to and interconnect data instance items."