Posts Tagged: "computer related inventions"

Article written by Martin Goetz… Over the years the term “software” has been terribly abused when a patent application has a computer in its specifications. We hear the terms abstract, ideas, laws of nature, mathematical algorithms when those against “software patents” argue their case. But true inventions — whether specified in hardware, software, solar power, gears, or what have you — must stand on their own two feet and meet the test of an invention as specified in the US Patent law. Additionally, the USPTO states that an invention is defined in its claims and not by its specification. Unfortunately, many USPTO examiners have been issuing patents for very questionable inventions that only computerize (or automate) a manual process or computerize a new, but obvious, use of a computer.

Software patents, like all patents, are a form of innovation currency. They are also ecosystem enablers, and job creators. The innovation protected by software patents is highly integrated with hardware. All of it must remain eligible for protection. The current software patent “war” is hardly the first patent war—and unlikely to be the last in our nation’s patent history. Whenever breakthrough technologies come onto the scene, market players find themselves joined in the marketplace by new entrants. The first instinct of the breakthrough innovators is to bring patents into play. This is not only understandable, it is appropriate. Those who invest in breakthrough innovation have a right to expect others to respect their resultant IP. However, in the end, as history has shown time and time again, the players ultimately end up agreeing to pro-consumer solutions via licenses, cross-licenses or joint development agreements allowing core technologies to be shared.

The disclosure requirements for these types of patent applications has been a moving target for years, which means that whatever the most stringent disclosure requirements are should become the target regardless of the types of claims you file. To ensure your software patent application has appropriate disclosure of the invention you should accept — even embrace — the requirements for having an appropriate means-plus-function disclosure. By meeting the strict standards set forth in the mean-plus-function algorithm cases you will file more detailed applications that have better disclosure and which will undoubtedly support more claims, thus making the resulting patent or patents more valuable.

What If you created an automobile engine that could deliver 500 miles per gallon of gasoline would you seek a patent? I suspect you would because that type of engine would almost certainly be revolutionary. So why wouldn’t you think about patenting a software system that more efficiently manages power consumption for a large office building? If you could reduce energy consumption by 25% wouldn’t that be noteworthy? Of course, and it should be patentable as well. Legally it doesn’t matter whether the advantage is created by an old world mechanical gadget or thanks to the constant monitoring and manipulation of parameters via a computer following instructions. Both are innovations and both are patentable, and rightly so.

The conundrum created by the Federal Circuit’s joint infringement doctrine and its impact on protecting interactive computer-based technologies got worse last week with McKesson Technologies, Inc. v. Epic Systems Corp. McKesson Technologies involved a patented interactive electronic method for communicating between healthcare providers and patients about personalized web pages for doctors. Judge Linn’s majority opinion (and a “thin” at majority at that) ruled that, because the initial step of the patented method was performed by the patient while the remaining steps were performed by the software provided by the healthcare provider, there was no infringement, direct, indirect, joint or otherwise of the patented method.

Listening to those who code complain about patents is nearly hysterical. They still haven’t figured out that by and large they are not innovators, but rather merely translators. Perhaps that is why they so frequently think that whatever they could have come up with themselves is hardly worthy of being patented. Maybe they are correct, but that doesn’t mean that an appropriately engineered system isn’t patentable, it just means that those who code are not nearly as likely to come up with such a system in the first place because they rarely, if ever, seem to approach a project as an engineer would. Rather, they jump right in and start coding. In the engineering world that is a recipe for disaster, and probably explains why so much software that we pay so much money for today is hardly worthy of being called a beta, much less a finished product.

What do you think of my jumping buddy over there? Let’s call him “George”. George is just one example of the enormous number of inventions being made to serve our newly emerging social networking economy. George was created using a patent pending process called Evolver. He’s an avatar that can be transported to any number of different full immersion virtual world networking sites. Many new companies are forming to commercialize these new social networking innovations. They are also filing patent applications. They have many challenges ahead of them to get those patents.

Software is now and will remain patentable in the United States. Software patents have been vilified by many, but they have been granted by the United States Patent and Trademark Office and upheld in federal courts across the United States. The much anticipated Bilski v. Kappos decision at the Supreme Court did nothing to slow down the patentability of software, and in fact even the original Federal Circuit decision wound up, as applied by the USPTO, to make it more likely that adequately written software patent applications would be granted and transformed into issued patents. What has changed over the last several years, however, is the amount of detail that must go into a software patent application in order to satisfy the adequate description requirements under US patent law. So don’t listen to anyone who tells you software cannot be patents in the United States; it certainly can, but it isn’t quite as easy as it used to be.

When embarking on a software development project it is critical to understand that in order to maximize the chance of obtaining a patent you need to approach the task with an engineering mind set, as well as a healthy familiarity with Murphy’s Law. Anything that can go wrong will go wrong, and once you release the process to end users a human element will complicate what should otherwise be a predictable, linear, machine driven response. Embrace the uncertainty and challenges because the fact that software rarely, if ever, works like it should is what makes a working process patentable.

As you can see from the first cartoon in the series, the creator of a project has left the company and his unfinished project is being passed on to the hapless Dilbert. Scott Adams, through Dilbert, teaches us not only that no one should ever trust Dilbert, but also about the importance of documenting your invention. I then take this opportunity to also opinion about the impending first to invent changes to US patent laws. What fun!

So the fact that a method or process may be performed on a computer is not enough. I dare say that strict adherence to the Federal Circuit test in Bilski would compel a similar ruling that a method or process is not patentable even if it must be performed on a computer. Thus, the take home lesson moving forward must be that it is not enough to recite a computer, or even articulate an invention that necessarily must and only can be performed on a computer. At least for now these types of inventions must be described with a level of particularity that explains the innovation on a system level.