The Technological Problem: The Elusive Key to Patent-Eligible Subject Matter
Over thirty-five years ago in Diamond v. Diehr, 450 U.S. 175 (1981) (hereinafter “Diehr”), the United States Supreme Court struck a compromise for patenting software inventions. In Diehr, the Supreme Court recognized that not every discovery warranted patent protection. In particular, the Supreme Court viewed laws of nature, natural phenomena, and abstract ideas as being such fundamental truths that no one deserved an exclusive right over them. However, the Diehr court found that a process designed to solve a “technological problem” in conventional industry practice could become patent eligible. In Diehr, the patent-eligible solution involved using the Arrhenius equation in a process for molding rubber products. While the solution in Diehr makes sense as patent-eligible subject matter in hindsight, what remained unclear for decades is how to identify a “technological problem” specifically solved by a given claim.
In a recent precedential opinion by the U.S. Court of Appeals for the Federal Circuit (hereinafter “Federal Circuit”), the Federal Circuit provides an illustrative example for determining whether a claim is a specific solution to a “technological problem.” In Data Engine Technologies LLC v. Google LLC, No. 2017-1135 (Fed. Cir. October 9, 2018) (hereinafter “Data Engine Technologies”), the Federal Circuit analyzed several claims in the field of electronic spreadsheets from U.S. Patent No. 5,590,259 (hereinafter “’259 Patent”) and U.S. Patent No. 5,303,146 (hereinafter “’146 Patent”). Under the analysis for patent-eligible subject matter, the Federal Circuit found claim 12 of the ’259 Patent directed toward a specific solution to a technological problem. However, the same court found claim 1 of the ’146 Patent merely recited generic steps directed toward an abstract idea. Thus, the Federal Circuit undertook a careful analysis to determine which claims offered a solution specific to a technological problem and which ones did not.
Turning to claim 12 of the ’259 Patent, the Data Engine Technologies decision analyzed the proposed technological problem in light of the prior art as discussed in the patent’s specification and contemporaneous articles showing the state of the art at the time of the invention. In particular, the Federal Circuit noted that the ’259 Patent “specifically identif[ies] problems with navigation through prior art three-dimensional or multipage electronic spreadsheets.” For example, the ’259 Patent’s specification “explain[s] that the complex commands required to manipulate each additional spread of the three-dimensional spreadsheet diminished the utility and ease of use of this technology.” Accordingly, the Federal Circuit found the claim’s specific solution “provid[ed] familiar, user-friendly interface objects—specifically, notebook tabs—to navigate through spreadsheets while circumventing the arduous process of searching for, memorizing, and entering complex commands.” For additional support, the Federal Circuit cited articles published after the ’259 Patent’s priority date as evidence of the solution in claim 12 being a success at solving the related technological problem.
Turning to the claim 1 of the ’146 Patent, the Data Engine Technologies decision performed a similar analysis of whether the claim provided a solution specific to a technological problem. For example, the Federal Circuit noted that the specification of the ’146 Patent contended that “prior art electronic spreadsheets were not particularly adept at managing ‘what-if’ scenarios in a given spreadsheet” and “provided little or no tools for creating and managing such a multitude of scenarios.” As such, the ’146 patent purported to solve this problem by providing an electronic spreadsheet system “having a preferred interface and methods for creating and tracking various versions or `scenarios’ of a data model.” However, unlike with claim 12 of the ’259 Patent, the court found “nothing [in claim 1 of the ’146 Patent] viewed in light of the specification convinces us that the claimed method improves spreadsheet functionality in a specific way sufficient to render the claims not abstract.” Without a clear connection to a specific solution for an identified technological problem, the court found claim 1 similar to past claims directed toward abstract ideas and without significantly more.
In conclusion, patent applicants in the software arts must carefully articulate a technological problem at the time of filing an application. Attempts at identifying a problem in hindsight may prove insufficient for the USPTO and courts. In Data Engine Technologies, for example, the patentee needed the patent’s specification and third party articles submitted in the prosecution history to survive a legal challenge to the ’259 Patent. Thus, software applications should include support in a patent specification above and beyond the basic patent requirements, e.g., with regard to the written description requirement, the enablement requirement, etc. In particular, patent applicants would be wise to provide additional details elaborating on the relationship between the claimed invention and a problem specific to the prior art in a particular technical field.
Moreover, a software claim needs to recite explicit limitations specific to the technological problem. Conclusory statements, e.g., “providing a preferred interface,” are of little value in support of patent-eligible subject matter. For example, claim 12 of the ’259 Patent identified a problem with three-dimensional spreadsheets and subsequently recited both “a three-dimensional spreadsheet” and “a plurality of spreadsheet pages” in claim 12. In contrast, claim 1 of the ’146 Patent recited “a base set of information cells for the system to track changes,” but with no further elements connecting claim 1 to the articulated technological problem. Merely describing a technological problem divorced from the actual claim language leaves a claim vulnerable to being found patent ineligible.