Answers · IP Strategy & Portfolio
How do you build an IP protection strategy for software?
Updated July 2026
The short answer
A software IP strategy uses four layers: patents for technical innovations a competitor could observe or reverse-engineer, copyright for the code itself, trade secrets for everything hidden in the backend, and contracts binding the people who touch all of it. No single layer protects a software product on its own, because each one fails in a place the others hold.
The decision rule that organizes the whole strategy: patent what competitors could see or figure out from your shipped product, and keep secret what they could not. Since the Supreme Court's 2014 Alice v. CLS Bank decision narrowed what software claims survive, running that sort before anything is filed matters more in software than in any other field.
What to patent vs what to keep secret: typical calls in software
| Observable in the product (patent candidates) | Hidden in the backend (trade secret candidates) |
|---|---|
| A data processing method whose technical effect shows up in the product's behavior | The algorithm's weights, thresholds, and tuning parameters |
| System architecture a competitor could infer from APIs and network traffic | Server-side infrastructure, deployment configuration, and scaling know-how |
| A performance improvement a competitor could benchmark and replicate | The profiling data and optimization process that produced it |
| Client-side features discoverable by decompiling the shipped binary | Training data, data pipelines, and model weights behind AI features |
| A novel user interaction or device-side sync method | Build tooling, test harnesses, and internal developer infrastructure |
The four layers and what each one actually covers
Patents protect technical innovations that can withstand Section 101 scrutiny: system architecture, data processing methods with a demonstrable technical effect, and performance improvements you can measure in speed, memory, or reliability. Copyright attaches automatically the moment code is written and covers the literal expression, so a competitor cannot copy your source, but it does nothing against one who studies your product and reimplements the same functionality independently.
Trade secrets carry the load for everything not observable from outside: algorithms and their tuning, training data, backend systems, deployment know-how, even supplier and infrastructure relationships. In our engagements we have seen a sustained shift toward trade secrets in software since Alice, and our trade secret practice has grown with it. Contracts are the fourth layer and the one that makes the third enforceable: assignment agreements, NDAs, and exit protocols are part of the reasonable measures that trade secret law, including the federal Defend Trade Secrets Act, requires before it protects anything.
Patenting software after Alice
Since 2014, claims directed at an abstract idea without a technical improvement are routinely rejected at the USPTO or invalidated afterward, often through inter partes review. Plenty of software patents granted before Alice turned out not to hold up. The claims that survive describe a specific technical problem and a specific technical solution: an architecture that changes how the system works, a processing method with a concrete technical effect, an improvement to the functioning of the computer itself. Claim strategy, meaning what you choose to claim and how the invention is framed as a technical advance, decides more of the outcome in software than anywhere else.
ipCG is a consultancy, not a law firm. We design the layered strategy, run the invention sessions, and produce the invention disclosures that give counsel the technical depth an Alice-resistant application needs. Section 101 opinions, claim drafting, and filings belong with a registered patent attorney or agent.
The observable test, open-source hygiene, and where AI models fit
The observable test does the sorting. If the innovation shows up in the interface, in network traffic, in API behavior, or in a decompiled client, secrecy will eventually fail and a patent is the only protection that holds. If it lives server-side where no teardown reaches it, a patent would publish it for nothing. The two layers can split a single product deliberately: patent the observable system, keep the implementation parameters and tuning secret. One discipline applies throughout: if everything is a trade secret, nothing is, so classify deliberately and document what you are protecting.
Two software-specific checks round out the strategy. First, open-source hygiene: know what licenses your dependencies carry, because an inbound copyleft license can constrain your proprietary position in code you thought you owned outright. Second, AI assets: model weights, training data, and pipeline design are usually trade secret territory, since none of it is observable from the product's outputs. We cover that call in a companion answer linked below.
This topic on the Invent Anything podcast
IP Power Play: Dominate Your Industry with Patents and Trade Secrets (Invent Anything Episode 47)
Using Trade Secrets to Create Tremendous Value (Invent Anything Episode 11)
More episodes on the Invent Anything podcast page.
Related questions
Are software patents dead after Alice?
No, but the bar moved. Claims that recite an abstract idea on a generic computer get rejected or invalidated; claims that show a specific technical improvement, in architecture, processing, or performance, continue to issue and hold up. The difference is made early, in how the invention is framed and disclosed, which is why claim strategy carries more weight in software than in any other field.
Is copyright enough to protect software?
No. Copyright is free and automatic, which makes it a good floor, but it only stops copying of the code itself. A competitor who observes what your product does and writes their own implementation owes you nothing under copyright. Functional innovations need patents, and hidden ones need a real trade secret program.
Should a SaaS startup patent anything?
Usually a small number of things, chosen carefully. Most of a SaaS product runs server-side where the observable test favors trade secrets, and commonly cited estimates put the full life cost of a single US patent at $25,000 to $40,000 or more. The patent candidates are the parts a competitor could see and copy: distinctive client-side methods, observable technical effects, and architecture that shows through the API. One or two well-chosen filings also carry weight with investors.
Do open-source dependencies really threaten our proprietary code?
They can. Most permissive licenses (MIT, Apache) pose little risk, but copyleft licenses in the GPL family can obligate you to release source you intended to keep proprietary, depending on how the dependency is linked and distributed. An inventory of dependency licenses is cheap insurance; the legal read on a specific license conflict belongs with counsel.
Sort your stack into the four layers
A free discovery call is enough to walk through your product and make the first pass: what is observable, what should stay secret, and where a patent filing would actually hold up. No obligation, and every engagement is scoped individually.
Book a Free Discovery CallRelated
ipCapital Group is a consultancy, not a law firm, and nothing on this page is legal advice. Dollar figures on this page are typical market ranges for professional IP services, drawn from published sources and industry experience across a variety of providers. They are not an ipCG quote or rate card; every ipCG engagement is individually scoped and priced. See how our pricing works.