Where Patentable Inventions Hide in a Mature Codebase

When I ask an engineering leader whether their code contains anything patentable, the usual answer is "probably not, we just build product." Then we open the repository and spend an hour on the parts nobody thinks about anymore, and a few candidates turn up. That pattern is common enough that I now start every review in the same places.

This is a practical map, not legal advice. Whether something is patentable is a question for your patent counsel. The goal here is to find the work worth bringing to them.

1. The workaround that became the system

Most mature products have a module that started as a fix for a hard constraint: a slow third party service, a memory limit, a data source that arrives out of order. Over time the fix got smarter and became core. Engineers stop seeing it as clever because they live with it every day. These are often the strongest candidates, because the problem was real and the solution was specific.

2. Data pipelines and scheduling logic

How you move, clean, batch or prioritize data is frequently more original than the user interface on top of it. Look for custom ordering rules, deduplication methods, caching strategies tied to your domain, and anything that decides what runs next.

3. Performance work with a measurable result

If a commit message says something like "cut latency on X by half," read the diff. A specific technical change that produced a concrete improvement is easier to describe and easier for counsel to assess than a broad idea.

4. Hardware and device interfaces

Code that talks to sensors, firmware, controllers or test equipment tends to solve physical problems in unusual ways. Calibration routines, error correction and timing logic are worth a close look.

5. The internal tools nobody markets

Deployment systems, test harnesses and internal dashboards sometimes contain the most interesting methods in the company, because engineers built them for themselves with no product manager trimming scope.

How to review without disrupting the team

• Keep access read-only and scoped. Pick the repositories that matter and leave the rest.
• Read first, interview second. Short conversations work better once the reviewer already knows which files to ask about.
• Write down who built it. Note the people involved and roughly when. Counsel will need this to determine inventorship.
• Record the reason for each call. Patent, trade secret or skip, with one sentence on why.

What to do with the list

A short, ranked list with plain descriptions is far more useful to counsel than a long dump of everything that seemed interesting. If you want an outside team to run this review, our Codebase Invention Audit does it under NDA with read-only access. For the patent versus secrecy question, see our decision framework.

This article is general business information, not legal advice. Idea Partnership does not practice law. Consult licensed patent counsel about your situation.