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.

 

        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.