Although there is no 'breakthrough' news on the subject of software patents, Digital Majority has some picks of interest. They shed light on where things stand.
Patent Trolls
Cisco went on the record criticising the current patent system. Cisco's former intellectual monopolies director, Rick Frenkel, turned out to be Patent Troll Tracker an then sued, but Mark Chandler's remarks seem similarly critical.
Mark Chandler - senior vice president of legal services and general counsel of Cisco Systems - said that "technology companies all too often find themselves as defendants in patent suits". Is it a sign that software patents contribute negatively to the benefit balance of the patent system for software firms?
After failing to get Congress to pass a patent reform bill, some large technology companies have decided that if they can’t beat the patent trolls, they can at least use some of the trolls’ own weapons against them.
Called different names—patent trolls, non-practicing entities (NPE), third-party patent holding companies—depending on who’s talking, trolls typically buy patents and then try to extract license fees from large corporations that they allege infringe on those patents. They have long been a thorn in the side of companies with successful products and deep pockets. But in the last five years, the problem has gotten worse as more money has flowed to NPEs (see sidebar, "Trolling for dollars").
Some Background
A couple of new posts explain how software patents came about in the first place:
However, with the addition of software and business method patents in the 1980’s, the statute has been the subject of dispute. Until about 1981, the U.S. Patent Office held that steps performed by a computer were unpatentable under at least €§ 101. However, in Diamond v. Diehr, 450 U.S. 175 (1981), the Supreme Court overruled the Patent Office and held that, though an algorithm and the like are abstract and unpatentable, the fact that an otherwise patentable process is carried out on a computer does not make it unpatentable.
In 1995, the U.S.P.T.O. decided it was time to develop guidelines for patent examiners that reflect these recent court decisions. After releasing draft versions of the guidelines for comment, the U.S.P.T.O. adopted guidelines for U.S.P.T.O. examiners to determine when a software related invention is statutory and therefore patentable.
When code can be produced so rapidly with just a keyboard and a $20 second-hand PC, the barriers imposed by software patents become significant. When this code is distributed, i.e. duplicated ('manufacturing' equivalent), then the R&D-equivalent cost becomes much greater and serious problems are encountered. Here is a post that conveys part of this conundrum.
Collecting the information necessary to prepare a patent application covering a computer related invention can be quite challenging. Typically, most computer related inventions today relate at least in some way to software, which is at the core of the challenge. This software challenge stems from the fact that the software code is not protected by patent law, but rather how the software operates is protected. This means that the description needs to be one that can be replicated by others regardless of how they choose to write code to accomplish the necessary tasks.
A patent does not need to be a blueprint, but it needs to direct. For example, you do not need to provide the code for the scripts, although that is certainly one way to make sure it is described adequately.
Papers
The following paper from Duke[PDF] explores the issue of code ownership at universities.
University policies towards ownership of software have recently become quite controversial. In this paper, we present what is to our knowledge the first systematic study of such ownership. We rely in part on a unique, hand-curated database of university software patents. The combination of our quantitative and qualitative research yields a number of interesting results. First, software patents represent an important, and growing, component of university patent holdings. Second, the main determinant of university software patenting is not computer science-related R&D (or even overall R&D) but the university's overall tendency to seek patents on R&D outputs.
I'm currently preparing a paper on the Open Source software developer's perspective on software patents (with a friend of mine, Owen Jones, who has the real expertise in patents), and so naturally I was interested in what the expert panel had to say about software patents.
An entire book has already been written on the subject and here is the latest review of this book (among several more reviews).
You'd have to do a lot of man-on-the-street interviews before you'd find someone who could explain the difference between a patent and a trademark. And even the relatively savvy participants in the Ars forums have been known to mangle copyright's fair use doctrine, misunderstand key provisions of the GPL, or foolishly assume that the law must track their own notions of common sense.
Yet the complex and esoteric legal regimes collectively known as "intellectual property"—copyrights, patents, trademarks, and trade secrets—have never been more important in the lives of software developers. Failure to understand the implications of key legal documents can prevent programmers from doing their jobs and enjoying the fruits of their labor. And because the free software community has learned to leverage the power of copyright law to protect end-users' freedom, understanding copyright law is especially important to developers of free software.
A report has been completed. It says, the inventive steps required to qualify for patents should be considerable, and the resulting patents must be well defined, as to mininise litigation and maximise the scope for subsequent innovators. In particular software and business method patenting is an Australian concern.
One of the heartening signs of things changing in the world of intellectual monopolies is that more and more groups and studies are coming out that highlight the manifest problems with the current system.
Appended below are some new (ish) video additions from YouTube which show not why patents are valuable; it helps in understanding how so-called 'inventors' think. It's underwhelming in places and maybe worth a glance over the weekend. ⬆
At this point it would be rather foolish to assume that IBM will let Red Hat just "do its own thing" or maintain its corporate culture, identity, projects etc.
