by Dennis Crouch
In a case highlighting the ongoing challenge of claim construction in software patents, the Federal Circuit has affirmed the district court’s determination that Fintiv’s asserted claims are invalid as indefinite. Fintiv, Inc. v. PayPal Holdings, Inc., No. 2023-2312 (Fed. Cir. Apr. 30, 2025). In the software-element two-step, the court first held that the claim terms “payment handler” and “payment handler service” should be treated as “mean-plus-function” limitations under 35 U.S.C. § 112(f) because the claim terms used lacked inherent structural meaning; and then as a result found the claims invalid as indefinite because the specification lacked sufficient structural support. U.S. Patent Nos. 9,892,386, 11,120,413, 9,208,488, and 10,438,196.
The Statutes at Issues:
- 35 U.S.C. 112(b) Conclusion. The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
- 35 U.S.C. 112(f) Element in Claim for a Combination.
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claim terms:
- a payment handler service operable to use APIs of different payment processors including one or more APIs of banks, credit and debit cards processors, bill payment processors. ‘386 patent.
- 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. ‘413 patent.
- a payment handler that exposes a common API for interacting with different payment processors. ‘499 patent.
The Two-Step Means-Plus-Function Analysis
The Federal Circuit followed its familiar two-step analysis established in Williamson v. Citrix Online, LLC, 792 F.3d 1339 (Fed. Cir. 2015). First, determine whether the claim limitation is drafted in means-plus-function format, invoking § 112(f). Second, if it is, identify what structure, if any, disclosed in the specification corresponds to the claimed function. Finally, in cases lacking any disclosed structure, the claim is found invalid as indefinite under § 112(b). (Note that Fintiv was decided under pre-AIA law, but I use the AIA statutory numbering here).
Before getting into the analysis, I want to note my concern with cases like Williamson and their further extension into cases such as Fintiv. The approach raises significant concerns about analytical overreach in the way the court myopically focuses on isolated claim elements under § 112(f) and then immediately invalidates those claims as indefinite without considering the claim as a whole. This approach creates a procedural shortcut that bypasses traditional indefiniteness analysis that should ask whether the entire claim provides sufficient clarity.
Step One: Do the Terms Invoke § 112(f)?
Because the disputed terms do not use the word “means,” the court began with a rebuttable presumption that § 112(f) does not apply. However, the Federal Circuit agreed with the district court that PayPal successfully rebutted this presumption by showing that the “payment handler” terms recite function without sufficient structure. The court particularly found that the terms are “drafted in a format consistent with traditional means-plus function limitations” and merely replaced ‘means’ with ‘payment handler’ The connecting terms “that,” “operable to,” and “configured to” are used to describe functions, not impart structure.
Fintiv made several arguments against means-plus-function treatment:
- Individual term structure: Fintiv argued that both “handler” alone and the complete “payment handler” terms identify structure to persons skilled in the art, citing technical dictionary definitions showing “handler” as “a part of an operating system software or a special software routine which controls a device or function.”
- Prior case law: Fintiv pointed to cases like Dyfan, LLC v. Target Corp., 28 F.4th 1360 (Fed. Cir. 2022), where terms like “code” and “application” were found to connote structure, arguing that “handler” similarly denotes structure.
- Contextual evidence: Fintiv noted the patents describe the inputs, outputs, and operations of the payment handler, noting that it “wraps APIs of different payment processors” and “exposes a common API.”
- The Internet Open Trading Protocol: Fintiv cited the IOTP as extrinsic evidence that “payment handler” had a recognized structure in the art.
The Federal Circuit rejected all these arguments and distinguished this case from Dyfan where unrebutted expert testimony established that terms connoted structure and could be implemented with off-the-shelf technology. Here, the court credited testimony that a person of ordinary skill would not understand how to implement the recited functions of the payment handler terms. Ultimately, the court concluded that the term was simply a “black box” effectively the same as using the word “means.”
One aside of note here has to do with standard of proof used to make the underlying evidentiary claims regarding PHOSITA’s understanding. Although this was part of an invalidation, the court did not appear to require clear and convincing evidence for this aspect of the claim construction.
Step Two: Is There Corresponding Structure in the Specification?
Having determined that § 112(f) applies, the court then examined whether the specification discloses adequate corresponding structure for the claimed functions.
For computer-implemented means-plus-function claims, the specification must disclose an algorithm for performing the claimed function. In this case, the court found that the specifications “disclose no structure at all, much less an algorithm for performing the recited functions.”
Fintiv argued that the patents disclose a two-step algorithm:
- “wrap[s] APIs of different payment processors, such as, for example, banking accounts, credit/debit cards or processor 121” and
- “exposes a common API to facilitate interactions with many different kinds of payment processors.”
The Federal Circuit rejected this argument, finding that this mere parroting of functional language did not constitute an algorithm. The court stated that the specifications “merely refer[] to the generic process of translating APIs” and a POSA would not understand where the wrapping of APIs occurs or to what entity the common API is exposed.
This case serves as another important reminder for patent drafters working in the software space. Claims using functional language without the word “means” still risk means-plus-function treatment unless they recite sufficiently definite structure in the specification. The Federal Circuit continues to apply a demanding standard for computer-implemented means-plus-function limitations, requiring a algorithm beyond merely restating the function.
