Software Patents, or, How to Make a Hamburger (Software Patents part 2)

I used to be a burger chef a long time ago. We made big, glorious burgers, works of art. We also assembled beef sandwiches, grilled chicken breasts, patty melts, and short ribs. Lots of fries & salads too. I worked in a busy restaurant which was just down the hill from a popular ski area and at the end of the day we would be packed for five solid hours. It was a small place, and when you are cranking out 500 dinners in five hours, movements must be efficient. The two cooks worked together, hot side and cold side, to whip together a tableful of hot food, mate each item with salad or fries, and get it all up while the sandwiches were hot and fresh. The job was all about speed and coordination.

To assemble a tableful of sandwiches quickly and efficiently takes a method. This is where we get into software and patents. The creation of a burger is remarkably like the structure of a software algorithm. For example, creating a graph from data requires a number of steps. There are as many ways to create a graph as there are ways to make a burger. And that is actually a helpful way to illustrate the process.

Say I work out a method with my old pal Ed where he’ll slap down the buns when I give him the 30-second mark on the patties. Ed lays out pickles while I get the next order’s meat on the grill and drop some fries. While he’s layering tomatoes on top of the pickles I’ll grab the lettuce and rip off a layer for each burger. Then as I turn to load up the spatula with patties, Ed smears sauce on the top of the buns and grabs a wrapper. As soon as I’m sliding on a patty, Ed is starting to wrap. Patties dropped, I turn, pull the fries dropped at the previous cycle, dump them into the tray and reload the basket. I turn back and help wrap the last burger. Ed now reads the next ticket and sets buns on the flat grill to toast while I load the plates with fries and set them up for the wait staff. Ed then starts salads for the next order while I flip the patties I put on previously. It starts again and repeats until all our ‘input’ (the incoming orders) is processed – just like a piece of software.

If we outlined the method, we would have something like this:

Fries loading +2 cycles

Meat loading +1.5 cycles

Bun loading +1 cycle

Start salad, flip burgers. Lay out buns, load burgers, wrap and serve.

If this procedure was being defined for use in a restaurant, I’d be free to tell anyone I want about our method, and they could copy us, and the world would be a better place. Other restaurants using our method would not take away our clientele. Maybe by using this process they’d improve and perhaps have a few more clients but if their ingredients were not as good, or their staff not as motivated and friendly as ours, they’d make little impact on our business.

However, rules for protecting software in the modern patent system is quite different. I could write down the above method with a few diagrams, spend a few thousand dollars on patent attorneys and get a patent for that ‘way of making hamburgers.’ Doing this would prevent anyone else from performing their actions in the same manner. I could get an injunction against anyone who tried to follow my pattern using those actions. The pattern of data and action is enshrined in the patent and thus protected for seven years.

Note that I am not patenting the set of ingredients, nor the final product. In fact, other folks are free to make a ‘hamburger,’ so long as they do not follow the steps in the way I have patented. They would have to use a ‘workaround,’ as we call it in the industry. And that really is what a software patent is all about. You take some inputs, which anyone could start with, and define steps for how you would go about arranging the information into a result that anyone would agree was the sensible result. However, you own the path between.

The question is, does a simple set of steps like my hamburger process really comprise what we think of as an invention? In days of old, the patent office protected things: devices and machines for seven years. An example is the disk harrow (a kind of plough), that was a useful and innovative advance. The way that one used a device, such as a disk harrow, was unrestricted. The rules for software are analogous to someone coming along and telling the farmer, hey, you can use that harrow, but you can’t pull it with a horse. Oh no. You’ll have to push it, because I’ve patented the pull method. Sorry if that doesn’t work out. Can you imagine the stultifying effect on human progress if that had been the case? That is exactly what is happening in the software world.

How long will this situation go on? I’ve been involved in five software patents, and in four of them I was the one who wrote up the proposal, diagrammed it and answered the thousand questions the patent attorney asks. In two of the cases, they have been approved (patents issued), so we know they passed the ‘not obvious’ test: the approach cannot be obvious to an expert in the field. Three more are pending, so their fate is not certain. But given my experience with them, the patent attorneys have a real good idea what will pass. The patent lawyers analyze applications because they do not want to burn all that time over a patent application which will get rejected.

However, for several of these patents, I felt the only reason we’d get them awarded is that we got there first. We had a need that required the methods described, and once someone approached the same requirements from the place we started, there was really only one efficient way to go about the solution. So why bother to patent? The patents were filed defensively; we needed to make sure no one else came along and patented a method we were planning to use in our product. That could be disastrous—no one wants to spend millions to develop a product only to find that someone else has patented the process you are using. That can result in an injunction forcing you to stop selling your version. Although suits are rare in our corner of the industry, we have the perpetuation of the patent-grabbing as a defensive measure. This is a behavior that will continue until the USPO changes its rules.

About H.W. MacNaughton

Technologist and communicator. Into technology, jazz, Formula One, sci-fi and any good writing about real stuff.
This entry was posted in Backstory, Technology and tagged , , . Bookmark the permalink.

1 Response to Software Patents, or, How to Make a Hamburger (Software Patents part 2)

  1. Pingback: Software patents, IP Seizure and the new Middle Ages (Software Patents part 1) | Pat Hayden Jones

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s