patentology

10 January 2013

It is no secret that the folks at the technology news site Ars Technica are no fans of patents in general, or of ‘software patents’ in particular. It was Ars that got stuck into Australian scientific research body CSIRO last year, because it had the temerity to invent something useful for wireless communications nearly 20 years ago, and then sue those companies that made millions from devices implementing the technology, while stubbornly refusing to enter into meaningful negotiations over licensing.

In our opinion, however, it is to the credit of the EFF that it is at least trying to engage with the issues around ‘software patents’ in a more nuanced manner. However, there is a far greater problem with almost all debate around this issue than whether or not it should be about ‘abolition’ or ‘reform’. The single most fundamental matter that must be resolved before we can have any type of meaningful discussion about ‘software patents’ is for us to agree on what we are talking about.

To put it simply, what is a ‘software patent’?

Not only has the EFF so far failed to address this question, it appears to have completely failed to recognise that it is an issue. To see this, you need look no further than the EFF’s ‘Defend Innovation’ project site. Starting with the first point of the proposed reforms, we see that ‘a patent covering software’ should have a shorter term than other patents. OK, this is something we could meaningfully talk about. Many software-based inventions do not require the same duration of protection in order to provide a fair return to their inventors when compared to, say, pharmaceutical products.

But what is a patent ‘covering software’? Does this mean a patent with claims that could encompass a software-based implementation of the invention, even if the patent specification additionally, or alternatively, describes a hardware-based implementation? What if part of the invention is implemented in software, and part in hardware? Should a competing product have some form of defence to infringement after the shortened period if it is implemented in software, but not if it is implemented in hardware? What if the invention cannot be implemented in software at the time of patenting, but then advances in technology and processing speeds make this practical later in the term of the patent?

DISTINGUISHING ‘SOFTWARE’

The simple fact is that there is no clear dividing line between ‘software’ inventions, and ‘non-software’ inventions.

While it may not seem likely that anyone would choose to implement an e-commerce system in hardware (unless they were trying to avoid a patent which had claimed only a software implementation), a very broad range of digital systems can sensibly be implemented in software, hardware, or a combination of both.

In the multimedia field, the MPEG-1 and MPEG-2 video coding standards were developed in the late 1980s and early 1990s, when the processing capacity of common general-purpose CPUs was inadequate to perform the compression or decompression in real-time. The specifications were therefore designed to simplify decoding, with the goal of making them easy to implement in hardware, so that consumer playback devices could be inexpensively produced. The cost and processing required for encoding was less critical, because this step is only required once per program (e.g. a movie or TV show), or at a single location in the case of a live digital broadcast.

Nowadays, decoding of full high-definition programs can be done in software on any reasonably modern PC using only a few per cent of the total CPU capacity. Real-time encoding is also possible in software. However, most PC-based implementations of video encoders and decoders take advantage of functions provided by hardware graphics accelerators. Indeed, in many PCs the most powerful processor is not the main CPU, but the graphics processor (GPU) on the video card. Of course, the GPU is optimised to perform only a limited range of specialised operations, but these it does extremely fast, and often employing massive parallelisation.

And while touch screen operations are currently most likely to be implemented in software, there are clear benefits in offloading these functions to hardware. For example, the implementation ‘pinch-zoom’ requires detection of multiple touch points, and tracking of the movement of each point. An integrated touch screen controller chip could readily be designed to track all multi-touch operations, and simply make, e.g., a ‘zoom scale factor’ available to the main CPU, simplifying the software implementation, and probably also saving power.

WHAT IS A ‘SOFTWARE PATENT’?

As we have reported previously, there have been efforts in New Zealand to draw a distinction between ‘embedded software’ and other types of software. However, for many types of digital inventions this distinction is as unworkable as any other that has been proposed. For example, is a new and inventive networking function to be considered patentable insofar as it is implemented within special-purpose devices, yet unpatentable for the purposes of implementation in a general-purpose computer, such as a desktop PC? Or is it patentable when implemented in hardware, but not in software executed on a general-purpose CPU? And what if it is implemented in software, but on a dedicated CPU – such as the ‘baseband processor’ employed in many portable devices – which is distinct from the main ‘applications’ CPU?

The point of all of this is not to argue that because there is no easy definition of a ‘software patent’, we will have to just forget the whole idea of patent law reform in this area. The are many stakeholders in the patent system who believe that some degree of reform is necessary, just as there are many who oppose any change.

The patent system has the potential to affect everyone – large corporations, small businesses, inventors, and consumers – and in a democratic society this system should be open to meaningful debate and discussion.

However, in the absence of a workable definition of exactly what types of technology we are debating – or even any acknowledgement that we have not established such a definition – there is no way the discussion can be meaningful. The identification of the ‘objectionable’ software patents amounts to no more than the old adage about ‘art’ – you may not know what it is, but you know it when you see it! But just like art, not everyone finds the same things objectionable.

Generally speaking, patents relating to networking and media technologies have not been widely considered objectionable in themselves, although the attempted enforcement of patents relating to industry standards, by Motorola, Samsung and others, has drawn criticism. The exception in this area is the CSIRO wireless LAN patent, mentioned at the opening of this article, which Ars Technica accused of claiming technologies that were ‘decades old’. Corresponding levels of vitriol have not been directed at the holders of patents relating to 3G/4G cellular mobile technologies, although many of the patented inventions can be – and are – implemented partly, or wholly, in software.

All of this provides the overall impression that the defining characteristic of an objectionable software patent is not its subject matter, but how it is used, and who it affects. Very few critics are calling for the complete abolition of the patent system, which means that most of the software patent opponents must hold the view that there is, somewhere, a dividing line between technologies that should be patentable, and those that should not. So where is this line, and how do we test an invention to determine on which side it lies?

ALTERNATIVES TO A DEFINITION OF ‘SOFTWARE PATENT’

Ironically, the system which has been most effective in barring the most controversial software patents without preventing all computer-implemented inventions from being patented, is one which, on the face of the law, prohibits patents on computer programs, and yet this is not the primary basis for refusing software patent claims. We refer, of course, to the European system.

The European Patent Convention provides that computer programs ‘as such’ are not patentable inventions. In practice, however, this prohibition is interpreted very narrowly. Unless a patent claim is directed essentially to program code itself (rather than to, say, a method of carrying out a task, a machine programmed to carry out the task, or a product, such a a CD-ROM, which stores code for carrying out the task) it will not usually fall foul of the ‘computer program’ exclusion.

However, where European law differs from that of Australia, the United States, and a number of other countries, is in requiring that all inventions provide a technical solution to a technical problem. Of course, any computer-implemented invention is technical in the sense that it involves the use of computer technology. However, since a computer program is not itself patentable subject matter, a technical contribution cannot arise merely from the fact that there is executable software involved in the implementation of an invention. A further technical effect must be achieved, which goes beyond the ‘normal’ interactions between hardware and software.

Thus, for example, a patent claim directed to an Internet auction system is unlikely to be allowable, to the extent that the system uses conventional computer technology and computer networks, and makes no inventive contribution to the level of existing technology. The system might use new and inventive algorithms to improve the operation of an auction, and may well provide business benefits to its users. However, providing improvements to the financial performance of a business addresses a commercial problem, not a technical problem, and is therefore excluded from patentability under the European approach.

Conversely, improving communications efficiency and reliability in a cellular mobile phone network is a technical problem. This problem, and its solutions, remain technical in nature, even if solved by modifications to the phone software rather than its hardware. Such inventions are therefore patentable in Europe.

In other words, the European approach enables a line to be drawn which at least distinguishes computer-implemented business processes (including the Amazon 1-clock process, for which patent protection was refused in Europe) from software-based inventions with greater technical merit. Furthermore, it does so without requiring any rigid definition of a ‘software patent’.

CONCLUSION

Whatever merit there may be in reforming the patent system in relation to inventions implemented wholly or partly in software, it is difficult to progress any meaningful discussion of the issue without firstly defining, with specificity, the technologies and subject matter in question.

Alternatively, it may be possible to avoid a prescriptive definition by examining the nature of the contribution made by the invention, regardless of how it might be implemented in practice. Such an approach elevates the substance of the invention above the form in which it is implemented or claimed, and is not without its problems, not least because identifying the actual contribution presupposes knowledge of the prior art, and creates overlap between the criteria for evaluating patent-eligibility, and for assessing inventive step. This does not bother the Europeans much, but in Australia or the US (for example) this approach would be considered by most practitioners to be an abomination!

Considering the innumerable words written every day on the subject of software patents, and their faults, it seems remarkable that the is no generally agreed answer to the question: what is a ‘software patent’?