PC Blues - News and Views: The patents war

For reasons which entirely escape me, the USA permits software to be patented.

In historical times, enlightened rulers would grant a patent to someone who had invented a new process. This encouraged development. In the dark ages, inventers would keep their process secret, forcing users to come to them, and pay them. The costs of travel stifled progress.

With a patent, the process was made public, and anyone could operate the process so long as they paid the patent holder a fee. This is something like the modern ‘franchise’.

If you consider a piece of software to be a process, in these terms, then it is reasonable to patent software. In olden days, the only processes conceived of were physical, or chemical processes, and it was to these that a patent applied.

A key feature of a patent was that the process was original. If you could show that the process was well known to practitioners of the craft, then you could block the patent. The King was not out to encourage existing processes, only novel ones, ones which made ‘progress’. On the other hand, it was not necessary to show that the process was useful. Whether or not the patent was commercially viable was of no concern to the King.

In the world of software, things are strange to the outsider. To many of the practitioners it is an art or a craft. To software companies, it is a commercial product, and they are in business to make a profit.

I shall describe things from the novel end first - where a new process has definitely come to light.

Some years ago, a cryptography algorithm (RSA) was developed from a deep understanding of features of number theory together with the ability of modern, fast, computers to manipulate the necessary numbers in sufficiently short time. Indeed, the algorithm to do the necessary manipulation of numbers was, itself, a novel method, known as the Fast Fourier Transform.

Here we have several steps. First, the necessary mathematical theory is developed: theorems are proved. Second, algorithms are invented, and (third) implemented on computers. Fourth, the algorithms are brought together in a novel way, to achieve something not expected by a) the mathematicians, or b) the inventors of the algorithms.

Should the mathematicians receive a patent for their theorems? History says ‘No!’.

Should the inventors of the algorithms receive a patent? USA says ‘Yes!’.

There is, in fact, a major step between a theorem and a practical implementation of it. Often, a theorem merely says that something is possible - it gives no indication of practicality. Also, the constraints of a computer, with limited word length, memory and file space, are severe constraints on the implementer. Finally, an efficient algorithm is worth money to the people who use it. An algorithm which enables something to be done in one tenth of the time of another on the same computer, will enable ten times the work to be had from the capital investment that the computer represents. The development of the Fast Fourier Transform algorithm is a case in point. It enabled things to be computed which could not previously have been done in the lifetime of the existing computers! (Implementations of the FFT algorithm are patented. Different implementations are separately patentable.)

If you agree that software should be patentable, then the fourth case (the algorithms are brought together in a novel way) is merely a variant on the third case. Bringing algorithms together is what all software programmers do. All software is larger algorithms built out of smaller algorithms, down to the microcode of the computer processor. The most useful algorithms are supplied along with the compiler/interpreter as run-time libraries.

The RSA algorithm was certainly novel, but an effective implementation relied on the FFT algorithm. Any useful implementation of the RSA algorithm would require an efficient implementation of the FFT algorithm. Any user of the RSA algorithm would therefore have to pay licence to the owners of the RSA patent, and to the owners of the FFT patent (and all subordinate patents!). How this chain of payments is managed is nobody’s business.

For Really Useful Algorithms, the patent system might be appropriate, but in its general form, it is a nightmare.

As a software designer, I put algorithms together in novel ways. In some cases I invent new algorithms. In others I (probably) re-invent old algorithms. What I do NOT know, is which algorithms have been patented. Note that this is very much a commercial decision. If I know of an effective algorithm (to do something my process needs), which is patented, but cheap to licence, I should specify this in preference to a more expensive algorithm. Alternatively, if I know of an effective algorithm which is not patented, I should specify this in preference to one which is licensed.

A second-order commercial feature now appears. What should my company do if I know of, or invent, an algorithm which is not patented. I may take the view that this is what is called ‘prior art’ - any practitioner would know of, or invent, such an algorithm. My company’s patent lawyers may not agree with me, however, and wish to patent this algorithm. I therefore have a duty to notify the company whenever I consider an algorithm to not have a patent.

If you look at the specification for HTML, which is what is used to make up many web pages, you will find a TAB tag (or some such). This allows the writer to specify the order in which fields of a form, or other features of the web page, are selected when the viewer hits the TAB key. Micro$oft are trying to patent this. Micro$oft obviously takes the view that this feature of the specification has never been patented, and that they must therefore patent it. Now, there is no novelty in this whatsoever. It is part of a public, international, specification. Not only that, but browsers, Internet Explorer among them, already implement this feature. The US Patent Office is probably ignorant of this prior art, and may well give Micro$oft this patent. All other makers of browsers will then be liable to pay Micro$oft for implementing part of a specification!

So, should processes which form part of a national or international specification be patentable? One is inclined to say ‘No!’. However, one must not be absolute on this. One should be more careful, and say that when use of a patented process is necessary to satisfy a national or international specification, this use becomes a free use, but only where it is being used for this purpose.

Micro$oft have tried before to patent prior art. Sometimes they got their patent, but have not exercised it, and so the patent has not been challenged. At present, they are trying to licence part of the SenderId standard, but under terms which will require users to acknowledge their right to other dubious patents - hence the current furore.

The EU decided against patenting software some time ago. Unfortunately, the EU Council has overturned that decision, and the future looks cloudy. The US has tried to export its policy on patenting software as part of its Free Trade Agreements: its trading partners probably have very few patents, and will end up paying heavily for this.

Whatever the theoretical rights and wrongs of patenting software, the practicalities of the US patent system make it a horror to be shunned. It will be expensive to undo the past ten/twenty years of such patents, but it will surely be more expensive to let the process continue.

Don’t let it happen here.