Opinion
CAUSE NO. 6:13-CV-858-RWS-JDL
05-27-2015
DATA ENGINE TECHNOLOGIES LLC, Plaintiff, v. INTERNATIONAL BUSINESS MACHINES CORP., Defendant.
MEMORANDUM OPINION AND ORDER
This Memorandum Opinion construes the disputed claim terms in U.S. Patent Nos. 5,603,025 ("the '025 Patent") and 5,615,367 ("the '367 Patent"). On April 23, 2015, the parties presented arguments on the disputed claim terms at a Markman hearing. For the reasons stated herein, the Court adopts the constructions set forth below.
BACKGROUND
Plaintiff Data Engine Technologies LLC ("Data Engine") alleges that Defendant International Business Machines Corporation ("IBM") infringes the two patents-in-suit owned by Data Engine. The '025 Patent is directed to a relational database management system for generating a report from a user's input query. A report includes embedded hypertext links that allow a user to view additional data related to an aspect of the generated report. The use of hypertext linking between reports allows a user to navigate between two or more traditional reports having related data. The '367 Patent is directed to automating the process of linking database tables in a relational database management system so that information stored in separate tables appears to a user to come from one place.
APPLICABLE LAW
"It is a 'bedrock principle' of patent law that 'the claims of a patent define the invention to which the patentee is entitled the right to exclude.'" Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc) (quoting Innova/Pure Water Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). In claim construction, courts examine the patent's intrinsic evidence to define the patented invention's scope. See id.; C.R. Bard, Inc. v. U.S. Surgical Corp., 388 F.3d 858, 861 (Fed. Cir. 2004); Bell Atl. Network Servs., Inc. v. Covad Commc'ns Group, Inc., 262 F.3d 1258, 1267 (Fed. Cir. 2001). This intrinsic evidence includes the claims themselves, the specification, and the prosecution history. See Phillips, 415 F.3d at 1314; C.R. Bard, Inc., 388 F.3d at 861. Courts give claim terms their ordinary and accustomed meaning as understood by one of ordinary skill in the art at the time of the invention in the context of the entire patent. Phillips, 415 F.3d at 1312-13; Alloc, Inc. v. Int'l Trade Comm'n, 342 F.3d 1361, 1368 (Fed. Cir. 2003).
The claims themselves provide substantial guidance in determining the meaning of particular claim terms. Phillips, 415 F.3d at 1314. First, a term's context in the asserted claim can be very instructive. Id. Other asserted or unasserted claims can also aid in determining the claim's meaning because claim terms are typically used consistently throughout the patent. Id. Differences among the claim terms can also assist in understanding a term's meaning. Id. For example, when a dependent claim adds a limitation to an independent claim, it is presumed that the independent claim does not include the limitation. Id. at 1314-15.
"[C]laims 'must be read in view of the specification, of which they are a part.'" Id. (quoting Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995) (en banc)). "[T]he 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.'" Id. (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)); see also Teleflex, Inc. v. Ficosa N. Am. Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). This is true because a patentee may define his own terms, give a claim term a different meaning than the term would otherwise possess, or disclaim or disavow the claim scope. Phillips, 415 F.3d at 1316. In these situations, the inventor's lexicography governs. Id.
The specification may also resolve ambiguous claim terms "where the ordinary and accustomed meaning of the words used in the claims lack sufficient clarity to permit the scope of the claim to be ascertained from the words alone." Teleflex, Inc., 299 F.3d at 1325. But, "'[a]lthough the specification may aid the court in interpreting the meaning of disputed claim language, particular embodiments and examples appearing in the specification will not generally be read into the claims.'" Comark Commc'ns, Inc. v. Harris Corp., 156 F.3d 1182, 1187 (Fed. Cir. 1998) (quoting Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir. 1988)); see also Phillips, 415 F.3d at 1323. The prosecution history is another tool to supply the proper context for claim construction because a patent applicant may also define a term in prosecuting the patent. Home Diagnostics, Inc., v. Lifescan, Inc., 381 F.3d 1352, 1356 (Fed. Cir. 2004) ("As in the case of the specification, a patent applicant may define a term in prosecuting a patent.").
Although extrinsic evidence can be useful, it is "'less significant than the intrinsic record in determining the legally operative meaning of claim language.'" Phillips, 415 F.3d at 1317 (quoting C.R. Bard, Inc., 388 F.3d at 862). Technical dictionaries and treatises may help a court understand the underlying technology and the manner in which one skilled in the art might use claim terms, but technical dictionaries and treatises may provide definitions that are too broad or may not be indicative of how the term is used in the patent. Id. at 1318. Similarly, expert testimony may aid a court in understanding the underlying technology and determining the particular meaning of a term in the pertinent field, but an expert's conclusory, unsupported assertions as to a term's definition are entirely unhelpful to a court. Id. Generally, extrinsic evidence is "less reliable than the patent and its prosecution history in determining how to read claim terms." Id. In cases where subsidiary facts, such as the background science or the meaning of the term in the relevant art, are in dispute, "courts will need to make subsidiary factual findings about that extrinsic evidence." Teva Pharm. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 841 (2015). The "evidentiary underpinnings" and "subsidiary factfinding" of claim construction are reviewed for clear error on appeal. Id.
AGREED CLAIM TERMS
The parties agree to the construction of the following terms:
| Claim Term | Agreed Construction |
|---|---|
| report | information from tables printed on paper orpreviewed onscreen |
| relational database tables | tables within a relational database system |
| record(s) | (a) horizontal row(s) in a system table thatcontains a group of related fields of data |
| design document | a form or report that one creates or modifies ina design window |
| field | a column of information in a table |
| table(s) | (a) structure(s) made up of rows (records) andcolumns (fields) that contains information |
| hypertext link | a link which connects information and allows areader or user of the document to navigatebetween connected information |
| linked | connected by a relationship betweencorresponding columns of information |
| foreign key | the value found in the child table that matchesthe key of the parent table |
| to link | to establish a relationship between tables bylinking corresponding fields |
| unique key | a primary key, another candidate key, or othermeans which uniquely identifies a record |
| indexable field | a field which is capable of being used todetermine an order in which the system canaccess the records in a table |
Docket No. 71-2, App. B; Docket No. 73-1, App. A; Docket No. 75.
DISPUTED CLAIM TERMS
A. "hypertext report"
| Data Engine's Proposed Construction | IBM's Proposed Construction |
|---|---|
| "a customizable report constructed from two ormore customizable reports linked together thatallows the user to navigate between differentrelated information items contained in thosereports via hypertext links" | "a single report constructed from two or morereports that allows the user to navigate betweendifferent related information items containedtherein via hypertext links" |
Claims 1, 8, 13, 22, 26, 27, 32, 37, and 38 of the '025 Patent contain the term "hypertext report." The parties first dispute whether a hypertext report must be customizable. Data Engine argues that the specification consistently emphasizes customizability as an inventive feature of the patent. Docket No. 66 at 7-8. Thus, it contends, a construction "without any customizing or formatting feature would ignore one of the most important features of a 'report' as defined in the specification." Id. at 8. IBM responds that "the system may 'allow' a user to customize how data is presented through 'design documents,' but the inventors never stated or even suggested that the reports must provide customizable formatting." Docket No. 68 at 8 (emphasis in original).
A hypertext report need not be customizable. The specification describes a hypertext report as "generally constructed by combining two or more traditional reports." '025 Patent col.3 ll.47-51. The parties initially disputed whether the term "report" must account for customizability. See Docket No. 73-1, App. A at 2. However, prior to the hearing, the parties agreed that "report" should be construed as "information from tables printed on paper or previewed onscreen." Docket No. 75. A hypertext report, just like any other report, is not itself customizable. The report is a fixed set of information that is returned from database tables in response to a database query.
Second, the parties dispute whether the information contained in a hypertext report must come from a single, self-contained document. Data Engine submits that a hypertext report "'link[s] together' two or more reports and provide[s] access to the related information" such that "the information need only 'appear[] to the user to come from one place.'" Docket No. 66 at 10 (quoting '025 Patent at [57]). Data Engine contends that there is no requirement that a hypertext report be a single file including all of the linked-to information. Id. In response, IBM argues that the '025 Patent requires a single report, located in a single file, which contains all of the information from the underlying reports. Docket No. 68 at 8-12; Tr. Apr. 23, 2015, Docket No. 81 ("Hearing Transcript") at 17:5-7. At the hearing, Data Engine conceded that a hypertext report is itself a single report, but contended that the information need not originate from a single file. Hearing Transcript at 13:17-19.
The '025 Patent describes a hypertext report as follows:
A "hypertext report" is generally constructed by combining two or more traditional reports. By automatically placing hypertext links or cross-indexes between reports, the system ties together relatable information into a single, cross-indexed hypertext report.'025 Patent col.3 ll.47-51. The specification is silent with respect to whether the combined "two or more traditional reports" must be consolidated within a single file. Further, neither the specification nor the parties have described what a "file" is in the context of the '025 Patent. The prosecution history instructs that a hypertext report "link[s] reports in a single hypertext report that combines a plurality of reports." Docket No. 68-2, Ex. A ('025 Patent File History) at 14-15.
The Court's role under O2 Micro is to resolve legitimate claim scope disputes. O2 Micro Int'l Ltd. v. Beyond Innovation Tech. Co., 521 F.3d 1351, 1361-62 (Fed. Cir. 2008). As discussed above, whether a hypertext report must originate from a single file is not clear from the specification or the record before the Court. Although Data Engine raises a concern regarding the scope of this claim term, it is not yet a "fundamental dispute." Id. at 1362 (recognizing that a court need not construe every limitation in a patent's asserted claims, particularly where the "disputed issue [is] the proper application of a claim term . . . rather the scope of the term"). Instead, the issue may mature later in the litigation or may involve non-construction issues such as invalidity. Id. The Court construes "hypertext report" as "a single report constructed from two or more reports that allows the user to navigate between different related information items contained therein via hypertext links."
B. "key"
| Data Engine's Proposed Construction | IBM's Proposed Construction |
|---|---|
| "a field or group of fields in a system tableused to order records or ensure referentialintegrity" | "A field or group of fields in a system tableused to order records or ensure referentialintegrity. Establishing a key has three effects:(1) The table is prevented from containingduplicate records; (2) The records aremaintained in sorted order based on the keyfields; and (3) A primary index is created forthe table." |
Claims 1, 2, 4, 6, 8-17, 21, 24-29, 32, and 33 of the '367 Patent contain the term "key." Both parties point to a glossary entry in the specification as providing an express definition of the term:
key: A field or group of fields in a system table used to order records or ensure referential integrity. Establishing a key has three effects: (1) The table is prevented from containing duplicate records; (2) The records are maintained in sorted order based on the key fields; and (3) A primary index is created for the table.'367 Patent col.6 ll.39-44. Data Engine argues that only the first sentence of this passage is definitional. Docket No. 66 at 12. According to Data Engine, IBM's proposal improperly includes optional effects which might result from establishing a key. Id. at 12-13. In response, IBM contends that the patentee acted as a lexicographer when it included an express glossary entry in the specification. Docket No. 68 at 14-15. Further, IBM argues, Data Engine cannot complain that the second half of the glossary entry uses effectual language because Data Engine's own proposal describes what a key is "used to" accomplish. Id. at 15.
The glossary entry on which the parties rely contains language that is superfluous to defining a key. The definitional aspect of the glossary entry is "a field or group of fields in a system table." The remainder merely describes a key's purpose and effects that may result when a key is established. Accordingly, the Court construes "key" as "a field or group of fields in a system table."
C. "primary key"
| Data Engine's Proposed Construction | IBM's Proposed Construction |
|---|---|
| "a selected field or group of fields containingdata that uniquely identifies each record of atable" | "the one key selected from all sets of columncombinations with unique values for a table" |
Claim 15 of the '367 Patent contains the term "primary key." Data Engine argues that IBM's proposed construction is "incomplete, reciting only how a primary key is selected without defining what constitute a primary key." Docket No. 66 at 14. IBM responds that Data Engine entirely omits the word "key" in its construction, and leaves open the possibility that multiple primary keys could be selected. Docket No. 68 at 16-17.
The specification describes the relationship between different types of keys:
As previously described, every relation (i.e., table) requires a unique, primary key to identify table entries or rows. Thus, a primary key (or just "key") is a field containing data that uniquely identifies each record of a table. In addition to creating a key on just a single field (e.g., key on Last Name), a user may create a "composite key" for a group of fields (e.g., key on Last Name+First Name). Whether a simple or composite key is employed, a key requires a unique value for each record (row) of table to ensure that a table does not have duplicate records.'367 Patent col.5 ll.29-31; id. at col.5 ll.36-38; id. at col.9 ll.48-57. IBM's proposal is consistent with the specification's teaching that only one key is a "primary key," whereas the rest are alternate keys. Data Engine's proposal conflates "primary key" with "composite key," a term that is separately defined and used throughout the specification. Accordingly, the Court construes "primary key" as "the one key selected from all sets of column combinations with unique values for a table."
. . . .
candidate keys: Keys comprising all sets of column combinations with unique values for a table. One of these is selected as the primary key; the rest remain alternate keys.
. . . .
composite key: A key comprised of two or more fields of a table which, together, provide a unique value for each record of the table.
D. "automatically linking"
| Data Engine's Proposed Construction | IBM's Proposed Construction |
|---|---|
| Plain and ordinary meaning. No constructionnecessary.Alternatively, "linking without userintervention" | "linking without any user intervention otherthan selecting the tables to be linked" |
Claim 1 of the '367 Patent contains the term "automatically linking." Data Engine argues that no construction is necessary because "automatically" is "easily understood based on its plain and ordinary meaning." Docket No. 66 at 15. Data Engine submits that the term does not have any specialized meaning within the '367 Patent. Id. Further, Data Engine argues that IBM's proposal "implies much broader automation than is supported by the specification," causing certain disclosed embodiments to be outside the scope of the claims. Id. at 16. IBM responds that "the 'automatically' limitations were added during prosecution to preclude any [] user intervention." Docket No. 68 at 18. IBM contends that in proposing the plain meaning of the term, Data Engine "effectively asks the Court to erase the amendments are [sic] revert the claims back to their original form." Id. at 20.
Claim 1 recites:
1. In an information processing system, a method of automatically linking information tables, each table including at least one information field, the method comprising:
(a) receiving user input for selecting first and second information tables to link;
(b) determining a unique key for one of the two tables;
(c) automatically determining by said system a foreign key for the other of the two tables which satisfies said unique key; and
(d) if a foreign key is available, automatically linking said first and second tables through the foreign key.'367 Patent col.22 ll.19-29 (emphasis added). Although the parties dispute the extent to which the "automatically" limitation precludes user intervention with the system, neither party disputes that the linking itself must be done by the "information processing system." At the hearing, the Court proposed the construction "linking without a user manually defining a linkage between the tables." Hearing Transcript at 36:1-3. Data Engine and IBM agreed to the Court's proposal. Id. at 37:21-22, 39:8-11. Accordingly, the Court construes "automatically linking" as "linking without a user manually defining a linkage between the tables."
E. "automatically determining"
| Data Engine's Proposed Construction | IBM's Proposed Construction |
|---|---|
| Plain and ordinary meaning. No constructionnecessary. | "determining without any user interventionother than selecting the tables to be linked" |
Claims 1 and 21 of the '367 Patent contain the term "automatically determining." As with the term "automatically linking," above, Data Engine argues that no construction is necessary because the plain meaning of the term is easily understood. Docket No. 66 at 15. Data Engine contends that the claim language, "automatically determining by said system a foreign key," simply means that "the system determines the foreign key without a human operator having to manually determine what foreign key is appropriate." Id. at 18 (quoting '367 Patent col.22 ll.25-26). IBM repeats its argument with respect to "automatically linking" to urge that the patentee's amendments during prosecution should limit the construction to determining "without any user intervention other than selecting the tables to be linked." Docket No. 68 at 20.
The amendment on which IBM relies does not carry the meaning IBM proposes. Claim 1, which is reproduced above with respect to "automatically linking," is representative. During prosecution, the patentee amended claim element (c) from "determining a foreign key for the other of the two tables which satisfies said unique key" to "automatically determining by said system a foreign key for the other of the two tables which satisfies said unique key." Docket No. 68-3, Ex. B ('367 Patent File History) at 1-2, 4. This amendment, like the amendment to "automatically linking," came in response to a reference which described a user "manually defin[ing] linkages between tables." Id. at 6-7. The patentee's remarks and the claim language itself make clear that "determining a foreign key" is done "automatically by said system," and not manually by a user. IBM's proposal precludes any user intervention beyond the selection of tables, even though such selection is not part of the "determining" process. Thus, IBM's proposal goes beyond the scope of the amendment and the term "automatically determining."
Having rejected IBM's proposal, the Court finds that no construction is necessary.
CONCLUSION
For the foregoing reasons, the Court interprets the claim language in this case in the manner set forth above. For ease of reference, the Court's claim interpretations are set forth in a table in Appendix A and the parties' agreed constructions are set forth in a table in Appendix B.
So ORDERED and SIGNED this 27th day of May, 2015.
/s/_________
JOHN D. LOVE
UNITED STATES MAGISTRATE JUDGE
APPENDIX A
| Claim Term | Court's Construction |
|---|---|
| hypertext report | a single report constructed from two or morereports that allows the user to navigatebetween different related information itemscontained therein via hypertext links |
| key | a field or group of fields in a system table |
| primary key | the one key selected from all sets of columncombinations with unique values for a table |
| automatically linking | linking without a user manually defining alinkage between the tables |
| automatically determining | No construction |
APPENDIX B
| Claim Term | Agreed Construction |
|---|---|
| report | information from tables printed on paper orpreviewed onscreen |
| relational database tables | tables within a relational database system |
| record(s) | (a) horizontal row(s) in a system table thatcontains a group of related fields of data |
| design document | a form or report that one creates or modifies ina design window |
| field | a column of information in a table |
| table(s) / information table | (a) structure(s) made up of rows (records) andcolumns (fields) that contains information |
| hypertext link | a link which connects information and allows areader or user of the document to navigatebetween connected information |
| linked | connected by a relationship betweencorresponding columns of information |
| foreign key | the value found in the child table that matchesthe key of the parent table |
| to link | to establish a relationship between tables bylinking corresponding fields |
| unique key | a primary key, another candidate key, or othermeans which uniquely identifies a record |
| indexable field | a field which is capable of being used todetermine an order in which the system canaccess the records in a table |