A response to Professor Lemley’s Paper on Functional Claiming to Limit 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.
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
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
    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
    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
Indeed, you can reduce Lemley’s 57 pages to:
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
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
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
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,
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.

6 thoughts on “A response to Professor Lemley’s Paper on Functional Claiming to Limit Software Patents”

  1. Hello, Neat post. There is an issue with your web site in web explorer, might check this? IE still is the marketplace leader and a large part of other people will pass over your fantastic writing due to this problem.

  2. I simply want to mention I am very new to blogging and certainly enjoyed this website. Very likely I’m planning to bookmark your blog . You definitely come with terrific stories. Thanks a bunch for sharing with us your webpage.

  3. It was excited to come across your site a short while ago. I arrived here today hoping to learn interesting things. I was not upset. Your well thought out ideas with new strategies on this subject matter were enlightening and a great help to me. Thank you for making time to create these things and for sharing your mind.

Comments are closed.