Most founders treat a PCT search report like a school grade.
“Uh oh. We got hit with X and Y. This looks bad.”
That reaction is normal. But it is also expensive.
A PCT Search Report is not a verdict. It is early, high-signal feedback from the patent world that you can use to steer your product and your IP plan while there is still time to change course. If you know how to read it, it can save you months of wasted work, prevent you from filing the wrong patents, and help you build a cleaner moat around what you are actually building.
At Tran.vc, we see the same pattern again and again with AI and robotics teams: the founders are moving fast, the code is changing weekly, and the first patent draft often reflects an older version of the idea. Then the PCT search report arrives, and suddenly the team is unsure what is “new,” what is “safe,” and what to do next.
This post is about what to do next.
Not in a vague way. In a practical, step-by-step way. You will learn how to use the search report to adjust your patent scope, decide what to claim, decide what to stop claiming, find the real invention hiding inside your system, and line up your next filings so you do not lose time or money. If you are building deep tech, this is one of the best chances you will get to correct the path before things get harder.
If you want Tran.vc to help you do this with real patent attorneys and a founder-friendly strategy, you can apply anytime at https://www.tran.vc/apply-now-form/.
What a PCT search report really is (and why it matters more than most founders think)
A PCT application is often used as the “global placeholder” for your invention. You file once, and it buys you time before you must pick countries. That part is widely understood.
What many founders miss is this: the PCT search process often produces the first serious “outside view” of your invention. It is not just a formality. It is a structured attempt to answer two big questions:
- What did the world already publish that looks like your invention?
- Based on that, what parts of your invention might still be patentable?
It sounds simple, but the impact is huge. Because the report does not just say “prior art exists.” It often points to which features are known and which features might still be different.
That is gold.
If you treat the report like a tool, you can use it to make four high-leverage moves:
- tighten your claims so you stop fighting battles you cannot win
- widen your strategy where the search did not find strong hits
- shift your “center of gravity” to the part of the system that is truly yours
- plan follow-on filings with much better aim
In plain terms: the report helps you stop guessing.
And guessing is what burns founders. Founders guess what the patent office will care about. Founders guess what competitors can copy. Founders guess which parts are “novel.” Then they spend money and time defending guesses.
A good strategy turns guesses into decisions.
The parts of the PCT search packet you must understand
You will normally receive a set of documents. Different offices format things differently, but the key pieces are the same.
There is usually:
- a list of documents the search examiner found (the cited references)
- a view of the claims and which ones are hit by which reference
- written comments about novelty and inventive step (sometimes short, sometimes detailed)
- codes like “X,” “Y,” and “A” that look scary if you have never seen them
You do not need to become a patent lawyer to use this properly. But you do need to know what the signals mean.
Here is a simple way to think about the categories:
“A” is background.
It means the reference is related, but not a direct threat by itself. An “A” citation can still matter, because multiple “A” references can be combined later, but on its own it is not the loudest alarm.
“X” is a direct hit.
It means one reference, by itself, can take out the claim. If your main claim is marked with an “X,” that usually means the claim is too broad as written or your “new” part is not clearly in the claim.
“Y” is a combo hit.
It means the examiner thinks two or more references, when combined, can take out the claim. This is common in software, AI, robotics, and systems patents because the building blocks exist in many places.
Most founders see an X and panic.
Do not panic. Start diagnosing.
Because an X can mean two very different things:
- your invention is not new
- or your claim did not point to what is new
The second case happens more than you think, especially when the initial draft is written before the product design is stable.
So your job is not to “accept defeat.” Your job is to separate these two cases and adjust.
First move: map the report to your product, not to your ego
If you only do one thing, do this: take the search report and map it to your system architecture.
Not to your pitch deck. Not to the marketing story.
To the real thing.
If you are building a robot, draw the real pipeline: sensors, state estimation, planning, control, safety, data logging, fleet learning, calibration, simulation, updates. If you are building an AI platform, draw the real pipeline: data ingestion, labeling, training, evaluation, inference, monitoring, privacy, edge deployment, feedback loop.
Then take each cited reference and ask: where does this reference sit in our system?
When you do this, you stop thinking in vague terms like “they found something similar.” You start seeing exactly what was found.
And that leads to better decisions.
For example, imagine you filed a PCT on a “robot navigation system using a neural network.” The search report cites papers on neural network navigation and marks your main claim with X.
If you stop there, you conclude “we can’t patent navigation.”
But if you map it to your actual system, you may notice the real value is not “neural network navigation.” The real value might be:
- how you calibrate low-cost sensors so the model works reliably
- how you detect drift and switch to a safe mode
- how you compress the model for edge use without losing stability
- how you train with weak labels that reduce data cost
- how you perform online learning while avoiding unsafe actions
- how you validate in simulation to reduce real-world failure
Those details are often where the patentable novelty lives. But early drafts often focus on the high-level concept. Examiners are trained to crush high-level concepts.
So the mapping exercise is how you find the real invention, the one your team built through hard work, not the one that sounds nice in a sentence.
This is exactly the kind of work Tran.vc does with founders. We translate the messy brilliance of your system into clear claim shapes that are hard to copy. If you want help, apply anytime at https://www.tran.vc/apply-now-form/.
Second move: separate “novelty” problems from “claiming” problems
Now we get tactical.
When a claim is hit with X or Y, do not jump to rewriting everything. First, classify the reason.
There are three common reasons a claim gets hit:
Reason 1: The claim is too broad.
This is the most common. The claim describes a goal and a general method, but it does not include the specific steps or constraints that make your approach different.
In AI and robotics, broad claims often sound like:
- “use a model to predict X, then control Y”
- “collect data, train a model, deploy it”
- “optimize a plan using cost function Z”
Those patterns are everywhere. If your claim reads like a common pattern, it will get hit.
Reason 2: The claim points at the wrong “new” part.
Sometimes the draft focuses on something that felt new early on, but later became standard or got replaced.
Example: you filed around a specific sensor fusion method, but now your product moat is actually in reliability checks and fleet learning. The report is not “wrong.” It is just evaluating what you asked for.
Reason 3: The invention is not new in the way you framed it.
This happens too. Maybe a strong paper or a big company patent already covers the core method. That does not mean you have no IP. It means you must shift to your true differentiator.
When you know which reason applies, your next move becomes obvious:
- too broad → narrow with specific features and boundaries
- wrong focus → shift to the right subsystem and file follow-ons
- not new → redesign claims around your unique constraints, data, deployment, or safety logic
This classification step alone changes the mood of the conversation inside a startup. Instead of “we failed,” it becomes “we learned where the edge is.”
Third move: use the citations to build a “feature ledger”
Here is a very founder-friendly way to work with prior art: treat the cited references like a ledger.
Make a simple table for yourself (not a fancy one, just a working note). For each cited reference, list the key features it discloses that overlap with your system.
Then, for your own system, list the features you believe are unique.
Now comes the key step: mark which of your features are clearly absent from the references.
You are not trying to prove the whole product is new. You are trying to find the smallest set of features that, together, create a new technical result.
That set is what your best patent claim will often be built around.
This is where founders often get surprised. The “unique” part is usually not the most obvious part. It is often the thing that sounds boring in marketing language.
Things like:
- timing constraints
- memory limits
- sensor error models
- fail-safe triggers
- data cleaning rules
- how you combine outputs from modules
- how you handle edge cases
- how you measure confidence
- how you decide to ask for human input
- how you update without breaking old devices
These are not buzzwords. They are engineering reality. And engineering reality is what patent offices respect.
Also, this ledger has a second benefit: it becomes a roadmap for what you should keep secret versus what you can disclose.
If you know which features are the core differentiators, you stop casually sharing them in sales calls, demo videos, or hiring slides.
Fourth move: plan your response like a product sprint
Founders hate legal timelines because they feel slow and outside your control. So treat this like an engineering sprint.
You have a report. It contains tasks.
Your tasks are:
- Identify the claims that matter commercially
- Identify what in those claims is being challenged
- Decide how you will adjust: narrow, shift, or split
- Prepare follow-on filings if needed
- Align the patent plan with the next 6–12 months of product changes
This is not “paperwork.” It is strategy.
A common mistake is to respond to the report by making small edits to the claims without changing the underlying structure. That often leads to weak patents that are narrow in the wrong place.
Instead, treat your response as a chance to restructure.
A good restructure might mean:
- one core claim that targets the deepest technical differentiator
- another claim set that targets a key reliability or safety mechanism
- a separate filing (later) that targets deployment or scaling details once they are stable
In other words: you stop trying to force the entire company into one patent.
One patent is rarely enough for deep tech anyway. The goal is an IP stack that mirrors how your system actually creates advantage.
Tran.vc’s model exists because early-stage teams need this kind of thinking before the seed round. If you want a partner that brings up to $50,000 in in-kind patent and IP services, apply anytime at https://www.tran.vc/apply-now-form/.
Fifth move: read the “inventive step” comments like a negotiation
Many search reports include comments that sound like:
“Claim 1 lacks inventive step in view of D1 combined with D2.”
Founders often read this like a final judgment. But it is better to read it like a negotiation opening offer.
The examiner is saying: “Based on what I see, I think your claim is obvious.”
Your response is: “Here is why the combination is not as simple as you think, and here are the constraints you missed.”
In AI and robotics, inventive step arguments often become strong when you tie the invention to a real technical constraint.
Not business value. Technical constraint.
For example:
- reduced compute on edge hardware
- real-time control stability
- safety under uncertain sensing
- latency limits
- battery limits
- limited training data
- noisy labels
- domain shift across environments
- mechanical wear effects that change the data distribution
When you show that your approach solves a technical problem under constraints that the references do not address, you change the story.
This is why your response team must include someone who understands the system deeply. A generic legal response often fails because it does not capture the real constraints the engineers worked around.
Sixth move: use the report to decide what to patent next
Here is the most underrated use of a PCT search report: it tells you what the world thinks is “close” to your idea. That helps you decide what to patent next.
Think of your product as a map with several routes a competitor could take to copy you.
The report shows which routes already have roads.
Your job is to build fences on the routes that matter most.
This is how you decide on follow-on filings:
- If the report shows the “core method” is crowded, focus on implementation details that create real advantage.
- If the report shows nobody cited your deployment pattern, your monitoring loop, or your safety gating, those may be open areas.
- If the report shows one reference is extremely close, you may need to design around it and patent the design-around.
That last point is important.
A search report can inspire better engineering. If you see prior art that blocks one approach, you can choose a different approach that is both better for the product and better for patentability.
That is not “gaming the system.” That is smart product strategy.
A quick reality check for founders: patents are not only about court fights
Some founders say, “We’re too early. Patents don’t matter unless we sue.”
That is not how it works in deep tech.
In robotics and AI, patents are often used for:
- making investors take you seriously early
- proving technical depth without giving away secrets
- supporting partnerships with larger companies
- deterring fast followers who want an easy copy
- increasing acquisition value later
A strong early patent plan is not about being aggressive. It is about being hard to ignore.
And that plan is built through feedback loops like the PCT search report.
Using PCT Search Reports to Adjust Your Strategy
A “bad” report can still be a win
A search report can look harsh on paper and still be one of the best things that happens to your IP plan. The report is doing its job. It is showing you where your first draft is weak, where your idea is crowded, and where your true edge is hiding.
If you treat it like feedback, you can re-aim your patent scope before you spend more money on the wrong claims. You also get a clearer story for investors: you are not guessing, you are learning fast and adapting.
What you should feel after reading it
You should not feel defeated. You should feel informed. The report is not a final ruling, and it is not the same as a rejection in national phase.
It is a map of what the examiner found quickly, based on what you wrote. That means you can often change the outcome by changing how you claim, not by changing what you built.
The mindset shift that saves time
Your PCT year is valuable because you still have options. You can narrow, split, or shift your claims while product work is still moving.
This is why founders who use the report well tend to end up with stronger patents and fewer dead-end filings.
If you want Tran.vc to help you translate a search report into a stronger claim plan with real patent attorneys, you can apply anytime at https://www.tran.vc/apply-now-form/.
Turn the Search Report Into a Clear Decision Document
Start with a one-page “what changed” note
Before you touch claim language, write a short internal note: what is the product today, and what was it when you filed. This matters more than most teams think.
Many PCT drafts reflect an older build. If your system has evolved, the report may be “attacking” an idea you no longer lead with. That is not failure. It is a sign you must re-anchor the patent around the current moat.
Build a simple map from citations to modules
Take each cited reference and tie it to a part of your system. Do not keep it abstract. Place it in your pipeline, like “sensor calibration,” “planning,” “edge inference,” or “fleet learning.”
When you do this, the report stops being scary text. It becomes a system diagram with labels that say “crowded” or “open.” That is the view you need to make strategy decisions.
Rank what matters commercially
Not every claim is worth defending. Some claims exist because the first draft tried to cover everything. That is common, and it is fixable.
Pick the few outcomes that matter to the business. If a competitor copies those outcomes, do you lose deals, margin, or speed? If yes, those outcomes deserve focus. If not, do not waste your best effort there.
Diagnose the “X” and “Y” Hits Without Panic
When an “X” is a drafting problem
An “X” often shows up because the claim reads like a common pattern. AI and robotics patents can get hit fast when they describe goals, not the real steps that make the system work.
If your claim says “use a model to do X,” you are inviting a direct hit. The fix is not emotional. The fix is technical detail placed in the right spot in the claim.