decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
A Groklaw Suggestion on SW Patent Wording
Wednesday, June 01 2005 @ 07:53 AM EDT

You probably already know that the U.K. Patent Office recently reported the results of its workshops designed to come up with a definition of "technical contribution" for purposes of patent law.

The conclusions of the report were not good news for anyone involved in Europe's great software patent debate. None of the definitions1 seemed to work. None resulted in a perfect match with what the UKPO views as current patent law.

There was considerable confusion over the definitions and what to do with the case studies. When participants were asked whether software patents should be allowed, at many workshops several participants immediately responded with "What do you mean by software"? That is, actually, the right question.

The workshops' participants were lawyers (35%), programmers (55%), and 10% from academia, the media and other organizations. You would assume a level of sophistication, and yet they did not vote for or against patentability on hypothetical case studies in harmony with projected results, using the definitions given. In fact, all of the definitions, the report concluded, would "make a significant change to the boundary between what is and is not patentable."

Significantly, at each workshop the tested Definition A was the definition used in the Council of the European Union's common position on the European Commission's patentability of computer-implemented inventions directive ("CIID") [PDF], and Definition B was the definition submitted by the U.K. chapter of the Foundation for Free Information Infrastructure, based on the language advocated by FFII before the European Council and Parliament.

Neither those definitions nor any other fared well in the U.K. Patent Office's view. Their report concluded:

It is clear from the workshops that none of the definitions as they stood:
  • had wholehearted or even widespread support;
  • tallied closely with the status quo when applied by the attendees at the workshops (i.e., they would all make a significant change to the boundary between what is and is not patentable);
  • was unambiguous (i.e., gave a near-unanimous answer in most cases)[.]
The European Council's definition received surprisingly low marks in the report. The results indicate -- just as opponents have been saying all along -- that it is so poorly worded, it would open the floodgates for software patents rather than preserving the status quo, its purported goal.

Since no one has come up with ideal language yet, we thought Groklaw might take a shot at it, and here we present suggested wording, for your consideration. Note that views on software patents and how they should be handled vary. Our objective was to see if better language could be devised to accomplish the UK Patent Office's stated goal.

In the U.K. Patent Office's words, here's what they found wrong with the CIID wording in this real-life test:

It would be fair to say the workshops felt definition A, taken from the Council of the European Union's common position, did not achieve what it sets out to achieve. It was ambiguous -- possibly because the references to novelty and non-obviousness confuse the test -- and appeared to be more permissive than current European law in terms of what is patentable.

On the FFII proposal, participants agreed it was better than the common position definition, and the best -- if the goal was to abolish all forms of software patents. But still, they felt that it would allow some software patents and many disagreed on the FFII definition's interpretation. Indeed, the workshops approved one of the test case software patent claims under the FFII definition.

Now what? Obviously, it may be back to the drawing board for all concerned. In the aftermath of the workshops, before the UKPO published its report, Groklaw folks from both sides of the Atlantic, including legal and software engineering professionals, began a collaboration to develop a definition for "technical contribution" that meets the needs of FOSS developers and end users. We had already polled our readers for their ideas, and after that, a small group started trying to formulate language that might be helpful. Following some 30 drafts, the proposed definition of "technical contribution" is set forth below and is ready for your review. If there is one thing we've learned from the effort, it is that finding the right language is a lot harder than it looks. If you spot a way to improve our language, please say so. This is our draft language:

The Groklaw definition

1. Applicability. As applied to all patents involving any computer or other programmable device or otherwise involving the automated processing of information, the following provisions shall apply:

a. Exclusion: A patent application and issued patent may, without thereby invalidating it and to the extent needed to explain the invention claimed, include a description of software; but no storage, communication, manipulation, or transformation of information in a software-controlled process, however described, shall be construed as being within a patentable field of technology or to constitute a technical contribution, nor shall any software or other information otherwise be construed as patentable subject matter. In interpreting these provisions, the following definitions shall apply throughout:
i. "Technical contribution" means a substantial advance to the state of knowledge in a field of technology made by a claimed invention considered as a whole.

ii. "Software" means any and all instruction sets for a physical device or for networked physical devices but shall exclude all carriers or physical devices. However, "software" shall include, inter alia, any representation of software in any manipulable physical state of a carrier or physical device.

iii. "Physical device" means any hardware computer, peripheral device, or other physical apparatus employing a carrier that alone or in combination performs, inter alia, computation, information storage, or communication tasks, but shall exclude any information so computed, stored, or communicated.

iv. "Carrier" means a force of nature manipulated for purposes of conveying or storing information, but shall exclude any information so conveyed or stored.

v. "Information" means any and all assignments of discrete symbolic meaning to a discrete manipulable physical state of a carrier or physical device, without regard to levels of abstraction of such information. "Information" shall be construed in its most inclusive sense and shall include, inter alia, all software and data.

The Groklaw definition draws from European Patent Convention Article 52 ("EPC/52") and amendments submitted by members of the European Parliament ("MEPs"), as well as ideas presented in the U.K. Patent Office definitions, scientific principles, numerous patent legal materials, and invaluable feedback from the FFII and others.

It should also be noted that the Groklaw definition focuses on defining "technical contribution" but does not specifically address other thorny issues around the CIID and Council common position, such as program claims and interoperability.

The Groklaw definition prohibits software patents by dividing the computing universe into three sets: (i) physical devices; (ii) carriers; and (iii) information. Software in turn is recognized as one subset of the information set, which also includes (but is not limited to) data. The Groklaw definition's language prohibits the patenting of all information clear down to the bit level. Our approach of singling out "information" as the key is not our original idea. A careful reading of EPC/52 will show that the non-patentability of information is an implicit underlying principle. Moreover, drawing that line has been called for in at least several separate proposals by MEPs. Just three examples:

Amendment 236 by MEPs Lichtenberger & Frassoni, justification text:
The dividing line between the material and immaterial world, and hence between what is patentable and what is not, can be defined with legal certainty. Once a physical signal is digitised, it becomes symbolic information, which can be manipulated in an abstract fashion in software, with no possible technical effect.
Amendment 191 by MEPs Kudrycka & Zwiefka, justification text:
Art 52 EPC says that programs for computers etc are not inventions in the sense of patent law, i.e. that a system consisting of generic computing hardware and some combination of calculation rules operating on it can not form the object of a patent. It does not say that such systems can be patented by declaring them to be "not as such" or "technical". This amendment reconfirms Art 52 EPC. Note that the exclusion of programs for computers is not an exception, it is part of the rule for defining what an "invention" is.
Amendment 141 by Kauppi, MEP:
Member States shall ensure that the distribution and publication of information, in whatever form, can never constitute direct or indirect infringement of a patent.
Our intended recipe to avoid backdoor software patents, by the way, is this: when a computer is involved in producing a physical effect, you mentally replace the software with a "magic" (but non-technical and non-patentable) black box that does the same thing by unspecified means. Is what is left a technical contribution? If not, the invention is non-patentable. If so, the invention is patentable, but the software remains non-patentable.

We strove to identify language that can satisfy the needs of appliance manufacturers to protect their inventions, but protect SMEs and individual software developers from the software "patent thicket." -- Lord Sainsbury expressed a similar desire at the meeting at the DTI (Department of Trade and Industry) in December. So, we tried for a balance, not making the presence of software an unfair hindrance to obtaining a patent for a device. Here, we took our guidance from EPC/52 itself. The original intent of its prohibition against patenting of software "as such"2 was to allow necessary software to be discussed in patent applications, but to deny any patent protection for such software. Therefore we have included that concept in the Groklaw definition.

Where software is part of the way a new apparatus (which has inventive physical aspects) works, you may end up with a situation where there is only a single algorithm capable of realising the invention, and therefore the patent to the invention as a whole does implicitly impact upon the software for that invention. The definition would nonetheless allow a patent on the apparatus; but that is different from allowing the software itself to be patented.

So the manufacturers of mobile phones, or car engine management systems, or traffic lights, would be able to patent appliances which may include software as the method of accomplishing a patentable technical process. But those patents would not stop someone else interoperating with their equipment, nor block access to or use of the information (i.e. software) in the devices. The software, being information, may still be protectable by copyright, trade secret law or reverse engineering restrictions. Combined with the patent protection available for the apparatus as a whole, we believe this offers enough protection for the genuine innovator to secure the market advantage they deserve.

One might quite reasonably ask: "Why not simply say 'you can't patent software'?" There are a number of reasons, such as:

(1) You have to define what is and is not software. For example, someone might be attempt to patent an XML word processor format on the grounds that a data format "isn't software." It is all too easy, though, to fall into an endless regress of definitions, so we've tried to reach the "terra firma" of terms with established scientific/legal definitions.

(2) A simple declaration "no patents on software" could be interpreted narrowly -- to have the same meaning as the current "no patents on computer programs as such" -- in which case no progress would have been made.

(3) To guard against the de facto software patent, that is, a patent that doesn't mention software but that you cannot avoid infringing by writing software on a PC that enacts the claimed process.

(4) To make clear, because of EPC/52, that "no software patents" does not mean that non-informational computing inventions are also non-patentable.

(5) So that the definition would be sufficiently explanatory that all concerned, both laypersons and experts, would be able to understand not only what is excluded from patentability but also why it is excluded.

(6) To invite debate on whether software is, in fact, information and if so, unpatentable.

One thing that came out very clearly from all the activity around the workshops, both there and here at Groklaw, was that finding the right wording was no easy task. For sure, this latest proposal won't be perfect; but perhaps you can improve it further.

1 Participants were invited to send in wording that they thought would work, and from the 208 suggestions received, the UK Patent Office chose 12. While not all were considered at each of the 13 workshops, the 12 different definitions of "technical contribution" were tested against 18 hypothetical "invention" case studies during the workshops, which were attended by some 300 persons. You can read the case studies used here and in more detail here.

Of the hypothetical cases, 9 inventions were considered to be patentable and 9 were considered to be unpatentable under current law by the UKPO. Breaking it down further, cases 1-5 were thought to be clearly patentable under current law, 6-10 were considered clearly not patentable under current law, and the rest were borderline, half leaning toward patentability and half not.

Each case study took the form of a brief background and explanation of an imaginary computer implemented invention. In each case, the explanation formed the basis of a claim which was used in the workshops to test possible definitions of technical contribution.

2 On EPC/52's original intent and the history of its erosion, see the articles collected by FFII on its Art 52 EPC: Interpretation and Revision page.

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )