This has some of the same material as last week’s post, but I’ve revised it considerably based on feedback from you all. Especially, it’s now more tightly focused on one thing: source code disclosure. Enjoy.

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.

If you’re thinking, “Oh, yeah, I’ve read all this before,” no, you haven’t. There are four main sections of the U.S. statute governing patentability, and you only ever read about the first and third:

  • 101: Patentable subject matter (what you can patent)

  • 102: Anticipation (someone else invented or described it)

  • 103: Obviousness (two or more references, taken together, describe it)

  • 112: Specification (here’s the statute)

Most of what you read is about 101: is software a “thing” or is it a “mathematical formula” and thus not patentable? Maybe sometimes people discuss 103: is it all obvious? Let’s ignore those for now. Let’s talk about “specification,” the sleeper in the bunch.

If you’re an engineer and someone says they’ve invented something, very likely you would say, “Let’s see the code. Is it on GitHub?” Maybe there’s a paper in an ACM or IEEE journal, which had to pass peer review and follows a prescribed format?

But no, software patent “specifications” don’t have any of that. This article explains why that is, and why they should.

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.

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)

I mentioned “Constructive Reduction to Practice.” Now let’s look at that with respect to software. You can find some patents with extensive source listings appended to them, just like some biological patents have large DNA sequences. Source code is totally legal and does add credibility to your patent, especially if you ever assert it against an infringer. However, the code is not examined, and there’s no requirement that you include it.

The theory behind CRP in general 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)

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 a part of what the courts have said counts as “disclosure”:

I should note here that there are other diagrams and text in this patent, but there are no requirements governing disclosure like that. You would imagine that the Association for Computing Machinery (ACM) or some professional association would have been consulted as to what constitutes a design specification, but you’d be wrong.

Do you think an average “coder” could just take this patent and write the code? Let’s consider that hypothetical person. A “Person of Ordinary Skill in the Art” is not rigorously defined anywhere. I’ve seen patent litigation where both sides agree on what that is, but a patent does not have to tell you. The cases I’ve seen said, “a Bachelor’s degree or equivalent, and two years of industry experience.”

Almost no software engineer thinks that’s reasonable. 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)


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, it actually does seem like a mere clerical function! That’s only because computers and 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, it is still valid.

Who’s Filing Patents

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.

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

CRP is supposed to allow for “reasonable experimentation” and not require explicit statements of what is generally known. It does not allow for a requirement to make more inventions.

Some “reasonable experimentation”

There are indeed 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.

Once you’ve disclosed the source and how to build it, is your patent limited to that version of that operating system with those libraries and those build tools? No, because those changes are reasonable experimentation.

Some not “reasonable experimentation”

Now let’s look at a patent that I covered in my SSRN paper: Automatic discovery of network elements. It describes a way of querying TCP nodes via SNMP to find all the nodes on the network.

The first claim, though, says nothing about TCP:

1. A computer network node discovery process for determining nodes connected to a computer network, said process comprising the steps of:

(a) obtaining, from one node of a set of known nodes on said computer network, a list of addresses of one or more other nodes with which said one node communicates comprising the steps of …

Claim 3 does limit it to TCP.

So this means that claim 1 covers networks running SNA, Novell Netware, DECNet, OSI, and any other non-TCP network, even those that don’t support SNMP.

Adapting this claim to cover those protocols is not reasonable experimentation (if it’s even possible).

What’s the Conclusion?

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 a 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.

Try to imagine Congress sitting down and deciding what to do about software patents. I’ll wait.

Pretty tough, wasn’t it? Lawyers and politicians don’t want to solve a problem; they want to make a living from it. Lawyers want to add it to their practice areas, and politicians want to raise campaign funds from it. Solving it would defeat the purpose.

But what if we picked a smaller issue? 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.

One of the most common questions on Quora’s patent forums is “how can I get a patent without giving away my secrets?

The answer is: you can’t. That’s the bargain you make with the government: you get a limited monopoly in exchange for giving your invention to the public. If you don’t want to do that, keep it a trade secret, like Coca-Cola’s formula.

Note that this would not mean that you’ve only patented your source code, and someone could change a few things and avoid your patent. That would be “copyright” and you have a patent.

In this “easy first step” law, a patent would still have claims, and an infringer would not need to copy your code to infringe. In other words, your legal rights would not change.

What would change, though, is that you’d be living up to Section 112 of the patent statute, by describing your invention.

Read More