Imagine a company called Birthday Scoop that makes ice cream for birthday parties.

Birthday Scoop develops software that predicts which flavors customers will want and how much ice cream the company should make. The software considers the weather, the number of guests, past sales, and customer preferences. It uses machine learning to create a production schedule and updates that schedule when the information changes.
The software may work extremely well. It may reduce waste and help ensure that each party receives the right amount of chocolate, vanilla, and strawberry ice cream on time.
Birthday Scoop applies for a patent claiming, in simplified terms:
Receive information about upcoming parties, use machine learning to generate an optimized ice cream production schedule, and update the schedule when the information changes.
Has Birthday Scoop invented new technology?
Not necessarily.
That question illustrates the current challenge of software patent eligibility. A company may develop a useful product, substantially improve its business, and outperform its competitors. Those accomplishments alone, however, may not be enough to support a patent.
Two recent Federal Circuit decisions explain why: Recentive Analytics, Inc. v. Fox Corp. and Trustees of Columbia University v. Gen Digital Inc..
Together, the cases show that using machine learning, computers, or another emerging technology does not automatically make an idea patent eligible. The patent application should identify a concrete technological contribution, and the claims should require the mechanism that produces it.
Recentive: Using Machine Learning for a New Purpose May Not Be Enough
In Recentive, the patents used machine learning to create television-event schedules and network maps.
The claims contained considerable detail. They referred to historical data, iterative model training, relationships among variables, optimized results, real-time changes, and updated outputs.
The Federal Circuit nevertheless held the claims patent ineligible under § 101.
The patents permitted the use of essentially any suitable machine-learning technique operating on generic computer equipment. The machine learning functioned in its ordinary manner: it received input data, identified relationships, produced an output, and adjusted when the data changed.
The claimed invention was not a new machine-learning technique. It was the application of established machine learning to the particular fields of television scheduling and network-map generation.
The court held that applying generic machine learning to a new data environment, without disclosing a technological improvement, was not enough.
For software patent eligibility, the technical terminology in a claim must match the substance of the claimed technological advancement.
Birthday Scoop may use complicated data and achieve impressive results. But if its patent effectively claims only “use conventional machine learning to make a better ice cream schedule,” the claim may remain directed to an abstract idea because it does not require a specific technological improvement.
The Same Lesson Applied to the Early Internet
This principel may sound familiar.
During the dot-com boom, as commercial websites became widespread, businesses sought patents covering familiar activities newly performed online. Some claims effectively took an existing commercial practice, such as selecting products, placing them in a shopping cart, and completing a purchase, and added the instruction to perform it through a website.
But adding “on a website” did not automatically transform an established commercial practice into a patent-eligible technological invention.
The important question was whether the claim merely used the Internet as a new setting for an existing activity or instead required a specific technological solution to a problem arising from the operation of websites or computer networks.
The same distinction applies to artificial intelligence today.
Replacing “on a website” with “using machine learning” does not, by itself, establish software patent eligibility. A patent should identify what the technology does differently and explain the specific mechanism through which it produces the asserted improvement. The claims should then require that mechanism.
This distinction also avoids confusing patent eligibility with novelty or nonobviousness. Whether an invention is new is generally addressed under 35 U.S.C. §§ 102 and 103. Eligibility under § 101 asks a different question: whether the claim is directed to patent-eligible subject matter rather than an abstract idea implemented with conventional technology.
The USPTO provides official information about that distinction at its subject-matter-eligibility guidance webpage.
Faster and More Efficient Does Not Necessarily Mean Patent Eligible
Birthday Scoop’s system may produce a schedule faster than its employees could create one by hand. It may consider more information, respond immediately to changes, and reduce mistakes.
Those advantages may demonstrate commercial value. They do not necessarily establish software patent eligibility.
The Federal Circuit explained in Recentive that increased speed and efficiency resulting from the ordinary use of computers does not, standing alone, establish a technological improvement.
The relevant question is not simply whether the software performs useful work faster.
The question is:
What specific technological mechanism does the claim require, and how does that mechanism improve the operation of the computer, the model, or another technological process?
Terms such as “automated,” “dynamic,” “real time,” “optimized,” and “machine learning” may describe desirable characteristics. They do not necessarily explain how the technological result is achieved.
Recentive Does Not Mean That AI Patents Are Dead
The Federal Circuit did not hold that machine-learning inventions are categorically ineligible.
A machine-learning claim may present a stronger case when it requires a specific implementation that improves the operation of the model, the computer, or another technological system.
Suppose Birthday Scoop developed a particular method that updates only the portion of its production model affected by a last-minute order. The method might reduce memory usage, avoid retraining the entire model, and prevent inconsistent production instructions from reaching the company’s equipment.
That could present a different software patent eligibility analysis.
The application should explain the operations that produce those benefits, and the claims should require the relevant technical mechanism. It is generally not enough to state that the system operates more efficiently or updates information in real time.
The patent should explain how the improvement is achieved. If that mechanism supplies the asserted technological advance, the claims should require it.
Columbia: The Specification Cannot Supply Missing Claim Limitations
Now suppose Birthday Scoop develops a second system.
This system monitors each batch of ice cream and compares information about its temperature, texture, and consistency with a model of a normal batch. If a batch differs from the model, the software flags it as potentially defective.
The patent specification describes several sophisticated features:
- The system can test only selected portions of a batch rather than testing the entire batch.
- Different stores can create deliberately different quality models.
- The system can combine information gathered from many stores.
Those features may make the system faster, more reliable, or more difficult to manipulate.
But suppose the patent claim says only:
Compare information about a batch of ice cream with a model and identify the batch as abnormal based on the comparison.
Can Birthday Scoop rely on every sophisticated feature described in the specification?
No.
The claim does not require selective testing. It does not require deliberately different models. It does not require information collected from a network of stores.
The specification may describe those features, but the claim remains broad enough to cover the simpler process of comparing information with a model and deciding whether it is unusual.
That is a central lesson of Columbia v. Gen Digital.
A $185 Million Warning About Claim Language
Columbia’s patents concerned detecting anomalous program execution, including activity associated with computer viruses and other malicious software.
The asserted claims required executing at least part of a program in an emulator, comparing a function call with a model of function calls, and identifying the function call as anomalous. The claims also required the model to be a combined model created from models developed using different computers.
A jury found willful infringement and awarded Columbia more than $185 million.
On appeal, the Federal Circuit held that the claims were directed, at Alice step one, to the abstract idea of comparing data against a model created using different computers to determine whether the data was anomalous.
The court did not finally hold the claims patent ineligible. It remanded the case for further proceedings at Alice step two.
In arguing that the claims were not abstract at step one, Columbia relied on several technical improvements described in the specification.
One involved selectively emulating only part of a program, which could reduce processing demands. But the claims permitted execution of part or all of the program. They did not require selective emulation.
Columbia also relied on the creation of diversified behavioral models. The specification described varying the features used to create different models, but the claims did not require those diversification techniques.
Columbia further relied on information gathered through distributed sensors or an application community. Again, the asserted claims did not require distributed sensors to participate in creating the model. One claim required notifying an application community after identifying an anomaly, but notification was not the same as using the community to develop the model.
The Federal Circuit therefore could not treat those optional features as though they were required by the claims.
This distinction is essential to software patent eligibility:
The specification may explain the invention, but the claims define the legal right.
A court may consider the specification when interpreting the claims and identifying the asserted advance. Under 101, the court could not add limitations that the claims omitted.
Putting the Feature in the Claim Is Necessary, but Not Always Sufficient
Columbia provides an important lesson.
The requirement that the combined model be created from models developed using different computers actually appeared in the claims. Nevertheless, the Federal Circuit held that the claims were directed to an abstract idea at Alice step one.
Columbia argued that distributing the work among different computers allowed the combined model to be created more quickly. But dividing an ordinary task among several computers, although potentially more efficient, did not necessarily create a technological improvement. The court treated that approach as an abstract computer-based divide-and-conquer technique.
The practical advice therefore cannot stop with:
Put the improvement in the claim.
The more complete advice is:
Put the actual technical mechanism in the claim, and then determine whether that mechanism represents a concrete technological improvement rather than an abstract or conventional technique.
Adding more computers, a machine-learning model, an emulator, or other technical components does not automatically resolve software patent eligibility. The analysis depends on what those components are claimed to do and whether their operation improves the technology itself.
Columbia Is Not Yet a Final Holding of Ineligibility
The Federal Circuit did not finally decide whether Columbia’s claims are patent eligible.
After holding that the claims were directed to an abstract idea at Alice step one, the court remanded for a limited determination at step two.
Columbia argued that the claimed “model of function calls” supplied an inventive concept. The parties disputed whether that feature was conventional.
Because the case arose from a motion for judgment on the pleadings, the Federal Circuit concluded that the factual dispute could not be resolved against Columbia at that stage. The district court must now determine whether the claimed model-of-function-calls feature was conventional.
That limited question may determine whether the asserted claims survive.
The case nevertheless provides a significant warning to patent owners. Even after obtaining jury findings of infringement and willfulness and securing a verdict exceeding $185 million, Columbia still faced a threshold dispute over whether the asserted claims covered eligible subject matter.
Three Common Risks for Software and AI Patents
Together, Recentive and Columbia identify three recurring problems.
1. The claim applies an established technology to a new use
Using conventional machine learning in a new industry may produce a useful product without producing a patent-eligible technological invention.
2. The specification describes the improvement, but the claim does not require it
An optional embodiment cannot save a broader claim that omits the mechanism on which the eligibility argument depends.
3. The claim includes the feature, but the feature remains abstract or conventional
Technical terminology and additional computing components do not establish eligibility when the claimed operation remains an abstract analytical process.
A patent attorney should address all three.
Questions Developers and Patent Counsel Should Ask
Before filing a software or AI patent application, the inventor and patent attorney should identify:
What technological problem existed?
The answer should be more specific than cost, inconvenience, or the time required for a person to perform the task.
What operations solve that problem?
The application should identify the relevant processing sequence, data structure, model architecture, update rule, system interaction, or other technical mechanism.
Why does that mechanism produce the improvement?
The application should connect the operative steps to the asserted technical benefit rather than merely stating that the system is faster, safer, or more accurate.
Do the claims require the mechanism?
The eligibility theory should not depend on an optional feature described only in the specification.
Is the claimed mechanism itself technological?
The final question is whether the feature changes computer or technological operation rather than merely performing an abstract comparison, prediction, organization, or optimization using conventional tools.
These questions should be addressed when the application is being prepared. Claims may be amended later, but technical substance missing from the original disclosure generally cannot be added after filing.
The Bottom Line
Return to Birthday Scoop.
Its software may be useful. Its machine-learning models may help it make better ice cream, reduce waste, and serve more birthday parties. Its competitors may even copy the commercial product.
Those facts do not answer the threshold question of software patent eligibility.
If Birthday Scoop merely applies conventional machine learning to ice cream production, Recentive presents a serious eligibility concern.
If its strongest technical features appear only in the specification, Columbia teaches that those features may not save the claims.
And even when a feature appears in the claim, the applicant must still determine whether it represents a concrete technological improvement or merely an abstract or conventional operation expressed in technical terms.
The practical lesson is straightforward:
Identify the technical mechanism. Explain how it produces the improvement. Require it in the claims. Then determine whether the mechanism itself is more than an abstract or conventional technique.
That is the level of precision that software patent eligibility increasingly requires.
The IP Center advises developers, founders, and technology companies on software, artificial intelligence, and patent strategy, including eligibility under 35 U.S.C. § 101. If you need help with a software patent, email our patent attorneys. This article is for informational purposes only and does not constitute legal advice or create an attorney-client relationship.