Patent Mining in Practice: Ten Questions I Ask Engineers, and Six Inventions They Forget to Mention

In my 20 years of patent practice, much of my time has gone not into drafting applications but into conversations with engineers: taking what they have already built and, piece by piece, turning it into technical solutions that can be protected. It sounds simple. The hard part is that engineers often do not know which parts of their own work are valuable.

This article covers the process I actually use, the questions I always ask, and the kinds of inventions that most often go unreported.

What does a practical patent mining process look like?

I work in six steps:

1. Review the documents. Project documents, drawings, test records, internal reports. The goal is an overall picture and a list of questions to bring to the interview.
2. Interview. Sit with the engineers who did the work and draw out what the documents do not show.
3. Break it into technical points. Split the material into relatively independent points, each tied to one specific problem and one specific solution.
4. Search and compare. Search the prior art for each point to see what others have already done and where the differences lie.
5. Supplement and verify. For valuable points with thin material, go back to R&D for implementation details, alternatives and test records.
6. Decide the filing plan. Which points to file, what type of protection, which to combine and which to file separately.

The interview is the core. Documents tell you what was done. Only conversation tells you why it was done that way, what was tried before and why it failed, and that is usually where the invention lives.

Which questions surface the most inventions in an engineer interview?

These are the ten questions I return to in almost every interview:

1. What was the hardest problem to solve this time?
2. Which problem caused the most rework and cost the most time?
3. Why didn't the original approach work?
4. Under what conditions did it fail?
5. What exactly did you change in the end?
6. Why does that change work?
7. Do you have before-and-after data or test records?
8. Which features cannot be removed, and which could be replaced?
9. Would it still work with a different material, position, sequence or trigger condition?
10. If a competitor wanted the same effect, how might they do it?

The first four look for the technical problem. Whatever gave the engineers the most trouble and the most rework is usually where existing technology falls short.

Questions five and six look for the technical means and the causal link. Here I have one firm rule: ask the engineer to draw the change (the structure, the steps, the control logic) rather than accept "we optimised it". "Optimised" cannot go into a patent application. Which structure changed, which step was adjusted, and under what condition the control logic triggers can.

Question seven looks for evidence. Before-and-after data and test records are the strongest support for a technical effect. But to be explicit: the data must come from tests that were actually run. If there is no data, there is no data; it must never be created to support a filing. Without data you can still honestly describe the mechanism and the implementation. Fabricated data creates far more risk than missing data.

The last three questions prepare the scope of protection. Which features are essential determines how broad the claims can be. Which are replaceable, and whether the invention still works with substitutes, determines which alternatives the description should record. How a competitor might work around it determines whether those workarounds should be written in as well.

The most important move in an inventor interview is refusing to accept "we optimised it". Have the engineer draw the change (structure, steps, control logic), then ask why it works and which features cannot be removed. Patentable subject matter only appears at the level of a concrete mechanism.

Which inventions do engineers most often forget to report?

This is the part I most want to share. Engineers readily report improvements to a product's main function. But the following six categories are routinely dismissed as "just engineering optimisation" or "something we changed to make the product easier to use", and never mentioned:

1. Jigs, fixtures and auxiliary structures. A locating feature that prevents parts being assembled backwards, a clamping method that protects thin-walled parts, a connection that allows quick changeovers. They are not the product itself, but they solve real production problems.

2. Process steps and how they work together. Changing the order in which materials are added, heating in stages, adding a pretreatment step, and the interplay of temperature, pressure and time. What is worth mining is not "we tuned a parameter" but how the arrangement solves a specific problem.

3. Fault handling and compensation. How the system keeps running when a sensor fails, how false alarms are avoided, how temperature drift and wear are compensated. These mechanisms are usually forced out of engineers during debugging, and are easily dismissed as patches.

4. Testing, measurement and calibration methods. Getting the information you need from fewer sensors, detecting defects without stopping the line, special calibration steps that improve accuracy. Many companies focus only on the product and forget that how you measure can itself be a technical solution.

5. New ways of combining existing parts. The components are off the shelf, but a new connection, layout or control timing solves an old problem. Engineers often say "it's all standard parts, nothing new". The novelty lies in the combination.

6. Workable alternatives that were not adopted. A solution dropped for cost, supply chain or product positioning reasons has not lost its technical value. It may be exactly the route a competitor takes later. The test is whether it is concrete enough to be implemented. A one-line idea is not enough; something that has been drawn, prototyped or at least has a clear implementation path deserves serious discussion.

The inventions most often missed sit where engineers think they "just made it work": fixtures, process coordination, fault compensation, testing and calibration, new combinations of existing parts, and abandoned alternatives that were developed far enough to be implemented.

How do you decide which mined points are worth filing?

Search and verification are the two filters.

Search asks how each point differs from the prior art and whether that difference would be obvious to others in the field. Don't limit the search to products in your own industry; search around the inventive point itself.

Verification asks whether the material can support an application. If the implementation cannot be described clearly or the key step cannot be explained, gather more material before filing.

When deciding the filing plan, I weigh the value of each point, how easily it could be reverse-engineered, and how hard infringement would be to prove, to decide between a patent, a trade secret, or waiting. Every company's situation differs, so make that call with a qualified patent professional.

The bottom line

Patent mining is not about inventing things. It is about finding what R&D has genuinely done, including what they did not realise was valuable, and expressing it completely and clearly in terms the patent system understands.

If you want to structure a technical problem before your next interview, the tool below helps you break it down as a technical contradiction and see which directions emerge.