An article on Ars Technica outlined a recent development in the US patent process, describing rules for patentability for software patents. While the article deals with some specifics around the regulations for patent examiners, it really speaks to a bigger issue in software patents. I wrote a piece before on the pros and cons of software patents (The Conundrum of Software Patents). What this post discusses is more around what I believe should be guiding patent examiners. The assumption is that, for better or worse, software patents are here for a while yet. Since they are, how do we get better quality patents, and avoid patents that might cause trouble down the road?
In the interests of full disclosure, I must state that I am a co-inventor on one patent (#5,644,706 “Failure Detection and Reporting for a Computer Mail Gateway”) as well as co-inventor on two patent applications (#20080168025 “Methods, Systems, and Computer Program Products for Reducing Database Workload Volume” and #20090006266 “Electronic Block Trading System & Method of Operation”).
My belief is that patent examiners need two things: they need to get “back to basics” on patent review, and they need to be better versed in how things really work in software, and the contexts in which software can be used. Without those, what is more likely is a larger and larger set of rules that will become unwieldy, impossible to fully comprehend and likely contradictory, and not result in better patents being granted.
What do I mean by back to basics? It’s simple: there have always been 3 basic tests under US patent law that a patent must pass to be granted. Those tests are:
- The invention must be unique
- The invention must be useful
- The invention must be non-obvious
The second item (usefulness) could be debated. Something seen as useful to a very small number of people could be viewed as useless to others. There could be arguments made about applying an implementation test (did they actually build it, are they actually selling it), but “useful” could be debated.
The uniqueness and non-obvious test are where a background in software as well as in various businesses would likely eliminate a lot of bad or questionable patents early. The body of prior art available is large, and growing all of the time. However, unless you know what to look for (or how to look for it), finding prior art can be tricky. Using tools like Google and Bing would be a good start, as would mining the various databases for the ACM and IEEE. But having some kind of experience to know how to interpret the data is also essential.
The non-obvious test can be trickier, but not impossible. The issue, though, is what makes something non-obvious? The complete definition is “non-obvious to someone who is a practitioner in the art”. The definition of “practitioner”, though, is broader than many people assume. Simply being a “computer programmer” isn’t enough. Someone who spends their career working on oil and gas accounting systems may not realistically know if an invention for software in real-time command and control systems is non-obvious or not. It isn’t just a technical background, its also having the relevant experience in the field of business, science or technology that also must come into play. A smart person with a computer programming background, but no experience in capital markets, is unlikely to realize that certain approaches to managing buy/sell orders and matching them for trades are actually fairly common. To someone without a lot of background, an invention could look non-obvious, at least to them. To someone who works in the field, they are more likely to know if something is truly non-obvious or not.
I’m not sure that more rules are really what is needed. Instead, what needs to happen is that the rules that already exist need to actually be used and enforced. To make that happen means having examiners with the background and experience available to review the applications, and the tools and information they need to do the job right. At this time, I just don’t see that happening.