Software Patent Eligibility

The Federal Circuit has developed a substantial body of case law that, when read together, provides practical guidance on software eligibility: CLEARLY ELIGIBLE SOFTWARE PATENTS (SUPPORTED BY FEDERAL CIRCUIT PRECEDENT): ENFISH (Fed. Cir. 2016): A self-referential database table that stored all entity types in a single table, allowing the table to define its own structure; The Federal Circuit held this WAS eligible because: it improved the computer's memory efficiency (less memory needed); it improved processing speed; the improvement was to the computer system itself, not just using the computer as a tool; LESSON: software that makes the computer itself work better is eligible; McRO v. BANDAI NAMCO (Fed. Cir. 2016): Specific rules for automatically generating lip synchronization and facial expressions in animated characters; The Federal Circuit held this WAS eligible because: the rules-based method was specific enough that it could not practically be performed in the human mind; it automated a process requiring technical computer implementation; LESSON: software that replaces a process that could not practically be done without a computer may be eligible; CORE WIRELESS v. LG ELECTRONICS (Fed. Cir. 2018): A specific user interface for a mobile communication device that improved the display of a limited number of the most-accessed functions; Eligible because: specific limitation to mobile communication device; specific technical improvement to UI interaction; TRADING TECHNOLOGIES v. IBG (Fed. Cir. 2021): Specific trader user interface with specific visual elements that reduced trading errors; Eligible because: specific visual arrangement in a specific display context solved a specific trading error problem; CLEARLY INELIGIBLE SOFTWARE: ALICE CORP v. CLS BANK (S.Ct. 2014): Intermediated settlement (using a trusted third party to reduce risk in financial transactions) implemented on a generic computer = NOT eligible; generic computer implementation of abstract economic concept = abstract idea + conventional computer steps; ELECTRIC POWER GROUP v. ALSTOM (Fed. Cir. 2016): collecting; analyzing; displaying information from a power grid without any specific technical improvement to the collection; analysis; or display = NOT eligible; mere data collection + analysis + display without more is abstract; BSG TECH v. BRAGDON (Fed. Cir. 2018): Using a relational model database and prompting the user to enter information using historical usage statistics = NOT eligible; applying abstract idea to prior art environment does not add 'significantly more'.

The January 2019 USPTO Revised Guidance made important procedural changes to how examiners apply the Alice test that practitioners need to understand: THE KEY CHANGES IN 2019 REVISED GUIDANCE: STEP 2A PRONG 1 — NARROWED ABSTRACT IDEA CATEGORIES: the 2019 guidance restricted abstract ideas to THREE specific categories: (1) mathematical concepts (mathematical relationships; mathematical formulas or equations; mathematical calculations; mathematical algorithms); (2) certain methods of organizing human activity (fundamental economic principles or practices; commercial or legal interactions such as agreements in the form of contracts; managing personal behavior or relationships); (3) mental processes (concepts performed in the human mind including observations; evaluations; judgments; opinions); IMPORTANT CONSEQUENCE: examiners can no longer simply say 'this is an abstract idea' without identifying WHICH of the three categories it falls into; a bare 'abstract idea' rejection without specific category identification is procedurally deficient under 2019 guidance; PROSECUTION RESPONSE: if an examiner rejects without identifying the specific abstract idea category, object and require the examiner to comply with the guidance; STEP 2A PRONG 2 — PRACTICAL APPLICATION BEFORE INVENTIVE CONCEPT: the 2019 guidance reordered the analysis: examiners MUST consider whether the claim integrates the abstract idea into a practical application BEFORE asking whether there are additional elements constituting an inventive concept; PRACTICAL APPLICATION INDICATORS (2019 guidance lists): improvement to technology or technical field (ENFISH principle); particular machine that is integral to the claim; specific transformation; specific application in a meaningful way beyond merely linking to a technology; IMPORTANT CONSEQUENCE: if the claim integrates the abstract idea into a practical application, the analysis STOPS — no need to reach Step 2B (inventive concept); PROSECUTION RESPONSE: argue practical application under Step 2A Prong 2 before conceding to argue inventive concept under Step 2B; STEP 2B — WELL-UNDERSTOOD/ROUTINE/CONVENTIONAL REQUIRES EVIDENCE: BERKHEIMER v. HP (Fed. Cir. 2018): whether additional claim elements are well-understood/routine/conventional (WURC) is a QUESTION OF FACT; PRACTICAL CONSEQUENCE: examiners cannot simply assert that claim elements are WURC without evidentiary support; examiner must point to prior art; existing case law; or widely-adopted standards that establish the elements are WURC; PROSECUTION RESPONSE: when an examiner asserts claim elements are WURC without evidence, challenge the assertion; argue that even if the individual elements are known, their unconventional COMBINATION is not well-understood.

Effective software patent drafting requires both strategic framing and specific technical precision: STRUCTURAL APPROACH TO SOFTWARE CLAIMS: CLAIM THE SYSTEM, NOT JUST THE METHOD: system claims ('A system comprising: a processor; a non-transitory memory storing instructions that cause the processor to...') are often more robust than pure method claims for software; advantages: clearer identification of a machine as the invention subject; harder to characterize as a mental process; less likely to encounter divided infringement problems; METHOD CLAIMS: still essential for comprehensive protection; method claims must recite specific steps with technical precision; avoid language that describes a mental process: 'comparing'; 'evaluating'; 'determining' (without specific technical steps for HOW) can sound like mental processes; COMPUTER-READABLE MEDIUM (CRM) CLAIMS: the third leg of the triple-claim approach; 'a non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform...'; avoids divided infringement (one party controls the medium); TECHNICAL LANGUAGE SELECTION: USE TECHNICAL VOCABULARY: specific algorithmic terms (gradient descent; Markov model; regex parser; hash table; Bloom filter); specific data structure names (B-tree; trie; ring buffer; inverted index); specific networking terms (TCP ACK; UDP datagram; BGP route table); specific hardware terms (ASIC; FPGA; GPU tensor core; cache line); AVOID PURELY FUNCTIONAL LANGUAGE: 'a module that detects anomalies' — functional only; 'a processor executing an isolation forest algorithm applied to a 47-dimensional feature vector derived from packet inter-arrival timing to identify anomalous traffic flows' — technical and specific; QUANTIFY TECHNICAL IMPROVEMENTS: where possible, include specific quantified improvements in dependent claims: 'wherein the compression ratio exceeds that of LZW compression by at least 15% for natural language inputs'; 'wherein the detection latency is less than 3ms for a 10Gbps network link'; DESCRIBE THE PROBLEM TECHNICALLY: describe what specific technical problem the invention solves in the specification: 'prior art TCP implementations require O(n) state per connection, limiting scalability to X connections per server; the invention achieves O(1) state per connection using [specific data structure] enabling Y connections per server'; CONTINUATION STRATEGY: file the application; then file a continuation as you observe what competitors actually implement; adjust narrow claims in the continuation to specifically cover competitor implementations while relying on the parent's specification to support the claims.

Software patents that survive initial prosecution still face potential cancellation via inter partes review (IPR) at the Patent Trial and Appeal Board, and drafting for PTAB survival requires additional considerations: WHY SOFTWARE PATENTS ARE VULNERABLE AT PTAB: software patents face IPR petitions more often than other technology areas because: prior art publications are numerous (academic papers; open-source code; standards documents; conference proceedings); the software field has a long publication history that provides extensive prior art; well-resourced tech defendants file IPRs rather than litigating in district court (cheaper; faster; more favorable standard); DRAFTING FOR PTAB SURVIVAL: AVOID OVERLY BROAD INDEPENDENT CLAIMS: a claim to 'a method of routing network packets based on classification' is almost certainly anticipated or obvious; the same claim with specific technical differentiation ('using a specific multi-dimensional classification algorithm that simultaneously evaluates [specific features] in O(log n) time') is much harder to invalidate; INCLUDE SPECIFIC TECHNICAL DETAILS IN THE SPECIFICATION: even if not in the claims themselves, the specification must enable the full scope of the claims; for software, this means: pseudocode or flowcharts for key algorithms; specific data structure definitions; specific inputs and outputs; examples with representative data; CLAIM DIFFERENTIATION ACROSS DEPENDENT CLAIMS: dependent claims should ladder from broad to narrow with meaningful technical distinctions; if the independent claim is challenged, dependent claims can fall back to; PRIOR ART SEARCH BEFORE FILING: conduct a thorough prior art search including: academic papers; conference proceedings (USENIX; IEEE; ACM); open-source repositories (GitHub; SourceForge); standards documents (IETF RFC; IEEE 802.x; 3GPP); earlier patents; this prevents filing claims that are clearly anticipated; RESPOND TO IPR PETITIONS STRATEGICALLY: if an IPR petition is filed: consider filing claim amendments in IPR (allowed in a limited form); use declaration evidence to distinguish the invention from the prior art; challenge the petition's claim construction (different claim construction often changes whether the prior art reads on the claims); DESIGNING AROUND WHILE MAINTAINING PROTECTION: continuation applications allow ongoing claim adjustment; monitor competitor products; file continuation claims that specifically cover what competitors are actually doing; this ongoing prosecution creates a patent portfolio that stays current with the technology.