How to Read a Software Patent

[The article below originally appeared in another publication -- I think I wrote it about 10 years ago. I've made some updates and decided to republish here. I've omitted the original introductory texts that explained the differences between patents, copyrights and trade secret protection -- I think that's pretty well understood these days.]

Background

Puppies help when dealing with patents.

This post describes what I've learned during "patent reviews" -- times when I've been approached to advise on the likelihood that a system we're developing infringes on a specific patent, or to assist with a patent search to look for "potentially infringed" patents.

The monopoly power conferred by a patent, the embarrassingly low standards of novelty applied by the US Patent Office, and the enormous cost of defending litigation has made patents an extremely attractive business tactic to harass or shut down competitors. It used to be the case that I would advise development teams to undertake a patent search to assess the need to "invent around" potential patent complications. However this is no longer good advice: 

• Many patents in the field are maddeningly obvious. It soon becomes clear to anyone researching a particular technology for applicable patents that far too many software patents offer nothing more than an obvious, incremental adaptation of well known software techniques or algorithms. The worst of them do not even do that.
• Software patents are poorly written, at least from a technical perspective. It is difficult to understand the technical architecture that the patent is trying to describe (in fact, I personally think this is a deliberate obfuscation strategy).
• Patents take effect from the date of filing – however they do not become public until after the patent is granted. For example, US Patent 5,960,411 (Amazon’s infamous “One-Click ordering” patent) was filed in September 1997, but was not made public until two years later. This poses a problem because, at the time of an architectural review, a designer cannot be confident that they have covered all applicable patents. As the volume of patent applications increases the lag time between initial filing and final public notification is stretching to many years.

So it's doubtful whether a patent search is an economically sensible choice. Consult your IP lawyers of course. What is more likely to happen now is a business owner becoming aware of an alleged or potential infringement and asking for a opinion on likely exposure. 

Reviewing a Patent

Keep a puppy handy in case of stress

If you've been given a list of patents to review you will need to quickly scan them for relevance. Be careful here. You are sorting the patents into two lists: 

1. The list of "obviously completely irrelevant patents that have no overlap with what we're doing."
2. Or the "pending review" list.

See what we did there? There is only "irrelevant / not infringed" and "considering". You will never, never, write that you think "we might be infringing this one." And you will also put the words "legal in confidence" on your emails. But your lawyer will tell you all this I'm sure. :)

You'll notice that all patents have certain standard sections. Care must be taken not to rely on either the patent title, nor the patent abstract. These can be misleading and are more or less irrelevant to a question of infringement. 

As an example, Amazon’s US patent 5,960,411 has as its title:

Method and system for placing a purchase order via a communications network

So yes, the title indicates a patent that potentially covers every system of trade in the world. From the point of view of clarity, the abstract is little better:

A method and system for placing an order to purchase an item via the Internet. The order is placed by a purchaser at a client system and received by a server system. The server system receives purchaser information including identification of the purchaser, payment information, and shipment information from the client system. The server system then assigns a client identifier to the client system and associates the assigned client identifier with the received purhcaser information. The server system sends to the client system the assigned client identifier and an HTML document identifying the item and including an order button. The client system receives and stores the assigned client identifier and receives and displayes the HTML document. In response to the selection of the order button, the client system sends to the server system a request to purchase the identified item. The server system receives the request and combines the purchaser information associated with the client identifier of the client system to generate an order to purchase the item in accordance with the billing and shipment information whereby the purchaser effects the ordering of the product by selection of the order button.

I still get headaches when I read that.

What matters in a patent application is the section titled Claims. The abstract and the title have little legal significance beyond shedding light on the claims. Note that in this case (and many others), neither the title nor the abstract accurately capture the essential nature of Amazon.com’s patent: that the ordering process can be completed in one step (hence “One-click ordering”). 

Bear in mind when reading a patent abstract that it was not necessarily drafted by someone with any technical knowledge. Or, for that matter, actual writing skills.

Analysing the Claims

This is a Four-Puppy-Job

Having discarded the obviously irrelevant patents you will next need to work with the patent lawyer to analyse the remainder a little more closely. The outcome of your analysis will be either:

1. The patent is not relevant because your software system can be distinguished from what the patent claims for its own. For example "our system always requires two clicks to purchase so this Amazon one-click patent isn't relevant."
2. The patent might be relevant, but some changes can be made to make your system obviously quite different (for example, by adding that second click).
3. The patent might be relevant. There's no easy way to make it clear that it's not. You might feel that the patent is so obvious that it should never have been granted in the first place. You'll probably be right. It won't matter though -- you'll ultimately decide what to do based on business tactics.

To arrive at the conclusions above you will be concentrating on the section titled Claims. The other sections (for example "Description") can be important (primarily as an aid to a court in interpreting the claims) -- but focus primarily on the claims.

The claims usually take the form of one or more "base" claims which cover the inventive steps. These are then supplemented by zero or more additional claims, which "inherit" from the base claim and then aim to extend and target the claims. Usually, the addition is an application of the base claim using certain specified technologies.

The Amazon patent used earlier is a good example:

1. A method of placing an order for an item comprising:
   • under control of a client system
   • displaying information identifying the item; and
   • in response to only a single action being performed, sending a request to order the item along with an identifier of a purchaser of the item to a server system;
   • under control of a single-action ordering component of the server system;
   • receiving the request;
   • retrieving additional information previously stored for the purchaser identified by the identifier in the received request; and
   • generating an order to purchase the requested item for the purchaser identified by the identifier in the received request using the retrieved additional information; and
   • fulfilling the generated order to complete purchase of the item
   • whereby the item is ordered without using a shopping cart ordering model.
2. The method of claim 1 wherein displaying of information includes displaying information indicating the single action.
3. The method of claim 1 wherein the single action is clicking a button.

[etc...]

Claims 4 –5 are also a “method of claim 1”. Claim 6 is a base claim that attempts to restate claim 1 in a wider, more generic manner and incorporates a “shopping cart ordering component.” Claims 9 and 11 are also base claims, with claims 12 to 26 being derivative of claim 11 – the widest, and most generic claim. (Note: After being granted in September 1999 there was a period of over 10 years during which the patent was challenged and re-examined.)

For the treatment of  extra-patent stress, add one kitty.

This is typical of most patent applications. If a court rules, for example, that claim 11 contains no inventive step, then claims 1, 6 or 9 (or their derivatives) may still be used to pursue an infringer. The patent application will go for an intellectual property “land grab”, attempting to have as wide and as generic an application as possible, to make it more difficult to invent around the patent or distinguish any of the claims.

The language itself will also be a barrier to understanding. The Amazon patent example I'm using is comparatively lucid. Others appear to be deliberately designed to be impossible to understand.

When conducting your analysis you will naturally focus on the base claims, since if you can distinguish your invention from each of these then the other, derivative claims will be automatically disqualified. It’s also common for each of the base claims to have some common element – get around the common element and you can get around the entire patent.

In the example used in this tutorial, Amazon.com’s common element is to respond to an order with only a single action being performed. This is the inventive step repeated in claims 6, 9 and 11. Putting to one side the argument about wether or not this is actually inventive you can see that by simply adding a second required action you can distinguish (that is, invent around) the patent. This is exactly what Barnes and Noble did when they were sued by Amazon.com in 1999.

Conclusion

I'm sorry for that past advice.

The original version of this essay concluded thus:

Irrespective of the debate over the legal merits of software patents, they are a reality that must be dealt with in the design and construction of any software system. This is particularly true in e-commerce, a highly valued area where competitors seek to raise the barriers to entry through prolific patenting.

A patent search should be conducted early in the design phases, and conducted a second time prior to launch to catch any additional patents and to double check architectural decisions. For the patent analysis to be conducted properly, it is important that it is conducted by a patent lawyer or intellectual property specialist.

I have to say now that this is rubbish. The volume of patents, the excessive lag between filing dates and public disclosure, and the uninspiring performance of patent examiners the world over have simply made this approach uneconomical.

In the meantime, if you're ever asked to provide an opinion on a patent, cut to the chase and look at the claims. Focus on the root claims first to find the cheapest argument out of there. If actual cease-and-desist letters are being sent though, call in the lawyers.