Software IP: patent or trade secret

For most software businesses, the choice between patent and trade secret protection is not a question of which is stronger. It is a question of which is appropriate for the specific invention and the specific company.

A founder building a software business who decides to protect the underlying technology has two main options, and they are nearly opposites. A patent is a published document granting a time-limited monopoly in exchange for full public disclosure of how the invention works. A trade secret is a competitive advantage that exists only as long as the underlying information stays confidential. The decision between them is not which is stronger in the abstract. It is which is appropriate for the specific invention, the specific company, and the specific way the technology will be commercialized.

A patent on software is harder to obtain today than founders often assume. The novelty requirement asks whether the invention has been previously known or used; prior art that discloses all the features of a claim defeats it. The non-obviousness requirement asks whether the invention would have been obvious to a person of ordinary skill in the relevant field at the time of filing. The eligibility requirement, shaped by the Supreme Court’s decision in Alice Corp. v. CLS Bank and the line of cases that followed, asks whether the claim is directed to an abstract idea, and if so, whether the claim adds something significantly more than the idea itself. A claim that reads as “do a known thing on a computer” usually fails. A claim that recites a technical solution to a technical problem, with concrete implementation detail, usually has a path forward. This is the criterion that catches the most software applicants by surprise.

A patent that issues is publicly available the day it does. Anyone, including competitors, can read the specification and the claims. The protection runs roughly twenty years from the filing date, and it ends. After it ends, the disclosure is in the public domain and the technique is free to use. The bargain at the heart of the patent system is disclosure in exchange for a time-limited right to exclude. That bargain is right for some inventions and wrong for others.

A trade secret is the other side of that bargain. The legal requirements are three: the information must derive independent economic value from not being generally known, it must not be readily ascertainable by proper means, and it must be the subject of reasonable measures to maintain its secrecy. If those conditions are met, trade secret protection has no expiration date. The Coca-Cola formula is the canonical example, but most trade secrets are far more mundane: source code, model weights, training data, customer lists, internal pricing logic, manufacturing tolerances. The protection lasts as long as the secret does, and ends the moment the secret leaks, whether through a former employee, a careless vendor, or a security incident.

The right way to choose between them is to ask what kind of invention this is and how it will be used in market. Inventions that can be reverse-engineered from the shipped product are poor trade secret candidates. The protection ends the moment the first customer pulls the product apart. Inventions that run server-side, never leave the company’s infrastructure, and are not observable from the output are good trade secret candidates. The architecture of the deployment matters as much as the architecture of the invention. Inventions that are commercially valuable only if competitors are blocked from copying them, and which can be described in claims that survive eligibility and obviousness review, are good patent candidates. Inventions that are valuable because of how they are operated rather than how they are described are usually better as trade secrets.

The two protections can coexist on the same product. A company can patent the parts of the system that benefit from public, time-limited exclusivity, and rely on trade secret protection for the parts that benefit from indefinite, unpublished confidentiality. The architecture of the IP portfolio should reflect the architecture of the technology, not the other way around.

Whichever path is chosen, the operational discipline starts on day one. For patents, that means filing before any public disclosure starts the one-year statutory clock, and tracking inventorship carefully as the technology evolves. For trade secrets, that means access controls, confidentiality marking, employee and contractor non-disclosure agreements, exit procedures, and a documented program that demonstrates the reasonable measures requirement is being met. Protection that is declared but not operationalized is not protection.

The wrong answer is to do nothing and assume that something will be available later if it turns out to matter. By the time it turns out to matter, the window for the right protection has often closed.