There is an old prosecution truism that a patent application is only as strong as its weakest claim. In the post-Alice era, that truism has taken on a sharper edge: a patent application is only as durable as its response to a § 101 rejection that a competent examiner can always raise, that the Federal Circuit can always sustain, and that a defendant in litigation will almost certainly attempt. The question is not whether § 101 will be an issue for your software, AI, or technology invention. It almost certainly will be. The real question is whether you waited until the rejection arrived — or whether you drafted with § 101 survival in mind from the very first claim.
This article is about the second approach. It covers the claim drafting strategies, specification architecture, and case law-backed principles that give technology inventions the best possible foundation for surviving § 101 scrutiny — before a rejection is ever issued.
Why Drafting for § 101 Matters More Than Responding to It
Most patent practitioners have encountered the situation: a well-meaning application comes in, the claims are drafted around a functional result, the specification describes the invention at a high level of abstraction, and six months later the examiner issues a § 101 rejection that cannot be cleanly overcome without a claim amendment that concedes significant scope. The application survives, perhaps, but the patent that issues is narrower than it needed to be — and the prosecution history now contains arguments that a future defendant’s lawyer will use to constrain enforcement.
The better path is to make § 101 concerns part of the drafting conversation from day one. This does not mean writing narrow claims. It means writing claims that are grounded in specific technical structure, supported by a specification that explains the technical problem and the technical solution in concrete terms, and framed in language that tells the examiner—and ultimately a court—exactly what the invention improves and how.
Understanding Why Claims Fail § 101: The Real Diagnostic
Before prescribing drafting strategies, it is worth being precise about why claims actually fail under the Alice/Mayo framework. The failure is almost never that the invention is genuinely abstract in any philosophical sense. Most failing claims represent real engineering work solving real technical problems. The failure is a drafting failure—the claims describe the end state (the result) rather than the technical means by which that result is achieved. They read, from an examiner’s perspective, as: “use a computer to do [abstract concept].”
The Federal Circuit’s 2025 decision in Recentive Analytics v. Fox Corp. is the clearest recent articulation of this distinction. The court held that applying established machine learning methods to a new data domain—optimizing TV broadcast schedules—was patent ineligible because the claims lacked specific technological improvement. The invention told you what the ML system achieved, not how the system’s architecture or methodology was technically distinct from prior approaches. The lesson is not that machine learning inventions are ineligible. The lesson is that machine learning inventions must claim the technical improvement, not the business result.
Contrast this with Enfish LLC v. Microsoft Corp. (Fed. Cir. 2016), where the claims were directed to a specific self-referential table structure — a particular data structure with defined relationships between rows and columns — that allowed a computer to store and retrieve data more efficiently than prior relational table designs. The court found these claims eligible precisely because they were directed to an improvement to how the computer itself operates, not to an abstract concept of data organization. The claims described a technical mechanism, not an outcome.
This is the central diagnostic: ask yourself, for every independent claim you draft, whether it reads as a technical mechanism or as a desired outcome. If the honest answer is “outcome,” the claim needs more work before it leaves the office.
Eight Drafting Principles for § 101 Survival
1. Identify the Technical Problem Before Writing a Single Claim
This step sounds obvious but is routinely skipped. Before drafting, you should be able to articulate — in one or two sentences — the specific technical limitation in the prior art that the invention addresses. Not the business problem. The technical problem. What breaks in a prior system? What computational inefficiency exists? What processing bottleneck, memory constraint, data structure limitation, or system architecture flaw does the invention correct?
For an AI application predicting equipment failure, the technical problem is not “equipment fails unexpectedly.” The technical problem might be: “Prior prognostic models require full retraining on new equipment classes, causing catastrophic forgetting of previously learned fault patterns, and resulting in increased computational overhead and reduced model accuracy during transition periods.” Now you have a technical problem that anchors a technical solution. The claims can be written around that anchor.
This is the problem-solution approach applied at the drafting stage. It is the framing that Director Squires’ “Three Pillars” framework supports, that the MPEP 2106.05(a) analysis rewards, and that the Federal Circuit’s eligibility opinions consistently validate.
2. Claim the Technical Mechanism, Not the Functional Result
The single most consequential drafting decision in a technology patent application is whether the independent claim describes a technical mechanism or a functional result. This distinction drives nearly every § 101 outcome.
A claim that recites “a method of improving network security comprising receiving network traffic data, analyzing the data for anomalies, and generating a security alert” is claiming a functional result. It tells you what the system does, not how it does it differently from prior systems. It will face a § 101 rejection and will likely not survive it.
A claim that recites “a method comprising generating, for each incoming network packet, a behavior profile comprising a feature vector of temporal transmission intervals and payload entropy values; comparing the feature vector against a dynamically updated baseline derived from rolling n-period averages stored in a non-relational memory structure; and generating a threat score when the comparison exceeds a statistically defined deviation threshold” is claiming a technical mechanism. It describes a specific computational architecture—the feature vector construction, the memory structure, the statistical comparison—that a court can evaluate as either conventional or unconventional.
The level of technical specificity in the second claim is not an accident of style. It is a deliberate drafting choice that transforms the claim from an abstract idea into a concrete technical implementation.
3. Name the Data Structure, Algorithm Architecture, or Hardware Constraint
Following from the previous principle, claims that pass § 101 scrutiny almost always name something specific: a particular type of data structure, an architectural feature of the algorithm, a hardware constraint being addressed, or a defined relationship between system components. Enfish named the self-referential table. McRO v. Bandai Namco (Fed. Cir. 2016) named the specific rules that defined the lip synchronization process. Finjan v. Blue Coat (Fed. Cir. 2018) named the behavior-based security profile—a new kind of file—that enabled a computer security system to do what it could not do before.
In each of these cases, naming the specific technical feature grounded the claim in something concrete that could be assessed as either an improvement to technology or an application of an abstract concept. It gave the court and the examiner something to hold onto. Vague functional language gives them nothing.
4. Show an Improvement to the Functioning of the Computer or System Itself
MPEP 2106.05(a) provides the clearest safe harbour available in § 101 drafting: claims directed to improvements in the functioning of a computer itself, or improvements to another technology or technical field, integrate the judicial exception into a practical application and survive the Step 2A Prong Two analysis. The question is whether your claim is directed to such an improvement.
This does not require the invention to be hardware-level. Software improvements count—Enfish established this clearly. But the improvement must be to the technology, not to what the technology enables a business to do. Faster processing, reduced memory consumption, improved accuracy of a technical function, more efficient data retrieval, and reduced network overhead—these are improvements to technology. Higher revenue, better user retention, faster customer service — these are business outcomes and do not satisfy MPEP 2106.05(a).
Draft your independent claims to make the technical improvement explicit within the claim language itself, not merely in the specification. A claim that recites “wherein the non-relational memory structure reduces data retrieval latency by eliminating join operations required in prior relational architectures” is both describing the technical improvement and building a prosecution record that supports Prong Two arguments if a rejection is ever raised.
5. Avoid Pure Functional Claiming Without Structural Support
Means-plus-function claiming under § 112(f) is a separate issue, but the underlying drafting problem it represents — claiming functional results without structural support — maps directly onto § 101 vulnerability. A claim that describes only what a system does, without describing how it does it at a level of technical specificity, invites both a § 112 indefiniteness rejection and a § 101 abstract idea rejection simultaneously.
The fix is structural: pair every functional recitation with at least one structural or architectural element that defines how the function is performed. “Analysing the data” becomes “analysing the data using a recurrent neural network architecture in which hidden state vectors from previous time steps are incorporated into the current prediction via gated memory units.” “Generating a recommendation” becomes “generating a ranked recommendation vector by applying a weighted cosine similarity function to embedded user preference vectors stored in a k-dimensional indexing structure.”
The added specificity serves three purposes at once: it defeats functional claiming objections under § 112, it grounds the claim in a technical mechanism for § 101, and it potentially creates an inventive concept argument for § 101 Step 2B if needed.
6. Build a Specification That Explains the Prior Art Problem and the Technical Departure
The specification is not window dressing. In § 101 prosecution and litigation, a well-drafted specification is often the deciding factor between a surviving claim and an invalidated one. Berkheimer v. HP Inc. (Fed. Cir. 2018) confirmed this directly: whether claim elements are “well-understood, routine, or conventional” — the Step 2B question — is a question of fact, and a specification that describes an unconventional combination or approach can create a genuine dispute of fact that defeats summary judgment on § 101 grounds.
Draft the specification to tell a complete technical story: what the prior art did, why it was technically limited, what your invention does differently at the architectural or algorithmic level, and what measurable technical benefit results. Quantify where possible. “The self-referential table of the present invention reduces memory footprint by approximately 40% compared to conventional relational tables in the described benchmark” is far more useful to a § 101 defence than “the present invention provides improved performance.” Finjan teaches the same lesson: if your client is a pioneer and the invention is technically significant, the specification must explain that in depth, with technical rigour, not marketing language.
One specific drafting habit worth developing: write at least one section of every technology specification explicitly titled “Technical Improvements” or “Advantages of the Present Invention” that describes improvements in technical terms, not business terms. This section becomes the foundation for every Prong Two and Step 2B argument in prosecution and every § 101 expert report in litigation.
7. Draft Dependent Claims as an Insurance Policy — and as an Opportunity
Independent claims set the scope. Dependent claims protect it. In the § 101 context, dependent claims serve an additional function: they progressively add technical specificity that can support eligibility arguments when broader independent claims face challenges. Each dependent claim that adds a concrete technical feature—a specific algorithm, a defined data structure, a hardware interaction, a measurable parameter—becomes a fallback position that preserves commercial value while potentially offering a path to allowance that does not require wholesale rewriting of the independent claim.
Draft at least three to five dependent claims per independent claim that add distinct, substantive technical features rather than merely narrowing numerical ranges. Think of them as the technical detail that the independent claim deliberately omits for breadth — the architectural specifics, the defined algorithmic steps, the system interaction constraints — each of which, if added to the independent claim, would make it clearly eligible but narrower than needed.
8. Use the USPTO's Eligibility Examples as a Drafting Checklist Before Filing
The USPTO’s 49 subject matter eligibility examples — including the three AI-specific examples published with the July 2024 guidance update — are among the most underutilised drafting tools available. Before filing any technology application, run a mental checklist against the examples most relevant to your invention’s field. If your claim structure maps to an eligible example, document that mapping in your prosecution notes. If it maps to an ineligible example, identify the specific differences and ensure those differences are explicit in the claim language and the specification.
This exercise takes thirty minutes and can save months of prosecution and years of litigation exposure. It is the drafting equivalent of examining prior art before drafting claims—standard practice that is too often skipped for § 101 specifically because the eligibility analysis feels more like a legal argument than a technical assessment. It is both.
The Specification-Claim Alignment Requirement
One principle underlies all eight strategies above: the specification and the claims must tell the same technical story. A specification that explains a sophisticated technical improvement provides no § 101 protection if the claims are drafted at a level of abstraction that reads on the abstract concept rather than the specific improvement. Conversely, claims that recite specific technical features are vulnerable if the specification provides no support for why those features are unconventional or technically significant.
The alignment between specification and claims is where § 101 drafting comes together. The technical problem identified in the background section should correspond to a specific claim element that addresses it. The technical improvement described in the detailed description should correspond to specific claim language that captures it. The measurable benefit articulated in the specification should correspond to functional language in the claims that reflects it.
When a court or examiner reads the claims and specification together — which is always how they are read — the technical story should be coherent, consistent, and specific.
The 2026 Drafting Environment: A Window Worth Using
Director Squires’ three-pillar framework and the precedential Ex Parte Desjardins decision signal that the current USPTO is prepared to support eligibility for AI and technology inventions that are drafted with technical specificity. The SMED practice formalised in December 2025 creates a prosecution tool that can be anticipated at the drafting stage — applications whose specifications are written with measurable technical improvements and specific architectural departures from prior art are precisely the applications for which a SMED will be most effective if a § 101 rejection is later raised.
The Federal Circuit, meanwhile, has not moved as far as the Office. Recentive Analytics in 2025 and GoTV Streaming v. Netflix in February 2026 confirm that courts remain prepared to invalidate claims that are directed to abstract application of known methods, regardless of the technology field. The drafting principles in this article are calibrated to survive both the examiner’s desk and the district court — not just the current institutional climate.
Protect Your Innovation
Schedule your consultation with our expert IP attorneys to secure your assets and scale your brand globally. Partner with us to build a lasting legacy.
Disclaimer
This article is for general informational purposes only and does not constitute legal advice. Please consult a registered patent attorney for guidance specific to your application or portfolio.