TL;DR
Patent claims define the legal boundaries of your patent. They determine what you own and what others cannot copy. An independent claim stands alone and describes the broadest version of your invention. A dependent claim adds specificity by referencing an independent claim and narrowing it further. For software patents, claims must describe concrete technical implementations, not abstract outcomes, to survive §101 eligibility scrutiny. Every claim is a single sentence with three parts: a preamble, a transition, and a body. Getting claims right is the single most important part of your patent application.
Key Definitions
- Claim
- A single, precisely worded sentence in a patent application that defines the legal boundaries of the invention. Claims are what get enforced in court.
- Independent Claim
- A claim that stands on its own and contains all the elements necessary to define the invention. It does not reference any other claim.
- Dependent Claim
- A claim that references an independent claim (or another dependent claim) and adds further limitations or specificity. It inherits all the elements of the claim it depends on.
- Preamble
- The opening portion of a claim that identifies what the claim is directed to (for example, “A system comprising” or “A computer-implemented method comprising”).
- Transition
- The word or phrase that connects the preamble to the body of the claim. “Comprising” is the most common and is open-ended, meaning the invention can include additional elements beyond those listed.
- Body
- The portion of the claim that lists the specific elements and limitations that define the invention.
- Limitation
- A specific element or requirement within a claim. Each limitation narrows the scope of what the claim covers.
- Antecedent Basis
- The rule that every element in a claim must be properly introduced before it is referenced. First mention uses “a” or “an.” All subsequent references use “the” or “said.”
- Claim Scope
- How broadly or narrowly a claim is written. Broader claims cover more potential infringers but are more vulnerable to prior art. Narrower claims are more defensible but easier to design around.
Introduction
If the specification is the story of your invention, the claims are the property lines. They define exactly what your patent protects, and everything outside those lines is free for anyone to use.
This distinction matters more than most inventors realize. A brilliant specification that describes a revolutionary software system is worth very little if the claims are poorly drafted. The specification supports the claims, but the claims are what get examined, what get litigated, and what determine whether a competitor is infringing or operating freely.
For software inventors specifically, claim drafting carries an additional layer of complexity. Under the Alice/Mayo framework, claims that describe abstract ideas implemented on generic computing hardware are routinely rejected under 35 U.S.C. §101. (For a detailed explanation of the eligibility landscape, see our guide on software patent eligibility.) The way you frame your claims can mean the difference between a granted patent and a rejection. This guide covers everything a software inventor needs to understand about patent claims before filing.
The Anatomy of a Patent Claim
Every patent claim is a single grammatical sentence. It does not matter how long or complex the claim is. It starts with a capital letter, ends with a period, and is one sentence. This is not a stylistic preference. It is a USPTO formatting requirement. Each claim has three structural components.
The preamble
The preamble identifies what the claim is directed to. For software patents, the three most common preamble forms are:
System/apparatus claims: “A system comprising...” This form protects the architecture of your invention, the components and how they are configured. It targets anyone who makes, uses, sells, or imports a system that matches your claim elements.
Method/process claims: “A computer-implemented method comprising...” This form protects the steps your software performs. It targets anyone who performs the claimed method, which in practice means anyone running software that executes those steps.
Computer-readable medium claims: “A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform operations comprising...” This form protects the software itself as stored on a medium. It targets anyone who distributes or uses the software.
Using all three preamble types in your application creates a multi-dimensional claim set that captures different classes of potential infringers. A competitor might not make the system (avoiding the system claim) but might run the method (infringing the method claim).
The transition
The transition is the word or phrase that connects the preamble to the body. Three transitions are used in patent law, and the choice matters.
“Comprising” is open-ended. It means the claim covers inventions that include at least the listed elements, but may also include additional elements not listed. This is the standard transition for most claims because it provides the broadest coverage. A system “comprising” elements A, B, and C still covers a system with elements A, B, C, and D.
“Consisting of” is closed. It means the claim covers only inventions that include exactly the listed elements and nothing more. This is rarely used in software claims because it allows competitors to design around your claim simply by adding one additional element.
“Consisting essentially of” occupies the middle ground. It allows additional elements, but only those that do not materially affect the basic and novel characteristics of the invention. This is uncommon in software claims.
For almost all software patent claims, use “comprising.”
The body
The body lists the specific elements and limitations that define the invention. Each element is typically separated by a semicolon, with the final element ending with a period. The body is where the substance of the claim lives, and it is where most drafting decisions are made.
Independent Claims vs. Dependent Claims
Understanding the relationship between independent and dependent claims is fundamental to building a claim set that provides both broad protection and fallback positions.
Independent claims
An independent claim stands alone. It contains every element necessary to define the invention without referencing any other claim. Independent claims are the broadest claims in your application and define the outer boundaries of your patent protection.
The strategic principle behind independent claims is to include the minimum number of elements necessary to define the invention's novelty. Every element you add to an independent claim narrows its scope. If an element is optional, implementation-specific, or does not define what is novel about your invention, it belongs in a dependent claim, not the independent.
For software patents, a strong application typically includes at least three independent claims: one system claim, one method claim, and one computer-readable medium claim. Each captures a different dimension of the same invention.
Here is a simplified example of an independent system claim for a software invention:
1. A system comprising: a processor; a memory storing instructions that, when executed by the processor, cause the processor to: receive a stream of user interaction events from a plurality of application interfaces; apply a pattern recognition model to the stream of user interaction events to identify recurring action sequences; generate, based on the identified recurring action sequences, an executable workflow definition that chains actions across the plurality of application interfaces; and execute the executable workflow definition without requiring user configuration of the workflow.
This claim defines a system with specific technical operations (receiving events, applying a pattern recognition model, generating workflow definitions, executing them) without specifying which pattern recognition model, which applications, or which execution environment. Those details belong in dependent claims.
Dependent claims
A dependent claim references an independent claim (or another dependent claim) and adds one or more additional limitations. It inherits all the elements of the claim it depends on and then narrows the scope further.
Dependent claims serve two critical strategic functions.
Fallback positions. If your independent claim is found invalid during examination or litigation (for example, because it is too broad in light of prior art), your dependent claims may still survive. Each dependent claim represents a narrower version of the invention that may be patentable even if the broader version is not. Think of them as a series of safety nets below the independent claim.
Design-around prevention. Dependent claims can cover specific implementations, variations, and embodiments that a competitor might use to design around your independent claim. If your independent claim describes a pattern recognition model generally, a dependent claim might specify “wherein the pattern recognition model comprises a transformer-based neural network trained on temporally ordered event sequences.” That specificity blocks a competitor from arguing that their transformer-based implementation falls outside your broader claim.
Here are simplified examples of dependent claims building on the independent claim above:
2. The system of claim 1, wherein the pattern recognition model comprises a recurrent neural network configured to process temporally ordered sequences of the user interaction events.
3. The system of claim 1, wherein the executable workflow definition comprises a directed acyclic graph in which each node represents an action and each edge represents a data dependency between actions.
4. The system of claim 2, wherein the recurrent neural network is retrained at a scheduled interval based on newly collected user interaction events.
Notice that Claim 2 depends on Claim 1 (adding specificity about the model type), Claim 3 depends on Claim 1 (adding specificity about the workflow structure), and Claim 4 depends on Claim 2 (adding further specificity about retraining). This creates a hierarchy: Claim 1 is the broadest, Claims 2 and 3 are narrower alternatives, and Claim 4 is the most specific.
Claim Scope: The Broad vs. Narrow Tradeoff
Every claim drafting decision involves a tradeoff between breadth and defensibility.
Broader claims cover more potential infringers. A system claim that describes “a pattern recognition model” covers any type of model: neural networks, decision trees, statistical methods, rule-based systems. But broader claims are also more likely to overlap with prior art, which means they are more vulnerable to novelty (§102) and non-obviousness (§103) rejections.
Narrower claims are easier to defend against prior art because they describe a more specific implementation. A claim that specifies “a transformer-based neural network with attention-weighted temporal encoding” is less likely to overlap with existing patents. But a competitor can design around a narrow claim by using a different model architecture.
The solution is to build a claim set with both. Your independent claims should be as broad as possible while still defining the invention's novelty. Your dependent claims should progressively narrow, covering the specific implementations you know are valuable. This gives you the broadest possible coverage at the top with defensible fallback positions below.
A common structure for a software patent claim set: your first independent claim (system) captures the broadest architecture. A second independent claim (method) captures the broadest process. A third independent claim (computer-readable medium) captures the software. Then 10 to 15 dependent claims progressively add technical specificity: specific algorithms, specific data structures, specific network architectures, specific processing parameters, specific interaction patterns.
Note that the USPTO charges additional fees for applications with more than 3 independent claims or more than 20 total claims. Each claim above 20 costs $200 (large entity), and each independent claim above 3 costs $600 (large entity), based on the 2025 fee schedule. Plan your claim count strategically.
Software-Specific Claim Drafting Challenges
Software claims face challenges that mechanical or chemical claims typically do not. Understanding these challenges before you draft will save you significant time and revision.
Surviving §101 eligibility
The Alice/Mayo framework is the primary hurdle for software patent claims. Claims that describe abstract ideas (mathematical concepts, methods of organizing human activity, mental processes) implemented on generic computing hardware are not patent-eligible. Your claims must describe a specific technical improvement.
Describe technical operations, not business outcomes. “A system for optimizing marketing spend” is a business outcome. “A system comprising a processor configured to apply a gradient-boosted regression model to a multi-dimensional feature vector derived from real-time conversion event streams to generate per-channel budget allocation weights” is a technical operation.
Anchor to specific technical components. Your claims should reference concrete technical elements: processors, memory, data structures, network interfaces, APIs, specific types of models or algorithms. But simply listing hardware is not enough. The claim must describe what the hardware does in a way that constitutes a technical improvement.
Show what cannot be done mentally. Claims that describe steps a human could perform with pen and paper are vulnerable under the “mental processes” category of abstract ideas. Emphasize operations that require computational capability: real-time processing of streaming data, parallel execution across distributed nodes, training and deploying machine learning models, processing datasets too large for manual analysis.
Antecedent basis
Every element introduced in a claim must be introduced with “a” or “an” on first mention and referred to as “the” or “said” on all subsequent mentions. Getting this wrong creates indefiniteness issues under §112.
Correct: “a processor” on first mention, then “the processor” everywhere after. Incorrect: “the processor” on first mention (no antecedent basis), or “a processor” used multiple times (creates ambiguity about which processor is being referenced). For complex software claims with many components, maintaining clean antecedent basis throughout the claim requires careful attention.
Functional vs. structural language
Software claims often describe what a component “is configured to” do (functional language) rather than what it physically is (structural language). This is necessary because software inventions are defined by behavior, not by physical structure. But claims that use “means for” language invoke §112(f), which limits the claim scope to the specific structures disclosed in the specification and their equivalents. Unless you intend this limitation, avoid “means for” phrasing. Instead, use “a processor configured to,” “a module that,” or “instructions that cause the processor to.”
Avoiding technology lock-in
Independent claims should not reference specific vendor names, programming languages, database products, protocol names, file formats, or other implementation-specific technology. “A PostgreSQL database” in an independent claim means a competitor using MySQL is not infringing. Instead, use “a data store” or “a database” in the independent claim and add “wherein the data store comprises a relational database management system” as a dependent claim. This keeps the independent claim broad while the dependent claim captures the specific implementation.
A Practical Claim Drafting Workflow
If you are a software inventor approaching claim drafting for the first time, here is a workflow that puts the principles above into practice.
Start by identifying your invention's core novelty. What does your system do that no existing system does? What is the technical mechanism that makes it work? Write this down in one or two sentences. This is the inventive concept your independent claims must capture.
Draft your broadest independent claim first. Use a system preamble (“A system comprising:”). List only the elements that are necessary to define the invention. Ask yourself for each element: “If I remove this, does the claim still describe my invention?” If yes, move it to a dependent claim. If no, keep it.
Test your independent claim against two questions. First: “Could a competitor copy my invention's core innovation without meeting every element of this claim?” If yes, the claim is too narrow or missing an element. Second: “Would a patent examiner find prior art that meets every element of this claim?” If yes, the claim is too broad. Iterate until both answers are no.
Build dependent claims from the top down. Start with the elements you removed from the independent claim. Each becomes a dependent claim. Then add claims for specific implementations, specific algorithms, specific data structures, specific processing parameters, and any alternative embodiments described in your specification.
Draft method and CRM independent claims. Take your system claim and rewrite it as a method (“A computer-implemented method comprising: receiving...; applying...; generating...; executing...”) and as a CRM claim. The elements should mirror the system claim but use method-appropriate language (gerund verbs for method claims: receiving, determining, generating, transmitting).
Verify antecedent basis. Read through every claim and check that every element is properly introduced on first mention and consistently referenced thereafter.
Verify specification support. Every limitation in every claim must be supported by the specification. If you claim “a transformer-based neural network,” your specification must describe that architecture. Claims without specification support are vulnerable to §112 rejections for lack of written description.
How Patent Geyser Handles Claim Generation
If you are using Patent Geyser, the platform's Module 4 (White Space & Claims) generates claim variations automatically based on your invention concept, prior art analysis from Module 3, and the white space identified through differentiation analysis.
The system generates claims with §101 survival built in: independent claims are anchored to concrete technical implementations rather than abstract outcomes, system claims reference processors configured to perform specific operations, and the claim structure follows the Enfish framework for describing improvements to computer technology. Module 5 (The Showcase) lets you compare specific (narrower) claims against broader claim alternatives side by side before selecting which set to include in your final draft.
The claims Patent Geyser generates are starting points. They provide structure, proper formatting, and technical anchoring, but they should always be reviewed and refined by a registered patent practitioner before filing. If you need help finding a practitioner with experience in software patent claim drafting, the PatentFit Directory scores practitioners based on their actual USPTO filing history across 112 CPC technology areas.
Common Claim Drafting Mistakes
Writing claims that describe outcomes instead of mechanisms. “A system for reducing latency” describes an outcome. “A system comprising a processor configured to maintain a priority-weighted routing table and select a transmission path based on a real-time latency score computed from periodic probe measurements across a plurality of network nodes” describes a mechanism. The mechanism is patentable. The outcome is not.
Including too many elements in the independent claim. Every element in an independent claim is a limitation that a potential infringer must meet to infringe. More elements means fewer infringers are caught. Keep your independent claims lean and push specifics into dependents.
Using inconsistent terminology. If your specification calls it a “pattern recognition engine” and your claims call it a “behavior analysis module,” you create ambiguity. Use the same terms in your claims that you use in your specification.
Forgetting to claim all statutory categories. A software patent with only system claims misses infringers who perform the method without making the system. A patent with only method claims misses the system builder. Draft system, method, and CRM claims.
Failing to create meaningful fallback positions. If your only independent claim is found invalid, and your dependent claims add only trivial detail, your entire patent is worthless. Each dependent claim should represent a commercially meaningful narrowing that a competitor would still want to practice.
Ignoring prior art in claim scope decisions. Draft claims without awareness of the prior art landscape and you risk either overlapping with existing patents (too broad) or claiming something no one cares about (wrong focus). Conduct a prior art search before drafting claims.
Conclusion
Claims are the most important part of your patent application. They define what you own. They determine whether competitors are infringing or operating freely. They are what gets examined, challenged, and enforced.
For software inventors, the claim drafting challenge is twofold: you need claims that are broad enough to provide meaningful commercial protection, and you need claims that are technically specific enough to survive §101 eligibility scrutiny. The solution is a structured claim set with lean independent claims capturing the core inventive concept and a ladder of dependent claims that add progressive technical specificity while creating fallback positions.
If you are drafting claims for the first time, start with the inventive concept, build the broadest defensible independent claim, test it against prior art and eligibility, and then layer dependent claims from the top down. And before you file, have a registered patent practitioner review your claims. The difference between a strong claim and a weak one often comes down to a few words, and those words can determine whether your patent is worth enforcing.
Frequently Asked Questions
The Basics
What is a patent claim?
A patent claim is a single sentence in a patent application that defines the legal boundaries of the invention. Claims are the enforceable part of a patent. If someone makes, uses, sells, or imports something that meets every element of your claim, they are infringing. If their product or method is missing even one element, they are not. Claims consist of a preamble (identifying what the claim covers), a transition (typically “comprising”), and a body (listing the specific elements and limitations).
What is the difference between an independent and dependent claim?
An independent claim stands alone and contains all the elements necessary to define the invention. A dependent claim references an independent claim (or another dependent) and adds further limitations. A dependent claim is always narrower than the claim it depends on because it inherits all parent elements plus its own additional ones. Both types are essential: independent claims provide the broadest protection, and dependent claims create fallback positions if the independent claim is challenged.
How many claims should a software patent have?
There is no fixed rule, but a typical software patent application includes 3 independent claims (one system, one method, one computer-readable medium) and 10 to 17 dependent claims, for a total of 13 to 20. The USPTO charges extra fees for applications with more than 3 independent claims ($600 each for large entities) or more than 20 total claims ($200 each for large entities). Focus on strategic value rather than claim count: every claim should add meaningful protection that the other claims do not already cover.
Drafting Strategy
How do I write software claims that survive §101?
Describe technical operations, not business outcomes. Anchor claims to specific technical components (processors, data structures, algorithms) performing specific operations. Show what cannot be done in the human mind. And make sure your specification explains the technical problem your invention solves, why prior approaches were inadequate, and how your invention provides a measurable technical improvement. For a full treatment, see our guide on software patent eligibility.
Should I include claims in my provisional patent application?
Claims are not legally required in a provisional, but including them is strongly recommended. Drafting claims forces you to define exactly what you are trying to protect, which reveals gaps in your specification. It also makes the conversion to a non-provisional application significantly faster and less expensive. And because your non-provisional claims must be supported by the provisional's disclosure, having claims in the provisional helps ensure alignment between the two filings. For a full guide on provisionals, see how to draft a provisional patent application.
Patent Geyser is an AI-assisted provisional patent drafting platform specializing in software, SaaS, and blockchain inventions. It does not provide legal advice and does not produce filing-ready patent applications. All AI-generated drafts should be reviewed by a registered patent practitioner before filing with the USPTO.