Software Patents

Software inventions can be patented in the US, but § 101 subject matter eligibility is the primary hurdle: BASIC RULE: patents are available for 'any new and useful process, machine, manufacture, or composition of matter' under § 101; software claims can satisfy this standard but must not be directed solely to abstract ideas, laws of nature, or natural phenomena; HISTORICAL DEVELOPMENT: State Street Bank & Trust Co. v. Signature Financial Group (Fed. Cir. 1998): business method patents broadly upheld (useful, concrete, tangible result test); Bilski v. Kappos (S.Ct. 2010): machine-or-transformation test is important clue but not sole test; abstract ideas not patentable; Mayo Collaborative Services v. Prometheus Laboratories (S.Ct. 2012): laws of nature + conventional steps = not patentable; Alice Corp. v. CLS Bank International (S.Ct. 2014): applying abstract idea of intermediated settlement on a computer = not patentable; ALICE/MAYO TWO-STEP TEST: STEP 1: are the claims directed to a patent-ineligible concept? (abstract idea, law of nature, natural phenomenon); STEP 2: if yes, do the claims contain an inventive concept — something 'significantly more' than the ineligible concept itself? (not just generic computer implementation); POST-ALICE LANDSCAPE: financial software, business method software, and algorithm-heavy claims face significant § 101 scrutiny; technical improvements to computer functionality, specific improvements to data processing, novel user interface elements with technical effect may be eligible; WHAT SURVIVES ALICE: claims with specific technical improvements (Enfish — specific database structure improving computer speed); claims tied to specific unconventional hardware configurations; claims that improve technology itself (McRO — specific rules-based animation technique); claims with concrete measurable results from specific technical steps.

The USPTO applies Alice/Mayo through its 2019 Revised Patent Subject Matter Eligibility Guidance: 2019 USPTO GUIDANCE (January 2019): addressed Alice/Mayo by creating a structured examination framework; STEP 2A, PRONG 1: is the claim directed to a judicial exception? three categories: mathematical concepts (mathematical relationships, formulas, calculations, algorithms); certain methods of organizing human activity (fundamental economic principles; commercial interactions; social activities); mental processes (concepts performed in the human mind, observation, evaluation, judgment, opinion); IF NOT IN THOSE CATEGORIES: claim is eligible; go no further; STEP 2A, PRONG 2: even if directed to a judicial exception, is the exception integrated into a practical application? the exception is applied or used in a manner that imposes meaningful limits on the claim's scope; the claim: improves the functioning of a computer or other technology; applies the exception with a particular machine; effects a particular transformation; STEP 2B: even if not integrated into practical application, do the additional elements add 'significantly more' beyond the exception itself? well-understood, routine, conventional activity (WURCA): adding generic computer steps is NOT sufficient; PROSECUTION STRATEGY: argue the claim is not directed to an abstract idea in the first place; argue integration into a practical application; demonstrate specific technical improvement; argue that additional elements are not WURCA; present extrinsic evidence that the claimed technique was not conventional; EXAMPLES OF ELIGIBLE CLAIMS POST-ALICE: specific compression algorithm with measurable technical improvement; particular neurological signal processing with identified technical benefit; specific routing optimization with concrete technical effect; claims tied to particular unconventional hardware architecture.

Drafting patent-eligible software claims requires technical specificity and avoiding purely abstract recitations: FOUNDATIONAL PRINCIPLE: a claim must solve a technical problem with a technical solution; 'doing X on a computer' is generally insufficient — the computer must do something technical; CLAIM DRAFTING TECHNIQUES: (a) CLAIM THE TECHNICAL IMPROVEMENT: identify what specific technical problem the software solves; claim the specific technical solution (not just the result); example: instead of 'processing transactions on a computer,' claim 'a method comprising: maintaining a first data structure in cache memory organized by [specific technical structure] to reduce cache collisions by [specific mechanism]'; (b) USE FUNCTIONAL LANGUAGE TIED TO STRUCTURE: claim specific functions performed by specific structural elements; 'a processor configured to [specific technical operation]' is better than 'a computer performing [abstract task]'; (c) CLAIM THE HARDWARE-SOFTWARE INTERACTION: claim how the software interacts with specific hardware components; specific memory management; specific processor operations; specific network architecture; (d) USE MULTIPLE INDEPENDENT CLAIMS: claim the method, system (with hardware), and computer-readable medium (CRM) versions; the system and CRM claims provide redundancy if method claim is challenged on § 101; (e) INCLUDE TECHNICAL DETAILS IN SPECIFICATION: document WHY the technical approach is novel and non-conventional; include performance benchmarks; show the technical problem (not just business problem) being solved; CLAIMS TO AVOID: purely abstract data manipulation without tied-to-technical-result; mental steps performable by a human; generic computer + abstract idea; ANALOGICAL FRAMEWORK: ask 'would a skilled person perform this claim element purely in their head or with pen and paper?' If yes, add concrete technical constraints.

Software patent eligibility rules differ significantly across jurisdictions: EUROPEAN PATENT OFFICE (EPO): Article 52(2) EPC: 'discoveries, scientific theories, mathematical methods, mental acts, playing games, doing business, and programs for computers AS SUCH' are excluded from patentability; 'as such' is critical: software WITH a technical character is patentable; the EPO's approach: a computer program claim is eligible if it has a 'technical character' — it produces a further technical effect beyond normal physical interactions between program and computer; WHAT IS TECHNICAL CHARACTER: controlling a technical process; improving how a computer processes information (specific technical improvement, not just doing accounting on a computer); specific hardware control; what is NOT: purely abstract mathematical calculation with no technical effect; pure business method; mental act; EPO vs. USPTO COMPARISON: EPO's technical character test is generally more permissive than Alice for genuinely technical software; EPO allows more financial software with technical components; EPO still rejects pure business logic; CHINA: Patent Law Article 2: inventions in a 'technical solution' are patentable; software must involve a technical solution to a technical problem with a technical effect; JAPAN: Patent Act Article 2(3): 'creation of technical ideas utilizing natural laws'; software + information processing using hardware = patentable; information processing done in a computer using specific technical resource cooperation = eligible; INDIA: no patents for computer programs per se (Patents Act § 3(k)); computer programs WITH technical application may be patentable; strict in practice — many software patent applications rejected; CANADA: Amazon v. Commissioner of Patents (Fed. Ct. 2011): business method patents available; similar to pre-Alice US approach; AUSTRALIA: Alice-like tightening after Encompass Corp v. InfoTrack (2019); technical effect required.

Software companies face a complex strategic landscape with software patents: PATENTING STRATEGY FOR SOFTWARE COMPANIES: (a) DEFENSIVE PORTFOLIO: software companies build large patent portfolios defensively; cross-licensing: use patents to obtain licenses from competitors holding patents you need; mutually assured destruction creates détente in patent disputes; large portfolios make it costly for competitors to assert against you; (b) OFFENSIVE PORTFOLIO: NPE (non-practicing entity) business model: buy patents, assert against operating companies; some software companies monetize peripheral patents through licensing programs; (c) PATENT PROSECUTION STRATEGY: focus claims on specific technical improvements; file continuations to capture evolving products; use multiple claim formats (method + system + CRM); ALICE RISK MANAGEMENT: perform § 101 analysis before filing; draft backup claims with more technical specificity; don't rely solely on abstract idea + computer implementation; GET TECHNICAL DETAILS INTO SPECIFICATION: specification should document: why conventional approaches failed; what specific technical problem is being solved; how the invention technically differs from conventional approaches; performance data; OPEN SOURCE TENSION: open source releases can invalidate novelty; conversely, building a patent portfolio while using open source creates licensing conflicts; patent pledge: Google, Microsoft, others have made non-assertion pledges for open source (OIN — Open Invention Network); TRADE SECRET ALTERNATIVE: for algorithms that are difficult to reverse-engineer, trade secret protection (avoiding disclosure) may be superior to patent (which requires disclosure); PORTFOLIO ACQUISITION: acquisitions often include significant patent portfolios; due diligence on acquired software patents essential; Alice risk in acquired portfolios must be evaluated.