Your team just shipped a new module. Maybe it’s a smarter matching algorithm, a new way to sync data across platforms, or a workflow automation layer that cuts processing time in half. Someone on the team says, “Should we patent this?” Nobody knows how to answer that question. So it gets tabled, revisited maybe six months later, and usually forgotten until a competitor launches something similar or an acquirer asks what’s protected.
I see this pattern constantly with companies that ship functionality on a regular cadence. They’re moving too fast to stop and evaluate every module, so they either patent nothing or they guess. Both approaches leave value on the table. Here’s a framework for making that call faster and with more confidence.
Start With What Changed, Not What It Does
The first mistake teams make is describing what the module accomplishes for the user. It lets customers reconcile invoices automatically tells you about the feature. It doesn’t tell you whether there’s anything protectable underneath it. The question that actually matters: what did your engineers have to figure out that didn’t already exist? Every module does something. Not every module represents a new way of doing it. A reconciliation feature that calls an existing third-party API and displays results in a new UI is functionality, not invention. A reconciliation feature that had to solve a genuine technical problem, like matching records across systems with inconsistent formatting, incomplete data, and no shared identifier, might be something else entirely. The distinction is between “we built a feature” and we solved a problem nobody had solved the same way before. Only the second one is worth evaluating further.
A useful exercise: have the engineering lead explain the module to you as if you were another engineer who works on a competing product and is trying to figure out how you did it. If the answer is we called an API and formatted the output, that’s the end of the conversation. If the answer takes ten minutes and involves diagrams, that’s a signal.
Ask Whether the Approach Is New, Not Just the Result
This is where most founders get confused, and understandably so, because the confusion is baked into how AI and software get talked about publicly. Whether a module may be patentable does not turn on whether it uses AI, whether it’s “innovative” in a business sense, or whether customers find it valuable. None of that answers the legal question. What matters is whether the specific technical approach, the architecture, the processing method, the way the system handles a particular constraint, is new and non-obvious compared to what already existed. Under 35 U.S.C. § 101, patent protection is available for any new and useful process, machine, manufacture, or composition of matter.35 USCS § 101.To be patentable, an invention must also be novel35 USCS § 102 and non-obvious.35 USCS § 103.
A module that uses a well-known machine learning technique in a fairly expected way to do something machine learning is commonly used for is unlikely to represent anything protectable, no matter how well it performs. A module that uses a novel combination of techniques to solve a problem in a way nobody else has published or shipped is a different story. The Supreme Court has held that an invention combining known elements may be patentable if the combination transforms those elements into something more than the predictable use of prior art elements according to their established functions. Diamond v. Diehr, 450 U.S. 175, 183 (1981).
Here’s a distinction I use with clients building on top of existing models or platforms: did you customize an existing tool, or did you build a new technical process? Fine-tuning a third-party model with your own data and calling it a differentiator is common, and it’s rarely enough on its own. Building a new pipeline that determines how inputs are pre-processed, how outputs are validated, or how the system adapts over time based on a mechanism you designed, that’s closer to something worth evaluating. Software inventions must contain an “inventive concept” that transforms an abstract idea into a patent-eligible application, not merely implement an abstract idea on a computer. Alice Corp. Pty. Ltd. v. CLS Bank Int’l, 573 U.S. 208, 212 (2014), Mayo Collaborative Servs. v. Prometheus Labs., Inc., 566 U.S. 66, 73 (2012).
This is a fact-specific question every time. Whether a particular module clears that bar depends on the technical details of what was actually built, and that’s a judgment call worth getting from an attorney who can look at the specifics rather than a general rule from a blog post.
Check Whether It Solves a Problem or Improves on a Known One
Modules tend to fall into a few categories, and they don’t all deserve the same amount of attention. New functionality that didn’t exist in your product before. This is the category most likely to include something protectable, especially if the functionality required solving a technical problem rather than integrating existing tools. An improvement to something that already worked, but works meaningfully differently now. Speed improvements, accuracy improvements, and scale improvements can be protectable if the improvement comes from a new technical approach rather than better hardware, more data, or incremental tuning. The test is whether a competitor could replicate the improvement just by knowing the result you achieved, or whether they’d need to know your specific method.
A new interface or workflow wrapped around existing technical capability. This is usually the weakest category. A better UI, a smoother onboarding flow, or a more intuitive dashboard can be valuable business differentiators without being technical inventions. Design and trade dress protections exist for some of this, but that’s a different conversation from patent protection. Not every module needs to be evaluated with the same intensity. A module that’s clearly a UI refinement doesn’t need a formal review. A module that took your engineers three months to figure out and that competitors have publicly struggled to replicate deserves a closer look.
Consider Who Else Could Have Built It
One more question worth asking before you decide a module is or isn’t worth pursuing: if you handed a competent engineer at a competing company the same problem and the same general constraints, would they likely land on the same solution? If the answer is probably yes, because the approach is the standard one anyone in the field would reach for, that’s a signal the module may not clear the bar. If the answer is no, because your engineers made a series of non-obvious choices to get there, that’s a signal worth pursuing further. This isn’t a precise legal test, and it isn’t meant to be. It’s a gut check to help you triage which modules deserve a real conversation with counsel and which ones don’t.
What This Looks Like in Practice
Companies that ship modules regularly don’t have time to run every release through a formal evaluation, and they shouldn’t try to. What works better is a lightweight internal habit: whenever a module requires solving a technical problem that took real engineering effort, someone flags it for review before the next release cycle, not after a competitor asks about it or an acquirer’s due diligence team does. That review doesn’t need to be a full patentability opinion every time. Sometimes it’s a twenty-minute conversation that confirms there’s nothing to pursue. Sometimes it surfaces something worth protecting before a public launch closes the door on that option. Either outcome is useful, and either one is faster and cheaper than trying to reconstruct the history of a feature two years later when someone else has copied it.
If your team is shipping new functionality on a regular basis and you don’t have a process for flagging what’s worth a second look, that’s usually the actual problem, not any specific module you’re wondering about today. Is there a module your team built this year that took longer than expected to figure out? That’s usually the first place to look.
If you want contracts that hold, IP that’s protected, and legal bills that don’t surprise you every month, let’s talk. Garcia-Zamor Law Firm delivers fractional in-house counsel with a unique advantage: business law PLUS IP expertise, brought to you by Ruy Garcia-Zamor, Elliott Alderman, Claudia Castillo, and Amulya Annasamudram. Passionately devoted to your success. Visit garcia-zamor.com or call (410) 531-9853.
