Note the wording of the four different attempts to define "technical contribution". If you can do better, please do.

*********************************

It was a bright cold day in April, and the clocks were striking thirteen. I was standing in a room in Harmsworth House having an enlightening, though brief, conversation with a solicitor.

Harmsworth House, an unremarkable office building of the UK Patent Office, was the London venue for the 1PM "'Technical Contribution' Workshop" to which I had been invited. It was the 7th of April, 2005. I had arrived just after 12:35, and had been swiftly directed to a room in which tea and coffee were available, along with biscuits. On the way, I was given a visitor's badge with a coloured spot stuck on it. The colour was to show which table I was to sit at. I was bright pink.

When I entered the reception room, there were about eight others there, some of whom were wearing Patent Office staff badges. More attendees arrived during the following half hour.

Being rubbish at small-talk, I mostly listened to the surrounding bits of conversation. What struck me was how familiar the conversations were - it was just like reading stuff on the web! The things people were saying were the same things that one reads in articles and discussions on software patents on the internet. What was different, though, was the atmosphere. There were no flames. Instead, it wasn't just civil, it was friendly.

As it approached time to start the workshop itself, I did have a brief conversation with a solicitor who had just arrived. He introduced himself as a patent solicitor, if I remember correctly, who was there to learn more about the issue of software patents. I didn't really know what category to put myself in, or how to introduce myself, so I said I was a sort of perpetual student, though not always 'officially' a student. I mentioned my interest in computing, and my use of Open-Source software.

My mention of Open Source prompted a familiar, though disappointing, response: Open Source is a problem. He said that it was a problem in the company where he worked, and mentioned the problem of "contamination", referring to the GPL in the process. His company was using Open-Source (more specifically, GPLed) software as parts of the software it was developing, which it wanted to distribute under its own terms as proprietary software. But, as we know, the use of GPLed software in this way meant that the company would have to make the source of it's own, derived work available under the same terms, too. This it did not want to do. It was a "problem".

This sounded all too familiar to me. He obviously didn't 'get it'. I wondered how to point out the apparent unreasonableness of his position, but without doing so confrontationally. I ventured that he was not a fan of Open Source.

Quickly he corrected me, and with quite a surprising twist. He actually explained, very swiftly and concisely, that the authors of Open Source software can distribute the software they write under whatever terms and conditions they choose, which is what they're doing when they GPL it. After all, they wrote the software! The GPL wasn't the "problem".

The problem, as he then clarified, was that the "techies" were using Open Source software in the software they were developing, but without realising or taking account of the legal implications for the company. The company still expected to distribute the software its "techies" had developed for them under its own terms. The problem was actually one of management.

This was something I found very enlightening, and was glad that I had not taken a confrontational approach. What initially seemed to be a case of hypocritical greed was actually a case of lack of communication and understanding between the "techies" and management. Dilbert and his Pointy-Haired Boss came to mind. I was also reminded of some people's preference for BSD-style licenses, as this seemed to fit very well with what I was being told.

Unfortunately, our conversation could not proceed further, as we were then called in to the workshop itself.

Each table had a coloured, numbered piece of folded card standing in the middle. It wasn't hard for me to find the bright pink table, as it was table number one, closest to the door. However, while I obediently sat at that table, it turned out that we weren't generally sitting at the tables to which we had been assigned. We just sat at the three tables at the front, as there were plenty of people who hadn't turned up. If I remember correctly, it was mentioned that only about half those who had been invited actually turned up to the workshops generally. There were about twenty of us in total, six at my table.

I was surrounded by three patent lawyers. When I mentioned I was an Open Source user and developer, one said that they would be most interested in hearing my views.

Once we were in our places, we were given an introductory talk by the Patent Office staff member who was chairing the workshop. It was the usual stuff that we've read before in reports from attendees of previous workshops (some of which are listed on the FFII website). We were also introduced to Peter Lawrence, who was sitting at a table by himself, observing the workshop. He was at the (in)famous December meeting with Lord Sainsbury.

One thing that was mentioned during this introductory talk was that, contrary to what had been reported by a previous attendee, there was not a Patent Office "plant" on each table. It seems the Patent Office are not ignorant of the things we say about them online. This I take to be a good thing.

Everyone was supplied with a booklet, which we were to work through. The booklet contained five case studies, each being a fictional invention, and four proposed definitions of the term "technical contribution". We were to test each case study with each proposed definition, to see whether the case study was patentable according to that definition or not. It had been emphasised that we were to assume each case study to be novel and non-obvious, as the focus of the exercise was on the term "technical contribution".

At the back of each booklet were two additional sheets: a results table, with space for comments in each cell; and a blank comments sheet for general comments. Both sheets had a blank for us to enter our table numbers in, though were anonymous on an individual level. Each table was also provided with a cumulative results sheet, and there were large results sheets stuck to the wall for the workshop as a whole.

Although the workshop ran for two hours, we only had about an hour in which to work through the twenty combinations of case studies and proposed definitions. While we reached and recorded individual conclusions, we did briefly discuss the case studies and definitions, seeking to reach a consensus each time. As the hour passed, we got faster and faster, but I constantly felt a lack of time. My attention did not extend beyond our table until we had completed the exercise.

During the course of our deliberations, a late arriver joined our table, bringing the total to seven.

While working through the case studies, the distinctions between lawyers and non-lawyers seemed quite irrelevant. We were not distracted by issues of whether or not the various case studies ought to be patentable, and focussed almost exclusively on the task at hand. Occasionally, a Patent Office staff member would visit our table to let us know how much time was left. I can see why previous attendees felt they were being hurried along, but it didn't feel to me that it was intended that way.

After an initial perusal of the booklets, during which I started taking some occasional notes to aid me in writing this report, we turned our attention to the four definitions of the term "technical contribution".

A

"Technical Contribution" means a contribution to the state of the art in a field of technology which is new and not obvious to a person skilled in the art. The technical contribution shall be assessed by consideration of the difference between the state of the art and the scope of the patent claim considered as a whole, which must comprise technical features, irrespective of whether or not these are accompanied by non-technical features.

B

"Technical Contribution" means a contribution made by a claimed invention, considered as a whole, to the state of the art in a field of technology. "Technical" means belonging to a field of technology.

New teaching about the use of controllable forces of nature under the control of a computer program, beyond the implementation of the data processing procedure itself, is technical. The processing, handling, representation and presentation of information by a computer program is not technical, even where technical devices are employed for such purposes.

I

1. The claim must include technical features but can also include non-technical features.

2. These technical features do not need to be novel or inventive, provided that the claimed invention as a whole is novel and inventive.

3. The technical features must be of a type that could, in isolation, be the subject of patent protection (ignoring lack of novelty or inventive step).

4. There must be a causal link between the technical features and the details of the non technical features.

J

A 'technical contribution' shall be the application of a new process using physical forces in an inventive and non-obvious way, with these provisos:

1. The process may require a computation using a computer, but the normal physical processes of a computer cannot be part of the 'technical contribution': a new process using physical forces separate from all computation is required.

2. The process may perform communication with computers or people, but the physical processes of a pre-existing communication apparatus cannot be part of the 'technical contribution': a new process using physical forces separate from any pre-existing communication apparatus is required.

3. Mere use and distribution of computer programs embodying the computations required by the new process shall not of itself be considered infringement.

As usual, the first two were the definition from the current draft Directive, as definition A, and the definition provided by the FFII, as definition B. The second two definitions, I and J, were taken from what we were told was a representative sample of the two-hundred or so suggestions that had been received by the Patent Office.

On our table, we concurred that definition A lacked clarity, particularly when it came to the term "technical". With the term "technical contribution" being defined in terms of "technical features", we were left with the term "technical" being defined as "technical" - a circular definition! We also noted that "The technical contribution shall be assessed by consideration of the difference between the state of the art and the scope of the patent claim considered as a whole". Did that mean that new, non-obvious aspects did not themselves have to be "technical"? As the definition said, while the "technical contribution" "must comprise technical features, irrespective of whether or not these are accompanied by non-technical features", we were to consider the claim "as a whole".

We also found that definition B, the FFII one, lacked clarity, but not as much as definition A. It was noted that the vagueness had been shifted from the term "technical" to the phrase "forces of nature". At least it wasn't circular this time.

We didn't think much of definition I, but noted that it was effectively quite similar to definition A. We found it unclear, and again it left the term "technical" undefined. Part 3, while supposed to provide some definition, only did so recursively in terms of what would be patentable, but without a terminating case. It was uselessly circular as a result.

Definition J, in contrast, was quite different. I don't remember anyone at our table expressing the view that this definition lacked clarity (though I may have missed such a view being expressed). It was noted that, similarly to definition B, technicity was tied to "physical forces". Proviso 3 was generally ignored, as it dealt with infringement rather than technicity.

Once we'd acquainted ourselves with the proposed definitions, we turned our attention to the case studies.

For our workshop, we had case studies 1, 6, 14, 16 and 17, taken from a set of about twenty. Each of these fictional inventions was presented with a brief background explanation, and then a short claim consisting of several parts. Although short (one page each), I found there wasn't enough time to read them all fully, and increasingly relied on getting enough of a gist from the claims to be able to determine whether or not they'd be patentable under each definition.

Case study one was "A system for dynamically optimising traffic flow along a highway by creating a traffic light control program from sensed data". Basically it was a centralised traffic light control system. This was the case study we spent most time on, from what I remember, with a lot of discussion on the issue of 'technicity'.

We also discussed the issue of how novelty and technicity were related, as the individual parts of the claim weren't necessarily novel, though were where the technicity would be found. This was of particular relevance to definitions A and I. The "as a whole" feature of definition A led us to disregard lack of novelty in the individual parts of the claim, leaving us assuming (as we were required) that the claim (as a whole) was still novel and non-obvious. It was therefore enough for us to find a "technical feature" in those claims, which we did. The lack of definition of the term "technical" gave us plenty of room for manoeuver. We reached a unanimous consensus that, under definition A, and also I, the claimed invention was patentable.

For definition B, there was some discussion on the issue of whether or not controlling traffic via traffic lights amounted to "the use of controllable forces of nature". For example, was the traffic controlled by the lights, or were the lights sending data to the drivers who then chose what to do with their vehicles? Five of us found the claimed invention to be unpatentable under definition B, with two (who, I believe, were both patent lawyers) finding it patentable.

Definition J was clear and easy to apply in this case, and led us to a unanimous verdict of unpatentable.

The next case study, number six, was a long-distance lorry driver scheduling system. All but one of the five parts of the claim started with the notorious word "apparatus", with the one exception starting with the phrase "means for".

For definitions A and I, we all agreed that this 'invention' was patentable. The use of "apparatus" provided the "technical features" for both A and I, with the "as a whole" aspect of A (and part 2 of I) leading these non-novel, even obvious "technical features" to render the 'invention' patentable.

For B, there was, like the first case study, the question of whether or not long-distance lorry drivers constituted "controllable forces of nature", with one person suggesting that they were surely "uncontrollable forces of nature". However, we unanimously concluded that the scheduling system was unpatentable. We reached the same verdict, again unanimously, for definition J.

Case study fourteen caught my attention as particularly interesting, bringing to mind such things as the Halting Problem, and pure, non-strict functional languages. It was a software testing system, where test scripts would be automatically generated from a formal specification of the software to be tested. The software would then be tested, and reports automatically generated. Not just a software patent, but a software patent to do with the writing and testing of software itself.

For definition A: was it "technical"? Yes! Therefore, it was patentable. For definition I, the same logic applied, so again it was patentable. (By this point, we were getting good at finding "technical features" in the claims, which was all we needed to do to grant patents under these definitions.)

For definition B, the 'invention' was not patentable, as there was a lack of "forces of nature". The same went for J when it came to "physical forces". It was also plainly data-processing, which was specifically excluded by both those definitions.

Next came case study sixteen, a system for determining whether or not vehicles are parked legally, and for providing routes to the nearest car parks if not. It involved GPS devices in those vehicles, along with a central server to do most of the work.

As you might have guessed, we found this invention patentable under definitions A and I, and unpatentable under J, these conclusions again being unanimous. For definition B, there was a 5:2 split in favour of unpatentability. As with the first case study, it came down to the issue of "controllable forces of nature".

The final case study, number seventeen, was for a "scheduling compiler", which basically optimised multithreaded code for more efficient execution on multiprocessors. Included in the claim was the actual execution of such code on multiprocessing computers.

Predictably, we all found it patentable under definition A, but, according to my notes, there was a 4:2 split (and one abstention) with definition I this time, with the majority finding it to be patentable. I can't remember why some found it unpatentable, though, and I didn't note down any reasons in my notes. For both B and J, we found it unpatentable. At least, that's what my notes tell me, though I thought, from memory, that it was with B that we lacked a consensus, with unanimity for a patent under I. My notes, and my memory, are not necessarily entirely accurate.

Once we'd finished, the cumulative results for each table were copied, in the form of tally marks, onto the large results sheets on the wall. I noted them down, though assumed that the tallies totalled twenty for each combination of case study and definition (so "~" in the following table means 'approximately'). Abstentions were not marked.

With the main part of the workshop finished, the chair took comments from each table in turn, usually from a table-selected spokesperson.

Generally, the opinions expressed about the four definitions were similar to the conclusions reached at our table. For definition A, it was said that it allowed too much to be patentable. Definition B did better, but there was still the issue of "forces of nature", and what exactly that meant. The recursive circularity of I was commented upon, with that definition even being described as "viral"! One observation that was voiced was that the word "computer" in an application made anything patentable. The general consensus was that it was not very good. J, in contrast, was "quite clear to apply", and generally found to be the clearest.

For all four definitions, the problem of adequately defining the term "technical" was observed, though B was regarded as doing quite well. Peter Lawrence added the comment that the problem with defining terms, such as the term "technical contribution", was that there would always end up being terms left undefined. For example, when using the phrase "forces of nature" to define "technical", there is then the question of what, exactly, "forces of nature" means. He said that this was a problem with defining terms generally, not something which is specific to just this issue.

A particularly note-worthy comment that was made was that there was difficulty in determining which actual features of each case study claim were the relevant ones when it came to determining patentability. It was explained that it was each claim as a whole which was supposed to be tested.

Some straw polls were taken, at the instigation of the chair, who mentioned that people at other workshops had often requested such polls. At some point, he also remarked that, so far, this particular workshop was the "most focussed set", and then, with some humour, added that he didn't just say that at every workshop.

The first was on whether or not we thought each case study 'invention' should be patentable. Case study one was split, with eleven each way. Only one supported patentability for number six, with no abstentions. There were four supporters of patentability for case fourteen, with one abstention this time. Case sixteen had eleven in favour of a patent, and ten against, with a single abstention. Thirteen were against a patent for case seventeen, with eight in favour.

Then we were asked how many of us thought that software should ever be patentable. Ten of us voted against. Finally, we were asked which of us considered ourselves to be "real software writers", for which twelve of us raised our hands. What I didn't catch with any certainty, though, was how strong the correlation between support for software patentability and being a lawyer was - but the impression I felt was that it was very strong, particularly at my table.

One attendee asked how useful these workshops were, now that the Council of Ministers had accepted the Directive as currently drafted. We were told that the process wasn't over, yet, and that opportunities were anticipated in the conciliation process following the European Parliament's second reading. Of course, this relies on the Parliament voting for amendments with an absolute majority.

Someone also said that only those amendments the Parliament had previously voted on could be applied in the second reading, but the Patent Office corrected this. Because the composition of the Parliament has changed since the first reading, particularly with the accession of the ten new member states, new amendments can still be added.

During this final stage, there were other comments made, and responses given, but it was generally the same, familiar stuff as from other such occasions and discussions.

With the workshop drawing to a close, we were told that the results of the workshops would be published in due course, though there was likely to be a delay due to the forth-coming general election. We were also told that additional copies of the booklets were available for anyone who wanted them, if they'd scribbled on their original booklets, for example. I'd kept mine clean, so did not request one.

Afterwards, familiar-sounding conversations resumed, as attendees gradually departed and fresh results sheets were stuck to the wall for the next session.

Overall, the workshop had seemed fairly informal. I suppose that's the nature of workshops, generally. It felt very much like I was now part of something I'd read a few times on the web. I was glad to have taken part, and to have found how reliable the collective reports of previous attendees had been. And just for the record: I only saw one woman there in the workshop. I think, from what she had said in a very long, notably uninterrupted comment, that she was on the legal side of things.

Some hours later, after having watched a film that's banned in China, and having eaten chips and talked with friends in a pub, I was standing in Liverpool Street station.

While waiting to find out which platform my delayed train would be at, I looked up at the telescreen above the entrance to the shops. It was a static BBC News 24 ident. Soon, a digital teletext summary of the day's weather came up. It had not been such a "bright cold day in April" after all, but a day of April showers, though with sunny intervals. Still, I thought, the literary reference I wanted to begin my report with was still worth making. It was, after all, this whole software patents saga that inspired me to finally read George Orwell's 1984.