Skip to content

IP Protection Checklist for Engineering Teams

Your team ships code every day. Some of it is novel enough to patent. Without a checklist, those inventions get published on GitHub, discussed in conference talks, and incorporated into products with no filing date, no protection, and no leverage.

This is not a problem that solves itself. Publishing code, documentation, or a conference talk that reveals how the invention works can start filing deadlines in the U.S. and can jeopardize rights in most other countries, which do not offer a comparable grace period. Whether a particular publication affects a particular claim is fact-specific. But by the time anyone thinks to ask the question, the publication has already happened.

This checklist gives engineering teams a repeatable process for identifying, capturing, and protecting the inventions their engineers create every sprint.

Last updated: July 2026. This page is informational only and not legal advice. Consult a patent attorney for your specific situation.

The IP Protection Checklist

Five areas, eighteen items. You don't need to implement all of them today. Start with the ones that prevent the most damage (Areas 1 and 3), then layer in the rest quarterly.

1

People and Agreements

Ensure every person who touches your codebase has the right paperwork in place.

Every employee has signed an IP assignment agreement.

Use a CIIA (Confidential Information and Invention Assignment) agreement. Without one, employees may retain rights to inventions they create on company time. Free templates are available from Cooley GO.

Contractor agreements include invention assignment and work-for-hire clauses.

Work-for-hire alone is not enough for patent rights. You need an explicit invention assignment clause. This is especially important for remote contractors in other jurisdictions. Read our guide on contractor IP clauses.

New hires complete IP onboarding within their first 30 days.

This means signing the CIIA, disclosing any pre-existing IP they are bringing in (or explicitly not assigning), and understanding the team's invention capture process.

Departing employees acknowledge IP obligations in exit process.

Confirm that all work product has been handed over, that the departing employee understands their ongoing obligations (such as cooperation with patent prosecution), and that they have returned any proprietary materials.

2

Code and Invention Capture

Build habits that catch inventions before they disappear into the commit history.

Regular cadence for reviewing recent work for patentable concepts (quarterly minimum).

Schedule a recurring review meeting. Walk through the last quarter's major features, architecture decisions, and novel algorithms. Ask: "Did we solve a technical problem in a way nobody else has?" That is the signal worth investigating.

Process for engineers to flag potentially novel approaches.

Give engineers a lightweight way to say "I think this is new." A Slack channel, a form, or a tag in your issue tracker. The goal is to reduce friction to near zero. Most engineers will not fill out a 10-page invention disclosure form, but they will drop a message in a channel.

Invention disclosure template accessible to the whole team.

When something is flagged, you need a structured way to capture it. A good disclosure template covers: what the problem was, what existing solutions look like, what your approach does differently, and who contributed to the solution.

Technical notebooks or structured logs for documenting approaches.

Commit messages, design docs, and architecture decision records all serve as evidence of conception. They establish who had the idea, when they had it, and how it evolved. This matters if inventorship is ever disputed.

3

Pre-Publication Review

Catch inventions before they become unprotectable public disclosures.

Code reviewed before open-sourcing for patentable content.

Publishing code can publicly disclose whatever it actually teaches a skilled reader. In the U.S., an inventor's own disclosure generally opens a 12-month window to file. Most other countries have no comparable grace period. Review before you push, not after.

Conference talks and blog posts screened for undisclosed inventions.

Engineers love sharing what they built. That is great for recruiting and community, but a talk that explains how a novel mechanism actually works can publicly disclose it. Screen presentations, slides, and recordings before they go out.

Grace period awareness: the U.S. gives 12 months from disclosure, most other countries give zero.

This is the single most important timing fact for engineering teams. If international rights matter, publicly disclosing the invention before filing can forfeit them in most jurisdictions, and the U.S. grace period does not extend abroad. The safe sequence is file first, publish second.

4

AI Tool Governance

Manage the IP risks that come with AI-assisted development.

Inventory of which AI tools the team uses and what data they receive.

Know what your engineers are pasting into ChatGPT, Copilot, and other AI tools. Data handling varies by provider, product, account tier, settings, and contract, and it changes over time. Keep an approved-tool register and verify the current terms rather than assuming from the brand name.

No unpublished invention details pasted into consumer AI tools.

Pasting an unpublished invention into a third-party AI service is a disclosure to that provider. That is not automatically a public disclosure in the patent sense, and it should not be described as one. What it can do is put confidentiality, trade-secret "reasonable measures," contractual obligations, and export compliance at risk, while creating a copy of your invention in a system you do not control. Treat it as a controlled disclosure that needs approval, not a routine tool call.

Local-first tools evaluated for invention discovery and drafting.

Tools that run locally (on your hardware, with your data staying on your machine) avoid the disclosure risk of cloud-based AI. Evaluate local-first options for code analysis and invention discovery. See self-serve scanning options.

AI-generated code contributions documented for inventorship clarity.

Only natural persons can be named as inventors. Under the USPTO's revised guidance (Nov. 28, 2025), there is no separate AI-specific test: the ordinary conception standard applies, and inventorship turns on who conceived the subject matter that ends up claimed. Prompting, selecting, testing, and modifying AI output can all be relevant evidence, but no single one of those activities automatically establishes inventorship. Record what the human decided and why, not a conclusion about who the inventor is. Read more about AI and inventorship.

5

Filing Readiness

Be ready to file when the time comes, not scrambling to get started.

Relationship with a patent attorney or firm established before you need one.

Finding a patent attorney after you discover a patentable invention is too late. The best time to establish the relationship is before your first filing. Look for an attorney with experience in software patents and your specific technology domain.

Provisional patent application budget allocated (fee plus preparation).

USPTO filing fees for a provisional are $65 for micro entities, $130 for small entities, and $325 for large entities. Budget for more than the fee. A provisional only supports subject matter it actually describes, so a thin filing that omits the architecture, the alternatives, and the technical effects may provide little useful support when you convert. The real costs are preparation time, drawings, attorney review, and the non-provisional or PCT conversion within twelve months. Read our provisional patent strategy guide.

Priority matrix for which inventions to file first.

Not every invention deserves a patent filing, and some are better kept as trade secrets. Weigh competitive advantage (does this differentiate the product?), revenue impact, defensive value, detectability (could you tell if a competitor used it?), and design-around difficulty. One factor teams routinely miss: a patent publishes. If the filing would teach competitors more than the resulting claims would realistically stop them from doing, secrecy may protect you better.

Getting Started

Don't try to implement all eighteen items at once. That is how checklists become shelfware.

Start here (Week 1)

Area 1: People and Agreements. If your employees and contractors haven't signed IP assignment agreements, nothing else on this list matters. Unsigned agreements are the single most common source of IP disputes.

Add next (Month 1)

Area 3: Pre-Publication Review. These controls prevent the least reversible damage. A single conference talk or open-source push can forfeit international rights, and unlike most engineering mistakes, publication cannot be rolled back.

Layer in quarterly

Areas 2, 4, and 5. Once agreements are signed and publication controls are in place, build out invention capture (Area 2), AI governance (Area 4), and filing readiness (Area 5) over the next two to three quarters.

The goal is progress, not perfection. A team that checks off six items this quarter is in a dramatically better position than a team with a perfect 18-item checklist that never gets implemented. Start with what prevents the most damage.

Frequently Asked Questions

We're a small startup. Do we really need all of this?

You need Areas 1 and 3 regardless of size. IP assignment agreements (Area 1) prevent co-ownership disputes that can destroy a company. Pre-publication review (Area 3) prevents irreversible loss of patent rights. The remaining areas become more important as you grow, but the foundation matters from day one.

How do we get engineers to actually flag inventions?

Reduce friction. A Slack message is better than a 10-page form. Some companies tie invention disclosures to performance reviews or offer small bonuses for submissions. The most effective approach is making it a normal part of sprint retrospectives: "Did we solve any problem in a way that surprised us?" That question surfaces more inventions than any formal process.

What counts as a "public disclosure" for patent purposes?

Broadly, something that makes the invention available to the public: publishing code on GitHub, presenting at a conference, posting a blog, submitting to a preprint server, demonstrating to a customer without an NDA, or discussing it in a public forum. Disclosures under NDA generally do not count, but the NDA has to be in place first. Worth separating from this category: sending material to a vendor or AI provider is a disclosure to that third party, which raises confidentiality and trade-secret questions, but it is not automatically a public disclosure in the patent sense.

Can we use AI tools to help identify patentable concepts in our code?

Yes, but choose your tools carefully. Cloud-based AI tools that process your code on external servers create disclosure risks. Local-first tools that run entirely on your hardware avoid this problem. The Concept Scanner, for example, runs locally using Ollama, so your code never leaves your machine. See all scanning options.

What if we've already open-sourced code that contains patentable concepts?

In the United States, you may still have time. The U.S. generally provides a 12-month grace period from an inventor's own public disclosure. If your push was less than 12 months ago, talk to a patent attorney now rather than assuming either way. Foreign rights are the harder question, since most jurisdictions have no comparable grace period, and whether a specific publication affects specific claims depends on what it actually taught. Going forward, add a pre-publication review step (Area 3).