This post originated from an RSS feed registered with Python Buzz
by Ben Last.
Original Post: Microsoft Patent Basic Laws Of Universe
Feed Title: The Law Of Unintended Consequences
Feed URL: http://benlast.livejournal.com/data/rss
Feed Description: The Law Of Unintended Consequences
Reading and writing patents isn't really that complicated or difficult; I do it a lot (part of the job). True, a professional patent attorney does the final writeups, but anyone used to the exact and technical way in which engineers write documents can pick it up.
The first thing to remember is that the claims are the key thing. The rest of the document just sets the context for them, and can make wild and sweeping statements of all sorts (and you might be surprised at how many do). The next point is that a single claim is a thing indivisible, an atom if you like. For example, Claim 1 of the offending patent runs thus:
1. A method for expanding the functionality of an application button on a limited resource computing device, comprising: (a) detecting that an application button associated with a limited resource computing device application has been pressed; (b) determining the length of time the application button has been pressed; (c) opening an application if the application button is released prior to the expiration of a threshold time limit; and (d) opening the application and automatically causing the application to display the last known state of the application if the application button is pressed, without being released, for a period equal to or in excess of the threshold time limit.
Note that it has four sub-parts, a to d. Suppose we write a bit of software and want to see if it infringes. In order for it to do so, it would need to do all of a, b, c and d. Just doing a to c wouldn't count, nor would doing a, b and d. All or nothing, that's the rule.
Claims come in two flavours, independent and dependent. Independent claims (like this Claim 1) stand on their own and define a concept, idea, method or invention over which the patent grants a monopoly. Dependent claims extend independent ones; for example, the patent has a Claim 3 which runs: 3. The method of claim 2, further comprising... In other words, Claim 3 is dependent on Claim 2. Think of them like classes. Claims 1 and 2 don't inherit from anything. Claim 3 inherits from Claim 2, and so on. When a patent's attacked (mainly because it's too broad), each claim is attacked individually. If an independent claim is knocked out, then any claims that are dependent on it also go, but it doesn't necessarily affect the other independent claims.
Finally, in order for a patent to be granted, it has to be both novel and inventive. Novel means that it's never been done before, anywhere. Again, it's the claims that matter - if a claim covers a given method or invention, that method or invention must never have been described before. Specifically, it must never have been described before "in public", but that's a really broad definition. If it was explained in a single footnote in an old book published only in Azerbaijan and out of print, it still counts - it's in the public domain.
It's also worth saying that the description must be an "enabling disclosure", which must explain how the thing is actually done, in a way that would be understandable and useful to someone who works in the field. Thus a book that refers to "a faster-than-light drive using space warps" is not an enabling disclosure, since it's not an explanation.
The invention, method, whatever must also not be obvious to "one of average skill in the art". This can be a real pain, since what's obvious to your average developer may not be at all so to a patent examiner. It's especially bad in the case of software, where there are so many general principles that can be applied to a myriad different actual problems, making obviousness a real grey area.
For something to be inventive, it must (and I'm using general language throughout, here) "solve a real problem". This is why many patent applications start by describing the state of the art and pointing out a problem with it, then explaining how "the present invention" solves it. Hence you can't get a patent on a way of fitting wheels to a tomato unless you can show that the problem of wheel-less tomatoes is a real and significant issue.
Anyway, that's a rough guide to the wonderful world of patents. It's not the actual patents that are the problem, it's lazy approaches to granting them and also to reading them. But then, it was on SlashDot, after all...
Previous Topic
