Guest post by Professor Kevin Emerson Collins, Professor of Law at Washington University Law School.
In its en banc decision in Williamson v. Citrix Online, the Federal Circuit held that there is no “strong” presumption that functional claim limitations that do not use the term “means” are not subject to the rules of means-plus-function claim construction laid out in section 112(f). There is still a presumption that claims that do not employ the term “means” are not means-plus-function claims, as Jason Rantanen explains in his earlier PatentlyO post on Williamson, but, in theory, this only requires the patent challenger to satisfy a more-likely-than-not burden of persuasion.
I understand Williamson to shift Federal Circuit case law on two distinct axes at the same time. First, as a matter of substance, it makes broad, functionally defined claims more difficult to obtain. The scope-narrowing rules of 112(f) now apply to a larger number of functionally defined limitations: a limitation that not employ the term “means” should now be governed by 112(f) whenever it “fails to ‘recite sufficiently definite structure’ or else recites ‘function without reciting sufficient structure for performing that function.’” Second, as a matter of form, Williamson makes patent law less rule-like and more standard-like. Courts may no longer use the rule-like, strong presumption that 112(f) does not apply when functional limitations do not employ the term “means.” Rather, whenever prompted to do so by a patent challenger, they must scrutinize the claim language on a case-by-case basis to see if it recites a sufficient quantum of structure in order to determine whether section 112(f) applies.
In my opinion, all things being equal, the substantive shift discussed above is a positive development. Unbridled functional claims over-reward an inventor and impose undue costs on society.[i] The strong presumption that functional claim limitations not using “means” avoided the scope-narrowing rules of 112(f) made such functional claims too easy to obtain. However, there is more work to be done to fully effectuate this substantive shift. For example, it is far from clear that the Federal Circuit will ever apply 112(f) to a method claim, despite the express mention of “step for” claims in the text of the statute. So, patentees can perform an end-run around Williamson and obtain broad, functionally defined claims simply by seeking a method claim rather than a product claim—a tactic that is particularly useful in the software arts where claims can be easily transformed from systems to methods and back again.
Nevertheless, being in a charitable mood, let’s assume all of the loopholes get closed and that all claims reciting “function without reciting sufficient structure for performing that function” are really subject to 112(f) after Williamson. It is at this point that we have to roll up our sleeves and begin the truly hard part of the work that is needed to reform functional software patents.
Bringing 112(f) to bear on software patents is tricky because the statute depends on a dichotomy between structure and function that simply does not exist in the software arts as a matter of fact. Although there is unquestionably a gray area, the structural and functional properties of a technology in the mechanical arts are, at their core, ontologically distinct to a philosopher and intuitively distinct to the rest of us. The description “coiled spring” denotes structure; the description “capable of generating kinetic energy when jostled” denotes function. However, this distinction vanishes in the software arts: most software inventions are function all the way down.[ii] Software is a powerful technology precisely because a programmer can remain ignorant of the physical, structural properties of a computer while specifying the functions that the software performs. Software functionality is therefore like a never-ending set of nested Russian dolls: you open up one more general functional description to look for structure, and all you find is another, more specific functional description. Patent law can, and does, identify an “algorithm” for performing a function as structure for legal purposes in a software claim, but it is importantly only metaphorical structure. An algorithm is a series of more specific steps for performing a more general function, but each of the steps in an algorithm is, in turn, specified only in functional terms. What is an algorithm as the term is used in patent law? It is a functional description of a software program that is specific enough that we are willing as a matter of patent policy to treat it like we treat a structural description in other arts. That is, the function-structure distinction in software is not a difference of kind but a difference of degree. Structure in the law of software patents is a legal fiction that has been manufactured to achieve patent policy goals.
The true challenge post-Williamson will therefore be identifying the level of specificity at which a functional description should count as metaphorical structure. Michael Risch alludes to this problem in his blog post on Williamson when he asked “[H]ow much structure is enough?” However, I think that a question precedent to Risch’s question is both more difficult and fundamental, namely “When is there any structure at all?” What level of specificity in a functional description counts as metaphorical structure?
To date, the Federal Circuit has answered this question with another layer of formalism that Williamson does not touch: any functional description in the specification that is more specific than the functional description in claims is likely to be metaphorical structure and thus an algorithm. This rule makes no sense from a policy perspective because the level of generality specified in a claim is often arbitrary. If a claim recites function A and the specification recites algorithmic steps 1, 2, and 3 for function A, a valid claim encompasses steps 1, 2, and 3 and their equivalents. However, if the claim were to directly recite functions 1, 2, and 3 (which are identical to steps 1, 2, and 3) without a more specific set of algorithms for those functions in the specification, then the claim is invalid for indefiniteness.[iii] The Federal Circuit’s approach to identifying algorithms is more like ducking the important question than providing an answer to it.
To be honest, I still waffle in my opinion on how hard the challenge of assessing the validity and permissible scope of functional software claims will be after Williamson. Some days, the problem seems difficult but tractable (although maybe not by an Article III court). Perhaps what we need to do is get patent lawyers, software engineers, and economists around a table. Perhaps they can articulate clear guidelines identifying a level of specificity at which functional software claims should be upheld, i.e., a level that identifies an algorithm and thus metaphorical structure. But, on other days, I’m less convinced that there is a tractable solution. Maybe the difference between a functional description of software and a software algorithm is like the difference between ideas from expression in copyright law, given that both differences are based on a levels-of-generality problem. Maybe therefore “[n]obody has ever been able to fix that boundary, and nobody ever can.”[iv] While the amount of uncertainty that follows from the idea/expression dichotomy may be acceptable in copyright law, the same amount of uncertainty in a function/algorithmic-step dichotomy in the law of software patents may not be.
In sum, although I believe that Williamson shifts the substantive reach of patent protection in the right direction, the costs of the inextricably linked shift toward a standard and away from a rule may, or may not, turn out to be too much to bear. If they are too much, then the need for a more rule-like patent regime will force us to choose doctrine that is either quite over-protective (e.g., that returns to the pre-Williamson strong presumption) or quite under-protective (e.g., that eliminates pure software patents altogether) as a substantive matter. Yet, despite the existence of these many possible futures, at least one thing is clear in the immediate aftermath of Williamson: the hard work of reforming functional software patents can now begin.
[i] The normative argument here is more complicated than is often presumed. For my take on why functional claiming should not be allowed, see Kevin Emerson Collins, Patent Law’s Functionality Malfunction and the Problem of Overbroad, Functional Software Patents, 90 Wash U. L. Rev. 1399, 1411–24 (2013).
[ii] To be clear, software only works because a programmed computer has certain physical, structural properties. But, the physical, structural properties of the programmed hardware are irrelevant to the definition of what constitutes a software invention. For more on what it means to say software is “function all the way down,” or to call software a purely functional technology, see id. at 1440–43.
[iii] Id. at 1463–67.
[iv] Nichols v. Universal Pictures Corp., 45 F.2d 119, 121 (2d Cir. 1930).