Software Patent Strategy

Alice Corp. v. CLS Bank International (S.Ct. 2014) created uncertainty about software patent eligibility, but subsequent case law has identified consistent patterns for eligible claims: THE ALICE TWO-STEP: Step 1: is the claim directed to an abstract idea, law of nature, or natural phenomenon? For software: most algorithms, data organization methods, and business logic qualify as abstract ideas; Step 2A, Prong 2 (2019 Revised Guidance): even if the claim recites an abstract idea, is it integrated into a practical application? Step 2B: if not a practical application, does the claim add significantly more than the exception?; WHAT COUNTS AS A PRACTICAL APPLICATION: the 2019 USPTO Revised Guidance identifies several ways a claim can recite a practical application: (1) IMPROVEMENT TO TECHNOLOGY/COMPUTER FUNCTIONING: the claim improves the functioning of the computer or another technology; NOT just using a computer to do something faster; must be an improvement to HOW the computer operates; ELIGIBLE: a claim to a specific data compression algorithm that reduces storage requirements in a database system; a claim to a specific garbage collection method that reduces memory fragmentation in a runtime environment; a specific interrupt handling mechanism that reduces processor wait time; INELIGIBLE: a claim to using a database to track financial transactions; a claim to a computer that processes insurance claims faster; (2) SPECIFIC MACHINE INTEGRATION: the claim applies the abstract idea by using a particular machine; the machine must be integral to the claim (not just the vehicle for implementing the abstract idea); (3) TRANSFORMATION/REDUCTION TO DIFFERENT STATE: the claim transforms a particular article to a different state or thing; software that transforms one form of data to a meaningfully different form (not just changing format); (4) UNCONVENTIONAL STEPS ADDING MEANINGFUL LIMITATION: the claim includes specific unconventional technical steps that are not well-understood, routine, and conventional; CONSISTENTLY ELIGIBLE SOFTWARE PATENT AREAS: network security (specific intrusion detection methods); data compression (specific lossless/lossy algorithms); caching systems (specific cache invalidation strategies); database optimization (specific query execution plans); user interface improvements (specific rendering techniques that improve performance); signal processing (specific filtering or transform algorithms); operating system improvements (specific memory management; scheduling algorithms).

Effective software patent drafting requires careful attention to claim structure, technical specificity, and specification content to both survive eligibility review and provide meaningful protection: CLAIM STRUCTURE FOR MAXIMUM ELIGIBILITY: SYSTEM CLAIMS (often best): 'A computer system comprising: at least one processor; and at least one non-transitory computer-readable medium storing instructions that, when executed by the at least one processor, cause the system to: [specific technical step 1]; [specific technical step 2]; wherein the [specific technical result] is achieved by [specific technical mechanism];'; KEY ELEMENTS FOR ELIGIBILITY: specific hardware-software combination; concrete technical operations (not abstract descriptions); specific data structures when relevant; measurable technical outcome; METHOD CLAIMS: list discrete algorithmic steps; include 'receiving [specific technical input]' and 'generating [specific technical output] configured to [specific technical purpose]'; avoid claiming only mental steps or pure data manipulations without context; CRM CLAIMS: 'A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to: [specific algorithmic steps];'; CRM claims are system-equivalent in eligibility analysis; useful for products (e.g., software on physical media or cloud service); CRM CLAIMS AVOID DIVIDED INFRINGEMENT: if a method claim requires actions by multiple parties (user + server + third party), each party may not infringe alone; a CRM claim locates all the instructions in one place — one infringer controls the medium; SPECIFICATION REQUIREMENTS FOR SOFTWARE PATENTS: (1) ALGORITHM DESCRIPTION: the specification must describe the algorithm in sufficient detail for a POSITA to implement; code or pseudocode is strongly recommended; insufficient to say 'process data using the algorithm'; (2) FLOWCHARTS AND DATA STRUCTURES: flowcharts showing decision logic and data flow; data structure definitions and schemas; (3) TECHNICAL IMPROVEMENTS STATED EXPLICITLY: explicitly state the specific technical problem; quantify the improvement if possible ('reduces latency by 40%'; 'reduces memory usage by 30%'); compare to prior art approaches; (4) DEFINING KEY TERMS: define technical terms precisely; software terms can be ambiguous (e.g., 'module', 'engine', 'component' — define what these mean structurally); (5) MEANS-PLUS-FUNCTION CLAIMS: § 112(f) means-plus-function claims require disclosure of the corresponding structure in the specification; for software means-plus-function, the structure is the algorithm disclosed; if the algorithm is not disclosed, the claim is indefinite.

Building a software patent portfolio requires a multi-layer strategy that combines filing strategy, continuation practice, and an understanding of the fast-moving technology landscape: CORE PORTFOLIO STRATEGY: (1) CLAIM ALL FORMS: for each significant software innovation, file claims in multiple forms: system claims; method claims; CRM claims; multiple dependent claims capturing specific embodiments; claims at different levels of abstraction (broad + specific); (2) CONTINUATION PRACTICE: file continuation applications from pending applications to claim additional aspects of the same disclosure; continue the application family as the technology develops and new applications become apparent; ensure at least one application in the family is always pending to allow claim amendments in response to competitor products; continuation applications must claim the benefit of the parent's filing date (§ 120); all claims must be supported by the original disclosure (no new matter); CONTINUATION STRATEGY FOR SOFTWARE: when a competitor launches a product, read the continuation applications to see if claim amendments can cover the new product; draft continuation claims to specifically cover the competitor's implementation based on the original specification; this is legitimate if the original specification supports the claims; (3) CLAIM NARROW VARIATIONS: separate continuation applications with claims specifically covering known products and design-arounds; this makes the portfolio more robust against design-around attempts; (4) DEFENSIVE PUBLICATIONS: for obvious variants or features you cannot protect well, publish technical disclosures as defensive prior art; this prevents competitors from patenting the variants and blocking your own implementation; IBM Technical Disclosure Bulletin and IP.com are common defensive publication venues; (5) TRADE SECRET vs. PATENT: consider whether core algorithms are better protected as trade secrets (perpetual, no disclosure required) vs. patents (20-year term, public disclosure); factors favoring trade secret: hard to reverse engineer; long commercial life; factors favoring patent: reverse-engineerable from product; short commercial cycle but want 20-year protection; PUBLIC COMPANY CONSIDERATIONS: publicly traded tech companies often disclose products before patent applications are filed due to public disclosure obligations; the 1-year grace period (AIA § 102(b)) protects inventors from their own public disclosures but not from third-party disclosures during that period; file provisional applications before product announcements to lock in a priority date.

Software patent protection varies significantly across major jurisdictions, with the EU and US having fundamentally different approaches: EUROPEAN PATENT OFFICE (EPO): the European Patent Convention (EPC) Article 52 excludes 'programs for computers' from patentability 'as such'; HOWEVER: the EPO and national courts have interpreted this narrowly; software claims are patentable if they have a 'technical character' and produce a 'technical effect'; the EPO test is different from Alice: the EPO focuses on whether the claimed method has a TECHNICAL CHARACTER (not just whether it is an abstract idea); WHAT HAS TECHNICAL CHARACTER IN EUROPE: specific algorithms that improve hardware function (memory management; compression); data processing with specific technical application; control systems with specific technical effects; network protocols with technical performance improvements; WHAT LACKS TECHNICAL CHARACTER: business methods implemented in software; financial calculations; organizational/management methods; the EU approach is generally more permissive for technical software patents than US Alice analysis in practice (even if the statutory language sounds more restrictive); EPO EXAM TIPS: frame claims as a 'computer-implemented method' with specific technical steps; avoid business outcome language; specify technical inputs and technical outputs; describe specific hardware-software interactions; UK POST-BREXIT: UK Intellectual Property Office (UKIPO) follows a similar technical effect test to the EPO; UK case law: Aerotel v. Telkom + Macrossan test + HTC v. Apple four-factor test; JAPAN: Japan Patent Office (JPO) follows a 'creation of technical ideas utilizing natural laws' standard; software that uses hardware components to achieve a concrete result = patentable; software-only claims are more challenging; JPO is generally more permissive than US Alice analysis; CHINA: China National Intellectual Property Administration (CNIPA) allows software patents if they technically transform or process external technical objects; rapidly growing AI/software patent activity in China; Chinese companies filing extensively in the US on AI software patents; GERMANY (EPO + German Patent Court): German courts have been technology-friendly; strong EPO-consistent technical character analysis; PATENT PROSECUTION STRATEGY FOR MULTINATIONAL SOFTWARE PORTFOLIOS: file PCT application first (preserves all national option + gives 18-month examination window); claim the same invention in all jurisdictions using jurisdiction-adapted claim language; US: technical improvement framing; EU: technical character framing; Japan: hardware interaction framing; China: external technical transformation framing.