Indefiniteness and Means-Plus-Function: Fintiv v. PayPal
| May 7, 2025
Case Name: FINTIV, INC., v. PAYPAL HOLDINGS, INC.
Decided: : April 30, 2025
Before: PROST, TARANTO, and STARK, Circuit Judges.
Summary
The Federal Circuit affirmed the Western District of Texas’s ruling that invalidated Fintiv, Inc.’s asserted claims against PayPal Holdings, Inc. on the basis of indefiniteness under 35 U.S.C. § 112 ¶ 6. The court held that Fintiv’s “payment handler” claim terms lacked sufficient structural disclosure and were therefore indefinite.
Background
Fintiv sued PayPal for patent infringement, asserting U.S. Patent Nos. 9,892,386; 11,120,413; 9,208,488; and 10,438,196. These patents relate to cloud-based transaction systems, described variously as “mobile wallet platforms” or “electronic payment systems.” The claims at issue recited a “payment handler” or “payment handler service” configured to use APIs of various payment processors or to expose a common API for interacting with them.
The ’386 and ’413 patents share a common specification, as do the ’488 and ’196 patents. The specifications of all four asserted patents are substantially similar. The key terms at issue in the case are the “payment handler” terms. These terms appear in the asserted claims as follows:
- ’386 patent, claims 1–3:
“a payment handler service operable to use [application programming interfaces (“APIs”)] of different payment processors including one or more APIs of banks, credit and debit cards processors, bill payment processors.” - ’413 patent, claim 1 (and similarly in claim 2):
“a payment handler configured to use APIs of different payment processors including one or more APIs of banks, credit and debit cards processors, and bill payment processors.” - ’488 patent, claim 1, and ’196 patent, claim 1:
“a payment handler that exposes a common API for interacting with different payment processors.”
After claim construction, the district court concluded that the “payment handler” terms were means-plus-function terms invoking § 112 ¶ 6 (pre-AIA, now § 112(f) in the AIA), and that the patents failed to disclose sufficient corresponding structures. All four patents are based on two provisional applications filed in 2011, and therefore fall under pre-AIA. The court held the claims indefinite and entered final judgment. Fintiv appealed.
Discussion
The central issue was whether the “payment handler” terms invoked § 112 ¶ 6. Although the claims did not use the word “means,” the district court held that the terms described functions without reciting sufficient structure. It found that words like “handler” and “service” were merely generic labels akin to the term “module.” The court emphasized that the surrounding claim language, including terms like “operable to” and “configured to,” described functions without imparting structure.
Fintiv argued that the term “payment handler” would be recognized by a person of ordinary skill in the art (POSA) as referring to a known type of structure, citing examples such as the Internet Open Trading Protocol (IOTP). Although Fintiv presented this as evidence of structural meaning, the court agreed with the district court and found that the term “handler” alone, and the “payment handler” terms as a whole, do not provide any structure for performing the claimed functions.
Fintiv also argued that the claim language defines the inputs, outputs, and operation of the payment handler. However, the court found that the claims and the specification, including the figures, do not provide sufficiently definite structure for the inputs, outputs, connections, or operation of the payment handler. Instead, the specification merely repeats the claim language without offering additional technical detail.
After determining that the payment handler terms were subject to § 112 ¶ 6, the court examined whether the patents disclosed corresponding structure for performing the claimed functions. Both the district court and the Federal Circuit found that the patents repeated the functional claim language without explaining how the functions were actually implemented.
Fintiv contended that the patents described a two-step algorithm: wrapping APIs and exposing a common API. The court rejected this, concluding that these so-called steps were nothing more than functional restatements and lacked the specificity required to inform a POSA how to perform the claimed functions. Without a disclosed algorithm or identifiable structure, the claims were held indefinite.
Technical Commentary
This case sets a high bar for software related patent applications, which would impose stringent requirements for disclosing functional models that serve specific design roles within a system. The court found the “payment handler” terms indefinite due to a lack of structural disclosure; however, this conclusion might be open to technical debate from a computer science perspective.
“Payment handler” alone may appear generic, but when tied to APIs as described in the claims, it might not be merely generic. Instead, it may reflect a specific design pattern commonly used in software architecture for implementing a handler component. In computer science, the use of APIs to abstract and manage interactions with multiple external systems is a well-known and standardized design pattern. The concept of “wrapping” APIs to unify interfaces across various systems has been widely practiced since at least the early 2000s. An API focuses on how code is organized and modularized, not on how internal tasks are executed algorithmically.
Courts have emphasized that when a general purpose processor performs a claimed function, the patent must disclose the underlying algorithm. However, in many software systems, APIs are part of a broader architectural design. When the API’s behavior is well-understood or supported by flowcharts or system diagrams showing data flows, this combination can be sufficient to convey structure for the system.
In this case, the court found the specification and figures insufficient to support the “payment handler” terms. However, the ’413 patent includes 23 interaction diagrams (Figs. 20A–22J), all illustrating interactions involving the payment handler. These figures provide multiple examples showing how the payment handler receives inputs and passes outputs. When read in context, the diagrams function as a software design guide that outlines system behavior and integration of modular components.
The claims are directed to a system, and within that system, the API is a defined component that plays its role in structuring and enabling its functionality. In this context, the API itself serves as a structural component of the overall system.
Expecting the specification to disclose an algorithm for such a structural component may not reflect how software systems are typically designed or understood by those skilled in the art. If a detailed claim analysis were to show that the system can perform its essential inventive function without requiring an algorithmic disclosure for the API, it would be arguable whether the term “payment handler” should be deemed indefinite.
Takeaways
- If a software claim recites only functional terms without disclosing how the function is performed, it may be at risk of being found indefinite for lack of supporting structure.
