Software Patents from the Inside. There has been much lamentation and gnashing of teeth in recent times about the evils of software patents. There is wild controversy about whether the whole idea is fatally flawed—for example, Dave Winer has argued that software patents are bad economics and (in the U.S. context) constitutionally unsound. Further, there is a widely-held belief that the US PTO has been too uncritical, and insufficiently attuned to prior art, in issuing such patents. Here’s a confession: I currently have two software patents in the US PTO pipeline, and did some work on them last week. Herewith some narrative of what the process is like from the inside, with commentary on the broader issues... [ongoing]
Interesting article, worth a read.
I am struck by this:
Are Software Patents a Broken Idea? ... It felt much more rigorous than the way we go about inventing new technology in the software space...
and reminded of an old Morcombe and Wise sketch with Andre Previn in which Eric is supposedly playing some classical piece but plays Chopsticks - to a complaint from Mr Previn Eric replies "its all the right notes, but may be not in the right order".
I just don't see invention in the software space. Each new line of code I write could be considered an invention - rather too many US patents are really expressed by just a relatively few lines of code - and often they are an old tune just played in a different order.
Yesterday I invented a way of turning floating point numbers into strings ('cos an OS routine was broken) without relying on floating point libraries (it was an invention to me) - should I (try to) patent it? Today I invented a way of passing licensing information around within a process space - should I patent it? Twaddle I should, both are built on other library code and both took about 5 minutes of thinking.
posted at: 11:16:56 PM 
|
