Plain-English answers about software patents, prior art, the Alice test, freedom to operate, and how Patentable fits a developer workflow. No legalese, no fluff.
A patent is a time-limited right granted by a government that lets you stop other people from making, using, or selling your invention without permission, in exchange for publishing how it works.
In the US a utility patent lasts 20 years from the filing date. After that, the invention is free for anyone to use.
The classic test has four parts: the invention must be patentable subject matter, novel, non-obvious, and useful. Subject matter is where software runs into trouble, which is its own question below.
Novel means nobody has publicly disclosed it before your filing date. Non-obvious means it would not have been an obvious next step to a skilled engineer looking at what already existed. Useful is a low bar that almost everything clears.
A provisional application is a cheaper, simpler filing that locks in your priority date for 12 months. It is never examined and never becomes a patent on its own. It buys you a year to decide whether to file the full thing.
A non-provisional (utility) application is the real one. It gets examined by the patent office and, if granted, becomes an enforceable patent. Most software founders file a provisional first to stake the date cheaply, then convert within the year.
A provisional can be a few hundred dollars in government fees if you draft it yourself, more with an attorney. A full utility application through a law firm commonly runs 8,000 to 15,000 dollars or more once you include drafting, filing, and the back-and-forth with the examiner.
That cost is exactly why a lot of genuinely patentable software never gets protected: founders cannot tell which ideas are worth the spend, so they protect nothing.
Yes, but it is the hardest category. The obstacle is a 2014 Supreme Court decision, Alice Corp v CLS Bank, which says you cannot patent an abstract idea just by adding the words "on a computer."
Courts apply a two-step test (often called the Alice/Mayo framework, codified around 35 USC 101). Step one: is the claim directed to an abstract idea? Step two: if so, does it add an inventive concept that amounts to significantly more than the abstract idea itself? A lot of software claims die at step two.
Software that solves a specific technical problem with a specific technical mechanism tends to survive. A named problem plus a concrete how. Improvements to how a computer itself works, network architecture, data structures that produce a technical effect, these have a real shot.
What dies: "use machine learning to do X," generic business methods dressed up with a server, automating a manual process with no technical innovation. If your claim could be performed by a human with pen and paper, it is in danger.
Specificity. "A system that recommends content" is abstract. "A system that reduces recommendation latency by precomputing embeddings in a tiered cache keyed on a derived session token" names a technical problem and a mechanism. The second one is the shape that survives.
Patentable scores both dimensions for you: how novel the idea is, and how likely it is to survive a Section 101 rejection, so you do not spend money on a claim that will not make it past the examiner.
Prior art is any public evidence that your invention already existed before your filing date. Existing patents, published applications, academic papers, product manuals, open-source code, even a public GitHub discussion can count.
If prior art describes your invention, you cannot patent it (it is not novel). If prior art makes your invention an obvious combination, you cannot patent it either (it is obvious).
Patents describe the same idea in wildly different words. A patent that anticipates your "neural network for fraud detection" might call it an "adaptive multi-layer classifier for anomalous transaction scoring." A keyword search for your phrasing will miss it entirely.
That is why Patentable uses semantic search over a 768-dimensional patent-specialized embedding model. It matches on concept, not wording, across millions of patent claims, so it surfaces the prior art that keyword search hides.
Patentability asks "can I get a patent on this?" Freedom to operate (FTO) asks the opposite and more urgent question: "can I ship this without infringing someone else's patent?"
You can have a perfectly novel product that still infringes an existing patent on one of its components. FTO analysis maps the patents you might be stepping on before you launch, so a lawsuit does not.
When a patent blocks your path, you do not always have to abandon the feature. A design-around (sometimes write-around) is a deliberate engineering of an alternative that achieves the same goal without practicing the patent's claims.
Patentable can generate design-around suggestions by reading the blocking claims and proposing technical alternatives that fall outside them.
Sometimes. A patent is an asset: it can raise your valuation, deter copycats, and become a bargaining chip in an acquisition. But it is also slow and expensive, and a granted patent you cannot afford to enforce has limited teeth.
The pragmatic move is to know what is patentable in what you have built, file provisionals cheaply on the few things that matter, and not waste money on the rest. Knowing which is which is the hard part, and the part Patentable automates.
It can. A public disclosure starts a clock. In the US you generally have a 12-month grace period to file after your own public disclosure, but in most of the rest of the world disclosure before filing is an immediate bar.
If you think something in your codebase is patentable, talk to it before you make it public, or at least file a provisional first.
Yes. Point a project at a GitHub repo (or an ElseHub project) and Patentable reads the code and docs, identifies candidate inventions, scores each for novelty and Alice survival, and runs prior-art search against the candidates.
It is built to find inventions in the implementation itself, not just from a description you write, so it can surface patentable work you did not realize was patentable.
They are sister products from the same team. Patentable protects what you invent (the novel mechanism in your code). Copyrightable proves what you authored (your creative control over AI-assisted output, as legal evidence).
For a developer working with AI, the same coding session can carry both: a patentable invention and a defensible authorship record. See the blog post "Meet Copyrightable" for how the two fit together.
A corpus of over 5 million US patents with plain-English claim translations and semantic embeddings, covering software, AI, ML, blockchain, networking, security, and related fields.
Every patent, inventor, and topic is a browsable page, so you can explore the landscape as well as search it.
No, and it does not try to. It does the expensive, slow, early-stage work: finding prior art, scoring patentability, drafting starting points, scoping freedom to operate. That makes the attorney conversation faster and cheaper because you arrive with the homework done.
Nothing Patentable produces is legal advice. It is intelligence that informs a decision you make with counsel.
Searches and analyses run server-side and your inputs are not published. If you are evaluating Patentable for sensitive work, ask us about data handling for your specific use case.
Start a prior art search, browse the patent corpus, or scan your own repo for patentable inventions.