DCT
2:10-cv-00133
DataTern Inc v. Staples Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: DataTern, Inc. (Texas)
- Defendant: Staples, Inc.; J.C. Penney Company, Inc.; Sears Holdings Corporation; The Bank of New York Mellon Corporation; and 20 other related corporate entities (various jurisdictions)
- Plaintiff’s Counsel: Russ, August & Kabat; Patrick R. Anderson PLLC; Spangler Law PC
- Case Identification: 2:10-cv-00133, E.D. Tex., 04/19/2010
- Venue Allegations: Plaintiff alleges venue is proper because each Defendant has transacted business in the district and has committed or induced acts of patent infringement within the district.
- Core Dispute: Plaintiff alleges that the backend systems of Defendants’ commercial websites infringe two patents related to methods for interfacing object-oriented software with relational databases.
- Technical Context: The technology at issue is in the field of object-relational mapping (ORM), a software engineering paradigm for converting data between incompatible type systems in object-oriented programming languages and relational databases.
- Key Procedural History: The complaint does not reference any prior litigation, inter partes review proceedings, or licensing history related to the patents-in-suit.
Case Timeline
| Date | Event |
|---|---|
| 1997-06-19 | Priority Date for U.S. Patent No. 5,937,402 |
| 1997-09-26 | Priority Date for U.S. Patent No. 6,101,502 |
| 1999-08-10 | U.S. Patent No. 5,937,402 Issues |
| 2000-08-08 | U.S. Patent No. 6,101,502 Issues |
| 2010-04-19 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 5,937,402 - "System for Enabling Access to a Relational Database from an Object Oriented Program"
- Patent Identification: U.S. Patent No. 5,937,402, titled "System for Enabling Access to a Relational Database from an Object Oriented Program," issued August 10, 1999 (the ’402 Patent).
The Invention Explained
- Problem Addressed: The patent describes a persistent need to interface object-oriented software with relational databases, noting that the two paradigms are fundamentally different (Compl. Ex. A, ’402 Patent, col. 1:11-14). Translating object operations into relational database calls is described as "processor-intensive," and the normalized structure of database tables often "fails to match the collection of information that would typically be found in a well designed object" (Compl. Ex. A, ’402 Patent, col. 1:18-42).
- The Patented Solution: The invention proposes a method to facilitate this interaction by using "logical tables" and "logical keys." A logical table is defined as a virtual table created from a subset of columns from a physical database table, allowing developers to create data structures that more closely align with their software objects without altering the underlying database (Compl. Ex. A, ’402 Patent, Abstract). A "normalization process" allows for the creation of these logical tables from existing, potentially denormalized, tables captured from the database (Compl. Ex. A, ’402 Patent, col. 2:48-62; FIG. 5).
- Technical Importance: This approach provided a way for developers to use modern object-oriented applications with legacy relational databases without requiring expensive database redesign or sacrificing application performance (Compl. Ex. A, ’402 Patent, col. 1:11-23).
Key Claims at a Glance
- The complaint does not specify which claims it asserts, but alleges infringement of the patent generally. Independent method claim 1 is representative.
- Claim 1 Elements:
- A method for enabling an object oriented user application to access a relational database having one or more physical tables segmented into rows and columns, comprising:
- defining a logical table comprising a subset of columns from at least one of the one or more physical tables;
- designating one column of the logical table as a logical primary key column;
- forming a normalized relational schema object representing the logical table;
- generating, responsive to the normalized relational schema object, one or more object classes associated with the normalized relational schema object; and
- employing an object of an object class including the one or more object classes associated with the normalized relational schema object and a respective corresponding logical primary key value to access data in the at least one of the physical tables in the relational database.
U.S. Patent No. 6,101,502 - "Object Model Mapping and Runtime Engine for Employing Relational Database with Object Oriented Software"
- Patent Identification: U.S. Patent No. 6,101,502, titled "Object Model Mapping and Runtime Engine for Employing Relational Database with Object Oriented Software," issued August 8, 2000 (the ’502 Patent).
The Invention Explained
- Problem Addressed: The patent again addresses the technical challenge of interfacing object-oriented applications with relational databases, highlighting the inefficiencies of translating operations and the effort required to adapt software to changes in the database structure (Compl. Ex. A, ’502 Patent, col. 1:26-51).
- The Patented Solution: The invention describes a comprehensive system architecture comprising a "mapping tool" that generates a "map" defining the relationships between an "object model" and the database "schema" (Compl. Ex. A, ’502 Patent, FIG. 1). A "code generator" uses this map to create "interface objects," which a "runtime engine" then uses to manage all data access, effectively creating an abstraction layer that decouples the application from the database (Compl. Ex. A, ’502 Patent, Abstract; col. 2:27-46).
- Technical Importance: The invention provides a framework for automating the generation of the intermediary code layer between an application and a database, which can increase developer productivity and make software more robust against changes in the underlying data store (Compl. Ex. A, ’502 Patent, col. 2:2-6).
Key Claims at a Glance
- The complaint does not specify which claims it asserts. Independent method claim 1 is representative.
- Claim 1 Elements:
- A method for interfacing an object oriented software application with a relational database, comprising the steps of:
- selecting an object model;
- generating a map of at least some relationships between schema in the database and the selected object model;
- employing the map to create at least one interface object associated with an object corresponding to a class associated with the object oriented software application; and
- utilizing a runtime engine which invokes said at least one interface object with the object oriented application to access data from the relational database.
III. The Accused Instrumentality
- Product Identification: The accused instrumentalities are the backend systems and "methods practiced on various... websites" operated by the numerous Defendants, including e-commerce sites like "staples.com" and "jcpenney.com" and financial service platforms like "bnymellon.com" (Compl. ¶¶30-37, 55-62).
- Functionality and Market Context: The complaint alleges that the accused systems facilitate the interaction between the websites' user-facing applications and their backend relational databases (Compl. ¶¶30, 55). Specifically for the ’402 Patent, the systems are alleged to use "logical tables and logical keys" (Compl. ¶30). For the ’502 Patent, they are alleged to use "object oriented software applications that rely on mapping information between a relational database and an object model, and a runtime engine for invoking one or more objects" (Compl. ¶55). The complaint does not provide further technical detail on the operation of these systems but identifies the Defendants as major corporations, implying significant commercial use of the accused technology.
IV. Analysis of Infringement Allegations
No probative visual evidence provided in complaint.
5,937,402 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| defining a logical table comprising a subset of columns from at least one of the one or more physical tables | The complaint alleges the accused methods use "logical tables... to facilitate interaction between user applications and a relational database." | ¶30 | col. 4:32-37 |
| designating one column of the logical table as a logical primary key column | The complaint alleges the accused methods use "...logical keys to facilitate interaction between user applications and a relational database." | ¶30 | col. 4:37-39 |
| forming a normalized relational schema object representing the logical table | The complaint does not explicitly allege the formation of a "normalized relational schema object," but states that the accused methods "facilitate interaction between user applications and a relational database," which is the purpose of the claimed step. | ¶30 | col. 4:25-30 |
| generating, responsive to the normalized relational schema object, one or more object classes associated with the normalized relational schema object | The complaint does not explicitly allege the generation of object classes from a schema object, but alleges that the overall method facilitates interaction between "user applications"—which are inherently based on object classes—and a database. | ¶30 | col. 5:35-39 |
| employing an object of an object class... and a respective corresponding logical primary key value to access data in the at least one of the physical tables in the relational database | The complaint alleges that the accused systems use "logical tables and logical keys to facilitate interaction," implying the use of such keys to access data. | ¶30 | col. 3:1-6 |
6,101,502 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| selecting an object model | The complaint alleges the accused methods rely on "an object model." | ¶55 | col. 2:29-32 |
| generating a map of at least some relationships between schema in the database and the selected object model | The complaint alleges the accused methods "rely on mapping information between a relational database and an object model." | ¶55 | col. 2:27-29 |
| employing the map to create at least one interface object associated with an object corresponding to a class associated with the object oriented software application | The complaint does not explicitly allege the creation of "interface objects" but alleges the use of a "runtime engine for invoking one or more objects." | ¶55 | col. 2:35-40 |
| utilizing a runtime engine which invokes said at least one interface object with the object oriented application to access data from the relational database | The complaint alleges the use of "a runtime engine for invoking one or more objects with information from a relational database." | ¶55 | col. 2:40-43 |
- Identified Points of Contention:
- Factual Specificity: The complaint's allegations for both patents are highly generalized and lack specific factual support describing how any particular Defendant's system operates. The allegations largely track the language of the patents' abstracts and claims rather than describing the accused technology, raising the question of whether sufficient facts have been pled to support the claims of infringement.
- Technical Questions: A key technical question for the ’402 Patent will be whether the Defendants' systems actually perform the specific steps of defining "logical tables" with "logical primary keys" and generating "normalized relational schema objects" as the claim requires. For the ’502 Patent, a central question will be whether discovery reveals a system architecture that includes the claimed "map," "code generator," "interface objects," and "runtime engine," or if the accused systems use a different, non-infringing architecture.
V. Key Claim Terms for Construction
Term from '402 Patent: "logical table"
- Context and Importance: This term is central to the invention of the ’402 Patent. The infringement analysis will likely depend on whether the database abstraction layers used by the Defendants can be properly characterized as implementing "logical tables" as claimed. Practitioners may focus on this term because its construction could either limit the patent to its specific embodiment or broaden it to cover a wider range of modern ORM technologies.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The Abstract defines a logical table broadly as "a group of at least one column from a table or view associated with a relational database" (Compl. Ex. A, ’402 Patent, Abstract).
- Evidence for a Narrower Interpretation: The detailed description links the creation of a "logical table" to a specific "normalization process" that requires a user-supplied "Discriminator," which is a "valid 'where' constraint clause" (Compl. Ex. A, ’402 Patent, col. 4:43-54). Defendants may argue that a "logical table" must be one created via this specific, constrained process.
Term from '502 Patent: "interface object"
- Context and Importance: The "interface object" is a critical architectural component in the system claimed by the ’502 Patent. Plaintiff must prove that the accused systems create and use such objects. The definition of this term will be vital in determining whether generic data transfer objects or other software components in the accused systems meet this limitation.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The term itself is generic in software engineering. Plaintiff may argue it should be given its plain and ordinary meaning, covering any object that serves as an interface between an application and a data access layer.
- Evidence for a Narrower Interpretation: The specification explicitly describes "interface objects (20)" as being generated by a "code generator (18)" after it examines "the relationships that are defined in the map (12)" (Compl. Ex. A, ’502 Patent, col. 2:35-40; FIG. 1). A defendant could argue this requires an "interface object" to be a specific, auto-generated artifact of the claimed mapping process, not a pre-existing or manually coded component.
VI. Other Allegations
- Indirect Infringement: The complaint's prayer for relief seeks to enjoin inducement and contribution (Compl. p. 24, ¶2). However, the substantive counts for infringement (Counts I and II) do not plead any facts to support the requisite knowledge or intent for indirect infringement, alleging only direct infringement by the Defendants.
- Willful Infringement: Plaintiff alleges that infringement is willful and seeks enhanced damages (Compl. p. 24, ¶¶1, 4). The allegation is predicated on notice of infringement occurring "at least as early as the date of the filing of this Complaint" (Compl. p. 24, ¶4). The complaint also reserves the right to prove pre-suit willfulness should supporting facts be uncovered during discovery (Compl. ¶80).
VII. Analyst’s Conclusion: Key Questions for the Case
- A central issue will be one of evidentiary sufficiency: The complaint's allegations are conclusory and devoid of technical facts about the accused systems. A key question for the litigation will be whether Plaintiff can develop factual evidence through discovery to demonstrate that the Defendants' complex, real-world systems actually practice the specific, multi-step methods recited in the claims, or if the initial allegations are based on unsupported speculation about how those systems might operate.
- A second core issue will be one of definitional scope: The case may turn on claim construction of foundational terms like "logical table" (’402 Patent) and "interface object" (’502 Patent). The key question for the court will be whether these terms, which are described in the patents as part of a specific architecture, can be construed broadly enough to encompass the diverse and potentially different object-relational mapping technologies used by the numerous Defendants, or if they are limited to the specific embodiments disclosed in the patents.