Software Patents: Why the Mechanism, Not the Formula, Decides Your Claim

In my 20 years of practice, first as a patent attorney and later also as a patent litigator, I have reviewed a great many software and algorithm applications. Clients usually ask me whether their code "can be patented." That is the wrong question. Code as such is not what a patent protects. The right question is whether there is a technical solution behind the code, and whether the claim describes it.

What do I look for first in a software patent application?

When a software or algorithm case lands on my desk, I ask one thing before anything else: compared with the prior art, through what specific mechanism does this algorithm solve a technical problem, and has that contribution been written into the claims?

Everything else follows from that. I break it down into three checks.

1. Technical character. Is the problem a technical one, such as recognition error, communication latency, memory footprint or controlling a device? Or does the algorithm only change marketing rules, pricing or commercial ranking? The second kind is a business improvement, however clever, and wrapping it in the words "server" or "AI" does not change its nature.

2. Inventive step. Where exactly is the difference from the prior art, and why would a practitioner in the field not arrive at it as routine handling? A new name for the algorithm, a more complicated formula or simply applying a known method in another industry does not, by itself, demonstrate inventiveness.

3. Sufficient disclosure. Are the inputs and outputs, processing steps, key relationships and necessary model details explained clearly enough that a skilled person can implement the solution, and can understand why the technical means produce the stated effect?

A software claim is judged on its mechanism, not its mathematics. The same formula can be unpatentable in one claim and patentable in another, depending on whether the claim recites the concrete technical process the formula serves.

How do patent offices in different jurisdictions treat software?

The vocabulary differs, but the underlying concern is similar across the major systems.

• United States. Eligibility is assessed under the two-step framework the Supreme Court set out in Alice: is the claim directed to an abstract idea, and if so, does it add something that amounts to significantly more? Claims that recite a specific improvement to how a technical system works tend to fare better than claims that recite a result.
• Europe. The EPO asks whether the claimed subject matter has technical character and, for computer programs, whether there is a further technical effect beyond the normal interaction of software and hardware. In assessing inventive step, only features that contribute to the technical character are counted.
• China. The Patent Law excludes rules and methods for mental activities, and the Guidelines for Patent Examination contain a dedicated chapter on inventions involving computer programs. Examiners look at whether the solution as a whole uses technical means to solve a technical problem and obtain a technical effect.

Whichever office you file with, the three checks above will carry you most of the way. If your claim describes a concrete technical mechanism, you are having the right argument. If it describes a business goal plus a computer, you are not.

What does a claim that fails look like, and how was it fixed?

This is a real case from my own practice, and it is the clearest illustration I know of the point above.

A client had developed a weld seam defect detection system. Its core was an adaptive threshold algorithm: it calculated a threshold from the mean and the degree of fluctuation of the data, and points exceeding the threshold were identified as anomalies.

Another agency had originally drafted the claim along these lines: "A method for identifying abnormal data, comprising: obtaining a data set; calculating a mean and a standard deviation; determining a threshold according to the mean and the standard deviation; and marking data exceeding the threshold as abnormal."

That claim describes nothing but abstract mathematical processing. It does not say what the data is, what problem is being solved or what makes the approach work. It is not a technical solution that can be granted patent protection.

When I took over the file, I went back through the original specification. What the R&D team had actually solved was this: changes in reflection from the metal surface caused a fixed threshold to produce false alarms, and the system compensated for those changes through a specific mechanism for selecting image regions and updating the threshold.

So I amended the claim to recite that mechanism: capturing an image of the weld seam; determining, according to the position of the weld seam, a detection region and a corresponding reference region; excluding saturated reflective pixels from the reference region; calculating a local threshold from the mean and standard deviation of the remaining pixels; and using that threshold to identify defects in the corresponding detection region.

The mathematical formula after the amendment was exactly the same. What changed was the object of protection: it was now clearly a specific industrial image inspection solution. The patent was eventually granted.

The amendment in the weld seam case was possible only because the original specification already described the reflection problem and the region-selection mechanism. Amendments cannot add what was never disclosed, so the real engineering has to be on paper before you file.

How should software teams prepare an invention disclosure?

From the weld seam case and many others, my advice to engineering teams is practical.

Start from the technical problem, not the algorithm's name. Describe what went wrong before: false alarms, latency, excessive memory use, unstable control. Then describe the conditions under which it went wrong.

Write down the mechanism step by step. Which data is taken from where, how it is filtered or partitioned, what is computed, and how the result drives the next step. Flowcharts and data-flow diagrams help both the drafter and the examiner.

Explain why it works. Examiners and later courts want to understand the causal link between the technical means and the effect. "Excluding saturated reflective pixels keeps the reference statistics from being distorted by glare" is an explanation. "The algorithm is optimized" is not.

Keep it truthful. Only describe mechanisms that the team has actually built and tested. A disclosure is a record of genuine R&D; it is not a place to invent features to make the application look stronger.

Put the contribution in the independent claim. It is common to see a specification that tells a detailed technical story while the claim reduces to a generic "obtain, calculate, compare" flow. Whoever reviews the draft should check, line by line, that the real contribution appears in the claim.

Where does structured thinking help?

Many software inventions are, at heart, the resolution of a technical contradiction: a fixed threshold is simple but triggers false alarms; a sensitive threshold catches defects but is disturbed by glare. Framing the problem as a contradiction makes it easier to see which part of your solution is the real contribution, and therefore what the claim needs to say. Tools based on TRIZ can help an engineering team articulate that contradiction before the disclosure is written. The judgment on patentability, however, should still be made by a qualified patent professional who has read the actual specification.