The Patentability of Software

Software as Mathematics

Anton Hughes

• Publisher: Routledge
• Year: 2019
• eBook ISBN: 9781315283197
• Edition: 1
• Topic: Law
• Subtopic: Intellectual Property Law
• Index: Law

This book explores the question of whether software should be patented. It analyses the ways in which the courts of the US, the EU, and Australia have attempted to deal with the problems surrounding the patentability of software and describes why it is that the software patent issue should be dealt with as a patentable subject matter issue, rather than as an issue of novelty or nonobviousness.

Anton Hughes demonstrates that the current approach has failed and that a fresh approach to the software patent problem is needed. The book goes on to argue against the patentability of software based on its close relationship to mathematics. Drawing on historical and philosophical accounts of mathematics in pursuit of a better understanding of its nature and focusing the debate on the conditions necessary for mathematical advancement, the author puts forward an analytical framework centred around the concept of the useful arts. This analysis both explains mathematics', and therefore software's, nonpatentability and offers a theory of patentable subject matter consistent with Australian, American, and European patent law.

1
The nature of software

1 Introduction

To understand why software is an issue for patent law, it is first necessary to understand a number of things about how modern software is organised and how any particular software component is likely to be built. The nature of software will be returned to in Chapter 5 in much greater detail. However, an understanding of the software development process is necessary in order to properly understand the problems which attend on the software patent cases discussed in Chapter 2.

Through an exploration of the nature of software, four things will become clear. First, the process of abstraction away from specific hardware limitations has been the key to the success of software. Second, the way in which software systems are constructed using layers, libraries, frameworks, and design patterns makes it clear that one important goal of software development is to encourage reuse. Third, the development of a particular piece of code tends to be very context-specific – not all software development activities are alike. Finally, software entities tend to be complex, typically involving large numbers of unique components. Abstraction, re-use, context, and complexity all raise important considerations for the patentable subject matter inquiry which will be developed in later chapters.

This chapter will also introduce one of the major themes of the book – that software is isomorphic to mathematics. This isomorphism can be demonstrated both at the formal level and at the structural level. Whilst there are undoubtedly some differences between the two, the prima facie identity established provides a proper basis for exploring software’s patentability by reference to the patentability of mathematics.

2 What is software?

Early in the history of computing, collections of physical components which make up a computer began to be called “hardware”. Software was then coined to refer to the non-physical aspects of the computer, especially the programs, or sets of instructions “which cause a computer to perform a desired operation or series of operations”.¹ Such a definition is useful to a certain extent, but overlooks the complex relationship of hardware and software, particularly when an externally stored program² is loaded into the memory of a computer. It also encourages a focus on the end product of the software development process – executable code – at the expense of other artefacts which exist at intermediary stages; and which in some sense determines the final product.

So to truly understand the nature of software, it is necessary to understand how the development of software has evolved since the early days, as much of this evolution has determined the way in which software developers currently operate. It is then possible to see how software developers take an abstract idea and develop it into working software through the paradigm known as top-down programming. It will also be possible to make some general observations about what makes software unique.

2.1 The evolution of modern software

Table 1.1 Example machine code instruction

A Machine code

Machine code, or native code, is the medium in which all software was originally written, and the form in which software ultimately executes on a computer. Machine code is a string of 1s and 0s (called bits) of a set length which tell the computer’s central processing unit (CPU) which instruction to perform, where to get the data and where to put the result. An example of a 32-bit instruction is given below:³ This instruction tells the CPU to add the contents of memory location 2 to memory location 3 and put the result in memory location 4. The available instructions set varies betweeen processors, but typically includes such operations as:

• arithmetic operations, such as add and subtract;
• logic instructions, such as and, or and not;⁴
• data instructions, such as move, input, output, load, store;⁵ and
• control flow instructions, such as goto, if … goto, call, and return.

Each instruction has its own corresponding binary number. This can make writing programs in machine code tedious and time-consuming. Errors are easy to make and hard to find. Further, the mappings of instruction to number can vary from processor to processor. This means there is little portability between machines.⁶

So early on, programmers began to look for ways of moving towards more human-readable representations of computer instructions.

B Assembly language

The next development was to write a program which could take care of converting human-readable instructions to number strings, called an assembler/disassembler. The assembly language version of the machine code instruction above looks like this:

ADD (L4, L2, L3)

“ADD” is obviously more memorable than 100000, but there is still a one-toone correspondence between assembler instructions and machine code instructions. Seemingly simple operations require a number of machine-level instructions,⁷ and assembly programmers still have to work within the constraints of hardware-specific instruction sets.⁸ So they set to work on hiding the low-level details of the computer in another way.

C High-level languages

Most programming these days is done using high-level languages, which are another step closer to natural language. High-level languages also hide the machine architecture from the programmer. A high-level representation of the assembly code above would be:

a = b + c

When using high-level languages, programmers no longer have to worry about memory locations, architecture-specific instructions, or other low-level hardware details. In order to be executed by the computer, however, high-level language commands need to be translated into machine code. As such, high-level languages are often classified according to how this translation is achieved.

D Compilers

Compiled languages cannot be run directly on a computer in their original (source code) form. Before they can be executed, a translation program (compiler) translates the high-level language instructions to machine-specific instructions (the result of compilation being known as object code). Common compiled languages include C and Java.

E Interpreters

Interpreted languages do not have this preparatory step. A program called an interpreter translates high-level code to machine code as the code is run. Modern examples of interpreted languages include Python, Perl, PHP and Ruby. Since no compilation is involved, the development and testing of software written in these programs is easier. The downside of interpreted languages is that they generally run slower and require more memory.

F Software stacks

But the abstraction of the software development process does not end with natural languages. A different type of abstraction is achieved by breaking software down into a series of layers, called a stack, where each layer offers the layer above access to its services, but only via a set of higher-level functions. The typical layers involved in the operation of a modern computer are discussed below.

Firmware, kernels, and operating systems: Firmware exists right at the borderline between hardware and software, and can be thought of as a computer program embedded in a hardware device. The most familiar role for firmware in modern computers is as the Basic Input Output System (or BIOS) which launches a computer’s startup process by detecting the installed hardware elements, then loading the operating system.

Operating just above the level of the firmware is an operating system’s kernel. The kernel handles the lowest level of interactions with the hardware of a computer. The most commonly known kernel is Linux, the kernel of a GNU/Linux operating system. The job of the kernel is to “manage the computer’s resources and allow other programs to run and use these resources”.⁹ These resources include the CPU, memory (RAM) and various input/output devices such as displays, disk drives, mice, and keyboards. Since there is usually more than one program running at any time on a computer, the kernel can be thought of as deciding...

Table of contents

• Cover
• Half Title
• Series Page
• Title
• Copyright
• Contents
• Acknowledgements
• Introduction
• 1 The nature of software
• 2 Why software patents are a problem
• 3 The nature of mathematics
• 4 Why mathematics is not patentable
• 5 Why programming is not among the useful arts
• 6 Implications
• Conclusion
• Index