What Fintiv v. PayPal means for Software and AI Patent Practice
“There are obviously some problematic aspects [of this opinion]
For those of us drafting Patent applications in the AI Space.”[]This Wednesday, the U.S. Court of Appeals, Federal Circuit, issued a precedent decision affirming a District Court holding that the software phrase “payment handler” is a “nonce term” for functional language that follows it, SS 112, sixth para, 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. The Federal Circuit held that the presumption was overcome in this instance because “the payment-handler terms recite function without reciting sufficient structure for performing that function.” 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.'”[a]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 SS 112 P 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). The Federal Circuit rejected that argument because the other claim limitations in the present instance did not outline the “rules” that the payment handler would follow, and the term “payment-handler” itself does not have a known meaning. 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? What now?
So, what to make of this? It’s because AI components are often described in functional terms. Think of a “classifier,” as an example. I would like to think that AI terms such as “classifier” are more similar to “code” or “application” now, as the term has been used for a long time and many skilled artisans will recognize it as connoting a 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 helpful to have a term such as that in the specification if the court rules that the claim term is purely functional. 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. Avoid using functional-sounding words after the “configured” 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”. Use dependent claims as a fallback to better define the type of model being used. 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
