Software patents have a reputation problem. Most engineers see them as legal theater—abstract nonsense that blocks innovation instead of protecting it. But that reputation comes from bad patents: vague methods, obvious workflows, marketing disguised as invention. When you claim a real mechanism—a novel technical solution to a concrete problem—patents become strategic tools, not paperwork.

This guide is for the moment you're about to demo a new feature, publish a paper, or ship a technical release and you ask: *Should I patent this?*

We'll give you a sharp decision framework, four clear outcomes, real-world examples, and a 10-minute worksheet you can use to decide before you expose your work to the world.

---

The Decision Checklist: Patent or Not?

Run through these five questions in order. If you can't answer yes to all five, you probably shouldn't file.

1. Is it a technical mechanism, not just a business process?

Yes: An algorithm that reduces latency by 40%, a data structure that prevents race conditions, a protocol that eliminates round-trips. No: "A method for displaying ads based on user preferences," "A system for managing subscriptions," "An AI-powered recommendation engine" (without specifying how). Rule: If you can't draw a diagram or write pseudocode that shows the invention working, it's not patentable. USPTO and EPO both require technical character—software that improves how computers operate, not just what they display.

2. Is it non-obvious to someone skilled in the field?

Yes: Combining two known techniques in a way that wasn't predictable, solving a problem that previously had no clean solution, achieving a result that surprised you when you first got it working. No: Using a cache to speed up lookups, storing data in JSON instead of XML, applying a standard library function to a new use case. Rule: If a competent engineer could arrive at the same solution in an afternoon given the same constraints, it's obvious. Obvious = not patentable.

3. Does it have commercial or defensive value?

Commercial: Competitors will need this technique to match your performance, or licensees would pay to use it. Defensive: If you don't claim it, someone else might, and then block you from using your own invention. No value: It's a one-time solution, only applies to your internal tools, or the industry will route around it anyway. Rule: Patents cost $10–30K (US) and 18–36 months of legal attention. If the strategic value doesn't justify that, publish defensively instead.

4. Can you disclose it without revealing trade secrets?

Yes: The mechanism itself is the value. Once competitors see the patent, they can implement it—but you still have first-mover advantage, brand, execution. No: The technique only works because of proprietary data, undisclosed parameters, or integration with secret systems. If you describe the algorithm, you give away the advantage. Rule: If the value is in keeping it secret, don't patent. Use trade secret protection instead (more on this below).

5. Will it still matter in 3–5 years?

Patents take 2–4 years to issue (US), sometimes longer (EPO). By the time you have enforceable rights, will the technology still be relevant? Will the market still care?

Yes: Fundamental protocols, core algorithms, infrastructure techniques. These have long half-lives. No: UI patterns, API syntax, features tied to a specific platform version. These evolve faster than patent timelines. Rule: If the innovation will be obsolete before the patent issues, skip it. Focus on execution speed instead.

---

Four Outcomes: What to Do Next

Based on your answers, pick one of these paths:

Outcome 1: File a Full Patent Application

When: You answered yes to all five questions. What to do:
  • Hire a patent attorney with software experience (not a generalist)
  • Prepare: working code, diagrams, performance benchmarks, prior art analysis
  • Budget $15–30K (US), €10–25K (EPO), more for global filing (PCT)
  • Timeline: 18–36 months to first office action, 3–5 years to grant
Example: You built a diff algorithm for virtual DOM updates that reduces re-renders by 60% compared to React's reconciler. It uses a novel tree-traversal order and marks subtrees with cryptographic hashes to skip unchanged branches. Competitors (framework authors) will need similar optimizations. You can describe it publicly without losing competitive advantage because execution and ecosystem matter more than the algorithm itself.

→ File. This is a core technique with broad applicability and long relevance.

Outcome 2: File a Provisional, Gather Evidence, Decide in 12 Months

When: You're 80% sure it's patentable, but you need time to validate commercial value or you're not ready to spend $20K yet. What to do:
  • File a provisional patent application ($2–5K, sometimes DIY)
  • This gives you 12 months of "patent pending" status
  • Use that year to: ship the feature, measure adoption, see if competitors care, gather performance data
  • Before the 12 months expire, either convert to a full application or let it lapse
Example: You designed a prompt-chaining system for LLMs that reduces hallucinations by validating intermediate outputs against a knowledge graph. It works in your tests, but you haven't shipped it to production yet. You're not sure if the technique will generalize or if competitors will need it.

→ Provisional. Lock in your priority date, ship it, see if it matters, then decide.

Outcome 3: Publish Defensively (No Patent)

When: The invention is real and non-obvious, but you don't want to pay for a patent and you don't want competitors to claim it either. What to do:
  • Publish a detailed technical description in a public, timestamped venue:
- Technical blog post with code examples - arXiv preprint - Open-source repository with documentation - Defensive publication services (e.g., IP.com, Research Disclosure)
  • This creates prior art that prevents anyone (including you) from patenting the same idea later
  • You get freedom to operate; everyone else does too
Example: You built a connection pooling strategy for serverless functions that reuses HTTP/2 streams across invocations. It's clever, non-obvious, and you want to share it with the community. But it's not worth $20K to claim exclusively, and you'd rather competitors adopt it (making your approach an industry standard) than have someone else block you.

→ Publish. Write a blog post with diagrams and code, post it on your site, tweet it, archive it on Wayback Machine. Now it's prior art.

Outcome 4: Keep It a Trade Secret (No Disclosure)

When: The value is in the secrecy, not the exclusivity. Or the mechanism depends on proprietary data, parameters, or infrastructure you won't disclose. What to do:
  • Do not file a patent (patents require full public disclosure)
  • Do not publish it
  • Protect it internally: NDAs, access controls, "confidential" markings, limited distribution
  • Document that you're treating it as a trade secret (for legal protection under trade secret law)
Example: Your edge routing algorithm balances load across data centers using real-time latency measurements weighted by proprietary demand forecasting. The algorithm itself is simple, but the forecasting model and the latency data are your competitive moat. If you publish the algorithm, competitors can replicate it with their own data.

→ Trade secret. Don't disclose. Keep it internal. Enforce confidentiality. This protection lasts as long as you keep it secret (no expiration), but if it leaks or someone reverse-engineers it, you lose all rights.

---

Real-World Examples: Patent, Provisional, Publish, or Secret?

Example A: Edge Streaming Protocol

Invention: A protocol that streams HTML fragments from edge workers, inserting