Microsoft Corp v. Kaufman Michael

1. Case Identification

• Case #: IPR2017-01142
• Patent #: 7,885,981
• Filed: March 24, 2017
• Petitioner(s): Microsoft Corporation
• Challenged Claims: 1-6

2. Patent Overview

• Title: System and Method for Generating Automatic User Interface for Arbitrarily Complex or Large Databases
• Brief Description: The ’981 patent discloses a system that automatically generates a user interface for a relational database. The system interrogates the database schema to build a UI with distinct display modes for user interaction, including mechanisms for representing and managing relationships across tables.

3. Grounds for Unpatentability

Ground 1: Obviousness over Microsoft Access Manuals - Claims 1-6 are obvious over Simpson in view of Prague.

• Prior Art Relied Upon: Simpson (Access 2003 All-in-One Desk Reference for Dummies, 2003) and Prague (Access 97 Bible, 1997).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Simpson, a comprehensive guide for Microsoft Access, teaches a relational database management system that automatically generates an end-user interface. Simpson allegedly disclosed creating various forms, query interfaces, and data access pages that correspond to the claimed set of modes: create (e.g., new record forms), retrieve (e.g., select queries), update (e.g., editing forms), and delete (e.g., delete queries, command buttons). Petitioner asserted that these interfaces provide a "corresponding display format for each mode." The combination with Prague, which also describes the Microsoft Access system, was used to show the claimed step of scanning a database and applying rules, as Prague details using the Table Analyzer tool with normalization rules to analyze and structure database tables.
  • Motivation to Combine: A POSITA would combine the teachings of Prague with Simpson because both references describe different features and versions of the same underlying product, Microsoft Access. Applying Prague’s teachings on normalization rules to the database system described in Simpson would be a straightforward application of a known technique to improve a known system, yielding predictable results like better database organization.
  • Expectation of Success: A POSITA would have a high expectation of success in combining features from two manuals describing the same commercial software, as the functionality would be compatible and lead to predictable improvements.

Ground 2: Obviousness over Dynamic Form Generation Patents - Claims 1-6 are obvious over Kesler in view of Bennett.

• Prior Art Relied Upon: Kesler (Patent 7,062,502) and Bennett (Patent 5,615,367).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner contended that Kesler teaches a system for dynamically generating data entry forms "at run-time without the necessity of writing computer code." The system works by extracting schema information from a relational database, storing it as metadata in a repository, and using this metadata to construct the user interface. Petitioner argued Kesler’s system provides distinct user interfaces for the claimed modes, including creating new records, retrieving data via search screens, updating records in edit forms, and deleting records via a delete menu option with a confirmation dialog. To meet limitations for representing and managing relationships, Petitioner relied on Bennett, which teaches a graphical design window where a user can view, create, edit, and delete the links representing relationships between database tables.
  • Motivation to Combine: A POSITA would combine Bennett's graphical interface for managing table relationships with Kesler's dynamic UI generator to provide a more intuitive and user-friendly method for defining the data model. This combination represents the application of a known improvement (a graphical design window) to a known system (an automatic UI generator) to achieve the predictable benefit of enhanced usability.
  • Expectation of Success: Integrating a graphical relationship management tool, a common feature in database systems, into an automatic UI generator would predictably enhance its functionality without disrupting its core operations.

4. Key Claim Construction Positions

• "a user interface paradigm comprising a set of modes... and a corresponding display format for each mode": For the purpose of the IPR, Petitioner proposed this phrase means that a respective user interface is provided for each of the specified modes (create, retrieve, update, and delete) for interacting with a database table. This construction was central to mapping prior art systems that used different screens or windows for different functions (e.g., a "New Record" form vs. an "Edit Record" form).
• "managing said relationships across tables": Petitioner proposed this phrase means "creating, revising, or manipulating a definition that specifies how one table is related to another." This construction allowed Petitioner to map prior art tools that focused on defining and editing the underlying relationship rules, rather than just manipulating the data within related records, to the claim language.

5. Key Technical Contentions (Beyond Claim Construction)

• Disputed Priority Date: A central contention of the petition was that the ’981 patent is a continuation-in-part and is only entitled to its filing date of October 26, 2007. Petitioner argued the claims introduced a distinct "delete" mode that was not disclosed or enabled in the parent application's specification, which only mentioned a "delete capability" as a pushbutton within the edit mode. Petitioner asserted this addition of a distinct "delete mode" constituted new matter, thus making numerous pre-2007 publications, including all asserted prior art, available for obviousness challenges under 35 U.S.C. §103.

6. Relief Requested

• Petitioner requests institution of an inter partes review and cancellation of claims 1-6 of Patent 7,885,981 as unpatentable.