PTAB

CBM2014-00132

DealerSocket Inc v. AutoAlert LLC

Key Events

Petition

petition Intelligence

Title: System and Method for Assessing and Managing Financial Transactions
Brief Description: The ’461 patent describes a computer-implemented method and system for identifying potential vehicle sales opportunities, known as "pull-ahead" transactions. The system analyzes customer and vehicle financial data to determine if a customer can trade their current vehicle for a new one with a comparable monthly payment.

Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that the challenged claims are directed to the abstract idea of performing basic mathematical and financial calculations. The core of the claimed method involves calculating new vehicle payments based on estimated equity and comparing the new payment to the existing payment against a preset threshold. Petitioner contended these are fundamental economic practices and mathematical manipulations that are not patent-eligible.
- Key Aspects: The petition asserted that the claims add only conventional pre-solution activity (gathering financial data) and post-solution activity (generating an alert) to the abstract calculations. It argued that performing these steps on a generic computer to increase speed and scale—the inventor’s stated contribution—is insufficient to transform the abstract idea into a patent-eligible invention, as the computer is not integral to the process and only provides a more efficient tool for an otherwise manual set of calculations.

Prior Art Relied Upon: VanCleave (declaration describing manual automotive sales prospecting processes from the 1980s) and Allan (declaration describing the manual "Pre-Trade" program sponsored by Ford Motor Company in 1983).
Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that the claimed invention is merely the obvious automation of a well-known, manual business practice for identifying sales leads. The declarations from automotive industry veterans described a long-standing manual process that included all key steps of the claimed method: (1) retrieving customer financial and vehicle information from files, (2) retrieving information on potential replacement vehicles, (3) calculating the customer’s equity, (4) calculating a potential new payment, and (5) comparing the new and old payments to identify a sales opportunity. Petitioner contended the claims simply recite performing this known analog process on a computer.
- Motivation to Combine: A person of ordinary skill in the art (POSITA) would be motivated to automate this known, labor-intensive manual process to improve efficiency, speed, and the ability to analyze an entire customer database rather than just a few records at a time.
- Expectation of Success: A POSITA would have a high expectation of success in applying well-understood computer automation to a routine, calculation-based business process.

Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued the claims lack written description support because they improperly combine elements from two distinct and mutually exclusive processes disclosed in the specification: a "modified-financial-variable batch process" (triggered by new data) and a "customer-specific real-time process" (triggered by a specific customer inquiry). The specification allegedly describes these as alternative modes of operation, providing no basis for a hybrid claim that recites receiving a real-time, customer-specific request ("configuration request") to trigger a process that assesses the impact of changed information, an element of the batch process.
- Key Aspects: The petition also asserted that key claim terms are indefinite. For example, "configuration request" is allegedly not defined or described in the specification, leaving the scope of the claim unascertainable. Similarly, the term "may affect" was argued to be insolubly ambiguous because information that "may affect" favorability is indistinguishable from information that "may not affect" favorability, making it impossible for the public to determine the claim's boundaries.

"batch process" and "in real-time": Petitioner argued these terms are well-understood in the art to be mutually exclusive. "Batch process" refers to processing accumulated data without user interaction, while "real-time" refers to processing that responds immediately to external inputs. Because the specification uses the terms consistent with these distinct meanings, Petitioner contended that dependent claim 10—which recites retrieving information "in real-time" as part of a "batch process"—is indefinite due to an irreconcilable contradiction.
"configuration request": Petitioner argued this term is indefinite because the specification provides no guidance as to what the request configures or how it functions. The term does not appear in the specification, and its plain meaning in the context of the claims is unclear, rendering the scope of the independent claims unascertainable.

Inoperability: Petitioner argued the claimed method is inoperable and fails the utility requirement of §101. The claims require "determining...whether the changed retrieved information may affect whether it is favorable" for a customer to replace a vehicle. However, the subsequent calculation steps only determine if a favorable deal exists based on all available data; they do not isolate or determine the specific effect of the "changed" information on that outcome. Therefore, the claimed method allegedly does not perform its recited function.

Petitioner requests institution of a Covered Business Method patent review and cancellation of claims 1, 3-5, 7, 9-11, and 15 of Patent 8,095,461 as unpatentable under 35 U.S.C. §§ 101, 103, and 112.