DCT

1:11-cv-02648

SAP AG v. DataTern Inc

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 1:11-cv-02648, S.D.N.Y., 04/18/2011
  • Venue Allegations: Venue is alleged to be proper in the Southern District of New York because Defendant DataTern, Inc. maintains its principal place of business in the district.
  • Core Dispute: Plaintiff seeks a declaratory judgment that its BusinessObjects enterprise software does not infringe Defendant's U.S. Patent Nos. 5,937,402 and 6,101,502, and that the patents are invalid.
  • Technical Context: The patents relate to object-relational mapping (ORM), a software technology that bridges the gap between object-oriented applications and relational databases.
  • Key Procedural History: This action arises in the context of multiple prior lawsuits filed by Defendant DataTern in the Eastern District of Texas against Plaintiff SAP's customers. In those actions, DataTern alleged that products using SAP's BusinessObjects software infringe the patents-in-suit. DataTern allegedly sent "illustrative infringement contentions" referencing SAP's software to those customers, prompting them to seek indemnification from SAP and creating the basis for this declaratory judgment action.

Case Timeline

Date Event
1997-06-19 U.S. Patent No. 5,937,402 Priority Date
1997-09-26 U.S. Patent No. 6,101,502 Priority Date
1999-08-10 U.S. Patent No. 5,937,402 Issue Date
2000-08-08 U.S. Patent No. 6,101,502 Issue Date
2008 SAP acquires Business Objects S.A.
2009-06-02 DataTern files first related Texas action against SAP customers
2010-02-16 DataTern files second related Texas action against SAP customers
2010-04-19 DataTern files third related Texas action against SAP customers
2010-10-07 DataTern files fourth related Texas action against SAP customers
2010-10-08 DataTern begins sending infringement contentions to SAP customers
2011-04-04 DataTern files fifth related Texas action against SAP customers
2011-04-18 Complaint for Declaratory Judgment 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," issued August 10, 1999

The Invention Explained

  • Problem Addressed: The patent describes the technical challenge of interfacing object-oriented software with relational databases. It notes that directly translating object operations into database calls is processor-intensive, while translating normalized database tables into software objects often results in poorly structured objects that do not match the application's design, creating a so-called "impedance mismatch" (’402 Patent, col. 1:11-41).
  • The Patented Solution: The invention proposes a system using "logical tables" and "logical keys" as an abstraction layer. A logical table is a user-defined virtual table, created from a subset of columns from a physical database table, that can be structured to better match a software object (’402 Patent, Abstract). This allows an application to interact with a simple, object-friendly logical representation, while the system manages the mapping to the potentially more complex underlying physical database structure, including denormalized tables (’402 Patent, col. 3:24-42).
  • Technical Importance: This object-relational mapping (ORM) approach facilitates the use of powerful, legacy relational databases by modern object-oriented enterprise applications without requiring developers to abandon object-oriented design principles (’402 Patent, col. 1:11-14).

Key Claims at a Glance

  • The complaint seeks a declaratory judgment of non-infringement and invalidity for all claims but does not identify specific claims asserted by DataTern in the underlying disputes (Compl. ¶¶ 38, 45). Independent claim 1 is representative:
  • 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," issued August 8, 2000

The Invention Explained

  • Problem Addressed: Like its related predecessor, this patent addresses the inefficiency and complexity of connecting object-oriented applications to relational databases (’502 Patent, col. 1:25-49).
  • The Patented Solution: The invention describes an architectural framework for automating the object-relational bridge. The system uses a "mapping tool" to generate a "map" that defines the relationships between a software object model and the database schema. A "code generator" then uses this map to automatically create "interface objects." Finally, a "runtime engine" uses both the map and the interface objects to transparently manage all data access for the application, handling tasks like generating SQL code (’502 Patent, Abstract; Fig. 1).
  • Technical Importance: This system provides a more automated and structured framework for ORM, aiming to provide transparent access to the database and reduce the manual work required by programmers to connect their applications to the data source (’502 Patent, col. 2:1-7).

Key Claims at a Glance

  • The complaint seeks a declaratory judgment of non-infringement and invalidity for all claims but does not identify specific claims asserted by DataTern (Compl. ¶¶ 42, 47). Independent claim 1 is representative:
  • 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

  • Plaintiff's BusinessObjects enterprise software ("BusinessObjects") (Compl. ¶1).

Functionality and Market Context

  • BusinessObjects is described as a portfolio of software for "business intelligence, enterprise information management, enterprise performance management, and governance and compliance applications" (Compl. ¶12). Its purpose is to allow business users to "efficiently search and explore their company's data for business insight, analysis, monitoring, and reporting" (Compl. ¶12). The complaint does not provide specific technical details on the internal architecture of BusinessObjects. SAP is alleged to be a "world leader in enterprise software applications" and acquired BusinessObjects in 2008 (Compl. ¶¶ 10, 12).

IV. Analysis of Infringement Allegations

The complaint is a declaratory judgment action and does not contain specific infringement allegations or claim charts from the plaintiff, SAP. It alleges that Defendant DataTern has provided "generic claim charts" and "illustrative infringement contentions" to SAP's customers which reference the BusinessObjects software, but these documents are not attached to the complaint (Compl. ¶28). Therefore, a detailed element-by-element analysis of DataTern's infringement theory is not possible from the provided filing. No probative visual evidence provided in complaint.

  • Identified Points of Contention:
    • Scope Questions: A central dispute will likely concern whether the data modeling and abstraction features within BusinessObjects fall within the scope of the patent claims. For example, a court may have to determine if creating a data model or "universe" in BusinessObjects constitutes "defining a logical table" as recited in the ’402 Patent.
    • Technical Questions: The infringement analysis may turn on the specific internal architecture of BusinessObjects. A key question is whether its architecture for accessing databases aligns with the claimed methods, such as by using a "runtime engine" that invokes "interface objects" generated from a "map" as described in the ’502 Patent, or if it employs a fundamentally different technical approach. The complaint does not provide evidence to resolve this question.

V. Key Claim Terms for Construction

  • The Term: "logical table" (’402 Patent)

    • Context and Importance: This term is the central concept of the ’402 Patent's claimed solution. The infringement analysis for this patent will likely depend on whether DataTern can successfully argue that a feature or construct within BusinessObjects meets the definition of a "logical table".
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The specification defines a logical table broadly as "a group of at least one column from a physical table or view" that "can be utilized like a physical table" (’402 Patent, col. 1:47-51). This language could support an interpretation covering any data abstraction layer that presents a simplified view of underlying tables.
      • Evidence for a Narrower Interpretation: The patent also describes the creation of logical tables as part of a specific "normalization process" that allows a user to "define different tables using subsets of columns" of a captured "denormalized table" (’402 Patent, col. 3:24-34). This could support a narrower construction limited to tables created through this particular process.

  • The Term: "interface object" (’502 Patent)

    • Context and Importance: The "interface object" is a critical component of the three-part architecture (map, code generator, runtime engine) claimed in the ’502 Patent. Practitioners may focus on this term because infringement will likely require showing that BusinessObjects uses components that function as these specific, generated objects.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The term is used in the background to generally refer to a method of interfacing applications with databases, suggesting any object that serves this bridging function could be covered (’502 Patent, col. 1:35-39).
      • Evidence for a Narrower Interpretation: The detailed description and Figure 1 show "interface objects" (20) that are specifically created by a "code generator" (18) which examines relationships defined in a "map" (12) (’502 Patent, col. 2:30-43). This context may support a narrower definition limited to objects that are dynamically generated based on a map, as opposed to pre-compiled components of a larger software platform.

VI. Other Allegations

  • Indirect Infringement: SAP seeks a declaratory judgment that it has not induced infringement or contributed to the infringement of others (Compl. ¶1). The complaint does not articulate DataTern's specific theory of indirect infringement. However, such claims in software cases are typically based on allegations that the defendant provides an infringing product to third-party customers along with documentation and support that instructs or encourages them to use the product in an infringing manner.
  • Willful Infringement: The complaint does not contain allegations related to willful infringement.

VII. Analyst’s Conclusion: Key Questions for the Case

  1. Jurisdictional Question: A threshold issue is whether DataTern's actions—suing SAP's customers in Texas and providing them with infringement contentions that identify SAP's product—are sufficient to create an "actual controversy" under the Declaratory Judgment Act, thereby giving the court in New York jurisdiction over SAP's pre-emptive lawsuit.
  2. Claim Scope and Technical Equivalence: The core technical dispute will be a battle of characterization: do the data abstraction and access mechanisms within SAP's BusinessObjects software function in the manner recited by the patent claims? This raises the question of whether BusinessObjects' features are merely analogous to the claimed "logical tables" and "interface objects" or if they represent a fundamentally different technical architecture for solving the object-relational mismatch problem.
  3. Validity in View of Prior Art and Patent Eligibility: SAP has put the validity of all claims at issue under 35 U.S.C. §§ 101, 102, 103, and 112 (Compl. ¶¶ 36, 40). A significant question will be whether the claims, which are directed to methods of structuring software interactions, are patent-eligible. Furthermore, given that object-relational mapping was a well-known problem with many proposed solutions, the case may turn on whether DataTern's patents claim a non-obvious invention over the body of prior art that existed at the time of filing.