A response to Professor Lemley's Paper on Functional Claiming to ...

September 14th, 2012 | Academic Perspectives, Software Patents

Professor Lemley has posted a paper suggesting that if we more strictly enforced 35 USC 112(f), the interpretation of means for language, then much of the problem with software patents would be eliminated.

His paper can be found here: ?Software patents and the return of functional claiming.

His basic argument is that most software claims are means-for claims, because they use the phrasing ?a computer system programmed to.? ?Means-for claims are construed to only ?cover the corresponding?structure, material or acts described in the specification and equivalents thereof.? ?The courts have interpreted means-for equivalents narrowly. ?Professor Lemley hopes to require the inclusion of algorithm/code/pseudocode in the Specification, and have the claim scope be limited to that code, and its equivalents.

Of course, this would likely invalidate most existing software patents which do not include algorithms. ?It would also lead to an immediate change in claim formats, to avoid the language which was interpreted to trigger the ?means for? type analysis. ?In this, Professor Lemley appears to take a ?magic language? based approach to a problem that is not the result of poor language choices. ?The primary problems with software patents are lack of rigorous prior art searching and the incredible expense of responding to even an unreasonable lawsuit. Even if Professor Lemley?s interpretation were adopted by the courts, it would be a stopgap measure, until patent owners could rephrase their claims to once again avoid limiting the claims to the specific structures/algorithms described in the Specification.

Greg Aharonian, a?perennial?critic of the patent system, does not agree with Professor Lemley?s thesis, and takes apart his argument in some detail. ?He has given me permission to post his response here. Be aware, he uses quite colorful language.

Lemley attacks the Federal Circuit, which rigorously applies 112(f) if your claim uses ?means for?, but won?t rigorously apply 112(f) if your claim uses ?computer programmed to? ? one reason why patent prosecutors no longer draft ?means for? claims.??Lemley argues that this is legal nonsense, since an algorithmic method requires a programmed computer, so the phrase is no more limiting than ?means for? (true, but doesn?t resolve anything). ? So Lemley argues that the CAFC should be as strict with ?programmed to? as it is with ?means for? ? that applicants should be forced to disclose actual algorithms in their specifications (obviously, IBM is not backing Lemley?s research). ? He concludes (page 43): ? ????????The patent claim should accordingly be limited to that particular computer program and ones that work in the ????????same way to achieve the same result. ? Which is a statement reflecting no knowledge of software engineering in its ill-specified use of ?computer program?. ? What follows is multiple legal/engineering critiques of Lemley?s suggestion (trite in that across all fields of technology, many want the CAFC to clean up 112 case law, starting with the unconstitutional Markman practice). Lemley suffers from the same weakness of another Stanford Law person ? Larry Lessig - writing on law and science/engineering without understanding the science and engineering.??Which is an insult to Stanford Engineering. ? ????????LEMLEY?s CALL FOR MORE SPECIFICATION OF COMPUTER PROGRAMS IS ????????A CALL THAT NEEDS MORE SPECIFICATION ? The first engineering/semantic defect of his paper is that he doesn?t define ?computer? nor ?computer program?.??He has kind of a 1980s view of computer and programs ? 100 line of Basic running on a personal computer ? something that can be clearly specified in a specification. ? But, for example, consider a collection of statements written in VHDL. I can signify that as a computer program, because with a VHDL-to-Java compiler, I can run the VHDL statements on a computer with a Java virtual machine. ? But I can also signify that collection as a computer, because I can run the VHDL through a VHDL-to-Netlist language, and burn some gate arrays with the netlist to create a computer.??And do I mean one computer throughout the patented computing process? Or many???That is, there exist software-restructurable computers that have computer architectures that can change at a machine cycle with software instructions.??And what is a computer?s microprogramming code???Hardware specification, or part of the software operating system???So when Lemley writes at the top of page 16: ? The hardware ?structure? of a computer software invention is ? a computer. ? Not only does he admit he doesn?t understand hardware and software, by using the quoted ?structure? (in Europe, the phrase is ?as such?), but also, in many cases, this statement is false, especially if you think about distributed computing and virtual machines.??He is drawing boundaries where none exist because he doesn?t understand the engineering.??His use of ?structure? is completely hypocritical because it is no different than the means clauses he attacks ? a shorthand term for something he can?t, or doesn?t want to, specify. ? So, if you show me some VHDL statements, I can?t tell if you are signifying a computer program, a computer, some computers, some computer programs, or what.??It all depends on how you define all of these terms, and Lemley, following in the unethical precedent of Benson/Bilgslki, doesn?t define any of these terms.??Maybe these concepts are ?obviously? too ?abstract? for ?law professor? Lemley, which in the patent world, I admit, is a meaningless sentence without definitions.??So, where I can?t define, I ?quote?. ? ????Greg note: indeed, the more general specification problem, which ????plagues all areas of technology, is the unconstitutional need for ????Markman claim construction hearings.??You don?t need to construct ????what was clearly specified in the specification, a 112 defect ????NOT ONLY of software patents.??Lemley?s ?solution? is deceitful ????in not recognizing this larger 112 problem. ? And assuming he has any idea of what he means by ?computer?, what does he mean by ?computer program????A compile-time-instantiated client-side program (of 100 lines of Basic), a partially run-time instantiated client/server program using library RPCs, a self-evolving genetic algorithm program???What does he mean? ? And by ?computer program?, does he mean ?data structure? as well, since in a variety of languages (such as the entire Lisp/Scheme/functional programming world), there is no difference between algorithms and data structures ? leading to such books as ?Functional data structures?. Indeed, in Lisp, there are functions that convert functions into data structures, and vice versa. ? ????Greg note: it is why Alappat is incomplete without Lowry, and ????more profoundly, both cases together are repetitive. ? And how about programs that comprise functions that take functions as arguments???What is the program?s function???The functions in the program, or the functions passed to the functions???And if I pass a virtual machine, as a function, to a program?s function, is the program a function or a machine, or a functional machine???If I pass a virtual machine to a software runtime-reprogramable ASIC, where is the computer and where is the program, and what?s the function? ? So what does Lemley lamely understand to be a ?computer? and ?computer program????He doesn?t say. ? ??????????????????????WHAT?S YOUR FREQUENCY, MARK? ? So at this point, you can stop reading his paper on requiring software patents to be more specified, because his paper itself is unspecified. ? His paper as a claim ?A method for federal courts to invalidate software patents by rigorously enforcing 112(f)?s requirements for specificity.?, well, the court?s would reject in light of his own claim because his paper, his specification, is very unspecified. ? ????Greg note: Lemley also takes seriously the PTO?s illegal requirement ????that patent applicants accept unenforceable ?non-transient computer ????medium? Beauregard claims.??There is no basis in engineering to ????support ?non-transient?, only the CAFC?s idiotic Nuijten decision. ? Back to Lemley?s paper.??More engineering defects.??Assuming the courts crack down and require more algorithm specification in the spec, the patent drafters will workaround this test as easily as moving from ?means for? to ?programmed to?.??Remember in policy, patent prosecutors and high school programmers are smarter than judges and law professors. ? First, nowhere in his paper does he mention ?incorporation by reference?. ? If I want a broad software ?means for?-like claim, I can circumvent a strict 112 enforcement by incorporating by reference specific libraries of source code that give me broad coverage.??I, Greg Aharonian, will start a business preparing such libraries that people can incorporate by reference.??This brings lots of Lemley-specifity into the specification, without resolving anything.??There are ten thousand software engineering tricks I have at my disposal (none of which Lemley is aware of) to game the system. ? ????Lemley argues his 112 attack just from a legal point of view - ????that patent owners will use just the ?equivalents? language of ????Section 112 to recapture ?means for? scope, without disclosing ????more in the spec.??Nonsense.??They can easily disclose more ????algorithm info in the spec, especially with incorporations by ????reference, and much more acceptably argue ?equivalents? to the ????CAFC. ? ????All you have to do is incorporate bunches of Java libraries, ????and in one paragraph mention a list of Java porting tools, ????and you can mostly capture the genus of the original means ????clause.??All Lemley?s requirement does is lengthen patent ????specification, without doing anything about quality or ????pendency. ? Indeed, you can reduce Lemley?s 57 pages to: ? SOFTWARE PATENTS NEED MORE #INCLUDE STATEEMENTS ? Second, there are countless source code, object code, and executable code transformation tools that allow me to generalize and repurpose a ?particular computer program? in ways that get us back more to broad ?means for claims?.??Again, I can teach how to do so in the spec.??All a patent applicant has to do is make sure to use a patent prosecutor with a good background in software engineering, one who (unlike Lemley) is familiar with such tools and techniques.??Or hire me. ? His ignorance of software engineering is seen at page 50: ? ??????But when the patent seeks to cover, not the implementation ??????of a specific algorithm across different machines, but the ??????implementation of different algorithms that happen to achieve ??????the same end, that patent is too broad. ? Again, if Lemley knew much about patents, he would recognize that this is an old problem across many technologies ? the genus/species problem. I broadly claim a genus of chemicals, but disclose only a few species. ? ??????But when the patent seeks to cover, not the implementation ??????of a specific algorithm across different machines [SPECIES], but the ??????implementation of different algorithms that happen to achieve ??????the same end [GENUS], that patent is too broad. ? Someone invents a new species that achieves a similar end, a species I did not claim in my patent.??But I still sue with the genus claim. Should I be able to, or not???This ain?t a new problem.??And his ain?t a new solution, except he likes to bully software patents. ? And he certainly can?t mean ?same? in his arguments ? that nonsense doesn?t even work in the copyright world, where you can get protection for derivatives.??In reading Lemley?s paper, I kept on thinking that he originally wrote a software copyright paper, and then accidentally did a search/replace for ?copyright ?> patent?.??Indeed, chaos theory was born out of the observation that if I run the same data through the same program (for weather prediction), I will usually get different results (to due floating point precision problems with numerical algorithms). ? ????CANT TALK ABOUT SOFTWARE WITHOUT TALKING ABOUT HARDWARE ? Yet another defect with his argument is that he doesn?t apply it to digital hardware patents.??They too have problems with overly broad ?means for? like claiming.??When you have a new digital circuit with millions of gates, you aren?t going to disclose a specific circuit structure, but rather generalize it into COTS blocks that are stitched together. ? For example, Qualcomm just was granted yet another Fast Fourier Transform twiddle patent: ? Fast Fourier Transform twiddle multiplication U.S. Patent 8,266,196 ? Now, lots of blocks are being used, as it should be ? all I care about is Qualcomm?s new twiddle, don?t need to see obvious circuitry.??And I can as easily have written this as software patent ? indeed, if you read claim 1, you can?t tell if it is for hardware or software, not that that matters, since most likely Qualcomm did the design using a representation language such as VHDL or SystemC (which can be used to automatically generate hardware or software), and left it to its manufacturing people to fight out how much to put into software and how much to put into hardware. ? So Lemley?s advice, is trite where it isn?t defeatable.??It is trite in that across all areas of technology, many (see Bilgski briefs) have argued for stronger enforcement of 112 (and 102/103 to eliminate 101).??Again, ? THERE IS NOTHING HOLY ABOUT SOFTWARE ? to be so criticized/attacked without treating other areas of technology patenting that have the same genus/species problem that Lemley is whining about.??Yes, there is a genus problem.??No, it isn?t specific to software. And restricted just to software, it is defeatable (in the sense of drafting patents) if you know anything about software engineering. ? And it is unnecessary.??The patent quality problem for decades has been incompetent patent office managements unable to provide examiners with the tools and resources to find prior art to easily kill all patents, not just software, under 102 or 103. ? 112 arguments are an implicit defense of incompetent patent office management, something Lemley has done for too long (for those of you who remember his role in the continuation rules package nonsense that cost all of us together hundreds of millions of dollars ? with Lemley spearheading academic efforts to give PTO management more authority to implement a solution (the continuation rules package) that even the PTO admitted at the time would achieve nothing). ? Software is just another area of technology that patent offices don?t know how to provide the time, tools and resources to examiners so that they can do the jobs they want to do.??Any solution to patent pendency and quality that picks on just certain areas of patenting ? with or without balkanization proposals ? is engineering philosophy and management nonsense.??But sadly, genius in law schools.

Source: http://blog.hiplegal.com/2012/09/aharonian-on-lemley/

martin luther king jr i have a dream speech packers score ricky gervais napoleon dynamite michelle williams the descendants the descendants