There's an old saying that everyone complains about the weather, but no one does anything about it. The open source community maintains an active voice of indignation when it comes to the harms flowing from bad software patents. So it's worth noting when a leading patent law scholar proposes a potential solution to the software patent problem, as Mark Lemley recently did in a new paper entitled "Software Patents and the Return of Functional Claiming."
In broad terms, functional claiming refers to writing patent claims that cover the broader function enabled by an invention rather than writing claims to the specific embodiment developed or contemplated by the inventor. In other words, instead of erecting a signpost that points others directly to the invention, functional claiming is akin to building a wide fence to surround the invention in an attempt to claim as much territory as possible. Lemley gives us the colorful example of the Wright brothers to illustrate both how functional claiming works and how it can cause problems.
As detailed by Lemley, the Wright brothers invented a particular improvement to flying machines: they came up with a way of warping a wing to control the direction of flight while turning a rear rudder to counterbalance the effect of bending the wing. In short, they solved the problem of maintaining stability of the plane by having a single cable warp the wing and turn the rudder at the same time. Lemley notes, however, that their patent was written using function language, claiming "means for simultaneously moving the lateral portions [of a wing] into different angular relations" and "means whereby said rudder is caused to present to the wind that side thereof… having the smaller angle of incidence."
A fellow by the name of Glenn Curtiss improved the wing design by using ailerons that could be moved independently of the rudder by the pilot. Unlike the Wrights' design, the ailerons and the wing were not connected. This nontrivial difference notwithstanding, the Wrights successfully asserted their patent against Curtiss and others, despite many of the alternative aircraft having surpassed the technical achievement of the Wrights. Lemley observes that it was not until the government later strong-armed the Wrights into licensing their patents that airplane innovation really "took off."
So how do airplanes relate to the current software patent problem?
Well, first off, a little more history. The Supreme Court eventually responded to the widespread use of functional claiming and effectively took the practice off the table in Halliburton Oil Well Cementing Co. v. Walker 329 U.S. 1 (1946). The Patent Act of 1952 invited functional claims back to the table, albeit with the limitations defined by section 112(f), which limits the means for performing a specified function to the corresponding "structure, material, or acts described in the specification and equivalents thereof." In other words, if you use functional claim language, then that claim will be interpreted narrowly to cover only the specific examples (and its legal equivalents) for performing the function that you have described in your patent application.
Because structure and function can be almost completely separated in computers, software patentees can exploit section 112(f) to circumvent the normal constraints it imposes. Lemley explains this concept well:
"The hardware 'structure' of a computer software invention is…a computer. Generally speaking it doesn't much matter what type of computer a program runs on. That fact has given patentees an opening to write 'structural' claims in which the structure is not novel and does no work. A patentee who claims 'means for calculating an alarm limit' is invoking the limits of section 112(f), and the claims will accordingly be limited to the particular software algorithm or implementation the patentee described in the specification. But if the patentee claims 'a computer programmed to calculate an alarm limit,' courts today will read the term 'computer' as sufficient structure and will understand the claims to cover any computer that can calculate an alarm limit, however the calculation is programmed."
Lemley argues that a simple closing the section 112(f) loophole (via judicial interpretation) on software claims will solve most of the problem described above with software patents. His argument leans on a couple of key observations. First, statutes generally operate prospectively while new judicial interpretations of existing statutes are normally retroactive. Thus, a new interpretation of 112(f) would apply to the hundreds of thousands of existing software patents and not just future patents. Second, section 112(f) equivalents do not apply to later-developed structures, but only to equivalents known at the time the patent issued. Because software changes so quickly, observes Lemley, most litigated software patents today are asserted against technologies that did not exist at the time of patenting. He continues, "[t]his is especially true of troll patents, which tend to be asserted in the last few years of patent life. Once those patents are understood to invoke section 112(f), their literal scope will be limited to the technology the patentee actually designed and equivalents known at the time the patent issued."
So, in summary, Lemley anticipates the result of actualizing his proposal is meaningful change to the claim scope of nearly all software patents. Voila. Just like that.
The obvious advantage of Lemley's proposal is that it would likely be easier to accomplish and to apply in practice than many of the other frequently evangelized solutions, such as abolishing software patents by statute or weeding out bad patents by beefing up examination at the PTO. Another potential advantage, as discussed above, is the potential negative impact on patent trolls.
Lemley offers a prebuttal to the concern that treating software patents as means-plus-function claims will unfairly disadvantage patentees. In particular, the concern is that limiting software claims to one particular algorithm or implementation on one particular machine unfairly restricts patent scope, allowing other companies to implement an equivalent technology while avoiding infringement. His defense seems to hang on the ability to define "an appropriate level of abstraction" for the technology developed by the patentee.
To me, this response seems inadequate because software, unlike ailerons, pipe wrenches, or lawn mower blades, is itself an inherent abstraction. Put another way, one of the key drivers in a lot of software innovation is the desire to abstract a design, feature, or function for increased extensibility and/or manageability. So if the novel and non-obvious contribution made by a software developer is the abstraction itself (embodied in a computer), how does a patent examiner or a court determine the "appropriate level of abstraction?"
While I haven't had the time to consider the answer myself, I suspect the answer might add some complexity to Lemley's otherwise straightforward proposal. Maybe we can't change the weather, but the open source community can surely be part of the software patent solution.
34 Comments