Software Patent Strategy: What's Patentable and Where

Software patentability is the most jurisdiction-dependent question in patent law. A software claim that is routinely allowed in South Korea may be rejected in the US under Alice, allowed in Europe only if it produces a "technical effect," and flatly excluded in India as a "computer program per se." This guide maps the rules office by office and provides drafting strategies that maximise the chances of grant across all major markets simultaneously.

The Global Patentability Landscape

What Is Patentable in Software

Clearly Patentable (Most Jurisdictions)

Software that controls physical hardware to achieve a measurable improvement — controlling an industrial process, optimising a sensor network, managing a power grid, improving the performance of a computer system itself (faster processing, reduced memory usage, improved data compression).

Patentable With Careful Drafting

Software that processes data to produce a technical result — image processing algorithms, signal processing, encryption methods, database optimisation, network protocol improvements. The key is tying the processing to a specific technical context and measurable technical improvement.

Difficult to Patent

Software that implements a business method — dynamic pricing, recommendation engines, financial analysis, inventory management. Patentable in limited form in the US (if tied to a specific technical implementation), largely excluded in Europe, China, India, and most other jurisdictions.

Not Patentable

User interface layouts (protectable by design patent, not utility patent), abstract mathematical algorithms without application, and software described only in functional terms without implementation detail.

The Multi-Jurisdiction Drafting Strategy

To maximise grant probability across all major offices simultaneously, draft every software claim with four elements:

1. Hardware context. Recite specific hardware — "a processor," "a memory storing instructions," "a sensor array," "a display device." This satisfies CNIPA's hardware requirement, supports Alice survival at the USPTO, and provides the physical anchoring expected by JPO and KIPO.

2. Specific data processing steps. Describe what the software does — not in abstract functional terms, but as a sequence of defined processing steps with specific inputs and outputs. "Receiving time-series sensor data; extracting frequency-domain features using a fast Fourier transform; classifying the features using a trained model; generating a control signal based on the classification."

3. Technical effect. State the measurable technical improvement. "Reducing false positive detection rates from 12% to less than 2%." "Increasing data compression ratio by 40% compared to standard LZW compression." This is essential for EPO prosecution and strengthens the application everywhere.

4. System claim structure. Lead with a system claim (processor + memory + specific modules) rather than a method claim. System claims are the strongest form for software patents at the USPTO (§ 101), EPO, and CNIPA. File method claims as well — but make the system claim the primary independent claim.

Open Source Considerations

Software inventions frequently build on or interact with open-source components. Patent considerations include:

Open-source code is prior art. Published open-source software — including code on GitHub, CRAN, PyPI, and npm — is publicly available prior art. Claims must distinguish from everything that is publicly available in the open-source ecosystem.

Open-source licences do not affect patentability. A patent can be granted on an invention that interacts with open-source software. However, some open-source licences (GPL, AGPL) include patent grant provisions that may affect enforcement if the patented software is distributed under those licences. Apache 2.0 includes an explicit patent licence grant to downstream users. Review the licence terms of any open-source components used in or alongside the patented software.

Defensive publication. If you want to prevent others from patenting a software technique without patenting it yourself, publish it — as a technical paper, a blog post, or through a defensive publication service (e.g., the Linux Foundation's Defensive Patent Pledge). Published code or documentation becomes prior art that blocks later patent applications by others.

SaaS and Cloud-Based Software

Software-as-a-Service creates specific patent challenges:

Multi-actor infringement. A SaaS system typically involves a server, a client device, and sometimes third-party services. A method claim that requires steps performed by multiple actors (the server processes data, the client displays results) may face divided infringement issues — no single entity performs all the claimed steps.

Draft system claims that capture the entire SaaS architecture as a single system — "a system comprising a server configured to [process], a client device configured to [display], and a communication interface therebetween" — so that the SaaS provider operates the entire claimed system and is the single direct infringer.

Jurisdiction of infringement. A SaaS system with servers in one country and users in another raises questions about where infringement occurs. File patents in the jurisdiction where the servers are physically located and in the jurisdictions where the largest user bases reside.

Sources

1. USPTO — Patent Subject Matter Eligibility — MPEP § 2106 guidance on Alice/Mayo framework for software eligibility
2. EPO Guidelines for Examination — Computer-Implemented Inventions — EPO's COMVIK approach and technical effect requirements
3. CNIPA Patent Examination Guidelines — China's 2021 guidelines for software and AI-related inventions
4. 35 U.S.C. § 101 — Inventions Patentable — Statutory basis for patent eligibility in the United States
5. WIPO — IP and Frontier Technologies — Global overview of software patent frameworks