By Michael Borella --
In June 2014, the U.S. Supreme Court handed down Alice Corp. v. CLS Bank Int'l, establishing a now-infamous two-step, judicially-imposed test for patent subject-matter eligibility that narrowed the broad statutory eligibility principles set forth in 35 U.S.C. § 101. Under Alice, one must first determine whether a patent claim is directed to an ineligible concept such as an abstract idea, a law of nature, or a natural phenomenon. If so, the second step requires further determination of whether the claim as an ordered combination amounts to significantly more than just the ineligible concept. In theory, this framework was meant to prevent the sweeping preemption of fields of technology that ostensibly should remain in the public domain. In practice, however, the Alice test has proven exceedingly difficult to apply consistently, especially for software inventions. Despite software having a concrete manifestation on physical media and being used to change the state of tangible devices, it often gets lumped into the abstract idea category even when claimed so narrowly that it can only preempt a specific use case.
The disarray is such that even older precedents that were once shining examples of eligibility have been thrown into doubt. The Supreme Court's own 1981 Diamond v. Diehr decision, which upheld the eligibility of a patent on a computer-implemented rubber curing process, was reaffirmed as good law in Alice. Yet, the Alice test as currently applied could easily be used to argue that Diehr's claims are actually ineligible.[1] This uncertainty has real-world consequences, raising the risk and cost for small and mid-sized companies seeking to protect their innovations.
If Alice set the stage, the U.S. Court of Appeals for the Federal Circuit -- the court that hears all patent appeals from district courts and the United States Patent and Trademark Office (USPTO) -- has written the chapters that followed. The last decade has seen the Federal Circuit dramatically narrow the scope of patent-eligible software, decision by decision. First, many business methods were declared ineligible, then more and more software inventions implemented on a general-purpose computer, then even software on any platform, and eventually some non-software innovations got swept up as well.
This tightening chokehold is reflected in the Federal Circuit's own track record. In 2024, for example, the Federal Circuit decided 22 patent cases on substantive grounds of § 101 and found the claims eligible in only one.[2] In other words, a staggering 95.5% effective invalidity rate of patents on appeal. For patent owners, the Federal Circuit has become an abattoir for software patents, with only the rarest of claims surviving.
On the front lines of patent eligibility, the USPTO has tried to bring some stability to the chaos. The USPTO periodically issues guidance to help examiners (and applicants) navigate the morass of § 101 case law. A notable effort was the January 2019 Revised Patent Subject Matter Eligibility Guidance, which categorized abstract ideas into three buckets (mathematical concepts, methods of organizing human activity, and mental processes) and instructed examiners to consider a claim to recite an abstract idea only if it falls into one of those recognized categories. The 2019 guidance also introduced the notion of considering whether a claim involving an abstract idea integrates it into a practical application. If the claimed invention is applied in a specific manner that improves technology or another field, it might be deemed patent-eligible at step one despite involving an abstract idea. This gave applicants new arguments to overcome rejections by pointing to technological benefits in their inventions.
By many accounts, the 2019 guidance somewhat reined in the wild inconsistency of examiner decisions and led to a modest increase in software patent allowances . . . for a while.[3] However, unpredictability still rules the USPTO's application of Alice, especially across different examiner art units. Some examiners (particularly in business-method oriented units) continue to issue near-automatic § 101 rejections, while others in computer hardware, software, and communications art units might be more receptive if the applicant articulates a clear technical improvement. Appeals to the Patent Trial and Appeal Board (PTAB) are often an uphill battle -- recent statistics show the PTAB affirms examiners' § 101 rejections about 90% of the time.[4] In effect, unless you can fit your claim into the mold of a past case found eligible or an example from USPTO guidance, the safer bet is that the PTAB will say "no patent for you."
The subjective nature of Alice leaves room for reasonable minds to differ. And they do. The experience of practicing before the USPTO can feel like trying to shoot at a moving target. Even after the 2019 guidance, applicants faced divergent outcomes on similar inventions. Examiners have significant discretion in characterizing what a claim is "directed to" at step one and what counts as "conventional" at step two. Thus, a savvy applicant must preemptively stack the deck in their favor through careful drafting (more on that below).
In late 2023 and 2024, the USPTO began grappling with how emerging technologies like artificial intelligence (AI) fit into the eligibility framework. Under a mandate from former President Biden's 2023 Executive Order on AI, the USPTO issued an Updated Subject Matter Eligibility Guidance in July 2024 focusing on AI-related inventions. Many had hoped this update -- the first in almost five years -- would address some of the widely voiced concerns about the unpredictability of examining AI and software inventions. Unfortunately, the 2024 Guidance dashed those hopes.[5]
The update largely restated generic eligibility principles and added only a few AI-specific examples. Even worse, the guidance arguably doubles down on a hardline approach suggesting that advances in AI and uses of AI are likely ineligible unless they are implemented in specific hardware circuitry or cause a significant change to the state of an ancillary system. In other words, merely improving an AI algorithm in software might not satisfy the USPTO's idea of a practical application unless you tie it to a particular machine or a real-world effect, even if that improvement saves massive amounts of compute and storage capacity on the algorithm's host computer.
The Supreme Court, for its part, has repeatedly declined to hear new patent eligibility cases that might clarify the doctrine. This includes denying certiorari in 2022's American Axle case, which many hoped would address the Federal Circuit's overly aggressive application of the law of nature exception and maybe soften Alice's impact. In Congress, a bipartisan group of legislators has been pushing for reform. Senators Thom Tillis and Chris Coons, among others, recently re-introduced the Patent Eligibility Restoration Act (PERA) to rewrite § 101 and roll back some of the Alice-era exclusions. But this is not the first time that a version of PERA has been introduced, and the patent community is waiting for the bill to get much closer to being a law before giving it their full attention.
Thus, 2025 can be characterized as largely status quo in terms of patent eligibility. Stakeholders are still watching the Supreme Court and Capitol Hill for rays of hope, perhaps a sense that someone, somewhere is going to pull the eligibility doctrine back to solid constitutional ground. But there is no reason to believe that meaningful change will take place this year.
Given this challenging landscape, what can attorneys, applicants, and patentees do to improve their odds of surviving a § 101 challenge? While no strategy is foolproof (indeed, even the most meticulous drafting cannot guarantee eligibility under an uncertain test), there are techniques that can tip the scales at least a modest amount. Patent practitioners over the last decade have essentially reverse-engineered the patterns of decisions to develop a playbook for software patents. Below are some best practices as a mix of drafting tips and prosecution strategies to help prevent or overcome a § 101 challenge.
1. Focus on a specific technical improvement: Frame the invention as a solution to a technical problem, not a business. Put differently, the claimed invention should improve the operation or performance of machines rather than that of businesses or people. In the specification, clearly articulate the technological improvement or advantage the software provides. For example, does it make a computer run faster, use memory more efficiently, use less network capacity, or operate under reduced power requirements? Does it improve features fundamental and specific to computer technology, such as network security, data compression, parallel processing, or overall availability? The Federal Circuit has emphasized that software claims directed to an improvement in computer functionality are not abstract. Make sure the claims explicitly recite the features that form this improvement, and that the specification describes how those features solve a specific technical challenge. In short, tell a story of innovation in real-world technology rather than casting the invention of an automation of a business process or human task. In fact, try to avoid emphasizing or even mentioning any business process or human task at all.
2. Avoid outcome-driven claim language: Draft concrete, step-by-step claims that explain how the invention achieves its results. Purely functional or result-oriented claims (e.g., "determining a classification for the data using machine learning") are red flags. Instead, include the specific mechanisms or steps that carry out the improvement. If your invention uses an algorithm, spell out key steps of that algorithm rather than claiming just the end result. If it processes data, indicate how the data is processed in a new way. Broad and generic claims are especially vulnerable under § 101, so consider adding technical limitations. For instance, instead of "generating a network map," you might claim a specific step like "iteratively constructing a network map based on real-time telemetry data received from network nodes." This helps tie the idea to concrete procedures or components.
3. Recite hardware or real-world effects (when possible): One way to show a claim is not abstract is to root it in a physical context or device. If the software interacts with new or specialized hardware, include those details. Even if it's running on a generic computer, mention any sensors, controllers, or other devices that are part of the system and used by the invention. Similarly, if the software produces a tangible real-world result (e.g., controlling an industrial process, adjusting a camera's settings, or providing a specific type of medical treatment), emphasize that. Simply saying "by a computer" or "on the internet" is unlikely to help. But describing, for example, how a specific AI algorithm embedded in a medical imaging device yields clearer images for diagnosis will make the invention more concrete.
4. Highlight any non-conventional techniques: Under Alice step two (the inventive concept analysis), claims that merely use routine or well-known computer functions won't cut it. If your invention uses an algorithm or data processing technique that is not conventional, or combines steps in a unique way, call that out in the specification. The goal is to create a factual basis that, if someone later alleges that the claimed invention involves just standard computing, you can rebut that by pointing to your disclosure. After the Federal Circuit's 2018 Berkheimer decision and ensuing USPTO memos, examiners are supposed to provide evidence when they claim something is well-understood, routine, or conventional. While this policy is not always followed strictly, it arms you with an argument: if you have described why your solution is innovative at a technical level, you can insist that an examiner (or court) acknowledge those concrete details rather than ignoring them.
5. Include a statement of technical improvement in the specification: In the unpredictable world of software patents, the specification is your lifeline. Use it to explicitly teach why the invention is technologically significant. Don't assume the benefit is obvious. Include an explanation of the technical problem (e.g., "existing media distribution systems could not handle real-time network changes without significant adaptation delay, which led to failures in live streaming or broadcasting") and how your invention overcomes it ("the claimed embodiments provide a solution by incorporating an iterative machine learning model that dynamically updates a representation of the network in real-time, something not achievable with prior manual or static methods"). The statement of technical benefit can take various forms, but it should include descriptions of at least: (i) the technical deficiencies in previous systems, (ii) the how the claimed invention overcomes these technical deficiencies, (iii) as many of the claimed invention's technical advantages as you can come up with (e.g., "by reducing the number of database accesses by an order of magnitude, these embodiments use less computational, network, and power capacity than conventional techniques."). Finally, leave the door open for other technical improvements potentially flowing from the claimed invention as well as the possibility that this invention could be used to solve other technical problems not explicitly discussed in the specification.
6. Reinforce the technical improvement at every opportunity in the specification: Even a general statement of technical improvement might not be enough. As you describe and specify the invention, consider enhancing each and every feature with a sentence or two describing its technical improvement. The goal is to repeatedly hit the reader over the head with technical improvements, as well as to give you a number of locations in the specification to point to during prosecution or litigation that support the patent eligibility of the claims. One example might be, "The system pre-allocates memory blocks in a deterministic schedule based on static task profiling, avoiding dynamic memory access during execution. This eliminates runtime memory fragmentation and latency spikes in real-time systems, improving timing predictability and reliability and thus providing a concrete enhancement in computer memory management." Another example might be, "The scheduler dynamically assigns processor cores and their clock rates based on predicted energy consumption models for application tasks derived from historical sensor and usage data. Doing so reduces power consumption without user-perceivable performance degradation, directly improving hardware resource management in mobile computing."
7. Include performance results or data demonstrating an improvement: Benchmarking data, latency reductions, improved throughput, or lower resource usage can help substantiate that the invention provides a technical benefit. However, applicants must exercise caution -- if your claims recite an abstract idea, examiners and courts may construe performance gains as improvements to abstract idea itself rather than to the underlying computing technology. To mitigate this risk, the specification should clearly tie the performance benefits to specific technical features -- such as arrangements of software modules, hardware interactions, or architectural changes, rather than to general functional outcomes.
8. Add narrower embodiments that include more hardware or specific steps: In case the broad version of the claims hits an eligibility roadblock, these more focused embodiments might survive. For example, reciting specific hardware components such as a sensor, display controller, or network interface can help anchor the claim in concrete technology rather than abstract functionality. Similarly, adding detailed steps, like preprocessing data in a defined format, performing a particular type of signal transformation, or using a designated memory allocation strategy, can demonstrate that the invention is not merely a result-oriented abstraction. These narrower embodiments provide fallback positions during prosecution or litigation and can help show that the claimed invention improves the operation of a particular machine or system. In some cases, it may be beneficial to include at least one very narrow claim directed to the precise implementation over which protection is sought. This forces the examiner to engage with a concrete technical contribution of the invention rather than dismissing all possible implementations as highly general abstract ideas. Even if such a claim has limited commercial value on its own, it can serve as a foothold for establishing eligibility and opening dialogue during prosecution.
9. Be aware of USPTO examples and precedents: It can be helpful to draft claims that are comparable to ones that have been deemed eligible in the past. The USPTO's examples (from 2019 and the 2024 update) provide model claims that the USPTO purports to be eligible. If the invention is technologically similar to one of these examples, consider using language from the example in your specification. Nonetheless, some examiners are skeptical of this USPTO guidance, as it does not have the authority of Federal Circuit case law.
10. Don't over-rely on Enfish and McRo: While these Federal Circuit cases are still good law and provide useful guidance for arguing that software-based claims can be eligible when they improve the functioning of a computer itself, they represent relatively rare wins in a legal landscape that has grown more skeptical of software patents. Subsequent decisions have narrowed their reach, often distinguishing them on factual grounds or finding that later claims failed to recite comparable specificity. Courts now expect a more rigorous showing that the invention solves a technological problem in a non-generic way, preferably with supporting disclosures in the specification that demonstrate how the claimed advance is achieved and why it matters from a technical perspective. When drafting claims and a specification, do not assume that any similarities to the claims of Enfish or McRo will be given much weight by an examiner.
11. Always interview the examiner when you are dealing with a § 101 rejection during prosecution: Examiner interpretation of subject matter eligibility varies widely, and what one examiner considers a clearly abstract idea, another might view as a technological improvement. These differences are often shaped by the examiner's background, personal approach to the Alice framework, and the prevailing norms of their art unit. Different examiners and art units can have dramatically different § 101 rejection rates even within the same technical center. An interview gives you the opportunity to understand how the examiner is construing the claims, what part of the specification they find compelling (if any), and whether they are open to particular claim amendments or additional details that could overcome the rejection.
It bears repeating that even following all these best practices is not a guarantee. The legal standard for patent eligibility remains, to put it mildly, a work in progress. By heeding these lessons, however, particularly the careful tailoring of claims and the emphasis on detailed technical improvements in the specification, practitioners can significantly improve their chances of securing and defending software patents in this hostile environment.
[1] https://www.patentdocs.org/2021/04/could-alice-be-used-to-invalidate-diehr-of-course-it-could.html.
[2] https://www.patentdocs.org/2025/05/the-narrow-pathway-to-patent-eligibility-in-the-federal-circuit.html.
[3] Numerous attorneys report anecdotally that the rate of § 101 rejections in 2025 has increased over that of previous years.
[4] https://www.patentdocs.org/2024/08/91-that-is-the-rate-at-which-the-ptab-affirms-examiner-section-101-rejections.html.
[5] https://www.patentdocs.org/2024/07/uspto-publishes-updated-subject-matter-eligibility-guidance-focusing-on-ai.html.
Could it be, Michael, that following your advice how to make progress at the USPTO, namely to frame the invention as a solution to a technical problem, is exactly what is needed, also, to make progress in every other Patent Office, all around the world?
Could it be that this advice returns eligibility in the USA to its statutory foundation, namely to confine the grant of patent rights to improvements found within "the useful arts" (as that expression was understood back when the Constitution was written).
Could it be that the rest of the world adopted "technical" as its Litmus test precisely because it was modelling itself on the pathfinder US creation of a patent system?
Posted by: Max Drei | June 10, 2025 at 09:42 AM
Very helpful, thank you.
Posted by: kotodama | June 10, 2025 at 09:49 AM