This ruling in no way shows that the USPTO did anything wrong. If the courts tell the USPTO to grant patents on everything, that's what they'll do; if the courts change their mind and tell the patent office to reject obvious patents, then the patent office will gladly do so.
If you look a the PDF, you'll see repeated reference to a line in KSR v Teleflex, a ruling from just last year: "The combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results." This is entirely common sense, but it wasn't how the Federal Circuit's appeals court saw things when the BB patent was granted, so the patent office didn't have the power to use such logic to make a rejection until KSR v Teleflex. And there are more recent rulings, some already handed down by the Federal Circuit's appeals court and some on the way, further reigning in what is patentable and giving the patent office the power to reject patents like the BB patent.
So the USPTO is (and has been) doing the right thing under the law: when the law was a watered-down mess that said that anything is patentable, they rubber-stamped. Now that the courts are granting them the power to reject again, they're using that power. Expect to see more rejections like this in the near future.
Why did I write a book about a polarized topic?
This is a fine, fine question, which I had in the back of my mind the
entire time I was writing.
--First, there are a surprising number of people who are not decided
on the software patent thing. Many of them work in the Senate and House
office buildings. Frankly, those guys were my primary target audience,
and I've made sure that at least a few of them get copies of the book,
because lobbyists for certain corporations are talking to the
same people. It's the least I could do.
[And as you can imagine, handing them a book works a whole lot better
than handing them a web page printout.]
--Second, I can tell you that many people who are pro-software patent
are reading the book---notably, patent attorneys. They are looking for exactly what many people in this
thread are looking for: a decent solution to the warts that the system
has displayed to date.
--Third, among those who are opposed to software patents, there's a lot
of misinformation, and I feel the debate is often going in the wrong direction. After studying the question for a few years, I strongly
believe that the problem is not about obviousness, and it's not about
details of enforcement.
I wrote the book, and made sure that Chapter 6 was online (the review
links to it) to bring forth what I take to be the root cause: patents
make no sense in a decentralized industry like software. [For more
explanation of this point, read the fine chapter.]
Even if I were only preaching to the choir, I felt that pushing the
debate away from obviousness and enforcement, and toward questions of
patents in a decentralized industry, would be a valuable contribution.
--Fourth, you'll notice that many of the commenters who got past the first
sentence of the review are looking for a decent line between software/business
method patents and more traditional patents. I'm sorry if this sounds
like I'm plugging my own book, but it's very difficult to draw that
line in a comment thread or a 750 word article. There's a case history for context, and questions about the effects various lines could have,
and questions about testing the limits of any distinction. I can't count
how many people have asked me `yeah, well what about FPGAs', so FPGAs
got a page or two.
Those who think that the question is
interesting, whether they agree with me or not,
are picking up the book.
So, that's why I wrote a book about a polarized topic, and my understanding of who's reading it.
--You're welcome to find a pro-software patent book, except there aren't
any. The best you'll find are a few academic articles, most published
since my book came out, that just fail to reject the hypothesis that
software patents do no harm.
And the Supreme Court is going to do it again soon. See This Brookings op-ed for some predictions and discussion about the Supreme Court's work with patents.
Meanwhile, just ignore the Congress. Nobody on the Senate Committee has much interest in really rocking the boat here. Further, they all know that there's no point spending political capital on fixing something that the Court can do by fiat. So you are guaranteed that nothing will happen until the Supreme Court rules on Metabolite, and decides whether to take on KSR v Teleflex and how to rule therein. That could be another year, during which Congress will at best hold more hearings and put out more press releases.
I use things originally written by Mr. Stallman about every day---notably gcc and gdb. It takes a special kind of brilliance to write a debugger---one that I certainly will never have---and I admire him for doing such great and valuable work.
His comparative advantage, and his most successful means of bringing people to the Free Software movement, is in writing good code. Too bad he doesn't do that anymore.
is George Meyer. Here is an interview that shows how his sense of humor was what made the Simpsons really, really funny for those seasons. After he left, it was mere mortals who were writing the show.
The Patent Reform Act of 2005 is in Congress now. As explained in this Brookings editorial, it is an appropriate place to include language limiting patentability. I can't force you to do something in particular, but maybe we can get out of this mess.
We make fun of people who insist that they profit from any surplus from their work--the people who say that if anybody anywhere is enjoying "Happy Birthday", then its owner should get paid for that enjoyment.
Why do we want all coders to turn into that? If people don't want to waste their time capturing every last million dollars in value that their code produces, then whatever. It is true that the average geek is way too averse to the conflict around splitting surplus, but to say that anybody who doesn't get the most surplus s/he possibly can is some sort of tool is to impose MBA values on the rest of us.
[Personal PS to multinationals: here is my own open source project. Please, find a way to make millions of dollars off of it.]
Slashdot Mirror
If you look a the PDF, you'll see repeated reference to a line in KSR v Teleflex, a ruling from just last year: "The combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results." This is entirely common sense, but it wasn't how the Federal Circuit's appeals court saw things when the BB patent was granted, so the patent office didn't have the power to use such logic to make a rejection until KSR v Teleflex. And there are more recent rulings, some already handed down by the Federal Circuit's appeals court and some on the way, further reigning in what is patentable and giving the patent office the power to reject patents like the BB patent.
So the USPTO is (and has been) doing the right thing under the law: when the law was a watered-down mess that said that anything is patentable, they rubber-stamped. Now that the courts are granting them the power to reject again, they're using that power. Expect to see more rejections like this in the near future.
--First, there are a surprising number of people who are not decided on the software patent thing. Many of them work in the Senate and House office buildings. Frankly, those guys were my primary target audience, and I've made sure that at least a few of them get copies of the book, because lobbyists for certain corporations are talking to the same people. It's the least I could do.
[And as you can imagine, handing them a book works a whole lot better than handing them a web page printout.]
--Second, I can tell you that many people who are pro-software patent are reading the book---notably, patent attorneys. They are looking for exactly what many people in this thread are looking for: a decent solution to the warts that the system has displayed to date.
--Third, among those who are opposed to software patents, there's a lot of misinformation, and I feel the debate is often going in the wrong direction. After studying the question for a few years, I strongly believe that the problem is not about obviousness, and it's not about details of enforcement.
I wrote the book, and made sure that Chapter 6 was online (the review links to it) to bring forth what I take to be the root cause: patents make no sense in a decentralized industry like software. [For more explanation of this point, read the fine chapter.]
Even if I were only preaching to the choir, I felt that pushing the debate away from obviousness and enforcement, and toward questions of patents in a decentralized industry, would be a valuable contribution.
--Fourth, you'll notice that many of the commenters who got past the first sentence of the review are looking for a decent line between software/business method patents and more traditional patents. I'm sorry if this sounds like I'm plugging my own book, but it's very difficult to draw that line in a comment thread or a 750 word article. There's a case history for context, and questions about the effects various lines could have, and questions about testing the limits of any distinction. I can't count how many people have asked me `yeah, well what about FPGAs', so FPGAs got a page or two.
Those who think that the question is interesting, whether they agree with me or not, are picking up the book.
So, that's why I wrote a book about a polarized topic, and my understanding of who's reading it.
--You're welcome to find a pro-software patent book, except there aren't any. The best you'll find are a few academic articles, most published since my book came out, that just fail to reject the hypothesis that software patents do no harm.
Meanwhile, just ignore the Congress. Nobody on the Senate Committee has much interest in really rocking the boat here. Further, they all know that there's no point spending political capital on fixing something that the Court can do by fiat. So you are guaranteed that nothing will happen until the Supreme Court rules on Metabolite, and decides whether to take on KSR v Teleflex and how to rule therein. That could be another year, during which Congress will at best hold more hearings and put out more press releases.
I use things originally written by Mr. Stallman about every day---notably gcc and gdb. It takes a special kind of brilliance to write a debugger---one that I certainly will never have---and I admire him for doing such great and valuable work.
His comparative advantage, and his most successful means of bringing people to the Free Software movement, is in writing good code. Too bad he doesn't do that anymore.
is George Meyer. Here is an interview that shows how his sense of humor was what made the Simpsons really, really funny for those seasons. After he left, it was mere mortals who were writing the show.
[Disclaimer: I'm the author of the editorial.]
Why do we want all coders to turn into that? If people don't want to waste their time capturing every last million dollars in value that their code produces, then whatever. It is true that the average geek is way too averse to the conflict around splitting surplus, but to say that anybody who doesn't get the most surplus s/he possibly can is some sort of tool is to impose MBA values on the rest of us.
[Personal PS to multinationals: here is my own open source project. Please, find a way to make millions of dollars off of it.]