We have another report from the UK Patents Workshops, from Groklaw member Cinly. What is interesting to me is, they used different definitions than our last reporter had to evaluate. I gather the UK Patent Office is trying out language on what constitutes a "technical contribution." Simon Best found the link where you can read all of the definitions, including the four used at Cinly's session. Matt Whipp of PC Pro attended a workshop too, and his report is here.
As I was reading this report, the section on the various case studies, it came into my mind that what they should use for case studies would be the components of the Internet. Seriously. I would bet that it would all qualify for a patent, and what a different world it would be if the creators of the Internet had patented each invention. Something, in my opinion, is wrong with patents on anything we *all* have to use.
If you read each case study that way, as I did, applying the current language of the software patents directive, it gives you a sinking feeling, realizing everything you can think of pretty much ends up patentable by that definition. In fact, there wasn't one case study presented at this session of the workshops that failed to be decided that way. And, of course, that is exactly the way it will play out in real life, if this awful software patents directive is passed as written. We really need a better definition of "technical contribution," one that isn't such a blank check, at a minimum. That's what I am getting out of these reports. Anybody got an idea for better language?
Here's mine: software and patents should get a divorce. It was a horrible mistake for the US to allow patents on software, and the results are clearly evident: patent trolls suing over patents they don't even use for anything but the patent infringement legal lottery, a playing field only the wealthy can play in, and a discouraging effect on innovation, and it is impossible to know how to avoid infringement currently in the US, and so unbearable legal costs must be assumed, which independent developers simply are unable to do. Here's just one example of the waste, fear, and annoyance software patents cause. And here's a paper on why patents can only cripple the software industry.
Software is developed so rapidly, a monopoly where everybody has to stand still for a time period (or pay) makes no sense anyway. I'm quite serious. The only beneficiaries are a handful of large corporations, who benefit by holding the rest of us back, and frankly, no offense, but they have enough money already. The public has a right to the benefits of real innovation, and that isn't something software patents encourage.
And it's math. One plus one should never be patentable. Never. If you must have patents on specialty items the rest of us don't much need to have, go ahead, but define your terms so that it really is limited to such things, please, and leave knowledge in the common pool, so the public has the benefit of scientific advances. You know. Like the Internet. Nobody needed a patent to encourage that to happen. And had Microsoft and a few others invented the Internet, trust me, it'd all be licensed and balkanized, like cell phones. You know how wonderfully cell phones work. I traveled recently to another state with a cell phone that it turned out doesn't work in the entire state. Imagine a patented Internet. It would work just like that. And didn't the Internet result in economic benefits? Think larger please, everyone. There really is an economic benefit to sharing knowledge. Look at GNU/Linux. It wasn't written to make a dollar, but it has turned into a cash cow. So think larger, please, about software patents. There is money to be made from innovation, but not that way.
For my session, there were 30 attendees (2 women, I have to stress that I am defining the gender as on one's birth certificate) and 5 UKPO staffs: The Patent Director, two patent examiners and two secretarial staffs.
The session is exactly as described by the FFII report. On arrival, we are randomly divided into 6 groups. My group is group 3 (white). Before the session starts, there is a tea session where people are probing each others' views on software patents. The most active participant is a patent attorney who seems to be more interested in getting others' opinions, while keeping his to himself. As the session starts, a person leaves an "anti-software patent" card on each table. It uses penalty kick in football (soccer) as an example. Effectively, to get software patent through -- i.e., kicking the ball into the net -- the player simply has to kick again and again, and the size of the goal month is adjustable.
The session starts with the Patent Director introducing himself and his staff and giving us instructions on what to expect in the session. The session starts with a group discussion on applying four definitions of patentability to 5 case studies concentrating on one topic: technical contribution. At the same time, we are asked to evaluate which definition is the easiest to apply, after which our opinions are tabulated into a chart. Then, each group has to elect a spokeperson to talk about the discussion in general, and individuals are given a chance to voice their opinions. At the end, a volunteery straw poll is taken on three questions:
(1) In your opinion, are any of the examples in the case studies patentable, applying whichever definition of patentability one fancies of the four
(2) Is software patentable or not?
(3) At the request of one participant: To which category do we classify ourselves: techie, lawyer, both, or neither.
The answer to (2) is 10 YES and 16 NO. For (3), it is 15 techies, 1 lawyer, 4 both, and 5 neither. I noted a strong tendency for patent attorneys to classify themselves as both rather than mere lawyers. Please remember that answers are not compulsory, so that is why the number of answers do not add up to the number of attendees, for you math-oriented folks.
It is important to note that the results of my session do not in any way represent the concensus for all the workshops. From other reports, different sessions do come out with distinctively different results.
One other point from this session I thought was significant is that there are 5 persons to a group, and despite efforts to in randomize the member composition of the tables, at my session, patent attorneys are heavily concentrated at one table. On the question on patentability of software, I noted that 4 persons from that table said software should be patentable, bucking the general trend of the group as a whole.
On the sheets of papers we were given, it is mentioned that the purpose of the workshop is to see whether it is possible to find a definition that give broadly the same results as the current "technical contribution" test in European law but is clearer to apply. UKPO says that while the case studies are hypothetical inventions, they represent borderline cases. There are 5 case studies and 4 definitions, hence in total, we have 20 cases to consider. We have approximately one hour to do so, hence on average, we needed to make a decision every 3 minutes.
It is important to note that we are supposed to assume the cases are "NON OBVIOUS" and NOVEL. Our duty is to review whether the claims in each case, *as a whole*, satisfy the "technical contribution" part of each definition. It is stressed to use that we are NOT deciding whether the patent should be granted.
Each case study contains a background description of what it is, together with a "Claims" section. It is the "Claims" section we are supposed to evaluate. The claims section consists of a few short paragraphs, each paragraph is, as we read it, worded as if they are separate mini claims. We therefore seek clarification from one of the Patent Examiners whether should we invalidate the claim if any sentence or paragraph in the "claim section" fails the "technical contribution" test. The patent examiner is understandably evasive by stressing that we are supposed to evaluate the claim as a whole. I take that to mean we do not have the "line strike" ability and the group decided that from his clarification, it means we must say the claims satisfy the "technical contribution" criteria if we can find one thing in the whole claim session to satisfy this criteria.
My group (group 3, white) consists of a journalist, a trainee lawyer, a software veteran now running a small software business, a software developer, and a university researcher (me). We decided to evaluate all case studies against one definition before moving on to another definition. Our methodology was, when evaluating each definition, we first would strike out sentences that were not the purpose of the session and concentrated on the rest.
We are each given a green-coloured result sheet to note down our decisions and are encouraged to put down what we think is important on the paper. There is a separate result sheet to note down the group decision and important concensus. All these were collected by UKPO at the end of the session.
For the definitions and case studies, I used the alphabet/numbers given to it by the UKPO.
The four definitions we were given are:
(A) The current definition used by UKPO: "'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."
As a group, our problem is that, after striking out parts that are not relevent to the workshop, we are left with no guidance at all. Given the fact that we were told the case studies are borderline cases, we have no choice but to pass every case study as satisfying the "technical contribution" test. We are so sure that our hands are tied that we did not bother reading any of the case study at all.
The session as a whole agrees that this definition does not give any guidance on what is a "technical contribution". A few pointed out that this definition concentrated on novelty rather than "technical contribution".
One participant, who says he is a non-lawyer but who has experience in filing for and being granted patents, and has successfully challenged the validity of another, opines that he likes the non-definition of "technical contribution," as it gives the court the ability to evaluate individual cases on their own merits. Jeremy, (one of the patent examiners) want to add a comment but was stopped by his boss. Later after the session, he says that he thinks this is not a good idea because it, in effect, leaves the definition to judges, and the definition will be decided on case law alone, with no clear guidelines.
(B)The FFII definition: "'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
The whole session finds it difficult to apply this definition. The term "controllable forces of nature" created havoc. One group argues whether "pushing electrons along circuits" constitutes forces of nature. In my group, I try but cannot persuade others who are not trained in telecommunications to agree that "dynamic allocation of bandwidth" is about "controlling forces of nature". More later in the case study.
Later, after the session, the suitability of this definition came out as we are picking the brain of a patent examiner. He says the some sessions find the definition, which consist of two sections -- the first paragraph saying what is patentable, the second saying what is not patentable -- difficult to apply. He says that this style of defining what's patentable and what's not can sometime cause unexpected difficulty.
(G) A definition that looks like a rehash of (B): "'Technical Contribution' should be applied to a putative invention
when considered in its entirety if that claimed invention is concerned
with new teaching in controlling forces of nature in a field of
"The processing, handling or presentation of information by a computer
program -- or abstract representations of programs and algorithms --
should not be considered technical, even when that processing, handling
or presentation of information is part of larger putative invention that
makes a technical contribution, and even when technical devices are used
in the processing handling and presentation of information."
The first problem we have is to determine how is this different from (B). In fact, we actually spent time debating if it is different from (B). In the end, because of the way it is worded, we decided that "technical contribution" is more stringent. This view was echoed by other groups. Based on this observation, for the case studies, we reviewed only cases which satisfied (B) to see whether it still satisfied (G), since anything that fails (B) must fails (G) as well.
(K): "'Technical contribution' means a contribution made by a claimed
invention, considered as a whole, to the state of the art in and limited
to a declared field of technology.
"'Computer-implemented invention' means any invention the performance
of which involves the use of a computer, computer network or other
programmable apparatus and having one or more prima facie novel features
which are realised wholly or partly by means of a computer program or
"The processing, handling, and presentation of information by a
computer program is not technical, even where technical devices are
employed for such purposes.
"Implementation of a software solution on a platform or architecture
not itself supported by the claimed invention is a separate contribution
and is excluded from the claimed invention."
This definition first defined "Technical contribution" as a claim that, as a whole, contributed to the state of the art in and limited to a declared field of technology. It then defined "computer-implemented invention" as anything that uses a computer or programming device and that a computer program is one of the main feature of the claim. The third paragraph contained the standard information that processing, handling and presentation of information by a computer program is not patentable. In the last paragraph, it stressed that reimplementing the software solution on a different architecture is permissible.
The last paragraph causes a lot of debate on why it is included. Most group says that, if the paragraph is struck from the definition, it is possibly the "least difficult" definition to apply.
However, at least two groups says that it is very ambiguious and open to interpretation, thus, potentially too permissive. For example, what constitutes "data" and what is "processing"?
Overall, the impression is that a common flaw of the definitions in B/G/K is that they do not define "data", "processing", "handling" and "presentation" and that we need a cast-iron definition for all the terms.
One patent attorney correctly raised the point that the definitions should not be too technology-related as this would not stnad the test of time. Another says that it is important to visit the definition of "obvious" too.
If you wish to read the case studies, to follow along in detail, here is the page.
I think it is important to stress the difference between "technical contribution" and infringing a patent. In the UK, there are at least two sections: "technical contribution" claims and the actual implementation. Technical contribution is written in the claim to show how it is different from the state-of-the-art. But you are infringing the patent if, and only if, you are reproducing the "technical contribution" USING the claimed implementation. Hence, it means if you reproduce the technical contribution using a different implementation, you are not infringing. This is the description given by the patent examiner.
After presenting the case study, I listed the majority result for each definition and the session's view on whether the invention is patentable (if one is free to write any definition of patentability). I should mention all results were calculated on a "one attendee, one vote" system rather than "one group, one vote" system. For the latter question, one can choose not to answer.
Each case study begins by giving some background information. This background information just set the scenario. We are to concentrate on the claims section.
Case study 4 is about digitally enhancing pictures taken in low light or night conditions. The claim is for a digital filter that:
creates a two-dimensional array representing the photograph, identifying an operator matrix that contains light-enhancement parameters, applying this matrix to the photograph and reproducing the same photo, this time enhanced.
As a group, we decided that the first -- "creates a 2D array representing the photograph" -- definitely fails the criteria. In the end, the question boils down to whether "applying the operator matrix to get an enhanced photo" constitutes a "technical contribution". In definitions B,G,K, the question is whether this constitutes "processing of data". I argued that the actual "composition of the operator matrix" will separate it from mere traditional "processing of data". A lot of people disagreed.
The final results:
(A) YES (All)
(G) NO (large majority)
Should it be Patentable?
In case study 10, the applicant developed a new operating system that is very secure and platform-independent. It is run as a virtual machine. It provides a set of standard tools. Each tool provides its own data structure and creates Graphical User Interface (GUI) elements. The applicant developed an Application Programming Interface (API) for programmers to use. The claim is for the API, specifically, a way of receiving parameters from a program, populating the data structure, and creating the GUI elements.
As a group, we have no doubt that it fails the "Controllable Forces" and the claim is simply "processing of data". Hence, we did not spend a lot of time on evaluating it against most definitions.
The final results:
(A) YES (Only one says no)
(B) NO (All)
(G) NO (All)
(K) NO (except 2)
Should it be patentable?
Case study 11 involved an improved manufacturing technique, to create custom chip for a specific purpose. The applicant developed a method of using probablility analysis to determine the scheduling of the functional components for the chip and used this to determine the chip floor plan (layout). The claim is for a method of manufacturing the chip to perform a particular computation by receiving the functional specification, then identifying relationship between individual function in the functional specification, analyze the relationship, and use it to determine the chip floor plan. Finally, manufacture the chip.
The fact that there is a physical manifestation of the result, i.e., a chip is being manufactured, weighs heavily in the mind of participants in this session. We know this because the patent examiner specifically asked us whether this is the most important consideration.
The final results:
(A) Yes (ALL)
(B) Yes (large majority)
(G) Yes (large majority)
(K) Yes (large maojrity)
Should it be patentable?
Case study 12 was about online gaming of Backgammon. A big problem is waiting for your opponent to respond to your move. The method is for the elimination of waiting time. The claim is on reducing the time delay in playing a traditional two-player game over the internet by creating a standard interface and presenting it to both the user and his opponent. Once the user makes 5 moves, based on what the system predicts of his opponent's move will do, the result is transmitted to his opponent, where the move is either replayed to the opponent if the prediction is correct, otherwise, a new prediction is done for the opponent. This is then transmitted to the user. The process is repeated until the game is finished.
[Aside: I have problem understanding how this could work.]
We, as a group, agree it is processing-of-data.
The final results:
(A) YES (3 No)
(B) NO (1 No)
(G) NO (All)
(K) NO (All)
Is it patentable?:
Study 13: A way of dynamically allocating bandwidth to different base stations according to the number of users it has. The claim is for mobile telephony to dynamically allocate bandwidth to base stations according to demands and to predict adjacent base stations that might require more bandwidth. The algorithm identifies the number of phones in a cell, monitoring "hand-off" data and generates a call for more bandwith. The algorithm also stores the hand-off path of a phone, and uses it to generate a bandwidth call for an adjacent cell.
A lot of participants believe this is simply processing of data and there is no "Controllable Forces of Nature". This is motivated by the fact that bandwidth is fixed by Mother Nature and the claim is simply "reallocation of existing bandwidth", even if it is a more efficient way of using existing resources. They are right.
However, applying my knowledge as a telecommunication engineer, I know that allocating bandwidth is a very big problem. The problem is that electromagnetic spectrum is a finite commodity. Bandwidth is an allocation of a part of this spectrum to different users. This is an age-old dilemma for all regulators/engineers: How to maximize the usage of this restricted commodity. In this case, it boils down to giving as much/as little bandwidth to suit the demand of a particular base station. This illustrated to me the importance of domain-specific knowledge in evaluating technical contributions.
The final results:
(A) YES (ALL)
(G) NO (Majority)
(K) NO (majority).
Is it patentable?: