Most patents fail for one simple reason: the claims are written like a product brochure, not like a fence.
A patent is not a story about your startup. It is not a press release. It is not a “look how smart we are” document.
It is a set of legal sentences called claims. Those sentences define what you own. Not what you built. Not what you plan to build. What you control.
If your claims are tight, a competitor has to go around you. They must spend more time, more money, and take more risk. That is what blocking means in the real world.
If your claims are weak, a competitor reads your patent, smiles, and makes one small change. They ship anyway. Your patent becomes a framed certificate. Nice to look at. Useless in a fight.
This article is about how to avoid that.
At Tran.vc, we work with technical founders in AI, robotics, and deep tech who want to build real protection early—without giving up control or chasing money too soon. Our model is simple: we invest up to $50,000 in in-kind patent and IP services so you can build a moat while you build the product. If you want help turning your invention into claims that matter, you can apply anytime here: https://www.tran.vc/apply-now-form/
Now, let’s start where all strong claim strategy starts: understanding what claims really do.
Claims are the product of the patent
When people say “we filed a patent,” they often mean “we wrote a document.”
But courts, investors, acquirers, and competitors care about a different thing: the claim scope.
Think of your claim as a boundary line on a map.
- Inside the line is your property.
- Outside the line is public land.
Your job is to draw the line so it covers the value, not the clutter.
This is hard for founders because founders think in features. Patents do not protect “features.” Patents protect structured ideas: a system, a method, a device, a process, or a composition, defined by parts and steps and how they connect.
And the biggest trap is this: founders try to claim what they built today.
That is the fastest way to get leapfrogged.
A competitor does not copy you step by step. They copy the result and change the path. They swap one model. They move logic from edge to cloud. They use a different sensor. They reorder steps. They rename a module. They hide it behind an API.
If your claim is tied to your exact build, it breaks.
A blocking claim is different. It captures the core move—the thing that makes the outcome possible—so that small changes still fall inside your fence.
That is claim strategy.
And it starts with a mindset shift: stop writing claims like you are describing your code. Start writing claims like you are describing the rules of the game.
What “blocking competitors” actually means
“Blocking” does not mean nobody can compete with you at all.
It means competitors cannot compete the easy way.
A good claim forces them into one of three painful choices:
- They take a worse path, which makes their product slower, less accurate, less safe, or more costly.
- They take a longer path, which delays launch and eats cash.
- They take a risky path, where they might still infringe and get pulled into a legal problem during fundraising, partnerships, or acquisition talks.
Real blockers do not rely on magic. They rely on coverage.
And coverage is not about adding more pages. It is about claiming the invention at the right level.
If you claim too narrow, you are easy to design around.
If you claim too broad, you get rejected because of prior work.
Your job is to land in the middle: broad enough to matter, specific enough to stand.
This is why claim strategy is a skill. It is also why it is hard to do alone while you are building product, hiring, and selling.
If you want Tran.vc to help with this, apply anytime: https://www.tran.vc/apply-now-form/
The three layers you must claim (without turning this into a checklist)
Every strong patent family has a shape.
At the top is a broad claim that captures the core idea in a way that is still believable over what already exists.
Below that are claims that add the details that make your version strong.
Then there are claims that focus on key parts you might sell, license, or enforce later.
I am not going to drown you in long lists, but you need to see the pattern.
Let’s use a simple example in robotics.
Imagine you built a warehouse robot that picks items from bins. The robot uses a vision model to estimate grasp points, then adjusts force based on slip feedback from tactile sensors.
If you claim: “a robot with camera X, sensor Y, model Z, and a gripper with three fingers,” you just gave away your playbook. A competitor uses a different camera and a two-finger gripper. They walk around you.
A better strategy is to claim the control loop idea: predicting a grasp, executing, sensing slip, adjusting force, and doing it in a specific way that creates a better outcome.
You can then add narrower claims that talk about your special sensor layout, your training method, your calibration trick, your on-device compression, your safety bounds, your edge-case detection, and so on.
This layered approach matters because you rarely win with one claim. You win with a set of claims that cover the core and also cover the ways people will try to dodge.
The goal is not “one perfect claim.” The goal is “a fence with depth.”
Start with the “value sentence,” not the architecture
Here is a practical way to begin claim strategy that works well for technical founders.
Before you write anything that sounds like a patent, write one plain sentence:
“We achieve [result] by doing [key move] under [key constraint].”
That sentence becomes your compass.
For AI and robotics startups, the result is usually one of these:
- lower cost
- faster speed
- higher accuracy
- better safety
- lower power
- less data needed
- more stable performance
- better reliability in edge cases
Now, the key move is the hard part. It is not “we use a neural net.” Everyone uses a neural net. It is not “we use sensors.” Everyone uses sensors.
The key move is the clever twist that makes your result happen.
Examples of key moves (not claims yet, just thinking):
- Using uncertainty estimates to decide when to ask for human input
- Splitting a model into a small on-device part and a larger cloud part, then syncing in a new way
- Training a policy with a special kind of simulated noise that matches a real factory floor
- Detecting drift using a compressed fingerprint of sensor streams
- Using a safety layer that clamps outputs based on physics bounds before sending commands to actuators
If you cannot say your key move in one clean sentence, your claim strategy will be messy. Your patent might still get filed, but it will not block.
At Tran.vc, this “value sentence” is often the first thing we extract in founder sessions. It saves weeks of wandering. It also makes the claims sharper. If you want that kind of help, apply here: https://www.tran.vc/apply-now-form/
The hidden enemy: copying your own product spec
Founders often bring a product doc to their patent team. That is not wrong. But it becomes dangerous when the claim mirrors the spec.
A product spec says, “Here is what we built and how it works.”
A blocking claim says, “Here is the smallest set of elements needed to produce the advantage.”
Those are not the same.
When you copy the spec, you load the claim with extra parts that are not needed. Every extra part becomes an escape hatch for competitors.
Let’s make that real.
Suppose your AI system detects defects on a manufacturing line. Your spec might say:
- camera is mounted at 30 degrees
- image is 1080p
- model is a transformer
- inference runs on a specific GPU
- defects are flagged in a dashboard
- results are stored in a database
- alerts are sent to a supervisor
Most of that is not the invention.
If the invention is actually: “combining multi-angle images with a confidence score to trigger a re-scan only when needed,” then your claim should focus on that logic, not the dashboard.
Dashboards change. Databases change. GPUs change. Alerts change.
Competitors will change those parts first.
A blocking claim holds onto what stays valuable even when implementation shifts.
That is why claim strategy is not documentation. It is compression.
You are compressing your advantage into legal form.
Claim language: why “comprising” matters more than you think
You do not need to become a patent lawyer to understand this, but you do need one core concept.
Most strong claims use the word “comprising.”
In plain words, “comprising” means: “includes at least these things.”
So if your claim says:
“A system comprising A, B, and C…”
A competitor cannot avoid the claim by adding D, E, and F. They still have A, B, and C.
That one word helps prevent silly design-arounds.
But it does not solve everything.
Competitors avoid claims by removing or replacing an element. That is why you must choose claim elements carefully.
If you include elements that are easy to replace, you are inviting a workaround.
This is also why you need to be careful with brand-new words, cute names, or internal code terms. A claim should use common, plain words whenever possible, so it covers more variants.
The more your claim reads like “our exact module names,” the less it blocks.
A simple test: can someone dodge this in one weekend?
Here is a test you can run on any draft claim, even if you are not an expert.
Read the claim and ask:
“If a competitor had one weekend and a smart engineer, what is the easiest change they would make to avoid this sentence?”
If the answer is obvious, your claim is too tied to an implementation detail.
Examples of easy weekend dodges:
- swapping “LIDAR” for “stereo cameras”
- moving a step from “local device” to “remote server”
- changing the order of two steps
- using a different model family name
- replacing a threshold rule with a learned rule
- changing a data type or sampling rate
A strong claim either avoids those details, or it claims them in a way that still captures the competitor’s alternative.
That is the art: claim enough to be real, but not so much that you gift-wrap an exit door.
Find Your Claimable Core
The input–transform–output map
Most deep tech inventions follow a pattern, even if the codebase looks messy.
There is something that comes in, something important that happens to it, and something valuable that comes out.
When you map your system into input, transform, and output, you start to see where the true invention lives.
It is rarely the raw input or the final screen. It is almost always in the transform.
For an AI startup, the input may be sensor data, logs, images, or user prompts.
The output may be a decision, a prediction, a control signal, or a ranked list.
But the transform is where your insight sits.
It may be how you clean the data, how you combine signals, or how you control uncertainty.
When you draft claims, you want to focus on that transform.
You want to describe the way the data is handled, shaped, or constrained.
If your claim only talks about inputs and outputs, it will be too thin.
If it talks only about surface-level parts, it will be too narrow.
Finding the step that changes the game
Ask yourself a direct question.
If a competitor copied everything except one step, which step would hurt them the most to lose?
That step is often your claimable core.
It is the step that makes your results stable, faster, or more reliable.
In robotics, this could be the way you fuse sensor signals before sending commands.
In AI safety, it could be the way you filter model outputs using real-world constraints.
In enterprise AI, it might be how you reduce hallucinations using structured context.
The core is the logic that turns raw capability into real-world performance.
You should be able to explain this step without using brand names or internal code terms.
If you cannot explain it simply, you do not yet see it clearly.
And if you do not see it clearly, your claim will drift into feature lists.
Clarity in thinking comes before strength in drafting.
Avoid claiming the obvious
Another common mistake is claiming what everyone already does.
If your claim says “receiving data and processing it using a machine learning model,” that will not block anyone.
It is too general and likely already known.
Examiners see that language every day.
Instead, you need to anchor your claim in what is different.
What constraint did you add that others ignore?
What ordering of steps did you change?
What feedback loop did you create that was not there before?
The core of a blocking claim is not that you used AI.
It is that you used AI in a structured, constrained, and purposeful way that changes the result.
That structure is what you must capture.
From messy architecture to clean claim logic
Most real systems are layered and complex.
There are microservices, APIs, queues, storage layers, and monitoring tools.
That complexity is real, but it does not all belong in the claim.
The claim is not an architecture diagram.
You must compress your architecture into a logical flow.
What must happen first, what must happen next, and what condition must be met?
By writing it as a logical chain, you reduce noise.
You focus on what drives the advantage.
This compression takes discipline.
It often feels like you are “leaving things out.”
That is the point.
A strong claim leaves out what competitors can change easily.
If you want expert help finding and compressing your claimable core, Tran.vc works side by side with founders to do exactly this.
You can apply anytime at https://www.tran.vc/apply-now-form/
Drafting Broad but Defensible Independent Claims
Start broad on purpose, then shape it
When you draft your first independent claim, do not begin small.
Start with the widest version of your core idea that still feels honest.
You can always narrow later, but it is hard to widen once the mindset shrinks.
The first draft is about possibility, not fear.
Write it in a way that captures the function, not the brand.
Focus on what is being done and why it matters.
Avoid locking yourself into a specific vendor, chip, or model name.
Those details belong lower in the claim set, not at the top.
The goal is to describe a system or method that performs your key move under real conditions.
It should feel like the skeleton of your advantage.
Not the skin, not the packaging, but the bones.
If the bones stay the same, the product may evolve and still fall inside your fence.
Balancing breadth with prior art
Breadth alone is not strength.
If your claim reads on what already exists, it will not survive examination.
So you must shape it around what is new in your approach.
That shaping is where strategy matters most.
You do this by understanding what others have done before you.
Not at a surface level, but at the logic level.
What steps were common?
What constraints were missing?
Your claim should include the element that creates separation from what came before.
That might be a specific feedback loop.
It might be a rule that limits how outputs are generated.
It might be the way two subsystems communicate.
The art is this: include enough detail to step over the past, but not so much that you shrink your future.
You want to carve around the old work without carving away your own growth.
That requires thoughtful drafting, not copying templates.
Claiming systems versus claiming methods
In deep tech, you often have a choice.
You can claim a system, which focuses on components and their interaction.
Or you can claim a method, which focuses on steps performed.
Both can block competitors, but they operate differently.
A system claim is useful when competitors will sell a product with clear parts.
It allows you to point to physical or logical components.
A method claim is powerful when the real value lies in the sequence of actions.
It captures the process, even if the hardware changes.
In many cases, you want both.
The system claim draws a fence around the structure.
The method claim draws a fence around the behavior.
Together, they make it harder for someone to dodge by shifting where the logic lives.
For AI startups, method claims often capture how data is processed and refined.
For robotics startups, system claims can capture the interplay between sensors, controllers, and actuators.
The choice is not random. It is based on how infringement would likely happen in the market.