Best Practices in Patent Drafting for Software and AI Inventions
Six habits that keep a claim eligible, clear, and hard to challenge — with the technical reasons behind each one.
By the iCuerious Research Team
Two applications can describe the same software idea and get completely different results at the patent office. One goes through. The other runs into rejection after rejection: the idea is called too abstract, a claim word is called unclear, the support in the specification is called too thin. Often the invention was fine. The drafting was not.
Software and AI inventions are especially easy to get wrong this way, because the things that trip them up are about how you write the application, not what you invented. Below are six drafting habits that keep a claim eligible, clear, and hard to attack later. For each one, it helps to understand the technical reason it matters, that is what tells you when to bend the rule and when not to. None of this is complicated. It just has to be done on purpose.
1. Claim the mechanism, not the result
The most common rejection for software claims is that the claim reads like a business goal running on an ordinary computer. Examiners call this an eligibility problem, a Section 101, "abstract idea" rejection, and it comes out of a two-part test. First the examiner asks whether the claim is "directed to" an abstract idea (a method of organizing human activity, a mental process, a mathematical concept). If it is, they ask whether the claim adds an "inventive concept" that amounts to significantly more than the idea itself. A claim that only states a goal fails both parts.
You clear the test by naming the actual technical step the software performs, not the outcome it produces. Claims that describe a specific improvement to how the computer works, a better data structure, a particular set of rules a person would not apply by hand, a new way of routing or storing data, tend to pass at the first step, because they are not "directed to" an abstract idea at all. That is the difference between claiming a result and claiming a mechanism.
For an AI feature, walk through the real pipeline and claim the part that is inventive: how the input is turned into a representation (say, an embedding or a feature vector), what the model does with it, and what happens to the output. "Personalize the interface" is a result, anyone can say it. "Generate an embedding from the item’s attributes and cluster it against stored embeddings" is a mechanism a competitor would have to copy. Wherever you can, point to a concrete technical gain: lower latency, fewer database calls, higher accuracy, or a manual step removed. There is a side benefit here too, claiming the specific mechanism instead of a broad function keeps the claim clear of the "purely functional" objection, where a claim is attacked for covering every possible way of getting a result while teaching only one.
2. Write steps and structure, not “modules”
Words like "module," "unit," or "mechanism" are risky in a claim. Courts can treat them as means-plus-function language, the Section 112(f) rule, which says a claim element written as a function is limited to the specific structure the specification describes for performing it. The trap for software is what counts as "structure." A general-purpose computer is not enough; courts have held that the structure for a software function has to be an actual algorithm in the specification, the steps, a flowchart, a formula. If the claim leans on "module" and no algorithm is disclosed, the claim can be struck down as indefinite.
It is worth knowing why "module" is singled out. Older law only applied the means-plus-function rule when a claim literally used the word "means." That presumption was loosened, and now a court will apply the same rule to any "nonce" word that acts as a stand-in for "means", and "module," "unit," "element," "mechanism," and "device" are the usual suspects. So, the safe move is to avoid them in claims entirely.
Write claims with plain verbs instead, receiving, embedding, clustering, synchronizing, storing, or with "one or more processors configured to…" followed by the actual operations. Note that "configured to" only helps if it is followed by real steps; "a processor configured to personalize content" is just a functional label wearing a hardware coat. The word "module" is perfectly fine in the specification, where you use it to describe the system. If a functional term genuinely can’t be avoided in a claim, make sure the specification spells out the steps or a flowchart behind it, so it reads as a described process rather than a black box.
3. Be careful with “at least one of” and other list phrases
This is a small phrase that quietly does real damage. "At least one of A and B" has been read by the courts to require at least one of each, in other words, both A and B, which is usually the opposite of what the drafter meant. One loose phrase can cut a claim’s scope in half, and nobody notices until it is challenged.
When you want a true either/or, write "one or more of." When you do use "at least one of," add a short line in the specification saying the phrase covers any of the listed items alone or in any combination, a definition like that can override the default reading. The same care applies to other list conventions. A "Markush" group written as "selected from the group consisting of A, B, and C" is a closed list, only those members, nothing else, so use it when you mean a fixed set, and don’t use "consisting of" when you actually want the list open. And keep an eye on antecedent basis: "the embedding" only makes sense if you earlier introduced "an embedding," or the claim can be called unclear.
4. Define every AI term in the specification
If a claim uses words like "embedding," "model," or "training," the specification has to actually describe them. This is really two separate legal requirements, both under Section 112. The written-description requirement asks whether the specification shows you actually possessed the invention, that you had a real, described version of it, not just a wish. The enablement requirement asks whether the specification teaches a skilled person how to make and use the full scope of what you claimed, without having to do their own research to fill the gaps. Thin support is where AI cases get weak, both during examination and later if the patent is challenged.
This matters more for AI than for most fields because AI claims are easy to write in broad, functional terms, "a model that predicts X", that cover far more than the specification teaches. Claiming a whole genus of solutions while describing only one is exactly the pattern courts have used to knock out functional claims for lack of enablement. The fix is to describe the pipeline concretely: the inputs (the features), the model (its type, and where it matters, its architecture), what it is trained to do (the objective and, at a useful level, the training data), and how it produces its output at run time, with at least one worked example. Naming the real techniques you use beats a generic "AI," and it also keeps the claim terms definite, which is a third Section 112 requirement.
Doing this well pays off twice. It supports the independent claim, and it gives you clean, described material to build dependent claims from, fallback positions you can retreat to during prosecution if the broad claim runs into prior art.
5. Claim the invention in all three forms
The same invention can usually be claimed three ways: as a method (a process), as a system (a machine), and as a computer-readable medium (the instructions themselves, stored on a disk or in memory). Each is a different legal category, and each catches a different infringer. This matters in practice: a method claim can be hard to enforce when the steps are split across more than one party, the user does one step, a server does another, because you generally need a single actor performing every step. A system or medium claim can capture the party that makes or sells the whole thing, sidestepping that problem. Having all three also helps the patent survive an attack aimed at just one category.
Two technical cautions here. First, keep each independent claim inside a single category, don’t mix a system and a method step in one claim (for example, "a system comprising… wherein a user selects…"). A claim that recites both an apparatus and a step of using it can be held indefinite, because it is unclear whether infringement happens when the system is built or when it is used. Second, for the medium claim, say "non-transitory" computer-readable medium. A bare "computer-readable medium" can be read to cover a transitory signal, which is not patent-eligible subject matter, and that one word avoids the objection.
Keep the three independents consistent with each other, and make sure the system and medium versions carry the same inventive step as the method, usually framed as "one or more processors configured to…" and "instructions that, when executed, cause…".
Instead of: One lonely independent claim carrying the whole invention.
Write: Three parallel independents: a method claim (“a computer-implemented method comprising…”), a system claim (“a system comprising one or more processors configured to…”), and a medium claim (“one or more non-transitory computer storage media storing instructions that, when executed, cause…”).
6. Put the “why it’s better” story in the specification
The clearest way past an eligibility rejection is to show the invention improves how the computer or system works, not just the business result. That improvement is what the second step of the eligibility test is looking for, and it is what separates the software cases that survive from the ones that don’t. But you can only argue an improvement that is actually on the page. If the benefit isn’t written down before examination, you generally can’t add it later, because you can’t put new technical detail into an application after it’s filed.
So, write the technical problem and its solution into the background and the detailed description. Say what the invention really improves: fewer repeated queries, less network traffic, lower storage or I/O, faster response, higher accuracy, or a manual step taken out. Then tie those benefits back to the specific claimed steps, so the improvement and the claim point at the same thing, a benefit floating free of the claim doesn’t help you. Where you can, give a number or a concrete before-and-after.
One balancing note: describe the benefit, but don’t over-sell it or over-narrow the invention while you’re at it. Strong words about what the invention "requires" or "must" do can come back later as limits on your own claim scope, or as admissions during prosecution that a competitor uses against you. Describe the improvement clearly, connect it to the claim, and stop there.
The thread running through all six
Every one of these habits comes back to the same idea: be specific, and put the specifics on the page. Claim the real step, not the goal. Use verbs, not vague nouns. Say exactly what a phrase covers. Describe the model instead of naming it. Cover all three claim forms, cleanly. Write down why the invention is better, and tie it to the claim. The legal doctrines behind these rules, eligibility, definiteness, written description, enablement, sound intimidating, but they all reward the same thing: an application that shows its work. A patent drafted that way is easier to grant, harder to design around, and far more likely to hold up if someone tries to knock it out.
Most software and AI applications aren’t lost on the invention. They’re lost on the drafting, and the drafting is the part you can control.
Where iCuerious comes in
Good drafting is a craft, and software and AI inventions raise the bar. iCuerious helps innovators and attorneys draft claims and specifications that stay eligible, read clearly, and stand up to scrutiny, from claiming the real mechanism to backing every AI term with the support it needs. If you’re preparing an application, or want a second set of eyes on claims before filing, we’d be glad to talk.
Talk to the iCuerious team → www.icuerious.com
