Author: Marc Lampert
Two recent Federal Circuit decisions, Finjan, Inc. v. Blue Coat Systems (2018) and Trustees of Columbia University v. Gen Digital (decided recently in March 2026), together draw one of the clearest lines in recent memory between software patents that hold up in court and those that don’t; and draw important lessons for drafting of software related patents. Both involved sophisticated, genuinely innovative cybersecurity software. Yet one patent survived a section 101 challenge and one potentially did not. The reasoning primarily has to do with how the inventions were described in the claims, not necessarily having to do with the underlying technology.
The central issue in both cases is a provision of patent law known as 35 U.S.C. § 101, which defines the basic categories of things that are eligible for patent protection. In particular, a Court (or Examiner) may look at a software claim and conclude that, when you strip away the technical language, what is really being claimed is an abstract idea, such as “organizing information” or “detecting anomalies by comparison,” with a computer simply serving as the tool to carry it out. Abstract ideas are not patentable subject matter under section 101, and courts evaluate these challenges using a two-step test; which first asks whether the claim is directed to an abstract idea and, if so, whether the claim contains something meaningfully more than that abstract idea alone.
In Columbia, the university’s patents described a system that ran programs through an emulator, compared their behavior against a model built from multiple computers, and flagged anything anomalous. The Federal Circuit said that, at its core, this was just “comparing data against a model to detect anomalies”; an abstract concept that computers were being used to execute, rather than a genuine improvement to how computers themselves work. Critically, Columbia’s patents did disclose more innovative techniques in the written description, including selective emulation and randomized models designed to resist mimicry attacks, but the court held that none of that mattered, because those features were never actually required by the claim language. As the court put it bluntly: only what is claimed counts, not what is disclosed.
Finjan succeeded precisely where Columbia fell short. Finjan’s patent didn’t just describe the goal of detecting malicious code; it claimed a specific, new kind of thing: a “security profile” that was generated by analyzing what a downloaded program might do (rather than simply matching it against a database of known viruses), and then linked directly to that downloadable so any receiving computer could review the scan results. That last detail, the linking, was the key. It meant the patent described a new data artifact that changed the way computers processed downloads, not just a new use of computers to accomplish a pre-existing goal. The court found this to be a genuine improvement to computer functionality, not an abstract idea in disguise.
The practical takeaway for software inventors is that the strength of your patent depends not on the sophistication of your technology, but on whether your patent claims specify the mechanism behind the improvement, not merely the result. If your claim could be summarized as “use a computer to do [abstract thing] better or faster,” it is at risk. If it instead describes a specific new process, data structure, or operational sequence that changes how the computer itself functions, it is on much firmer ground. Every technical feature that can be considered genuinely novel should be expressly claimed in the patent, because anything left only in the written description does not help in a section 101 analysis. This is a nuanced and consequential evaluation where experience in the patent space is required. Knowing which technical details to elevate into claim language, and how to phrase them so they capture the invention without unnecessarily narrowing the scope of protection, requires an understanding of both the technology and the evolving body of case law that governs software eligibility.
The broader lesson from Columbia is that patent drafting for software is not simply a documentation exercise. No matter how detailed and innovative your specification is, the test looks at what the claims require. If your technical improvement is buried in the specification but properly not reflected in the claim language, it simply doesn’t count. This means that your patent cannot merely have broad, functional claims and then expect to rely on the specification to explain the innovation. The innovation has to be structurally embedded in the claims themselves, which must include a concrete mechanism that makes the invention work differently from conventional approaches. Accordingly, experience navigating section 101 challenges is eminently important when drafting software patents, as a skilled practitioner will draw out the specific mechanisms that distinguish your approach from the prior art and ensure those distinctions are woven directly into the claims.