I. Introduction

The goal of the patent drafter is to envision the broadest possible framing of an invention without getting fully ensnared in the prior art. In pursuit of this goal, skilled drafters conceptualize the invention at the highest possible level of generality. In most if not all technical arts, this exercise isolates the objective and function of the invention, and the claims tend toward higher level functional terms. 

Functional claiming is an essential tool, and in some fields like software or computing, unavoidable.  Yet, accused infringers have strong defenses in invalidating functional claims as indefinite or ineligible for lacking the “how” of the function. The same deficiency drives invalidity under §112(f), §112(a), and §101, and AI can be used to systematically cure it.

II. The Convergence: One Problem, Three Doctrines

While practitioners debate the underlying merits of a disciplined distinction among the policies of definiteness and eligibility, the reality is that courts have converged three doctrines, §112(f), §112(a), §101, into the fundamental principle:  result oriented claiming is fatal; claims must recite the “how.”

This convergence is illustrated in the following table:

Across doctrines, patent owners must answer the question: How is the function actually performed?

III. Case Snapshots: What “Bad” Looks Like

A few examples drawn from the case law cement the multi-faceted problem of so-called “result-oriented” claiming.

Example 1 — Fintiv v. Paypal:  §112(f) No Corresponding Structure

Exemplary claim 1 of Fintiv’s patent 9,892,386 recites system claim elements with the following functional element that lacked corresponding support:

“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”

Fintiv failed to prevent application of a means plus function interpretation, and the specification merely parroted the claim function. Fintiv argued that the specification provided a two-step algorithm, but since it did not break down the function beyond the claim language, this argument failed. The specification lacked operational substance regarding how to implement the claimed function. 

Example 2 — Longitude Licensing v. Google: Ineligible Result Oriented Claim

Exemplary claim 5 of Longitude’s patent recites:

“main object determining module that determines the main object using the acquired position data and the results of analysis”

Longitude’s claims were held to be ineligible for being framed entirely in functional, resort-oriented claims.  The court concluded that each claim was directed to the same abstract idea of using data to identify an image’s subject and modifying image data based on that subject, stating that: “none of the claims described how these results are achieved.”

These failures are avoidable with architectural discipline in building functional claims and corresponding support. 

IV. The Solution: Hierarchical Functional Support

The solution is to construct hierarchical functional support as illustrated in the following table.

 In software systems, the “how” is not merely explanatory, it is the structure. All functions encompass, at some level, a result. Years in the future, in the context of enforcement or licensing negotiation, accused infringers will inevitably isolate one or more functions in claims and characterize them as “result-oriented” and then raise a phalanx of attacks under Sections 101 and 112. This risk can be mitigated by forcing a decomposition of the broadest functions into “how” layers. The distinction between good and bad functional claiming is careful building of “how” functions. 

The first step is to articulate function at the broadest statement of key points of novelty, keeping mind the closest prior art.  This establishes claim breadth and sets the foundation for building a hierarchy of varying levels of functional detail. This first step entails building a diversity of claim sets, with independent claims built around varying expectations of points of novelty.  

The second step is then to build operational sub-functions for the level 1 functions. This exercise explicitly encompasses decomposing level one functions into operational how elements. Each level one function is decomposed into sub-functions. For computer implemented inventions, this begins the process of constructing algorithmic structure, for both inclusion in the claims as well as hierarchical structure of components and their sub-components in the specification.

In the second step, the “how” elements provide a foundation for written description support and eligibility risk mitigation. These “how” elements provide a roadmap for a structured detailed description that meets written description and enablement requirements. For computer implemented inventions, the how elements recite algorithms, preferably a technical solution to a technical problem, at their highest level of generality.  

The third step is to build the next level of detail in the form of example embodiments. Preferably, they provide alternatives and algorithms for implementing the level 2 functions.

V. Dual-Track Claim Strategy

A valuable exercise is to employ a two-track claim strategy, with a first track forming means plus function claims and a second track forming claims composed of “how” elements without expressly invoking means or step for elements.  In track 1, the high level functions in levels 1 or 2 are constructed as “means for” functions. This forces the discipline of expressing a level 1 function at a high level of generality with corresponding “how” structure described in the specification.  

In track 2, the level 2 functions are recited as “how” elements in independent claims to defeat a result-oriented claim and build claim differentiation relative to the track 1 claims. This increases robustness of attacks under §101 (Longitude) and § 112 (Williamson). 

The following table provides a simplified summary of the approach.

The hierarchy in the specification enables claim diversity without inconsistency.

VI. AI prompting as a Controlled Workflow 

AI-based drafting tools, primed with a strong invention disclosure and prior art, and driven by well-structured prompts, are exceptionally effective in ensuring the hierarchy is properly constructed.

The workflow is:

1. Start with an invention disclosure that outlines points of novelty and technical solutions, preferably paired with prior art analysis and references.  

2. With or without the AI drafting tool, construct an initial set of claims, explicitly laying out components at level 1 and at least initial drafts of level 2 “how” elements. 

3. Apply Prompt Templates 1–3, described below, to the draft claims: 

   • hierarchy extraction 

   • algorithm expansion 

   • anti-result refinement 

4. Build spec iteratively 

AI tools must derive the hierarchy from the disclosure with auditable citations to ensure the invention is traceable to the inventors, not the AI tool.

VII. Prompt Templates 

AI-assisted drafting only adds value if it is controlled, source-grounded, and hierarchical. The following prompt structures enforce that discipline while maintaining traceability to the inventor’s disclosure.

Template 1 — Function-to-Hierarchy (Source-Grounded)

For each functional element in the claim, generate a three-level hierarchy:
(1) functional objective;
(2) 3–5 sub-functions describing how it is achieved;
(3) at least two implementation approaches per sub-function.
For each Level 2 and Level 3 item, provide citations to the invention disclosure.
If no support exists, explicitly flag the gap.

Purpose:
Forces decomposition of results into “how” layers while maintaining auditable linkage to inventorship.

Template 2 — Algorithmic Structure Builder (§112(f))

For each sub-function, generate corresponding structure including:
step-by-step logic, inputs/outputs, and optional pseudocode.
Tie each step to disclosure support with citations.
Where disclosure is partial, identify gaps and label any inferred implementation.

Purpose:
Operationalizes the principle that algorithm = structure for computer-implemented inventions.

Template 3 — Anti-Result-Oriented Stress Test

Identify claim elements that are result-oriented or circular.
Rewrite each to include intermediate “how” steps while preserving scope.
Provide disclosure support for each revision and flag unsupported elements.

Purpose:
Directly addresses the failure mode identified in cases like Longitude—claims that describe what but not how.

VIII. Litigation Lens

From a litigation perspective, the attack vectors are predictable:

• “Nonce term” characterization → triggers §112(f) under Williamson v. Citrix 

• Absence of algorithmic structure → indefiniteness under §112(f) 

• Overbroad functional scope → lack of enablement under §112(a) 

• Result-oriented claiming → ineligibility under Longitude Licensing Ltd. v. Google LLC 

The common thread is the same: the claim recites a function, but the claim or specification fails to explain how that function is achieved across its scope.

Hierarchical functional support neutralizes these attacks:

• Level 2 decomposition demonstrates operational substance and highest level of algorithm

• Level 3 algorithms provide additional corresponding structure 

• Multiple implementations support full-scope enablement 

• Explicit “how” elements align claims with technical solutions to technical problems 

Courts do not reject functional claiming. They reject unsupported functional abstraction.

IX. Checklist

A disciplined AI-assisted workflow should satisfy the following:

Per Functional Element

• Decomposed into 3–5 sub-functions (Level 2) 

• At least two implementation paths per sub-function (Level 3) 

• Algorithmic steps disclosed (not just labels) 

• Inputs, outputs, and data transformations identified 

• No circular or self-referential definitions 

Specification-Level

• Hierarchy supports both MPF and non-MPF claim strategies 

• Corresponding structure exists for each functional element 

• Multiple embodiments support scope breadth 

• Gaps in disclosure identified and resolved with inventor input 

Eligibility Alignment

• ☐ “How” elements tied to a technical solution 

• ☐ Claims avoid purely result-oriented framing 

• ☐ Operational steps reflect improvement over prior art

X. Conclusion

Functional claiming is not going away. In modern systems, particularly software-defined architectures, it is the only practical way to capture the breadth of an invention. What has changed is the level of scrutiny applied by courts.

Across §112(f), §112(a), and §101, the Federal Circuit is converging on a single requirement: claims must be grounded in a disclosure that explains how the function is actually performed.

AI tools, when properly directed, enable a level of drafting discipline that was previously difficult to achieve consistently. They can systematically decompose functions, generate alternative implementations, and build the layered disclosure necessary to support broad claims. But this value only emerges when the process is controlled, and when the hierarchy is derived from the inventor’s contribution and supported by traceable disclosure.

The advantage is not in using AI. It is in using AI to enforce rigor.

The practitioners who succeed will be those who can answer, at every level of abstraction, the question courts now consistently ask: how does it actually work?