Posted on 05/05/2009 8:41:19 AM PDT by ShadowAce
Six months ago I noted that the European Patent Office had embarked upon a fairly abstruse process:
a referral of a “point of law” concerning software patents by the President of the European Patent Office (EPO) to the EPO “Enlarged Board of Appeal”, something that seems to happen quite rarely. Now, you do not have to be a genius to see the problem with this; essentially, the EPO is asking itself whether it wants to widen its own jurisdiction, increase its power and boost its income by allowing software patents. Unless the Enlarged Board of Appeal consists entirely of self-denying, altruistic masochists, I think we can all guess what the answer will be.
The comments period ended last week, and just before the deadline passed I was wrestling with the issue of whether I should send something in. As regular readers of this blog will know, I am not particularly shy and retiring when it comes to offering my opinions on matter dear to me, but on this occasion, I decided not to send anything.
My reasoning was that this was an extremely technical consideration of the issue of software patents, and that the people pondering the matter would not be interested in vague philosophical waffle about why software patents were a bad thing. They would be looking for keenly-argued, legalistic comments of the kind I was manifestly unable to provide.
Instead, I thought it better to leave this one to those better able to obtain some heavy legal advice on what should be written, and how. Among those doing precisely that, was Red Hat:
Today Red Hat took its efforts to confront the problem of software patents to new ground by filing a brief with the European Patent Office. The brief explains that software patents hinder software innovation, and that there is a sound legal basis not to expand availability of such patents in Europe.
Now, a little while back I wrote a piece called “A Question Red Hat Must Answer” - the question being where exactly it stood on software patents. Happily, this present submission to the EPO leaves us in no doubt. But it goes well beyond establishing Red Hat's bona fides: it presents one of the best introductions to why software patents are so harmful to free software.
It begins by presenting a short history of software patents:
The historical record of innovation in software shows that, both for open source and proprietary software, remarkable progress in the U.S. and Europe occurred prior to the time that software patents became generally available. Innovative open source software projects began to appear by the early 1980s.
At that time, software patents were relatively few in number and case law was interpreted to limit their availability. See Diamond v. Diehr, 450 U.S. 175, 185-86 (1981). By contrast, it was already settled that copyright law covered software. Thus the early innovators of open source software had no reason even to consider obtaining patents on their work, and in fact opposed software patents.
Such opposition is not surprising, because the open, collaborative activity at the heart of the open source model is fundamentally at odds with the patent system. Patents exclude the public from making, using, or selling patented inventions. An open source developer seeks to contribute code to the community -- not to exclude others from using the code. The exclusionary objectives of the patent system are inherently in conflict with the collaborative objectives of open source.
It then pinpoints the problem with software patents:
Software patents are generally claimed in relatively abstract language, compared with patents concerning other subject matter, and as a result their boundaries typically are vague and ill-defined. Therefore it is often not possible to be confident that a particular patent does not read on a particular new product.
Moreover, there is no reliable, economical method for searching the hundreds of thousands of existing software patents that would allow a developer to rule out the possibility that a new product (which may have hundreds or thousands of separate components and features) infringes one or more patents. Thus simply by virtue of producing and marketing an innovative software product, a software developer assumes an unmeasurable risk of a costly patent infringement lawsuit.
It concludes its historical discussion thus:
In sum, legal changes in the U.S. that have allowed software patents have not served the purpose of promoting innovation. Experience has shown that such patents are not only unnecessary but actually detrimental.
They discourage innovation, by imposing costs and risks on software development that would not otherwise exist. As discussed below, however, the U.S. Court of Appeals for the Federal Circuit recently appeared to recognize that the existing system must be substantially modified, and it has provided an approach for repairing the system.
The last point being a reference to In re Bilski, which many believe could substantially change the US position on software patents.
Red Hat's submission then goes on to interpret the main definition concerning software patents in Europe, Article 52 of the European Patent Convention, and proposes doing so “According to Its Plain Language”, particularly with reference to the vexed issue of what on earth the famous “as such” included there means:
Under the approach here proposed, Article 52 should be read according to its plain language. "As such," as used in Article 52(3), is properly interpreted according to its ordinary meaning of "in and of itself or themselves, separate and apart from other things or processes." Under this approach, a computer program could be part of a larger patentable invention, even though it could not in and of itself be a patentable invention.
This possibility is noted in T 0204i93 AT&T, where the Board said that "a computer may control, under control of a program, a technical process and, in accordance with the Board's case law, such a technical process may be patentable." The Board inT 0204/93 further noted that "computer programs as such, independent of such an application, are not patentable irrespective of their content, i.e. even if that content happened to be such as to make it useful, when run for controlling a technical process."
Having done this, it then finishes by addressing the particular points of the EPO's questions (also discussed in my original post last year). It summarises its views as follows:
For the reasons set forth above, Article 52 should be read according to its plain language. "As such," as used in Article 52(3), is properly interpreted according to its ordinary meaning of "in and of itself or themselves, separate and apart from other things or processes."
Under this approach, a computer program could be part of a larger patentable invention, but it could not in and of itself be a patentable invention. Reading extraneous distinctions concerning the technical character of computer programs into the words "as such" has created a set of intractable interpretive problems. We therefore respectfully request that the Enlarged Board reaffirm the plain language of the computer program exclusion. This approach is consistent both with the language of the EPC and sound policy promoting innovation in software development.
Red Hat is to be commended not only for calling for software patents to be judged against a literalistic – and hence minimalist - interpretation of the European Patent Convention, but also for producing such a clear introduction to what is a hideously complex area. Its submission is well worth reading by anyone who wants to get their head round the subject without guaranteeing themselves a serious headache along the way.
How very diplomatic of them to avoid mentioning that another reason software patents aren’t feasible is that patent examiners are too stupid to review software and thus are likely to issue a patent on “PI = 3.1416” or something.
But you're correct. Patent examiners, because they are patent examiners and not IT people, cannot verify with any authority the reasonableness of any example of code.
From the article above: "Software patents are generally claimed in relatively abstract language, compared with patents concerning other subject matter, and as a result their boundaries typically are vague and ill-defined."
This just isn't true. Examiners issue lots of rejections all the time about lack of clarity, and read claim language as broadly as humanly possible to force more detailed and clear claim language from the inventors.
"Moreover ... a software developer assumes an unmeasurable risk of a costly patent infringement lawsuit."
Every company - not just software developers - run an "unmeasured" risk of patent infringement.
When I worked at PacBell, I encountered many persons from Bellcore with patents. The patents were for exceptionally simple things. Some that I had done hundreds of times before. Trivial things. AT&T, Bell Labs and Bellcore encouraged this rampant seeking of patents to give the lawyers fodder to attack competitors in the future.
Well, for something to be patentable, it’s supposed to be somewhat novel and non-obvious. I don’t think they’re up to evaluating novel and non-obvious for software, which is why we end up with patents for “shopping carts” on websites.
Sorry, they just don't have the expertise, and let mumbo-jumbo make it sound like something is original. Take the common example of 1992 patent 5,175,857:
A method and apparatus for sorting object data, the object data having a data format of a next address and a record. The next address indicates the address of another object data, and the record includes information data which is the subject of the sort. The sorting method and apparatus perform two sorting processes. The first process performs a divisional sort which sorts the object data into blocks of object data; these blocks being sorted with respect to one another. In sorting the object data into these object data blocks, it is unnecessary to actually move the object data within the memory. Instead, only one address of an object data out of all the object data in a block needs to be stored. Use is made of the next address of the object data to link the remaining object data to the single object data stored in an object data block. Then the second sorting process performs a sort of the object data in each block; thus all the object data becomes sorted. By the combination of the two sorting processes, an overall sort of the object data is performed in less time.Ooh, sounds good. You don't even have to move data to sort! Wow, that's fast! A programmer knows it just describes a data structure known as the doubly-linked list, something invented and published in the 50s.
Then we have the sorting. Break large chunks into smaller ones, then sort those. Sounds great too. The larger sort he describes is a partial Quick Sort from the 60s, which is very fast on large datasets, but has a very bad worst-case, followed by a 1970s Bubble Sort on the remainder (claim 4, "adjacent record exchange method"), which is efficient on small data sets, but not large ones. The problem is the patent is basically describing a Comb Sort, which was invented solely to leverage the small dataset speed of the Bubble Sort without incurring the performance hit it has on large datasets by sorting on larger gaps (his first pass) before going down to where a Bubble Sort is efficient (his second pass).
Basically, anyone who knows anything about data structures and sorts would have laughed at this patent application.
I'm not saying the patent is good or bad - just that you've not even started with the correct approach.
Look, I'v seen some really crappy patent language w.r.t. software patents - and some really good language. I did an infringement opinion on a particular patent only to tell the client that the language was nearly impossible to make sense of, and then did an invalidity opinion that basically allowed me to confidently say that the bounds of the claim language could not be extended to cover my client's product without being anticipated by at least four other patents.
Anyway, there are some good examiners and some crappy ones. I've seen really bad decisions coming from the USPTO's Board of Appeals and Interferences as well. These people aren't always as technically qualiied as they need to be, but that extends to a LOT of different tech areas.
That was just to get you started. The argument I gave against the patent included what was from specific claims. For example, I said "bubble sort" when a claim said exchange sort. A bubble sort is the most common form of this going with the description in the claim.
All I can say is that as a developer myself I have rarely seen software patents covering that which couldn't be accomplished by any competent developer "versed in the art," or that hasn't already been done.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.