Can an algorithm be patented? Can a business model be protected as intellectual property? These questions sit at the intersection of technology law, innovation policy, and competitive strategy—and the answers differ dramatically depending on which country you ask. The same software invention that is routinely granted a patent in Japan may be repeatedly refused in the United States under the Alice/Mayo framework, and may require careful drafting to pass the European Patent Office’s “technical character” test. This article explains the three major approaches and the policy tensions that drive their divergence.
Japan: The Hardware-Cooperation Standard
Japan’s Patent Act defines an invention as “the highly advanced creation of technical ideas utilizing natural laws” (Article 2(1)). Pure mathematical formulas, abstract concepts, and mental processes do not utilize natural laws and are therefore outside the scope of patentable subject matter. This fundamental limitation applies to software and business methods just as it does to any other type of invention.
The JPO’s Examination Guidelines for Computer Software-Related Inventions (最終改訂 2023) articulate how this principle applies to software. The key standard is whether the claimed processing is embodied as a concrete technical means for information processing through the cooperation of software and hardware resources. If the claim describes how specific software operations are implemented in and through a hardware environment to achieve a particular purpose, the invention has sufficient technical character for subject matter eligibility.
In practice, this means that a claim directed to “a method for managing inventory automatically issuing purchase orders when stock falls below a threshold by processing inventory data in a specified sequence” can be patent-eligible in Japan if it is expressed as a concrete implementation in a computer system. A claim directed simply to “a method for managing inventory efficiently” would be rejected as insufficiently specific—not identifying a technical means for achieving the stated purpose.
Business method inventions follow the same logic. A subscription billing model as such is not patentable; but a specific system for automatically processing subscription transactions with defined data structures, processing steps, and database interactions may be patent-eligible if the technical implementation is sufficiently specified. Japan’s approach does not impose categorical exclusions on business methods—it requires that any method, if claimed, be expressed as a concrete technical implementation.
United States: The Alice/Mayo Framework and Section 101 Rejections
US patent law under 35 U.S.C. § 101 broadly covers “any new and useful process, machine, manufacture, or composition of matter.” Historically, this broad language was interpreted to encompass software and business methods. In State Street Bank & Trust Co. v. Signature Financial Group, Inc. (149 F.3d 1368, Fed. Cir. 1998), the Federal Circuit held that any invention producing “a useful, concrete and tangible result” could be patented—a standard that opened the door to widespread software and business method patents.
That door was substantially narrowed by two Supreme Court decisions. Mayo Collaborative Services v. Prometheus Laboratories, Inc. (566 U.S. 66, 2012) established that laws of nature, natural phenomena, and abstract ideas—and methods that merely apply them without “significantly more”—are ineligible under § 101. Alice Corp. Pty. Ltd. v. CLS Bank International (573 U.S. 208, 2014) applied this reasoning to software and business method patents, introducing the two-step “Alice framework”:
- Step 1: Are the claims directed to a patent-ineligible concept (abstract idea, law of nature, natural phenomenon)?
- Step 2A/B: If yes, do the additional elements of the claim, considered individually and as an ordered combination, amount to significantly more than the abstract idea itself—transforming the claim into a patent-eligible application?
In Alice, claims directed to intermediated settlement of financial transactions—implemented on “a computer”—were found directed to an abstract idea (the concept of intermediated settlement), with no additional elements that would constitute an “inventive concept” beyond applying the abstract idea on a generic computer. The Supreme Court found that merely implementing an abstract idea on a computer does not transform it into eligible subject matter.
After Alice, § 101 rejections exploded at the USPTO. The Federal Circuit issued dozens of conflicting decisions on what constitutes an impermissible abstract idea versus a patent-eligible technical improvement. In 2019, the USPTO issued revised examination guidance (2019 Revised Guidance) that restructured the Alice inquiry: Step 2A asks (i) whether the claim recites a judicial exception, and (ii) if so, whether the claim integrates that exception into a “practical application.” The practical application analysis looks for whether the claim improves the functioning of a computer or technological process—a standard that has allowed some software patents to survive that might have been rejected under earlier guidance.
Despite the revised guidance, § 101 rejections remain a significant obstacle for AI and software patent applicants in the US. Claims directed to machine learning algorithms, data processing methods, and user interface improvements face regular § 101 scrutiny. Courts have generally upheld patents that claim specific technical improvements (such as improved data compression, enhanced virus detection, or faster network protocols) while invalidating patents that claim the application of generic computing steps to abstract financial or administrative tasks.
Europe: The Technical Effect Requirement
The European Patent Convention (EPC) Article 52(2) explicitly lists “programs for computers” among the things that “shall not be regarded as inventions.” But Article 52(3) immediately limits this exclusion: these things are excluded only “to the extent to which a European patent application or European patent relates to such subject-matter or activities as such” (emphasis added). The phrase “as such” has become the key to European software patent law.
The EPO’s interpretation, developed through decades of case law from its Boards of Appeal, is that a computer program can be patented if it produces a “technical effect” when run on a computer that goes beyond the normal physical interactions between the program and the computer on which it runs. A program that merely implements a business method or mathematical concept on a standard computer, without any further technical effect, is excluded “as such.” A program that improves the internal functioning of the computer—memory management, processing efficiency, network handling—or controls a technical process in the external world, produces a technical effect and may be patented.
In the landmark T 0931/95 (IBM/Computer program product) decision, the EPO’s Technical Board of Appeal held that a computer program that produces a technical effect when run is not excluded from patentability. T 0258/03 (Hitachi/Auction method) extended this reasoning to business-related inventions with technical features, holding that such inventions may be patentable if they have “technical character.”
In practice, the “technical character” or “technical effect” requirement means that European patent applicants claiming software inventions must articulate a specific technical problem solved and a technical effect achieved. Improvements in processing speed, accuracy, energy consumption, data transmission efficiency, or control of physical devices all qualify as technical effects. Improvements that are purely economic, administrative, or cognitive in nature do not.
Why the Same Invention Can Be Patentable in One Country and Not Another
The divergence among Japan, the US, and Europe reflects fundamentally different policy choices about what innovation the patent system should incentivize.
Japan and Europe share a “technical solution” philosophy: the patent system is for protecting technical advances, and software is protectable only as a technical implementation. Neither system categorically bars software patents—both allow them when the software implements a technical solution to a technical problem. But both require the technical character to be genuine and explicitly claimed.
The US, historically more expansive in its treatment of patentable subject matter, is navigating the consequences of over-extension. The combination of business method patents (post-State Street) with the rise of patent assertion entities (PAEs) using broad software patents as litigation tools contributed to the Supreme Court’s retrenchment in Alice. The challenge since Alice has been defining a stable line between the abstract (ineligible) and the technical (eligible) that neither excludes too much legitimate software innovation nor permits monopolization of basic computational concepts.
| Feature | Japan | United States | Europe (EPO) |
|---|---|---|---|
| Core test | Hardware-software cooperation | Alice framework (2-step) | Technical effect/character |
| Software alone | Not eligible (hardware cooperation required) | Not eligible (abstract idea) | Not eligible “as such” (EPC 52(2)) |
| Algorithm implementation | Eligible if implemented in a hardware system | Eligible if technically improving the computer/process | Eligible if producing technical effect |
| Business methods | Eligible if technically specified as IT implementation | Difficult under Alice (many §101 rejections) | Eligible if technical character present |
| AI algorithms | Eligible as concrete system implementation | Technical improvement identification is key | Eligible with demonstrated technical effect |
Practical Drafting Strategies for Software Patent Applications
For applicants seeking protection in all three major jurisdictions, several drafting principles improve the prospects of grant across borders. First, claim the invention in multiple forms—method claims, system claims, and computer-readable medium claims—to provide redundancy if one form is rejected in one jurisdiction. Second, specify the technical problem being solved and the technical effect achieved, with quantitative data or comparative examples in the specification where possible. Third, avoid claiming abstract outcomes (“a method for improving customer satisfaction”) and instead claim concrete technical steps (“a system that processes customer interaction data using a trained neural network to generate real-time personalized recommendations, reducing server response latency by X%”).
During national phase prosecution, claims can be adapted for each jurisdiction: emphasizing “technical improvement to the functioning of the computer” for US purposes; articulating “technical effect” explicitly for European prosecution; and ensuring “hardware cooperation” language is present for Japanese examination. These adjustments, made within the scope of the originally filed disclosure, can significantly improve grant rates in each jurisdiction.
This article concludes the ten-part “Patent Basics” series on patent-detectives.com. From the definition of a patent and the four types of IP rights, through examination procedures, claim interpretation, infringement analysis, prior use rights, PCT filings, invalidation proceedings, and finally the contested terrain of software patents—the series has provided a systematic introduction to the legal and strategic foundations of patent practice. Future articles in the Patent Basics category will explore individual topics in greater depth as the field continues to evolve.
コメント