For a software or business method invention to be patentable in the UK, the invention must provide a “relevant technical effect”. The meaning of “relevant technical effect” is open to interpretation, but the UK Intellectual Property Office (UKIPO) generally applies the following five “signposts” set out by the High Court:
i) whether the claimed technical effect has a technical effect on a process which is carried on outside the computer;ii) whether the claimed technical effect operates at the level of the architecture of the computer; that is to say whether the effect is produced irrespective of the data being processed or the applications being run;iii) whether the claimed technical effect results in the computer being made to operate in a new way;iv) whether the program makes a computer a better computer in the sense of running more efficiently and effectively as a computer;v) whether the perceived problem is overcome by the claimed invention as opposed to merely being circumvented.
As a patent applicant, the important task at the drafting stage is to identify what contribution(s) your software invention makes to the state of the art and consider ways of illustrating that the contribution(s) is technical in nature. The UKIPO stance on what can be considered as a “technical contribution” can be very strict, and often whether a software-based patent application will be considered by the UKIPO depends largely on successfully showing that the software invention makes a “technical contribution”.
Similar to the UK, European patent law explicitly excludes software and business methods from patent protection, but again, it is possible to protect the technical features of a software invention.
The EPO’s approach to what constitutes a “technical feature” is more liberal than the UKIPO, in that any features that describe a physical object, even just the computer itself, is considered “technical”. However, in order for a software invention to be patentable, the technical features must solve a “technical problem” in a non-obvious manner.
During examination, the EPO would formulate a “technical problem” by comparing the “technical features” of a software invention with the state of the art, and consider whether the “technical features” are obvious to a skilled person (e.g. a computer programmer) given their knowledge of the state of the art and the technical problem. Clearly, if the software invention is merely an automation of a known or obvious method implemented on a computer, it will fail the novelty and/or obviousness test.
In practice, similar to the UK approach, whether a software invention is ultimately patentable or not often relies on successfully arguing that the novel and non-obvious features are technical.
In order for a software feature to meet the requirement of being "technical", it is usually necessary for the software, when executed on a computer, to produce a technical effect which goes beyond the ordinary functions of the computer (such as the graphical display of data on a monitor or the movement of data from one location to another).
By way of example, software containing a new algorithm for controlling the operation of a robotic arm in order to more efficiently assemble parts in a manufacturing process should in principle be patentable at the UKIPO and the EPO. Similarly, software containing a new code that enables a computer processor to process graphics more efficiently should in principle be patentable at the UKIPO and the EPO. In both examples, the technical effects produced by the software invention clearly go beyond the ordinary functions of a computer, and there is a straight-forward argument for a “technical contribution” to the state of the art, or a “technical problem” being solved (improving the efficiency of parts assembly, improving the efficiency of graphic processing).
As a contrasting example, complex financial systems may use computers to monitor the movements of large numbers of stocks and shares and recommend buying or selling activity according to a set of predetermined criteria. In general, software implementing such financial methods are not patentable at the UKIPO and the EPO, even if the underlying financial methods are new and non-obvious, e.g. the set of criteria used is new. In this example, the contribution made, or effect produced, by the software, namely improved recommendation for buying or selling stocks, is primarily business in nature and unlikely to be seen as “technical” by the UKIPO or the EPO.
For software inventions that are on the borderline at the UKIPO and the EPO, you may wish to consider a patent application with the United States Patent and Trademark Office (USPTO).
The USPTO has traditionally taken a more liberal approach to patent protection for software and business methods inventions, in that there isn’t an explicit exclusion from patentability of software or business method. In practice, the USPTO has a requirement for a software invention to be more than an “abstract idea” in order for it to be considered patentable, which can be said is broadly in line with the UKIPO and EPO requirement for a software invention to be technical.
While the USPTO seems to take a similar approach to the UKIPO and the EPO, many applicants and practitioners generally find the USPTO has a more permissive approach towards software and business methods.
This is a tricky question that does not always have a clear-cut answer, and you should consult a patent attorney with software expertise to discuss your specific case. However, here are some questions to consider which your patent attorney would want to establish:
● Can you identify ways that your software functions differently from existing software?● Is the identified difference an improvement over existing software?● Does the difference solve a particular problem in the existing software?● Is the improvement or problem technical in nature?● Given knowledge of the existing software and the technical problem, would the difference have been obvious to a skilled person (e.g. a computer programmer)?