Search Before You Build: Why I Ask R&D Teams for a Simple FTO at Project Kickoff

What happens when R&D finishes before anyone searches?

In my 20 years of practice, one technical due diligence engagement stays with me more than most.

An academician, a Chinese scientist who had returned from Canada, had developed a new type of electrical cable. A US-dollar fund had already put tens of millions of RMB into the project as angel investment. The fund then engaged my team to carry out technical due diligence. When we searched, we found that the same type of technology had been patented in Japan decades earlier.

That is what reinventing the wheel looks like in practice. A large amount of R&D investment had gone into solving a problem that had a published answer all along. The problem was not the quality of the research. What was missing was a search at the start.

The most expensive patent search is the one done after the money is spent. In the cable project I reviewed, the answer had sat in Japanese patent literature for decades before the R&D began.

Why does this keep happening to good R&D teams?

Patent literature is a different body of knowledge from the journals and conferences researchers follow. Plenty of engineering solutions are only ever written up as patents. They are written in legal language, classified under schemes engineers rarely use, and published in many languages. A team can be expert in its field and still never see the one document that matters, especially when that document is old and not in English.

The fix is not to make engineers into patent searchers. It is to make the search a gate in the project approval process, so it happens before the budget is committed rather than when someone thinks of it.

How deep should the pre-project search go?

My recommendation to R&D teams is specific: search to the depth of a simplified freedom-to-operate (FTO) analysis before the project is approved. One search effort, two purposes.

Purpose one: avoid reinventing the wheel. Here you are asking whether the core technical idea has already been published. For this question, everything counts: old patents, expired patents, abandoned applications, foreign-language documents. The Japanese patents in the cable case would have been found by exactly this kind of search.

Purpose two: avoid infringement risk later. Here you are asking a different question: if we build the product we are planning, could it fall within the claims of a patent that is still in force in the markets where we intend to sell? Only live patents in relevant jurisdictions matter for this, and you compare them against the features of your planned product, not against the abstract idea.

Doing both at kickoff is what makes the search pay for itself. The first half cuts ineffective R&D. The second half stops you from building something new that you then cannot sell freely.

One search at kickoff, two answers: has this been solved before (all prior art counts, however old), and could our planned product fall within a live patent in our target markets? That is the depth I ask R&D teams to reach.

What does a kickoff search look like in practice?

It does not need to be elaborate, but it does need to be disciplined:

1. Write the technical problem and the planned solution in plain words, one short paragraph each. If the team cannot do this, the project is not ready for approval anyway.
2. List the key technical features of the planned product: the structures, steps, materials or control logic that make it work.
3. Search by those features, not by the product name. Combine keywords with patent classification codes, and include other languages where the field has strong foreign players. The cable case is a reminder that the decisive document may not be in English or Chinese.
4. For the infringement half, read the claims, not the abstracts, of live patents in your target markets, and compare them feature by feature with the planned product.
5. Write down what you searched and what you found.

What should the results change?

A kickoff search rarely says simply "go" or "stop". The usual outcomes are:

• The problem is already solved. If the earlier patent has expired, the technology may be free to use, which turns a research project into an engineering one. Whether a particular patent has actually lapsed must be checked, not assumed from its age.
• Part of the problem is solved. Redirect the effort to the parts that are genuinely open.
• A live patent sits in the way. Decide early whether to design around it, seek a license, or choose another route, while the design is still flexible.
• Nothing close turns up. Proceed, and record what you searched, because that record helps later when you file your own application.

What does a simplified FTO not do?

It is a steering tool for R&D, not a legal clearance. Designs change during development, so the search should be repeated when the design is frozen and again before launch in each market. A formal FTO opinion depends on detailed claim interpretation, the law of each country and the exact product, and that is work for a qualified practitioner.

This is not legal advice; consult a qualified patent attorney for your situation.

How do you make this a habit rather than a one-off?

Make it part of project approval. In practice that means the project proposal must include a short note on what was searched, what came up, and how the plan responds to it. Once that question is asked at every kickoff, the case I described above becomes much harder to repeat.