Here is some trivia to test your knowledge about software patent eligibility:
Can you patent a piece of software that incorporates a self-referential lookup table to improve a database system’s memory configuration?
What about a piece of software that enables a user to archive digital images over a cellular network?
The answer is (as you would expect in almost all legal contexts)—it depends.
Recent Supreme Court decisions and subsequent lower court opinions have introduced significant ambiguity to a traditionally straightforward analysis. Today, we need quite a bit more information before we can make a patentability determination on the questions posed above, including more information on the underlying technology, and how the patent application is written.
If the software in question improves “computer functionality” (i.e. improves computing speeds or reduces the amount of computing resources required), or performs the computing tasks in an unconventional way, then it may be patentable.
The answer also depends on how the patent is written.
Notice how the lookup table question above describes a technical feature of software (self-referential lookup table). Whereas, the archiving system question describes a benefit to a user (i.e. what a user can do as a result of the software—archive digital images).
The former approach is more likely to be deemed patentable, while the latter approach is more likely to be deemed unpatentable.
To put it in more startup friendly terms, if your patent is focused on one way to solve a customer’s pain point, then you have a better shot at patentability. But, if your patent attempts to claim the benefits that a customer will enjoy as a result of your software, then your invention will likely be deemed unpatentable.
TL;DR
Software based inventions are still patentable in the United States. But, in order to patent eligible, software patent applications must meet certain technical requirements, and must be written very carefully.
From a technical standpoint, your software may be patentable if:
it improves computer functionality in some way (i.e. it enables certain computations that were previously unavailable, speeds up processes, or requires fewer resources), or
it solves a computing challenge in an unconventional way.
Moreover, your software may be patent eligible only if it is written with a precise focus on the technical merits of your particular software solution.
You can improve your odds of getting a patent by:
describing the technical challenges in your field of invention, and
specifically describing and claiming the solutions that you have come up with to address those challenges.
If you try to claim all of the ways to solve a particular pain point, or if you focus on the benefits that a user is enabled to perform as a result of your software, then you’ll have a very difficult journey to patentability.
The Law
Under the current patentability regime in the United States, software patent applications must meet one of the following two requirements to be patent eligible:
the invention should be much more than an “abstract idea,” or
if the invention is directed to an “abstract idea,” then it must include/claim additional elements that “transform” the abstract idea into a patent-eligible application.
Super clear and helpful, right?
Didn’t think so.
We discuss each of these requirements in more detail below.
The “abstract idea” requirement – A software based invention is patent eligible if it “improves computer functionality” by, for example,
enabling computations that were previously unavailable or could not be performed by computing devices,
speeding up previously available computing processes, or
reducing the number of computing resources that are required execute a task.
The “transformation” requirement – If software does not tend to “improve computer functionality,” it may still be patent eligible if one or more of the following factors are met:
necessarily rooted in computer technology” (i.e. the problem does not arise in a traditional brick-and-mortar context);
solves that problem by using “unconventional” components, or by arranging conventional components in an “unconventional” way;
the patent claims do not preempt every application of the idea.
Quick Detour: should software be patentable in the first place?
Before we jump into a discussion of software patent eligibility, it is important to at least acknowledge a viewpoint held by many developers: software shouldn’t be patentable in the first place. Many techies argue that software patents actually impede innovation, and that 99% of software is neither “novel” nor “non-obvious” to other developers who are equally skilled in the same technical field. (All inventions must be “novel” and “non-obvious” in order to be patentable). (Brad Feld outlined some of these criticisms in his blog post here).
We tend to agree, and sympathize, with the anti-software-patent community, but software patents are often an important point of emphasis for some investors and large corporate buyers. We are not taking a position on the larger philosophical debate here; we aim to simply demystify the laws around software patent eligibility based on the rules that have been promulgated by the United States Congress and the U.S. Supreme Court.
How did we get here? – Supreme Court’s decision in Alice v. CLS Bank and the subsequent morass
Recent confusion about software patent eligibility stems from a 2014 Supreme Court decision in Alice v. CLS Bank, 134 S. Ct. 2347 (2014).
In this case, the Supreme Court articulated a two-step inquiry for determining whether a particular software is patentable. First, a computer-related patent application must not be directed to an “abstract idea.” But, if it is, then the patent application must claim some elements that “transform” the claimed invention into a patent-eligible invention.
The Supreme Court, in its articulation of the rule, however, provided little guidance about what an “abstract idea” is, and how much detail in needed to “transform” an abstract idea to a patentable invention.
Some follow-on cases at the Federal Circuit and at the District Court level have attempted to clarify this standard. But the state of the law remains in disarray. We examine each step of the two-step inquiry in detail below.
When is a software an “abstract idea?”
The general rule here is as follows: if the focus of the patent application is on improving a computer’s functionality, then it is patent eligible and not an “abstract idea.”
If, however, the focus of the patent application is on a generic process for which computers are invoked merely as a tool for executing the process, then it is considered an “abstract idea.” The courts argue that you should not be able to patent a generic process simply by having a computer execute it. Additionally, mathematical algorithms, including those executed on a generic computer, and some fundamental economic and conventional business practices are also abstract ideas.
At first blush, the “improving computer functionality” rule appears to be helpful, at least superficially. But seasoned technologists and patent attorneys immediately recognized that it doesn’t help with real world analyses, and doesn’t comport with the way software operates in today’s technologies. After all, doesn’t all software tend to improve computer functionality by enabling some computation that was previously unavailable, speeding up certain transactions, or requiring fewer computing resources?
In practice, the “abstract idea” inquiry often turns on how the patent application is written. If you describe and claim your invention in general terms, then your invention will likely be categorized as an “abstract idea.” If, however, you describe and claim your invention with significant technical detail, and with a focus on the technical challenges that your invention overcomes, then your invention will likely be categorized as not being directed at an abstract idea.
Case study – an improvement in computer functionality
In one case (Microsoft v. Enfish), database software that used a self-referential table was deemed patent eligible because it “improve[d] the way a computer stores and retrieves data in memory.” (As opposed to an “abstract idea” for storing, organizing, and retrieving memory in a logical table—as argued by the other side). The Enfish court was convinced that the invention improved computer functionality because the patent specification “disparage[ed] conventional data structures,” and described the claimed invention “as including the features that make up a self-referential table.”
Case study – generic implementation
Conversely, in another case (TLI v. AV Automotive), the same court found that a patent was directed to an “abstract idea” because it claimed generic steps for recording, administrating, and archiving digital images from a cellphone over a cellular network (as opposed to presumably patent eligible steps for improving image retrieval speeds). In this case, the court noted that the patent application did not describe any challenges associated with transmitting digital images over a cellular network, or structuring the data for optimal storage. It was not sufficient to simply claim a method for “recording, administration and archiving of digital images simply, fast and in such way that the information therefore may be easily tracked.” The court wanted the inventors to describe how these improvements were actually achieved.
Notice how the decisions can come down to how to describe your invention in the patent application. If you describe your invention too broadly, without a specific emphasis on the technical challenges and solutions, then your invention will likely be considered an “abstract idea.” If, however, you focus the patent on the computing challenges that others faced prior to your invention, and the specific computing technologies that enable your software to overcome those challenges, then you may have a shot at avoiding the “abstract idea” classification.
When is an abstract idea “transformed” into a patentable software?
Software that is deemed to be an “abstract idea” may nonetheless become patent eligible if it solves a problem that is “necessarily rooted” in computer technology, or solves the problem in an unconventional way (or with unconventional components). Moreover, the claims of the patent must be written in a way that does not preempt every application of the idea.
This rule supersedes an earlier rule that permitted software patents to be issued if the patent merely recited some concrete or tangible components along with the software. The courts justify this rule change by arguing that mere recitation of concrete, tangible components is insufficient to confer patent eligibility to an otherwise abstract idea. Rather, the components must involve “more than” performance of well understood, routine, conventional activities previously known to the industry.
Case study – an “unconventional” solution
In one case (DDR Holdings v. Hotels.com), a method for creating and displaying a “hybrid” webpage, (which incorporates “look and feel” elements from a host website, and content from a third party website) was deemed patentable eligible. More specifically, the court found that the abstract idea of displaying a “hybrid” webpage was “transformed” into a patent eligible concept by the recitation of unconventional components that did not preempt every application of the idea.
In DDR, the patentee created software for improving customer retention on a webpage by automatically creating and displaying a “hybrid” webpage when a user clicked on an advertisement on a host webpage. The “hybrid” webpage used the “look and feel” of a host website, but displayed merchandise from a third-party website. In effect, the software prevented a user from bouncing to a third-party website upon clicking an advertisement. Instead, the software enable a user to complete a transaction on a host webpage (to purchase third-party merchandise) despite clicking on a third-party advertisement.
The court found that the specific customer retention problem that DDR solved was “necessarily rooted” in software (i.e. in the hyperlinking architecture of internet protocol), which did not have a real-world analogue. Moreover, the court found that DDR’s solution was unconventional. Instead of using the conventional method of transporting users to a third-party website, the DDR solution created an unconventional solution of creating a “hybrid” webpage.
Finally, the court believed that the patent claims were narrowly tailored to one specific solution. DDR did not try to patent every method of “increasing sales by making two web pages look the same.” Instead, DDR’s patents were narrowly tailored to identifying specific types of third-party merchants, creating specific types of “look and feel” elements, and using a specific type of data store.
This last point makes founders or technical people scratch their heads. The DDR claim appears to patent every application of creating a “hybrid” webpage. But it does not claim the abstract concept of retaining users who visit a webpage. It is very important that you have several discussions with your patent attorney on this point. The line between preempting every application and narrowly claiming your invention is often invisible at the drafting stage. But this is where your patent attorney earns his or her fees. Identifying the right level of abstraction for your claims is critical).
Case study – an “unconventional” implementation
Your software may be patentable even if it does not use “unconventional” components similar to DDR’s—as long as it uses conventional components in an unconventional way. In another case, (Bascom v. AT&T) the court found that a patent must be examined as a whole to discern whether an unconventional installation using traditional components is sufficiently “transformative” to be patent eligible.
The underlying technology in that case dealt with software for filtering internet content based on permissions and other controls. The conventional method involved installing filtering software on an end-user’s terminal. But the patentees sought to patent a filtering tool that could be installed at a specific location that is remote from the end-user.
The court found methodology to be patentable because the solution was unconventional and because the claims were not overbroad. Specifically, Bascom did not claim every method for filtering web content. Instead, Bascom narrowly claimed a “specific location for the filtering system (a remote ISP server) and require[d] the filtering system to give users the ability to customize filtering for their individual network accounts.”
Best practices
Much to the chagrin of developers and founders—the patentability question for software inventions often comes down to how the patent and the patent claims are written. You can improve your odds of getting a patent by describing the technical challenges in your field of invention, and specifically describing the engineering solutions that you have come up with to address those challenges. Moreover, you must claim your invention very carefully. You should not claim every method of relieving a particular pain point. Instead, your claims should be narrowly tailored to claim only the pain point that you have come up with.
From a technical standpoint, you can improve your odds of obtaining a software patent if you can articulate how your invention improves computer functionality, and how your solution is “unconventional” compared to other solutions in your particular field of invention.