If you build software in Cedar Rapids, Iowa City, Des Moines, or elsewhere in Eastern Iowa, you have probably heard that “software patents are dead” after Alice. That slogan is too blunt. Some computer-implemented inventions are refused under 35 U.S.C. § 101. Others clear eligibility and go on to examination for novelty and nonobviousness. The difference usually sits in how the invention is described and claimed—not in whether the product is written in code.

This article is general information for Iowa innovators, not legal advice, and it does not create an attorney-client relationship. Outcomes depend on the specific claims, specification, and facts. Prior results do not guarantee a similar outcome.

What Section 101 actually asks

Section 101 sets the outer boundary of patent-eligible subject matter. In broad terms, a utility patent may cover a process, machine, manufacture, or composition of matter that is new and useful. Courts have long treated laws of nature, natural phenomena, and abstract ideas as outside that boundary. You cannot patent a mathematical formula standing alone, a fundamental economic practice, or a mental process merely stated as “do it on a computer.”

Alice Corp. v. CLS Bank International (2014) is the Supreme Court decision that now frames much of the software and business-method eligibility analysis. It did not ban software patents. It restated a two-step framework examiners and courts still use when someone argues that a claim is directed to an abstract idea.

The Alice two-step framework, without the jargon fog

Step one: What is the claim “directed to”?
Look past the labels. If the claim, as a whole, is aimed at an abstract idea—such as a method of organizing human activity, a mental process, or a mathematical concept—the analysis continues. Reciting a generic computer, a network, a database, or a user interface does not, by itself, change the answer. Courts often ask whether the claim focuses on a result people have long wanted (match buyers and sellers, target ads, score risk) rather than on a particular technical way of achieving a result.

Step two: Is there an “inventive concept” that transforms the claim?
If step one finds an abstract idea, the claim may still be eligible if it includes something more—enough to transform the abstract idea into a patent-eligible application. That “something more” is not a magic phrase. It often involves a specific technical improvement: how data is processed, how components interact, how a system solves a computer-rooted problem (security, latency, memory use, protocol handling, device control), or how software and hardware work together in a concrete architecture.

Generic instructions to “apply it with a computer,” “store it in memory,” or “display it on a screen” usually fail step two. Detailed technical solutions that improve the functioning of the computer or the technical system itself have a better chance of surviving—though survival of § 101 is never guaranteed, and the claim must still meet every other patent requirement.

Why Iowa software teams still care

Eastern Iowa’s technology mix—SaaS, embedded controls, RF and signal processing, manufacturing software, ag-tech, fintech workflows, and cloud platforms—often sits right on the § 101 fault line. A Cedar Rapids product team may have a real engineering advance and still receive a § 101 rejection if the application reads like a business goal wrapped in computer vocabulary.

Conversely, a well-supported application that explains the architecture, data flows, failure modes, and technical effect can be examined on the merits. Eligibility is the gate. Novelty, nonobviousness, written description, and enablement are the rest of the path. For a broader overview of computer-implemented protection options, see the site’s software patents page and the general patents overview.

Patterns that often draw § 101 scrutiny

These patterns do not automatically kill an application, but they commonly appear in office actions and court opinions:

• Claiming a desired business or user outcome without claiming a particular technical mechanism.
• Using functional language at a high level (“analyzing,” “optimizing,” “recommending”) with little structural or algorithmic support in the specification.
• Relying on conventional computers, networks, and storage as the only “technology” in the claim.
• Describing industry practice or human judgment and then adding “on a processor” at the end.
• Mixing trademark-style brand goals with patent claims. Brand protection is a different toolset; see trademarks and registering a trademark with Iowa vs. federal options when the issue is name and identity rather than technical function.

Patterns that often help the eligibility story

Again, none of these is a promise of allowance:

• Identify the technical problem in the prior art or prior systems (not only a business pain point).
• Explain how the claimed arrangement differs in structure, sequence, timing, data representation, or device interaction.
• Tie claim language to embodiments that a skilled engineer could implement from the specification.
• Prefer concrete system or method steps over slogans about “intelligence,” “insights,” or “engagement.”
• Consider whether a provisional filing is the right first step while the technical disclosure is still being completed—see the site’s guide on provisional patent applications for Iowa inventors—understanding that a thin provisional can undermine later claims.

How § 101 shows up in real prosecution

Many Iowa applicants first meet Alice in a USPTO office action. An examiner may reject claims under § 101, sometimes together with novelty or obviousness issues. A response can amend claims, clarify the technical improvement, point to specification support, and argue why the claims are not directed to an abstract idea—or why they include a transformative inventive concept. Strategy is case-specific. Timing, claim scope, continuation practice, and business goals all matter. For a practical overview of examiner communications generally, see Responding to a USPTO Office Action: What Iowa Inventors Should Know.

Court and PTAB decisions also evolve. Case-reaction posts about particular opinions can illustrate trends, but they are not a substitute for analyzing your claims. An evergreen takeaway remains: draft and prosecute as if the technical contribution must be visible on the face of the claims and grounded in the specification.

Practical checklist before you file (or before you pitch investors)

1. Can you state the technical improvement in one clear paragraph? If the only answer is a market benefit, pause and dig into the engineering.
2. Does the specification teach more than a black box? Architecture, inputs/outputs, control logic, and alternatives help.
3. Are the claims aligned with that teaching? Broad marketing language in claims is a common § 101 magnet.
4. Have you separated patent, trade secret, copyright, and trademark decisions? Code can be copyrighted; brands are trademarks; some process details may stay confidential; patents trade disclosure for potential exclusivity.
5. Do timing and public disclosure plans fit? Demonstrations, app-store launches, and publications can affect patent rights. Talk through the calendar early.
6. Is counsel reviewing claim strategy with an engineering lens? An electrical engineering and registered patent attorney background can help translate implementation detail into claim strategy—see About Jason and the firm bio at Shuttleworth & Ingersoll.

What this article is not saying

It is not saying every Iowa SaaS feature should be patented. It is not saying Alice is easy or predictable. It is not a guarantee that any claim style will overcome § 101. Patent law is fact-specific, examination and litigation outcomes vary, and advertising rules require that reminder: attorney advertising; prior results do not guarantee a similar outcome.

For some teams, the right answer is a focused provisional, a narrow nonprovisional, a trade-secret program, or no patent filing at all while the product and market mature. For others, a carefully supported computer-implemented application is a core part of fundraising, licensing, or competitive positioning. The useful question is not “Does Alice kill software patents?” It is “What technical contribution, if any, should we try to claim—and how do we support it?”

Next step for Iowa innovators

If you are evaluating software or computer-related patent protection for an Iowa company, start with the invention’s technical story, not the buzzwords. Review the software patents and patents pages, then contact the office to discuss whether a patentability assessment, provisional filing, or full application strategy fits your timeline. You can also learn more about Jason’s practice on the About page and at Shuttleworth & Ingersoll.

This post is for educational purposes only and is not legal advice. Consulting an attorney about your specific facts is the only way to obtain advice on which you can rely.