The "Technical Contribution" Myth

If you ask your MP or MEP about the current directive, they will often say that the UK Government is supporting the directive because it sets down "firm guidelines about what software is and isn't patentable". This is misleading at best; at worst, it's a downright lie. The premise they base this statement on is that it is possible to distinguish technical contribution in a piece of software; that it does something that "pure" software does not.

Background: we can't patent all software!

It's a very easy trap to fall into. Consider two inventions A and B; one is implemented in gears and motors, and the other is implemented in software. Further imagine that they solve the same problem, and that from the outside invention A is indistinguishable from invention B. Is it right to say that invention A should be patentable while invention B is not patentable? At first sight, that seems unfair - so, the idea is that a technical invention should be patentable, whether or not it is software. But, we cannot allow all software to be patentable - because then we are truly opening the door to patents on maths, for example. So, the idea of technical contribution is mooted.

However, this grossly mischaracterises the situation. In fact, it draws your attention away from what you should be looking at: that the implementation is the nature of the invention, and the level of difficulty of solving a problem actually varies with the tool you're using. For example: if you only have a manual screwdriver, an invention which allows you to tighten a screw to a precise torque is exceptionally useful - you couldn't do that by hand! However, if your screwdriver is electric, suddenly your invention looks very simple: the clutch on the screwdriver will slip at certain torques, so it's just a matter of adjusting the gearbox and you have a precise way of doing it.

Does the fact that some problem can be solved simply with one toolset mean that any solution to a problem should be unpatentable? No, of course not - and the inverse is also true; that a solution with one set of tools is patentable does not mean any equivalent solution using other tools should also be patentable.

Trying to prevent algorithm patents: technical contribution

Logically, it's obvious that you must assess the patentability of an invention with regard to how the invention was implemented. But, if you say that, then you cannot hold onto your idea of equivalency (between identical inventions implemented in different ways). Because they are trying to disregard the implementation of the invention, the people who are proponents of this idea are trying to find another dividing line: they cannot say all software should be patentable without admitting that they are patenting algorithms, and further admitting that they should also be able to patent business methods, mathematics and other algorithm-oriented ideas. They think that it is possible to divide between software which has a technical outcome and that which doesn't.

Generally, technical contribution will be found in two ways:

1. a computer running the program operating some external apparatus in which a technical change is produced; or
2. the program causing the computer itself to operate in a technically different way

Bear the latter in mind as you read my example:

An example of technical contribution

In a recent leaflet on "computer-implemented inventions" (the weasel word for software patents), the UK Patent Office invites people to review its ex parte judgement list, to show how well they do at throwing out pure software patents. Unfortunately, all it shows is that people who word their patents poorly don't get them. Here is an example of a software patent that was close to being thrown out: they just needed to find a technical contribution.

Patent GB0025696.6 is the patent in question, and although I am examining it here, I wish to cast no aspertions on ARM Ltd., their lawyers, or the inventors: they are only patenting what the UKPTO allows them to patent. Here is what is stated at the end of the summary:

"The Hearing Officer concluded that this invention did involve a technical contribution — not simply because it produced a faster simulator, but because the fundamental construction of the simulator had been modified. He described it as a technical improvement in the construction and operation of a simulator — a 'neat' technical solution to a technical problem."

If you wish to read the decision, I strongly recommend reading the whole thing - the discussion on finding a technical contribution is highly entertaining. But, as a precis, there are essentially the steps the inventor went through:

1. They designed a CPU emulator program, which effectively models the design of a CPU internally, so that you could run programs designed for this CPU on the emulator
2. One of the features of this CPU was that it is "multi-stage": that the CPU does a number of operations in parallel, in a manner similar to the way car construction lines work. Data comes in at one end, it gets processed as it goes down the line, and the result comes out at the other end.
3. Unlike a car contruction line, you cannot just "move" data around, you can only copy data from location to location. So, data has to be copied down the pipeline rather than just moved.
4. The inventor spotted that rather than copy the data around in bulk, they could keep the data in buffers, and only copy pointers to the buffers around. Because a pointer to a buffer is much smaller than a buffer (it's like a sign pointing at a town), it's much quicker to copy when you "move" things down the pipeline
5. Because this copying of pointers is quicker, it results in a technical effect - the CPU emulator goes faster.

And that's basically it. They wrote a program. They made part of the program faster. Like most optimisations made to programs, this was a change in the construction of the program. If rewriting a program to use a new algorithm is a technical contribution in the sense of "causing the computer to operate in a technically different manner", you can see that the phrase is technically meaningless.

So, we can see where you can get a technical contribution. Anything which alters the way the computer runs the program (in terms of things you can measure from the outside world) is a technical effect. Are there programs which don't exhibit that kind of technicality? They denied GB0222072.1 on the grounds of there not being a technical contribution (but that was also a business method, which they don't dare talk about patenting), ditto GB0110300.1 - fact, only once in the whole 2004 ex parte decisions list (GB0217629.5) is there a decision where a patent has been denied solely on the grounds that the software did not make a technical contribution. This is unsurprising, because the patent application is actually one of a business method and the use of software is mostly incidental.

Of the other decisions where technical contribution has not been found in a piece of software (they are also all further denied on the grounds that they are business methods), the following reasons for rejection are interesting:

• GB 0217000.9 is denied because "[although] the system could consider a larger number of options than conventional techniques[, this] was just the sort of advantage to be expected from using these known programming technique". Pointer arithmetic is also a known programming technique with known advantages (i.e., a fast way of dealing with data), but although GB0025696.6 (the example above) is allowed, this is denied.
• GB 0202537.7 is denied. The applicants argue "the invention made a technical contribution because the new and simplified nature of the system resulted in reduced use of bandwidth and other physical resources in comparison with existing systems", but it is rejected because "such benefits are not on their own enough to warrant a finding of technical contribution if the field of the invention is itself non-technical". The applicants of GB0025696.6 are lucky then - their invention is in a technical field, so they have a lower barrier of technical contribution for some reason. It seems reduced use of bandwidth is not as technical a contribution as reduced use of CPU time...
• GB 0128602.0 is denied because although "the system did increase the rate at which transactions were carried out", "this was achieved not through the computer system operating more efficiently, but through changing the rules of participation in the market". Apparently, changing the way you deal with memory to improve speed is technical, changing the way you deal with a market is not. Even though both algorithms are coded into the software.

I examine these not to show that the examination process is at fault, but to show that the idea of technical contribution cannot be applied fairly because it is, at its heart, an illogical test. A flawed test will result in flawed decisions, and I think the above shows that clearly.

The ex parte process is an appeals process: if a patent is applied for and denied, usually the applicant would re-draft or drop the application. The above decisions only occur when the applicant feels that their examiner is not fairly viewing their application - so they actually have plenty of opportunity beforehand to word their application such that a technical contribution is apparent. That said, the Patent Office claim that 15% of their thousands of annual applications are software-related. There are fewer than 10 which have been rejected in the appeals process as being non-technical. That represents an exceptionally low number, and it's not as if the examination process is acting as a filter - for example, patent application for GB0312175.3 is summarised thusly:

"The applicant appeared to be trying to protect the use of ‘0’ and ‘1’ in computer technology. [...] The applicant appeared to have completely misunderstood the patent system, and had not actually invented anything."

This kind of application - a kind which is satirised to mock the US patent system - still gets through to appeals. It seems software "inventions" are rarely refused on the basis of non-technicality; that says an awful lot about the strength of the test.