The Illogic of the Algorithm Requirement for Software Patent Claims

A long line of Federal Circuit precedent holds that a function in a software claim under 35 U.S.C. 112, sixth paragraph, must refer to a corresponding “algorithm” in the specification.  Absence of an algorithm is fatal to the claim. [1]  Clever defense attorneys have used this trick to invalidate many software claims that were perfectly novel and nonobviousness.

Recently, patent scholar Mark Lemley has renewed attention to software claims under 35 U.S.C. 112, sixth paragraph.  Lemley tends to agree with widespread concerns that broad software patents may be deeply problematic.  Lemley encourages strict application of the algorithm requirement to police software patents and resolve these concerns. [2]

Unlike Lemley, I am convinced that the algorithm requirement makes no sense.  The problem is not that the concern about broad software claims is unjustified.  (I think the concern is overblown, but that is not my argument here.)  The problem is that, even if the concern is justified, the algorithm requirement does not solve it.  At least, the requirement does not solve the problem in an appropriate way, as explained below.

The algorithm requirement is intended to provide structure to avoid purely functional claim language. [3]  “If the specification is not clear as to the structure that the patentee intends to correspond to the claimed function, then the patentee has not paid that price but is rather attempting to claim in functional terms unbounded by any reference to structure in the specification.” [4]

The Federal Circuit applies section 112, sixth paragraph, by requiring corresponding structure in the description.  The Federal Circuit says that “the corresponding structure [for software claims] is the algorithm[.]” [5]  On its face, this statement is paradoxical: algorithms are not structural.  Algorithms are formed of acts or steps—which are, broadly construed, functions—not structures.

That is the ultimate problem for the algorithm requirement: algorithms are composed of functions.  The creators of the algorithm requirement thought of algorithms as distinct from functions, such that algorithms can cure deficiencies in functions.  But this is a fallacy.  Algorithms and functions are cut from the same cloth—functions—and one does not meaningfully cure the other in the software arts.

Because algorithms are composed of functions, algorithms cannot help avoid purely functional claim language.  When you inject algorithms into patent documents, you do not inject structure, you inject further functions.  If those functions require algorithms, then those algorithms will be composed of further functions, and so on.  The algorithms and functions are nested within each other like Russian Matryoshka dolls, turtles all the way down.

The following example illustrates the problem.

Consider a claim that recites:

1. A computer comprising:

storing means for storing a user input of an integer in a variable;

modifying means for modifying the variable.

Now the patent defense attorney might say that this claim is invalid for many reasons.  But only one of those reasons interests us here.  Under Federal Circuit law, the means-plus-function claim is invalid unless there is a corresponding algorithm in the description for each recited “means.”

Here, we reach a first problem.  The defense attorney demands an algorithm, but the claim already recites an algorithm.  The “storing” and “modifying” functions form an algorithm.  (This becomes clearer if we switch the recited “means” with “steps.”  In that case, 112, sixth paragraph would still govern the “step[s] for” clauses.)

Even though claim 1 already recites an algorithm, the defense attorney will persist.  Each function in the algorithm of claim 1 needs its own algorithm—or so the attorney says (and the Federal Circuit agrees).  The defense attorney wants to supplement the algorithm of claim 1 with further algorithms.

In response to the defense attorney’s argument, we can modify the example of claim 1.  We can imagine that, if we placed an algorithm to perform the “modifying” function in the patent’s description, then we would help satisfy the defense attorney.  (We would also need to add an algorithm for the other, “storing” function of claim 1, but let’s focus on the “modifying” function for now.)

Suppose that the description disclosed the following sentence: “modifying the variable corresponds to an algorithm of the following sequence of steps: multiplying the variable by 2 and then adding the variable to 10.”  For brevity, let’s call this the “Sentence Algorithm.”  If we placed the Sentence Algorithm in the description, then we would expect the defense attorney to be satisfied about the “modifying” function.

But what if, instead, we simply filed an original claim that contained claim 1 and the Sentence Algorithm?  Consider claim 1*:

1*. A computer comprising:

 storing means for storing a user input of an integer in a variable;

modifying means for modifying the variable, the modifying means comprising:

multiplying means for multiplying the variable by 2;

adding means for then adding the variable to 10.

Under current Federal Circuit law, we would expect the defense attorney to not be satisfied with claim 1*.  Instead, the defense attorney would demand that we disclose further algorithms for each of the multiplying and adding means of claim 1* in the description.  If we did that, then the attorney would be satisfied.

But let’s go another level.  If we filed an original claim 1** that recited multiplying and adding algorithms (to address those functions in claim 1*), then the attorney would demand further, further algorithms in the description.  And so on, turtles all the way down.

This does not make sense.  The only difference between claim 1 and claim 1* is the location of the Sentence Algorithm.  For claim 1, the algorithm is located in the description.  For claim 1*, the algorithm is located in the claim.  This is a matter of mere form—the location of the algorithm within the patent document—and not substance.

Of course, for typical claims, whether claims recite language, instead of the description, is a matter of supreme importance.  Patent law generally does not permit claims to incorporate limitations from the description.  But claims under 112, sixth paragraph, are different.  These claims cover the element recited in the claim as defined by the corresponding “structure, material, or acts” of the description.

In view of the above, as a matter of policy, it should not matter whether the Sentence Algorithm is placed in the claim or in the description.  In both cases, the patent document will disclose both the hardware and the algorithm for performing the recited function.  That should be more than enough to enable and define the claimed software.  Yet, under Federal Circuit law, the location of the Sentence Algorithm does matter.  That is illogical.

The algorithm requirement is also illogical because it is arbitrary.  The requirement’s creators failed to appreciate that one can describe software at arbitrary levels of abstraction.  Roughly speaking, one can describe software at any of the following (generally) decreasing levels of abstraction:

(A) prose

(B) flow diagram

(C) data structures as abstractions of variables and functions

(D) variables and functions

(E)  sequential instructions with goto (or equivalent) commands

(F)  prose descriptions of hardware functions in terms of processor functions, memory, and registers, etc.

(G) binary machine code

The above hierarchy is a rough sketch.  Not every level is less abstract, in every aspect, from the level above it.  There are also countless variations at each level, and between levels, which I have omitted.

Nevertheless, the hierarchy (A)-(G) illustrates how the algorithm requirement is arbitrary.  The algorithm requirement is intended to provide structure to avoid purely functional claim language.  Yet the algorithm requirement does not specify what level of abstraction, along the hierarchy (A)-(G), one must overcome.  Regardless of what level the claim language meets, the algorithm requirement encourages the patent drafter to disclose an algorithm at a lower level of abstraction.  For example, a claim written at level (A) would be satisfied by any algorithm at level (B) through (G).  But a claim written at level (F) would be satisfied by an algorithm at level (G) or beyond—even though the claim at level (A) was satisfied merely by an algorithm at level (B) (far above level (G)).

Indeed, the algorithm requirement does not even require the algorithm be less abstract than the claim language.  One can still satisfy the requirement by disclosing an algorithm that is written at the same level of abstraction as the claim.  For example, both claim 1 and the Sentence Algorithm are written at about the level of prose.  Yet a claim written at level (G), which is far less abstract than either claim 1 or the Sentence Algorithm, would still require a narrower algorithm in the description.

The arbitrary narrowing of software claims does nothing to avoid purely functional claim language.  It simply places an arbitrary narrowing requirement on claimed algorithms.  For example, the requirement narrows the plain language of claim 1 to the narrower scope of the Sentence Algorithm (“multiplying the variable by 2 and then adding the variable to 10”).  In practice, the requirement tends to limit a claim written at an arbitrary level of abstraction to an arbitrarily lower level of abstraction.  Accordingly, the algorithm requirement is a useful tool for undermining software patents, like the weakening of injunctions after eBay [6] and the growing sphere of patent ineligible subject matter after Bilski and Prometheus. [7]

Nothing in the statute compels the algorithm requirement.  Section 112 does not contain the word algorithm.  Section 112 does require that inventors disclose corresponding structure in the description.  But that structure can simply be a computer or processor that performs the recited function.  The corresponding structure need not be a computer or processor that performs an arbitrarily narrower version of the recited function, as illustrated above.  The solution to the problem of the algorithm requirement is to simply abolish it.