Software Patent Eligibility

Section 101 provides that any 'process, machine, manufacture, or composition of matter' that is 'useful' may be patented — but the Supreme Court has carved out exceptions for laws of nature, natural phenomena, and abstract ideas: THE ALICE TWO-STEP (Alice Corp. v. CLS Bank, S.Ct. 2014): STEP 1 — Is the claim directed to a patent-ineligible concept? For software, the relevant exception is abstract ideas: mathematical concepts (formulas, algorithms, mathematical relationships, mathematical calculations); certain methods of organizing human activity (fundamental economic principles, commercial interactions, managing relationships); mental processes (observations, evaluations, judgments, opinions); STEP 2 — If directed to an abstract idea, does the claim add significantly more — an 'inventive concept' — beyond the abstract idea? The combination of elements must add something more than generic computer implementation; claims that merely implement an abstract idea on a generic computer by 'applying it' with conventional computer functions do not satisfy step 2; the additional elements must be something that was NOT well-understood, routine, conventional at the time; USPTO 2019 REVISED GUIDANCE (Step 2A): Step 2A, Prong 1: Is the claim directed to a mathematical concept, certain method of organizing human activity, or mental process? Step 2A, Prong 2: Does the claim integrate the abstract idea into a practical application? (practical application = real-world technical improvement beyond the abstract idea); Step 2B: If not, does the claim add a specific limitation beyond what is well-understood, routine, conventional? CURRENT PATENT OFFICE APPROACH: 2019 guidance gives more structure; practical application focus helps claims that tie abstract ideas to concrete technical improvements; examiner must now affirmatively identify why elements are routine/conventional — cannot just assert it.

The Federal Circuit has upheld some software claims and invalidated many others — the pattern reveals what works: CLAIMS THAT SURVIVE — FEDERAL CIRCUIT DECISIONS: ENFISH LLC v. MICROSOFT CORP. (Fed. Cir. 2016): patent on a specific database table structure that improved computer function by enabling faster searching; the claim was directed to a specific improvement in computer functionality — the self-referential database; STEP 1 SURVIVAL: not directed to an abstract idea — improving computer function itself is not abstract; KEY LESSON: claim the technical improvement to the computer system, not the application result; McRO INC. v. BANDAI NAMCO (Fed. Cir. 2016): patent on specific rules for animating lip synchronization using phoneme sequences; improved a specific technical process (3D animation); the specific rules produced a specific technical result that prior art methods couldn't achieve; TECHNICAL FOCUS LESSON: tie the algorithm to a specific technical improvement in how machines process and output data; BASCOM GLOBAL INTERNET SERVICES v. AT&T MOBILITY (Fed. Cir. 2016): internet content filtering patent; individual elements were conventional; but the specific ordered combination was inventive — locating filtering logic at a specific ISP-level location in the network architecture was unconventional; COMBINATION LESSON: even if individual elements are known, an unconventional arrangement or architecture may survive step 2; FINJAN INC. v. BLUE COAT SYSTEMS (Fed. Cir. 2018): patent on behavioral-based malware detection (scanning for potential behavior, not known signatures); new type of technical result (security profile); behavioral detection approach was a different way to achieve technical security; CORE WIRELESS LICENSING v. LG ELECTRONICS (Fed. Cir. 2018): improved user interface for small-screen mobile devices; claimed a specific structural and functional improvement to how an application window operates on a limited-display device; CLAIMS THAT DO NOT SURVIVE: purely abstract ideas (electric power generation management, data organization); conventional computer functions (storing, retrieving, transmitting) with no technical twist; implementing a known process (auction, hedging, escrow) on the internet.

Drafting software claims that survive § 101 requires deliberate strategy: IDENTIFY THE TECHNICAL PROBLEM AND TECHNICAL SOLUTION: what specific problem in prior art computing systems does the invention solve? Does it improve speed, efficiency, accuracy, or capability of computing systems? Frame the invention as a specific technical improvement to computer systems — not just a new way to achieve a business result; CLAIM THE TECHNICAL IMPROVEMENT EXPLICITLY: instead of: 'a method of managing financial transactions comprising applying Rule X'; try: 'a method for improving the efficiency of transaction processing by reducing state conflicts in distributed systems comprising: [specific technical steps that achieve this improvement]'; DESCRIBE THE TECHNICAL IMPROVEMENT IN THE SPECIFICATION: for Berkheimer (Fed. Cir. 2018) purposes, the specification should explain: what was wrong with the prior art computing approaches; what specific technical limitation was overcome; why the claimed combination is not routine/conventional; Berkheimer held that whether elements are well-understood, routine, conventional is a factual question — detailed specification language about unconventionality creates a fact dispute that defeats rule 12 dismissal; AVOID PURE FUNCTIONAL LANGUAGE: 'a processor configured to perform X' is vulnerable if X is a purely abstract function; add: how the processor performs X (the specific algorithm or data structure); why this specific approach is technically distinct from prior approaches; USE THE PATENT'S STRUCTURE TO SHOW TECHNICAL CHARACTER: hardware claims (computer system with specific structural elements) may fare better than method claims; specific data structures with technical advantages; specific network architectures; DRAFT MULTIPLE INDEPENDENT CLAIMS AT DIFFERENT LEVELS: a broader claim directed to the technical concept; a narrower claim adding specific algorithmic steps; a system claim; a CRM (computer-readable medium) claim; if the broader claim is killed on § 101, the narrower claims with more specific technical detail may survive.

Software patents face challenges at the PTAB (IPR) and in district courts under different legal frameworks: DISTRICT COURT § 101 CHALLENGES: Early motions to dismiss under Rule 12(b)(6) or Rule 12(c): § 101 is a threshold question of law that can be decided without a full trial; courts decide eligibility before claim construction in some cases; many software patent cases are dismissed at the pleading stage on § 101 grounds; Berkheimer v. HP (Fed. Cir. 2018): whether claim elements are well-understood, routine, conventional is a factual question that may require more than pleadings; AATRIX SOFTWARE (Fed. Cir. 2018): patents survive § 101 at pleadings when the complaint alleges the claimed combination is unconventional; defendants increasingly argue § 101 in early motions (less expensive than going to trial); STATISTICS: approximately 60-70% of software patent § 101 challenges at district court result in invalidation; PTAB § 101 CHALLENGES: IPR cannot challenge on § 101 grounds (IPR is limited to prior art under §§ 102/103); Post-Grant Review (PGR): available within 9 months of patent grant; CAN challenge on § 101; CBM (covered business method review): EXPIRED March 16, 2020; was available for software/financial method patents; § 101 was a frequent CBM ground; WHAT THIS MEANS: for software patents, § 101 is primarily challenged in district court — IPR alone doesn't solve the problem; a strong § 101 defense requires clear prosecution history establishing technical improvements; PTAB EXAMINATION GUIDANCE: USPTO examiners apply the 2019 revised guidance; many software patent applications still get § 101 rejections; prosecution strategy for § 101 rejections: argue practical application; emphasize technical improvements described in the specification; submit declarations if needed showing unconventionality.

Software patent eligibility varies significantly across jurisdictions: EUROPEAN PATENT OFFICE (EPO): software is patentable if it has a 'technical character' — if it produces a 'technical effect'; the EPO allows software patents that: produce a technical effect beyond normal physical interactions of running software; solve a technical problem in a non-obvious way; WHAT IS PATENTABLE AT EPO: algorithms that improve computer functioning (faster processing, reduced memory usage, improved error correction); specific software architectures that improve hardware operations; signal processing, data compression, image processing algorithms; WHAT IS NOT PATENTABLE AT EPO: purely abstract algorithms without technical effect; programs that only produce a mental/economic effect (business methods); computer implementations of purely mathematical methods; KEY DIFFERENCES FROM US: EPO does not apply an 'abstract idea' test like Alice; it focuses on technical character and technical effect; in practice, many claims acceptable at EPO are also acceptable under a rigorous Alice analysis — both require technical improvement; JAPAN: Japan Patent Office (JPO) allows software patents when the software uses hardware resources cooperatively; machine-readable programs that control hardware are patentable; CHINA: China has become more receptive to software patents; technical solutions involving software are patentable; increasingly important given China's large market; PCT STRATEGY FOR SOFTWARE: given eligibility uncertainty in the US, PCT applicants draft claims carefully; EPO prosecution can be used as evidence that claims have technical character; TAKE-AWAY: software patents with genuine technical improvements are broadly protectable internationally; purely abstract business method implementations on generic computers face rejection in most major jurisdictions.