PTAB

CBM2012-00001

SAP AG v. Versata Development Group Inc

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Method and Apparatus for Pricing Products in Multi-Level Product and Organizational Groups
  • Brief Description: The ’350 patent discloses a computer-implemented method for determining product prices by organizing customer and product data into hierarchical groups. The system uses these hierarchies to store, retrieve, and apply pricing adjustments, including the use of "denormalized numbers" whose units and meaning are determined at runtime.

3. Grounds for Unpatentability

Ground 1: Invalidity Under §101 - Claims 17, 26-29 are Unpatentably Abstract

  • Core Argument for this Ground: Petitioner argued that the challenged claims are directed to patent-ineligible abstract ideas without adding an inventive concept. The claims centered on two abstract principles: (1) the mere rearrangement of pricing data into arbitrary hierarchies, and (2) the calculation of prices using abstracted, "denormalized" numbers. Petitioner contended these are fundamental economic practices and mathematical operations. The argument asserted that the claims add nothing more than routine, conventional computer functionality, noting that the patent specification concedes the invention can be implemented on any general-purpose computer. Furthermore, Petitioner argued the claimed methods could be performed manually by a human using a pencil and paper, confirming their abstract nature and lack of a true technological improvement. The claims were argued to fail the machine-or-transformation test as they are not tied to a particular machine and only manipulate data without transforming any article to a different state or thing.

Ground 2: Invalidity Under §112 - Claims 17, 26-29 are Indefinite and Lack Written Description

  • Core Argument for this Ground: Petitioner asserted three distinct invalidity arguments under 35 U.S.C. §112.
    • Lack of Written Description (§112, ¶1): The petition argued that claims 26-29, which require computer instructions to perform various functions, are not supported by the specification. The patent allegedly describes key steps, such as “arranging a hierarchy of organizational groups,” as being performed by a user, not by software. The specification was said to lack sufficient detail to guide a skilled artisan on how to implement these user-dependent functions in computer code, thus failing to demonstrate the inventor was in possession of the claimed software invention.
    • Indefiniteness (§112, ¶2): Petitioner contended that claim 17 is indefinite for two reasons. First, the phrase “eliminating any of the pricing information that is less restrictive” was argued to be insolubly ambiguous, as the specification provides no clear or objective standard to determine what information is "less restrictive," particularly in complex hierarchies. Second, the claim was argued to lack a proper antecedent basis for "the pricing information" in the "sorting" and "eliminating" steps, creating ambiguity as to which previously recited pricing information is being acted upon.
    • Improperly Mixed Statutory Classes (§112, ¶2): Claims 26 and 28 were argued to be indefinite because they improperly mix two statutory classes of invention. The claims recite a "computer readable storage media" (an article of manufacture) containing instructions to perform a method that, as recited in claim 17, includes steps performed by a user. This mixing of apparatus limitations with user-performed method steps allegedly makes it impossible to determine the point of infringement.

Ground 3: Anticipation Under §102 - Claims 17, 26-29 are Anticipated by the SAP R/3 System

  • Prior Art Relied Upon: SAP R/3 2.2 System (publicly available with documentation since at least January 1995).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that the SAP R//3 system’s documentation discloses every limitation of the challenged claims. The R/3 system’s Sales and Distribution (SD) module includes a flexible pricing mechanism called the "condition technique" that determines product prices. This technique directly maps to the claim elements:
      • Hierarchies: R/3 organizes customers into "customer hierarchies" and products into "product hierarchies" or "material pricing groups."
      • Storing: The condition technique stores pricing data (condition records) associated with various "condition types" (e.g., base price, discount), which correspond to the claimed "pricing types." This data is linked to specific customers, products, or their respective hierarchical groups in "condition tables."
      • Retrieving & Sorting: For a given sales order, R/3 uses a pre-defined "access sequence" for each condition type. This sequence dictates the order in which condition tables are searched to find the applicable price, discount, or surcharge. This search is performed hierarchically, from most specific (e.g., customer/product specific price) to most general (e.g., base product price), which Petitioner argued constitutes the claimed "retrieving" and "sorting."
      • Eliminating: The access sequence can be configured with an "exclusive access indicator." When set, the system stops searching and uses the first valid condition record it finds (the most specific one), thereby "eliminating" all other less specific (i.e., less restrictive) pricing information.
      • Determining Price: The R/3 system then applies the retrieved condition records in a sequence defined by a "pricing procedure" to calculate the final product price.

4. Key Claim Construction Positions

  • "sorting the pricing information": Petitioner proposed this term means the pricing information is ordered, consistent with its plain meaning and the patent owner's prior litigation positions. Crucially, Petitioner argued this ordering does not require a temporal sequence where sorting must occur after retrieving is complete; an interleaved or pre-ordered process would suffice.
  • "the pricing information that is less restrictive": Petitioner argued this term is insolubly ambiguous and renders the claims indefinite. However, for the purpose of its prior art analysis, Petitioner adopted a construction based on hierarchy, where information higher in a hierarchy is considered "less restrictive."
  • "denormalized numbers": Petitioner argued that the broadest reasonable interpretation must encompass the patent owner's broad construction from district court litigation. This construction defined the term as a number whose units and application are determined at runtime by retrieving information previously associated with it by an administrator, a feature Petitioner alleged was present in the SAP R/3 system.

5. Relief Requested

  • Petitioner requested institution of a Covered Business Method post-grant review and cancellation of claims 17 and 26-29 of the ’350 patent as unpatentable.