If you are building real tech—AI, robotics, sensors, chips, medical devices—your patent claims matter as much as your code. Claims decide what you truly own. And when you file in more than one country, claims are not “copy and paste.” Each office has its own habits, its own red flags, and its own way of saying “no.”
This guide shows a practical claim strategy that still holds up when you go global. Simple words. Real moves you can use. No fluff.
If you are working on deep tech and you want help shaping a strong patent plan early, you can apply anytime here: https://www.tran.vc/apply-now-form/
What “claim strategy” really means (in plain words)
A patent is not mainly the drawings. It is not the long background story. The real fence around your invention is the claims.
Think of a claim like a rule that says: “If a product has these parts, or does these steps, it is inside my fence.” That fence can be wide or narrow. It can be easy to defend or hard to enforce. It can cover your product today, or still cover you when you change the design later.
Now add countries. You may file the same invention in the US, Europe, Japan, Korea, China, India, and more. The fence must still stand in all those places. That is the hard part.
A claim strategy across countries means you plan your “fence” so it:
- Covers the real value in your tech
- Is hard to design around
- Can survive strict examiners in more than one place
- Still matches what you can honestly support in your patent description
- Leaves room to adjust later without losing the big picture
Most founders do not lose patents because their invention is “not new.” They lose because the claims were built in a way that breaks under pressure.
If you want a team that does this with you, early, before you raise and before competitors copy, Tran.vc exists for that. Apply here: https://www.tran.vc/apply-now-form/
The main mistake founders make when they file globally
They start with the “US claim style” in their head.
In the US, you can often start broad, take some hits, and then narrow through arguments and amendments. In many cases, you can also use continuation filings later to keep adjusting claim scope as your product evolves.
But that same approach can cause trouble elsewhere.
In Europe, examiners often push hard on clarity, added matter, and support in the description. They do not like vague “black box” words. They also treat claim amendments with strict rules. If you did not clearly write it in the original filing, you may not be allowed to add it later.
In China, you often need clear support, clear terms, and careful drafting around “functional” words. Examiners can be strict on what counts as enough detail.
Japan and Korea can also be very detail-driven in claim language and support.
So if you draft like you are only filing in the US, you may be forced into weak, narrow claims later—or worse, you may be blocked from fixing key issues because your original patent text does not support the fix.
The solution is not to “write like Europe.” The solution is to build a claim plan that gives you safe paths in every major office.
Start with the business: what must the claims protect?
Before you write one claim, you need a clear answer to one question:
What is the part of your system that creates unfair advantage?
Not “we use AI.” Not “we do robotics.” The real advantage is usually one of these:
- You get better results with the same inputs
- You get similar results with cheaper hardware
- You make the system stable in edge cases
- You cut time, power, cost, or steps
- You make deployment easier at scale
- You solve a hard safety problem
- You make a messy real-world process predictable
Your claims must target that advantage. If your claims only describe your full product in a big bundle, competitors will copy the advantage while changing the bundle.
So do this exercise in one short paragraph:
Describe your tech as if a smart engineer at a rival company is reading it and trying to copy the core trick. What do they need to replicate to get the same benefit?
That “core trick” becomes the center of your claim strategy.
This is also where Tran.vc helps a lot, because founders often feel the “secret sauce,” but struggle to describe it in a way that becomes a legal fence. If you want that help, apply here: https://www.tran.vc/apply-now-form/
Think in layers, not one claim
Most patents fail because the claims are a single layer.
A cross-country strategy works better when you plan claims in layers, like a castle:
- An outer wall that is broad enough to matter
- Inner walls that still block design-arounds
- A “keep” that is narrow but almost impossible to reject
- Multiple viewpoints so you are not trapped if one path gets blocked
You do not need a long list in the claim set. You need coverage from different angles.
Here is what “different angles” means in real life.
If you are a robotics startup, you might claim:
- The robot control method (steps)
- The robot system (parts)
- The training process (how you got the model)
- The safety checks (how you stop bad moves)
- The way the robot uses sensor data (fusion)
- The way you plan motion (planning constraints)
Not all countries treat these the same. Some offices may like system claims. Others may prefer method claims. Some examiners may reject “training” claims as too abstract unless written with strong detail. But if you have multiple angles, you can still win strong coverage.
This is the heart of claim strategy across countries: you do not bet everything on one claim type.
The “anchor claim” concept (this is your best friend globally)
An anchor claim is the claim you expect to survive in almost every country with minimal pain.
It is not your broadest claim. It is the claim that is:
- Clearly supported by your description
- Clear in terms (few fuzzy words)
- Tied to real technical steps or structure
- Easy to explain as a technical improvement
If you draft an anchor claim well, you can build other claims around it. Even if your broad claim gets cut down in one country, you still have something valuable.
A good anchor claim often includes:
- A concrete input
- A concrete processing step
- A concrete output
- One key relationship that creates the advantage
Example, in plain style (not legal wording):
“A method where the robot reads force data and vision data, builds a shared scene map, checks a safety rule before moving, and then moves using a motion plan that stays inside a safe zone.”
This is not the broadest possible claim. But it is specific enough to be real, and broad enough that competitors cannot easily avoid it if they want the same safety and control.
When you go country to country, you will adjust the exact language. But the anchor stays stable.
Use the description to “feed” your claims later
This is where global filing is won or lost.
In many countries, you cannot add new details later. If your first filing is thin, you are stuck.
So instead of writing a short patent draft that only matches your current product, write one that contains many “support beams”:
- Several ways to do each step
- Several choices for key parts
- Several thresholds, ranges, and options
- Clear definitions for key terms
- Variations that remove non-essential parts
- Alternatives that move functions between software and hardware
This does not mean you dump random ideas. It means you capture your real design space.
Why this matters across countries:
- In Europe, you must avoid “added matter.” If you did not clearly disclose it, you cannot add it.
- In China, support and clarity can drive what you are allowed to claim.
- In Japan and Korea, detail helps you avoid rejections and gives more amendment options.
Founders often treat the first filing as a “placeholder.” That is risky if global rights matter. A placeholder that is not deep can become a trap.
A strong filing is like storing extra wood and nails before winter. You may not need them today, but you will be glad you have them when an examiner forces changes.
Tran.vc’s model is built around this early foundation work—turning what you already built into a clear, defensible asset. If you want to explore that, apply here: https://www.tran.vc/apply-now-form/
Be careful with “functional” words (especially across borders)
Functional words are words that describe what something does, not what it is.
Example: “a module configured to optimize” or “a unit that determines” or “a processor that analyzes.”
These words are common in US patents. They can still work globally, but they need support. If your claim only says what the module does, and your description does not show how it does it, some offices may treat it as too vague or too broad.
The safer approach is to tie functional words to:
- Specific steps
- Specific data flows
- Specific structures (even if high-level)
- Clear examples in the description
For AI, this is critical. “A model configured to predict” is not enough. But “a model that produces a score from features X, where the score is used to do Y” is clearer. Even better if you describe training, inputs, outputs, and how the result changes system behavior.
You do not need to give away trade secrets. You do need to show enough that your claim feels like a real technical teaching, not a wish.
Plan for different “patentability filters” by country
Each office has its own common reasons to reject claims. You can prepare for these early, in the way you draft.
US: breadth battles and obviousness fights
In the US, you often face obviousness arguments that combine two or more prior art references. You want claim features that create a strong story: “The prior art does not do this relationship that improves this real technical result.”
So you want to include at least one element that is not just “use AI,” but “use AI in a specific way that changes system control.”
Europe: clarity and “technical effect”
Europe is strict on clarity and support. For software and AI, you also need a clear technical character and a technical effect. It helps if your invention is framed as improving a technical system: lower latency, better control stability, less power, less memory, better sensor accuracy, safer operation.
So you want the description to clearly explain the technical problem and the technical effect of your solution, without marketing language.
China: support, clarity, and careful wording
China can be strict about whether the claim is supported by the text, and whether wording is clear. Drafting with clear terms and solid examples helps.
Japan/Korea: detail helps you move faster
These offices can be efficient, but they often reward detail. When the description is rich and consistent, you can prosecute smoothly.
The key is this: you cannot write a different invention for each country. You write one strong invention story that meets the strictest needs, then you adapt claim form and language per office.
That starts at the first draft.
Write claims that map to real infringement
When you draft claims, you must ask:
If a competitor ships a product, can we prove they do each claim part?
This matters more across countries because evidence access differs.
So prefer claim elements that can be seen or reasonably tested:
- Inputs and outputs
- Observable signals
- System behavior
- Steps that happen in a device or server you can measure
If your claim relies on hidden training steps that no one can see, enforcement may be hard unless you have strong discovery tools (which vary by country).
This does not mean you should avoid training claims. It means you should balance them with claims that cover the deployed system behavior.
For example: claim the way the model output changes robot motion, not only the way you trained the model.
A simple tactical way to structure a “global-ready” first filing
Here is a practical approach founders can use when working with counsel. I will keep it simple and not turn it into a long list.
Start by writing down three versions of your invention:
- The simplest version that still gives the benefit
- The version you ship today
- The version you expect to ship in 18 months
Now, for each version, write:
- What goes in (inputs)
- What happens (key steps)
- What comes out (outputs)
- Why the output is better (technical effect)
Then, look for the common thread across all three. That thread is your anchor.
Next, identify one or two “optional but powerful” features that make it even better. Those become inner-layer claims and fallback positions.
Finally, write the description so that every key term is explained the same way, and every optional feature is shown as optional, not required.
This “optional vs required” part is huge. Founders often describe an example as if it is the only way. Later, that example becomes a cage.
Your goal is to show examiners that the invention works in multiple forms, so your claim scope can be wider without breaking support rules.
A quick example: robotics + vision + safety
Imagine a warehouse robot that picks items. Your advantage is fewer drops and safer motion near humans.
A weak claim approach is: “A robot that uses a neural network to pick items.” Too broad. Too vague. Too easy to reject.
A stronger global strategy is to claim the relationship:
- The robot uses vision and force signals
- It builds a grip confidence score
- It changes grip force and motion plan based on that score
- It runs a safety check before executing
- The result is fewer drops and safer movement
Now you can draft:
- An anchor method claim around this flow
- A system claim that matches the real product
- A dependent claim that tightens the safety rule
- Another dependent claim that covers the confidence score form
- Another that covers sensor fusion variations
Across countries, the exact phrasing will change. But the structure holds.
And the invention story is clearly “technical,” not abstract.
Where founders can accidentally block themselves (and how to avoid it)
Here are a few common traps that hurt global prosecution, explained plainly.
If you say “the invention is X” too strongly in the description, examiners may treat X as required. Instead, write that X is “one example” or “in some cases.”
If you define a term one way in one section and a different way later, you create clarity problems. In Europe, that can be fatal.
If you only describe one model type, one sensor, one network, one threshold, you reduce your claim space later. Include alternatives that are realistic.
If you use marketing talk like “revolutionary” or “best,” it does nothing for patentability and can confuse the technical story.
If you leave out the technical effect, software and AI claims often struggle in Europe. Explain the improvement in system terms, not business terms.
A note on timing: use PCT wisely, but don’t treat it as magic
Many startups file a first application, then file a PCT within 12 months, then enter countries around 30 months.
This can be a good path. But a PCT does not fix a weak first filing. It mainly buys time and keeps options open.
The real win is drafting the first filing in a way that is already friendly to the strict places.
If you do that, the PCT phase becomes a time to learn, refine, and plan—rather than panic and patch holes.
If you want help building that first filing right, Tran.vc invests up to $50,000 in in-kind IP and patent services for deep tech founders. You can apply anytime at: https://www.tran.vc/apply-now-form/
Claim Strategy That Works Across Countries
Broad does not mean vague
Broad claims are not “anything that does the job.” Broad claims are “many versions of the same core idea.” When a claim is broad and still strong, it covers a big space, but it stays clear about what must happen. That is how it survives in the US, Europe, and Asia without falling apart.
A vague claim sounds big, but it is easy to reject. Examiners can say it is unclear, not supported, or too abstract. Even if it gets allowed, it can be hard to enforce. The safest path is to draft broad claims using concrete building blocks: inputs, steps, outputs, and a key link that creates the benefit.
Use “wide meaning” words that stay clear
Some words stretch a claim in a safe way. These words do not hide the invention. They simply avoid locking you into one narrow example. For instance, “sensor data” can cover vision, depth, radar, and force data, if your description explains these options.
The trick is to match every flexible word with support in the description. If you say “sensor,” show multiple sensor types. If you say “model,” show a few model forms. This is not filler. This is what lets you change claim scope later, especially in Europe where you cannot add new detail after filing.
Keep one hard edge in every broad claim
A broad claim should still have one feature that is hard to find in old prior art. This is your hard edge. It is usually a relationship between parts, not a part itself. Many patents fail because they claim common parts, then hope the combination feels new.
For deep tech, your edge is often a specific data flow, a control rule, a timing rule, or a safety constraint. In AI systems, the edge is often how the model output drives a real system action, not the fact that a model exists.
Build a claim set that can bend without breaking
Why one “perfect” claim is a trap
Founders often want one master claim that covers everything. That sounds clean, but it creates risk. If that claim is rejected in one country, you may lose the most important coverage. A global plan needs claims that can flex as examiners push in different directions.
The goal is not to flood the patent with dozens of claims. The goal is to have a few strong claims that cover the same value from different angles. That way, if an examiner blocks one angle, you still have others.
Anchor claims and support claims
An anchor claim is your steady claim. It is the one you expect to keep in most places. Support claims sit around it and give you options. Some of these options will matter more in the US, and some will matter more in Europe or China.
This approach also helps you in business talks. When investors ask what your patent covers, you can explain it clearly. You can point to the anchor as the core fence, and then explain how the other claims block easy design-arounds.
Different claim views for one invention
A single invention can be claimed as a method, a system, a device, or even a non-transitory storage medium in some cases. These are not just legal forms. They are different ways to catch infringement.
In some countries, system claims may be smoother. In others, method claims may be easier to argue. If your invention touches hardware and software, you often want both. This is not extra work for no reason. It is a way to avoid being cornered.
How to draft claims that survive Europe’s strict style
Clarity is not a bonus, it is the entry ticket
Europe often tests clarity early and hard. If your claim has fuzzy words, the examiner may stop the discussion right there. They may not even reach novelty and inventive step until the language is fixed.
So you want claims that read like a technical recipe, not like a marketing line. If a term can be read in two ways, define it. If a step could happen in several places, say where it happens. If a value matters, explain what it controls.
Avoid hidden “must-have” features
A common mistake is writing the description as if one example is the invention. In Europe, this can shrink your claim scope later because the examiner may treat the example as a required feature.
To avoid this, the description should show that features can be mixed and matched. It should explain that some parts are optional, and that the core idea still works without them. When you later narrow claims during prosecution, you want to choose your narrowing features instead of having the examiner choose them for you.
Technical effect should be stated in system terms
Europe cares about whether the invention solves a technical problem in a technical way. For AI and software, it helps to explain the effect in measurable system terms, not business terms.
For example, instead of saying “improves user experience,” say it reduces latency, reduces errors, improves stability, reduces compute load, or makes the robot safer around humans. When you write it this way, your claims have a stronger foundation in Europe.
How to keep claims strong in China without over-narrowing
Support in the description must be real, not implied
China often looks for clear support for what you claim. If your claim includes a feature, it helps when the description shows that feature clearly, with examples and variations.
This does not mean you must disclose sensitive training data or private datasets. It means you should explain the structure of the solution: what inputs come in, what processing happens, what comes out, and how outputs are used in the system.
Functional language needs a backbone
If a claim says “a module configured to do X,” the examiner may ask what structure makes it do X. You can protect yourself by describing the module as a set of steps, a pipeline, or a defined component relationship.
For AI inventions, it helps to describe features, labels, output scores, decision thresholds, and how the output changes real device actions. This makes the claim feel like an engineering disclosure rather than a wish.
Plan for clean amendment paths
Across countries, you often need to amend claims to get allowance. China, like Europe, may limit what you can add if it was not clearly present in the original text.
That is why the first filing matters. If your first filing has strong fallback features written clearly, you can narrow claims without losing the invention’s core value. If it does not, you can be pushed into a narrow corner.
AI and software claims that hold up across borders
Claim the system change, not the label “AI”
Saying “a neural network predicts a value” is rarely enough. It can sound abstract. A stronger approach is to claim what the system does with the prediction.
If the prediction changes robot speed, grip force, path planning, energy use, or safety checks, then the claim becomes tied to a technical system. This is easier to argue across countries, especially in places that care about “technical character.”
Make the inputs and outputs concrete
Many AI claims fail because the claim does not say what data is used and what result is produced. The claim becomes too open-ended.
You do not need to list every feature. But you should anchor the claim with at least one concrete input type and one concrete output type. You can then use broader terms supported by the description to cover variants.
Treat training as optional coverage, not your only fence
Training claims can be valuable, but they can be hard to prove in enforcement. Across countries, access to training details may be limited.
So a good cross-country set often includes claims that cover deployment behavior too. If a competitor ships a product that behaves the same way, you want a claim that reads on what you can test and observe.
The art of drafting fallback positions without making the claim weak
Fallbacks should be meaningful, not random
A fallback feature is something you can add to a claim if the examiner says the claim is too broad. Many patents include fallback features that do not really help. They are minor details that still leave the claim obvious.
A good fallback feature is one that changes the story. It adds a control rule, a safety constraint, a timing relationship, a fusion method, or an allocation of tasks that is hard to find in prior art. These features are often what made your system work in real life.
Put fallback material in the description early
Fallbacks only help if they are supported in the original filing. This is where many startups lose options, especially in Europe.
So when you draft, you want to include variations that are not just “more sensors” or “more layers.” You want variations that represent real engineering choices: different thresholds, different sampling rates, different ways to fuse, different ways to validate outputs, different ways to handle edge cases.
Write your description like you expect to negotiate
Patent prosecution is a negotiation. You should assume an examiner will push back.
If you write the description as if you are telling one neat story, you may run out of room when you need to adjust. If you write it as a structured set of supported options, you can respond to rejections without losing the big fence.
Claims must map to real infringement evidence
A claim is only as good as what you can prove
A claim can look strong on paper and still be hard to use. The reason is simple: you may not be able to prove the competitor does each claim feature.
For global strategy, this is important because evidence access and discovery differ. You want at least some claims that can be supported by observable behavior, product testing, public docs, or signals you can measure.
Choose elements that show up in products
For robotics, this might be motion patterns, safety stops, sensor usage, or calibration steps that appear in logs. For AI software, it might be output scores used to trigger actions, latency improvements, or specific constraint handling.
This does not mean you avoid internal steps. It means you balance them. You want a mix where at least part of the claim set can be enforced even without inside access to the competitor’s training pipeline.
Draft with enforcement in mind from day one
If enforcement is the end goal, then claim language should avoid features that only exist in your internal code comments. It should focus on what must exist for the system to work.
This mindset also helps you avoid wasting claims on parts that competitors can easily swap out. You aim claims at the unavoidable parts of the advantage.
A practical workflow founders can use with counsel
Step one: name the “copy path”
Imagine a competitor is trying to copy your results in the fastest way. What would they copy first? What would they try to avoid copying? This mental exercise reveals what parts are essential.
If your invention’s value comes from a control loop rule, claim the rule. If it comes from a safety gate that prevents bad moves, claim the safety gate. If it comes from a data fusion step that reduces drift, claim that fusion step.
Step two: draft the anchor, then expand
Start with the anchor claim that is concrete and defensible. Then create broader and narrower claims around it.
When you do this, you avoid the common problem where the broad claim is disconnected from any supported technical story. You also avoid the opposite problem where the only allowed claim is tiny and easy to design around.
Step three: pressure test against each region
Before filing, you can do a simple pressure test. Ask: would Europe attack clarity or added matter risk? Would China ask for more support for functional terms? Would the US combine references and argue obviousness?
If your draft can answer these pressures with language already in the description, you are in a strong position.
If you want experts to do this pressure test with you and shape a global-ready filing early, Tran.vc invests up to $50,000 in in-kind IP and patent services for deep tech startups. You can apply anytime at: https://www.tran.vc/apply-now-form/