But others disagree: Judith Szepesi argues that this "stopgap measure" would not prevent patentees from "avoid[ing] limiting the claims to specific structures/algorithms" by not using the "magic language" that triggers Lemley's solution, and she also posts a response by Greg Aharonian, who criticizes Lemley for imprecision in defining "computer program" and for singling out software in particular (and not digital hardware or non-computing technologies). Aharonian argues that patentees will use "software engineering tricks" such as "incorporating by reference specific libraries of source code that give [them] broad coverage."
While Lemley's working paper might benefit from defining some terms more precisely, his basic idea is reasonably clear, and I think that some of the criticisms result from misreading his proposal. First, I don't think he is suggesting a "magic language" approach where he is simply expanding the triggering language for § 112(f) (previously § 112 ¶ 6); rather, his point is that courts should not apply a formalistic approach to determining when "means for" analysis applies (see p. 40 of the current 7/26/12 draft). Second, in response to Aharonian's "why target software" critique, I think Lemley would respond that patentees should never be allowed to claim broad functions without limiting algorithms, but that this is only a particular problem now for software claims (e.g., on pp. 54-55 he rebuts the argument "that software ought to be different"). And third, Lemley seems to have no problem with the idea of incorporating libraries of existing code by reference for standard functions; for example, see this passage on p. 54:
Standard computing elements are precisely the sort of things that ought to be written in means-plus-function language. The fact that it doesn’t matter what database I use in my encryption program – that for my purposes they are all equivalent – will mean that the claim elements not located at the point of novelty will be entitled to broad construction. It is precisely at the point of novelty that the patentee should be forbidden from substituting broad functional language for an actual implementation of the invention. I should be able to include "an analog-to-digital converter" in my claim if ADCs are well-known in the art and not the focus of my invention, but if I am the first person to have invented a way of converting data from analog to digital format I shouldn't be allowed simply to claim "an analog-to-digital converter" without any limitation as to how the invention works.As I understand Lemley's argument, if you were the first person to develop the quicksort algorithm, and you disclosed the details of the algorithm in code or pseudocode, you should be allowed to claim the quicksort algorithm (including in other languages)—but you could not claim "sorting" in general, and your claim would not be infringed by someone using mergesort. If instead your invention is allowing Internet shoppers to sort products by relevance, you may use functional claiming for the "sorting" part of your claim (because algorithms like quicksort and mergesort are well known in the art), but you must disclose your specific algorithm for defining the relevance factor that is being sorted—you may not claim "sorting by relevance" in general. (It might be helpful if Lemley included some specific examples like this—either made-up or from actual cases—to make his idea more concrete.)
As Tan described yesterday, one issue is that it is not entirely clear how the "and equivalents thereof" language of 112(f) should be interpreted. Lemley argues at pp. 46-49 that 112(f) equivalents of software claims should be read narrowly and "limited to the technology the patentee actually designed and equivalents known at the time the patent issued." I think it would be helpful to explain what this means. If an infringer creates a new programming language to implement the patented algorithm, is there really a logical basis for excluding this from the claim scope? A related concern is that many algorithms carrying out the same function with the same complexity might be said to be "equivalent" in the computer science sense of being easily (e.g., polynomial-time) reduced to each other—but I assume Lemley thinks 112(f) software claims should be limited to equivalents in implementation (i.e., the same pseudocode), not equivalents in some mathematical sense.
I'd also like to highlight one aspect of Lemley's proposal that hasn't been discussed so far—he argues that his approach would help with the debate over whether software is patentable:
Treating these functional software patent claims as means-plus-function claims may end up saving them from invalidation under section 101. If the patent is interpreted as a means- plus-function claim, it will be limited to the particular software implementation the patentee actually built or described. Such a narrow, specific claim should not be an unpatentable "abstract idea."It would be interesting if someone familiar with software patents looked at some of the recent software patent eligibility cases (summarized on PatentlyO in a table at the bottom of this post) and discussed how the claims at issue would be interpreted under Lemley's proposal. If overly broad software claims could be either easily invalidated for failing to disclose an algorithm or narrowed based on the disclosed algorithm, would it alleviate the need to rely on the fuzzy "abstract idea" test of 101?
Finally, I'll note that it seems to me that Lemley is is taking ideas that scholars have written about already—more narrowly restricting claim scope to the disclosed invention and the novel idea—and finding a statutory hook to argue that this is the best interpretation of the current patent law. His paper is directly addressed to judges: "The Federal Circuit or the Supreme Court could, with one fell swoop, do away with most of the problem of overclaiming in software patents – and with it, most of the problems with software patents." This is the same kind of move as in one of my favorite recent articles, Abramowicz & Duffy's The Inducement Standard of Patentability, and I think Lemley's paper suffers from the same mild tension between strategic lawyering and normative arguments. But it also makes Lemley's paper more directly helpful for the bar and the courts. Is Lemley's approach the right one for software patents? I don't know—I would want to see more discussion of how it would apply in actual cases. But I think it deserves to be taken seriously and debated on its merits.
No comments:
Post a Comment