What Fintiv v. PayPal Means for Software and AI Patent Practice

“Obviously there are some problematic aspects [of this opinion] for those of us drafting patent applications in the AI space.”

This past Wednesday, the U.S. Court of Appeals for the Federal Circuit issued a precedential decision affirming a district court holding that the software term “payment handler” was a “nonce” term for functional language that followed it, thereby invoking 35 U.S.C. § 112, sixth paragraph, as mean-plus-function claiming. The Federal Circuit then held that the corresponding patent specifications did not recite sufficient structure that corresponded to the claimed function, making the “payment handler” element indefinite and therefore invalidating the associated patents.

While the opinion did not concern artificial intelligence (AI) per se, it is easy to see how it might carry over into AI inventions. Let’s begin by examining some of the more problematic aspects of the opinion, and then move on to ways to draft AI patent applications in light of the decision itself.

What the Court Said

The Federal Circuit began its opinion by addressing whether the term “payment handler” was functional language that overcame the presumption against invoking § 112 ¶6 in instances where the term “means” is not used. The Federal Circuit held that the presumption was overcome in this instance since “the payment-handler terms recite function without reciting sufficient structure for performing that function.” The Federal Circuit went on to explain that the district court “correctly analogized ‘handler’ with the nonce term ‘module,’ which we have determined was ‘simply a generic description of software or hardware that performs a specified function.’”

The opinion then remarked that while the connecting terms that followed “payment handler” – terms like “that”, “operable to,” and “configured to” – are “more often used with structural terms rather than non-structural ones,” there was in fact no blanket rule that claims that recite such phrases connote structure and “necessarily avoid[] means-plus-function claiming,” citing Rain Computing, Inc. v. Samsung Electronics America, 989 F.3d 1002, 1006 (Fed. Cir. 2021). Rather, “the applicability of § 112 ¶ 6 depends on the specific context of the patent at issue.” With this in mind, the Federal Circuit then held that “payment handler” followed by function was still purely functional claim language that recited no structure.

The Federal Circuit also rejected the argument that the payment-handler terms from the claims are a class of software structures that do not invoke means-plus-function claiming in a way that’s akin to the sufficiently structural terms “code” and “application” from the Federal Circuit’s opinion in Dyfan, LLC v. Target Corp., 28 F.4th 1360 (Fed. Cir. 2022). But in contrast Dyfan, here there was no expert testimony that the term “payment handler” would be known by skilled artisans to connote structure and, “[a]s used in the claims, the payment-handler terms are no more than a ‘black box recitation of structure’ that can operate as a substitute for ‘means.’”

The court then rejected the argument that the claim language surrounding “payment handler” defines the inputs, outputs, and operation of the payment handler in such a way as to confer sufficient structure on the term itself. The reason the Federal Circuit rejected that argument is that the other claim limitations in the present instance still did not outline the “rules” that the payment handler would follow, and the term “payment handler” itself does not have a known meaning.

It is at this juncture that the Federal Circuit remarked (for the second time) that “the sole textual support in the specifications for the payment-handler terms merely parrots the claim language.” As in, the drafter didn’t expand on what structure might be conferred on that term and simply made sure the term itself appeared in the written description.

This, in turn, resulted in the Federal Circuit invalidating the patents on the basis of the shared specification failing to disclose any corresponding algorithm for the functional “payment handler” terms recited in the claims.

What Now?

So, what to make of this? Obviously there are some problematic aspects for those of us drafting patent applications in the AI space. This is because components of an AI system are often referred to in functional terms – think of a “classifier,” for instance. And as much as I’ve tried not to, I’ve acquiesced in claiming things in such terms myself because that is the nature of AI – a black box often characterized more so by what it does than what it is.

Now, I’d like to think AI terms like “classifier” are much more akin to “code” and “application” at this point, since the term has been around for a while and many skilled artisans would undoubtedly recognize the term as connoting structure. But what about terms that aren’t as commonly-used and accepted?

Well, one fallback would be to make sure you’re not just parroting the language of the claims in the specification for written description purposes. Rather, as much detail as possible should be disclosed on the actual algorithm(s) being used to provide a backstop to an indefiniteness challenge if one of your AI claim terms is held to be purely functional.

For instance, terms like “feed-forward neural network”, “convolutional neural network”, and “generative pre-trained transformer” arguably impart additional structure, should they be disclosed in the written description. It would be nice to have a term like that in the specification when trying to save a patent if a court holds that the corresponding claim term is functional in nature. After all, each one of those AI models is itself an algorithm.

The next thing to remember is that terms like “configured to” and “operable to” do not always confer structure on an otherwise functional claim term. So, to the extent you can, avoid using a functional-sounding noun followed by more functional language after the “configured to” phrase. Instead, consider using AI terms for which a better argument can be made that they connote structure.

For instance, the term “model” seems much more akin to “application” or “code” that is structural rather than functional in nature, and since “model” itself is still a fairly broad term, maybe consider using that term instead of something that seems more functional on its face but is still at its core a “model”. As another fallback, perhaps use a few dependent claims to more particularly define what kind of model is being used.

These are all just suggestions – no one knows which way the Federal Circuit will rule on any given claim term. But they might just give you a better chance than the “payment handler” patents the Federal Circuit just struck down.

Image Source: Deposit Photos
Author: Wavebreakmedia
Image ID: 81996574