Reasons Why Software Patents Should Die: Part One

Written Description, Enablement, and Best Mode

Are you an engineer who’s repulsed by lawyers talking about software? Maybe you once described your invention to the company lawyer and couldn’t even recognize what came back? This is for you, my primary audience. I’m not a lawyer but I can translate for you.

Conversely, are you a lawyer who practices patent law? Maybe you’re just waiting to pick this article apart as ignorant of the law? You’re the secondary audience. I passed the Patent Bar and spent three years in Google’s Patent Litigation department. I know how patent law works. Bring it on.

Overall Conclusion

The US Congress needs to declare that software is obvious and not patentable subject matter. We cannot rely on lawyers and judges to solve this problem. They’ve already failed.

For a long time, the CLS Bank case at the Supreme Court was the shining hope for accomplishing this. I myself wrote an article which was cited in an amicus brief for that case.

Most articles or social media posts on this subject fall into one of two categories:

1. Engineers ranting.

2. Lawyers taking for granted that software should be patentable, but maybe just one more decision from SCOTUS or CAFC will solve the problems there still are, once and for all.

I’d like to quote Nessim Nicholas Taleb from Skin In The Game:

People who are bred, selected, and compensated to find complicated solutions do not have the incentive to implement simplified ones.

With that said:

The law is wrong. Engineers know it, and they will have to take the political system in their hands and force it to recognize reality. Lawyers and judges will never do it. Corporation management will never do it. Even the professional societies (ACM, IEEE) will never do it.

Patents are authorized in the Constitution, Article I, Section 8, Clause 8:

[The Congress shall have Power . . . ] To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.

You can read the US Patent Office’s general explanation here. Ask yourself: does the patent system “promote the Progress of Science and useful Arts” for software?

There are three forms of legally-protected intellectual property: patents, copyrights, and trademarks. I won’t go into any detail on those, except to note that unschooled people often say “Can I get a patent on the idea for… ?”

Any lawyer will stop you right there. You don’t patent ideas; you patent inventions. But now we get into some interesting legal territory: the law says you have to “reduce to practice” your invention. There are two forms of reduction to practice:

1. Actual Reduction to Practice (ARP): you actually built the thing.

2. Constructive Reduction to Practice (CRP): you describe it in sufficient detail that a Person of Ordinary Skill in the Art (POSITA) could build it, with a “reasonable amount of experimentation.” The classical example of “reasonable experimentation” is a lab assistant in a chemistry lab, who determines the exact sequence and amounts of chemicals to add, the heat to be applied, the pressures, etc.

We will come back to what CRP means in software. Here’s what your specification is supposed to do: explain to the public how to build it, like this guy is doing

(Generated by Dall-E, the AI program)

If we’re going to talk about whether software should be patentable at all, we have to consider what the laws passed by Congress actually say about patentability:

In the language of the statute, any person who “invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent,” subject to the conditions and requirements of the law. The word “process” is defined by law as a process, act, or method, and primarily includes industrial or technical processes. The term “machine” used in the statute needs no explanation. The term “manufacture” refers to articles that are made, and includes all manufactured articles. The term “composition of matter” relates to chemical compositions and may include mixtures of ingredients as well as new chemical compounds. These classes of subject matter taken together include practically everything that is made by man and the processes for making the products.

…

Interpretations of the statute by the courts have defined the limits of the field of subject matter that can be patented, thus it has been held that the laws of nature, physical phenomena, and abstract ideas are not patentable subject matter.

Nearly all of this language predates the computer era. There is no notion of an invention being “information;” it’s always a thing. This has caused endless semantic debates in legal circles: if you put your software on a machine, isn’t that hardware-and-software-together a thing?

That’s led some judges to say, “no, just because you add ‘on a computer’ to a software claim, that doesn’t make it a hardware claim.” But the legal system has struggled to define what does make it patentable.

So what does it all mean? Should software be patentable at all? Prior to 1982, it was not; it was considered an “abstract idea.” Consider this example if you have a strong opinion on the subject:

• In 1950, you invented an improved fuel injector for a V-6 engine that combined air and fuel in a particularly novel and useful way, using an ingenious system of hoses, vacuums, heat-sensitive metals, and pressure-sensitive containers.

• In 1998, you invented an improved fuel injector for a V-6 engine that used an embedded microprocessor to do the same functions, but mainly in software.

So why should the first be patentable, but not the second?

Since 1982, software has been considered patentable. That’s why I had a job dealing with lawsuits over it.

Does CRP Mean “Crap”? Written Description and Enablement

I mentioned “Constructive Reduction to Practice” a while ago. Now let’s look at that with respect to software:

The theory behind CRP is, the “scientist” who conceived of the invention uses lab assistants for the tedious work of carrying out his invention: wiring up the prototype, titrating the solutions, buffering the medication appropriately so it can be pill-sized and not microscopic, whatever. Those are not essential to the “invention.”

(Generated by Dall-E, the AI program)

The relevant law 35 U.S. Code § 112 is given here. Lawyers’ shorthand for this is “written description,” “enablement,” and “best mode," or often just “112.”

Here are some relevant excerpts:

The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.

…

An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.

Is there an analog in software for the “trained scientist who entrusts the messy details of his ‘invention’ to the underlings?” And is the source code just a “messy detail?” Some judges and people in marketing would think so. Here’s a diagram from an actual patent belonging to Facebook / Meta. This is an example of what the courts have said counts as “disclosure”:

Do you think an average “coder” could just take this and write the code?

Almost no software engineer does. The code, on the other hand, does prove you “have” the invention. The inventive concept counts for nothing. Everyone in the profession has seen a product manager’s “concept” of a system (often called the “requirements document”), which bears only a vague resemblance, or no resemblance, to what’s actually shipped.

But the lawyers’ opinion of that is, at best, bemusement at our naiveté. When courts have determined the “structure” required to provide a written description of a software invention, they’ve usually said that flowcharts or textual descriptions are enough. The actual source code is something that a less skilled programmer can produce given the proper direction.

How shall I put this? This is something that only lawyers, judges, or out-of-touch executives would ever think of. No one who has ever worked in the industry would subscribe to it. Brilliant concepts are a dime a dozen.

Some Legal Homework

I can read legal opinions, on patents at least. So could you, the non-lawyer, but as I like to put it, “I read them so you don’t have to.”

So if you’re reading this and you’re a lawyer: I’ve got my citations. You can correct me if I’ve misused them. I’m not writing this for you, though; I’m writing it for engineers, i.e. the Persons of Ordinary Skill in the Art.

The disclosure of source code in software patents: Should software patents be open source (Columbia Law Review)

Article

Vas-Cath Inc. v. Mahurkar, 935 F.2d 1555 (Fed. Cir. 1991)

This is an often-cited case. A patentee claimed priority to a design patent, which contained only diagrams.

112 contains at least two separate requirements: “written description” and “enablement.” In Vas-Cath, the court affirmed that they’re separate. We’ll come to enablement.

the applicant must also convey with reasonable clarity to those skilled in the art that, as of the filing date … he or she was in possession of the invention. The invention is, for purposes of the "written description" inquiry, whatever is now claimed.

We agree with the district court's conclusion that drawings alone may be sufficient to provide the "written description of the invention" required by § 112, first paragraph.

Another case: Northern Telecom, 908 F.2d 931 (Fed. Cir. 1990)

This case was suggested to me by a well-known law professor. The inflammatory part of the appellate opinion (which I’ll explain in more detail below) is:

In assessing any computer-related invention, it must be remembered that the programming is done in a computer language. The computer language is not a conjuration of some black art, it is simply a highly structured language.... [T]he conversion of a complete thought (as expressed in English and mathematics, i.e. the known input, the desired output, the mathematical expressions needed and the methods of using those expressions) into a language a machine understands is necessarily a mere clerical function to a skilled programmer. [emphasis mine]

This case was about a patent originally filed in 1971 (long since expired)! You have to realize when reading this archaic terminology: things were different then. If you read the patent, it is strictly about using a device to input data without involving “the computer” (at the time, “the computer” was a big mainframe, so being able to input and check data without its involvement was a big deal). That was what DataPoint was accused of infringing.

Fifty years later, what they’re arguing about actually does seem like a mere clerical function! That’s only because computers and their programmers have gotten so much more sophisticated in the ensuing years. The judge was picturing something like “y = x ^^ 2 + 3x + 2” as the “mathematical expression” and saying, “Hey, you can just type that into FORTRAN or COBOL and the compiler will take care of it.”

Needless to say, while it may have been true then for a mathematical expression like that, the sorts of things programmers do today are definitely not clerical functions. But as a precedent that other judges can cite, there it is.

Where It’s At Today

Computers and communications account for a huge proportion of patents filed. This is for 2020:

If you add up “computer technology” and “digital communications,” you have 95,000 patents, per year. Some of those will end up in the hands of Non-Practicing Entities, better known as “patent trolls,” who will sue high-tech companies that actually build things.

Source code is necessary

I’m going to be blunt here. Lawyers are 100% certain that source code will never, and should never be, required for a software patent. I often had this discussion with lawyers at Google. They are wrong. They are looking at what the law says and judges have interpreted it to mean. I will grant that maybe they’re right about what it says, but “the law” ultimately comes from Congress and the Constitution. The law can be changed for good reasons, no matter how political (as long as SCOTUS determines that the new law is constitutional).

The way you share a software invention is, you check it into GitHub or other public repository.

Other engineers download it, build it, and give feedback. If it doesn’t build given your instructions, or fails simple tests, they will tell you, “Your software doesn’t work.” This is exactly what the PTO examiner would do. Believe it or not, many of the examiners in software have Computer Science backgrounds and are perfectly capable of this. It is not black magic anymore.

I can hear the anguished cries now: “But that would mean anyone can just download and run it!”

Exactly. That’s what it means to “disclose an invention.” But you’ll still have a legal right to prevent anyone from stealing it, right? Isn’t that good enough?

This was only slightly sarcastic. You’re probably thinking, “Right. Everyone’s using my software, so what was the point of getting the patent?” But “constructive reduction to practice” is supposed to mean exactly that: any ordinary coder could produce the invention, given the description! That means you were already doing that by publishing your patent, which happens 18 months after you file it. Was that not correct?

Of course it wasn’t. Here’s an experiment: let’s get some software patents, hire some POSITA’s, and have them try to create the inventions described there. Let’s see how many can do it, and how similar each of the resulting “inventions” are.

The legal rule that the code is just a detail that anyone of ordinary skill in the art can provide is just plain wrong.

What would be “reasonable experimentation”?

You’re probably thinking, “OK, there must be some coding that really is just a detail, which any ordinary programmer can handle, right?”

Yes, there are some “mechanical” changes. Here are a few:

• Updating the software for a new version of included libraries. Usually this is mechanical, but not if the library changed a lot.

• Configuring it to run in a different cloud environment.

• Updating from Python 2 to 3. Again, this is tedious but not usually an invention in itself.

• Porting to an operating system that’s fairly similar, e.g. from BSD Unix to Linux.

Are you thinking now, “How is a judge ever supposed to decide this stuff, let alone a jury?” I would turn that around and ask, “If you don’t understand the technology, how can you regulate it?”

It’s normal in the law to use experts to back up or contradict your position on a question of fact. Judges and juries don’t understand chemical engineering or microprocessor chips, either, but they manage to decide somehow. Software is not any different.

What’s the End Result?

Suppose that all Congress managed to do was to amend 35 U.S. Code § 112 to say that source code for all software patents shall be checked into a public repository. This could be decided judicially, I suppose, but my preference is that it’s done the old-fashioned way: by an Act of Congress.

What would be the result?

• The number of software patent applications would plummet. That would happen because (1) the applicants don’t want to disclose their invention, or (2) they are not really in possession of the invention, as the law requires. This is not a disaster; it’s patent law working as intended.

• Copyright law would have to evolve to clarify what constitutes an “insignificant change” and what is a “derivative work” with software. A derivative work would be porting from Windows to MacOS; the original copyright holder would have rights to that as well. Contrary what enemies of copyright have alleged, simply changing all the variable names is an insignificant change and does not avoid copyright.

• Copyright terms for software would have to shorten, drastically, maybe to five years. These are notoriously too long already for artistic works.

This will be explored in another post. I’m exploring the notion of a modern regime of IP protection for software, which would be loosely based on copyright. “Derivative work” law would explicitly contain “taking the algorithm and reimplementing it.” Feel free to contribute Comments on that.