Price F X AG v. Vendavo Inc

1. Case Identification

• Case #: CBM2019-00024
• Patent #: 7,640,198
• Filed: December 18, 2018
• Petitioner(s): Price f(x) AG and Price f(x), Inc.
• Patent Owner(s): Vendavo, Inc.
• Challenged Claims: 1-18

2. Patent Overview

• Title: System for Displaying a Transaction Table with a Calculated Index
• Brief Description: The ’198 patent describes a system for calculating and displaying pricing data. The system populates a transaction table with data from a data source, calculates at least one index based on that data (e.g., "price minus average price"), and displays the index in the table.

3. Grounds for Unpatentability

Ground 1: Patent Ineligibility under §101 - Claims 1-18

• Prior Art Relied Upon: Not applicable.
• Core Argument for this Ground: Petitioner argued that claims 1-18 are directed to patent-ineligible subject matter under 35 U.S.C. §101 and fail the two-step framework from Alice Corp. v. CLS Bank Int’l.
  • Alice Step 1 (Abstract Idea): Petitioner asserted the claims are directed to the abstract idea of calculating a summary measure (an index) using price modeling data, updating that index as the underlying data changes, and displaying the result. This process was characterized as the fundamental and abstract practice of collecting information, analyzing it with a mathematical formula, and displaying the results. Petitioner contended that claim elements such as using a "calculation parameter" (a mathematical equation) and a "mapping parameter" (transforming data format) are themselves abstract concepts. The "display" and "zoom" functions were argued to be conventional methods of viewing information, which is also abstract.
  • Alice Step 2 (No Inventive Concept): Petitioner argued the claims lack an inventive concept sufficient to transform the abstract idea into a patent-eligible application. The claims recite only generic and conventional computer components (a database, server, network, and display) performing their ordinary functions. Petitioner asserted that storing data, requesting it over a network, populating a table, and performing calculations are all routine functions. The "dynamically update" limitation was argued to be a mere instruction to perform the abstract calculation repeatedly, which is not an inventive concept. Petitioner concluded that the claims, viewed as an ordered combination, do not improve computer functionality but merely use a computer as a tool to perform an abstract business practice.

Ground 2: Lack of Written Description under §112 for "Dynamically" Limitations - Claims 1-18

• Prior Art Relied Upon: Not applicable.
• Core Argument for this Ground: Petitioner argued the claims are unpatentable under 35 U.S.C. §112 for lacking written description support for the "dynamically" limitations.
  • Argument for Lack of Support: The limitations requiring the system to "dynamically store changes" and "dynamically update" the index were added via examiner amendment during prosecution to overcome prior art. Petitioner contended that the term "dynamically" or any variant does not appear in the original specification. Furthermore, the specification's flowcharts depict a linear process that acquires data, calculates an index once, waits for user input, and then stops. Petitioner asserted there is no disclosure of a loop or continuous process that would support the claim requirement for automatic and continuous updates in response to changes in the source data. As these limitations were critical for allowance, their lack of support in the as-filed specification renders the claims invalid.

Ground 3: Lack of Written Description under §112 for Claimed Architecture - Claims 1-18

• Prior Art Relied Upon: Not applicable.
• Core Argument for this Ground: Petitioner argued the claims are unpatentable under 35 U.S.C. §112 because the specification fails to disclose the claimed three-part system architecture.
  • Argument for Lack of Support: The claims recite three distinct elements: a "data source," a separate "database" that stores data from the data source, and a "server" coupled to the database that requests data from the database to populate a transaction table. Petitioner argued the specification does not disclose this architecture. Instead, the disclosed flow diagrams show a direct data flow from a "data source" to the server for processing and population of the transaction table, with no intervening, separate "database" as claimed. The petition asserted that terms like "Oracle databases" in the specification are described as examples of "data sources," not as a separate intermediary element. Because the inventors did not disclose possession of this specific architecture at the time of filing, the claims are invalid.

4. Key Claim Construction Positions

• "dynamically": Petitioner proposed this term be construed as "continuously and automatically." This construction was central to the argument that the specification, which describes a start-to-stop process, fails to provide written description support for the claims.
• "calculation parameter": Petitioner proposed this term be construed as "a mathematical operation." This supported the §101 argument that this claim element is an abstract mathematical concept.
• "mapping parameter": Petitioner proposed this term be construed as "a parameter to map data from one format or database to another." This construction supported the §101 argument that the claimed data transformation is an abstract idea.
• "zoom function": Petitioner proposed this term be construed as "a function that further limits a displayed data set." This supported the §101 argument that this element is a conventional, abstract function rather than a technical solution.

5. Relief Requested

• Petitioner requested institution of a Covered Business Method patent review and cancellation of claims 1-18 of the ’198 patent as unpatentable.