Barbed wire may not seem to have much to do with software, but both stirred a lot of controversy when they were first patented. In the 19th century, there were 570 different patents on barbed wire, and the legal fights between the different patent owners lasted for years. Yet the Western pioneers had plenty of barbed wire to stake their claims.
Today, we’re seeing a similar controversy with software patents. In the early stage of any new technology’s development, the scope of some issued patents may be overly broad. Yet such problems have all been resolved over time, and inventors have always been rewarded for their innovations while being protected from those who want to co-opt their work.
For CIOs, the issue is not whether patents should be granted for software but whether anything can be done to improve the quality of the granted patents. The problem relates more to the examining process in the USPTO than to the appropriateness of patents for software. CIOs who are concerned about overly broad patents can lobby for more thorough examination of patent applications by the USPTO or request that an already established patent be reexamined, for example. And, in fact, the USPTO recently implemented a program for closer review for business method patent applications (“one-click” ordering on a website, for example) because of public concern about overly broad protection for business methods.
There’s a good reason your software vendors take out a patent: They spend millions—even billions—to develop their products. Patents and licensing fees are some of the ways they get compensated for their efforts. Patent license fees may push up the cost of software to CIOs, but those fees don’t begin to compensate companies for the money they put into software development.
That said, CIOs shouldn’t simply ignore the patent licensing issue and pay up whenever asked. They should develop (or acquire through purchase) a defensive portfolio of software patents to use as a bargaining chip when faced with another company’s patents. By offering to license your patents—or by threatening to assert your patents—it may be possible to avoid simply giving in to their demands or fighting a lengthy and costly legal battle. Sure, acquiring a patent portfolio is an extra cost and a management headache, but it beats going to court: An American Bar Association study estimates that an average patent case costs each side $2 million in attorney and expert fees through the end of trial, not including the cost of an appeal.
CIOs also need to understand misconceptions about software patents so that they can act as informed advisers to the business. Here are three of the biggest myths.
Myth #1 Patents favor large corporations and penalize small companies and individuals. Without patents, new companies may not be able to establish themselves in the marketplace or deter large competitors from providing similar functionality. For example, small software vendor Stac Electronics stopped giant Microsoft in its tracks in 1993, after Microsoft included file compression functionality—which had been patented by Stac—in Windows. A court injunction prevented Microsoft from selling Windows, and within a week Microsoft settled the lawsuit by paying Stac $120 million. In addition, antitrust laws severely limit the manner in which companies can use their patents. For example, requiring the purchase of an unpatented product to obtain a patented product is illegal.
Myth #2 Patents are too broad and cover the entire software program. Because patents require sufficient disclosure of an invention to enable others to practice it, there is a misconception that they cover everything disclosed. Patent protection extends only to what is claimed, not to everything in the entire software program (or even all of the material in the patent). Software developers can learn about advances in software through reviewing patents and can use those advances in their own products if they are not claimed in those patents.
Myth #3 Software is intangible and is different from other technologies. Software that controls the operation of a computer is certainly an “intangible” process, but no less protectable than other more tangible processes, such as the manufacture of pharmaceutical products or semiconductors. It is not the software code that is patentable. Rather, the processes that are performed by a computer executing the code are what can be patented. Moreover, most “software” functions can be performed in special purpose hardware—which has long been considered patentable. The choice of one or the other is relatively arbitrary.
Innovation in software is no less worthy of patent protection than other technologies traditionally protected by patents. CIOs need to be prepared to advise their companies on how to protect their important innovations. And they need to question their vendors closely when purchasing software. A nasty patent suit may force the vendor to divert substantial resources and may even make the product unavailable. A vendor’s patent strategy and its risks should be as much a part of the due diligence process as ROI or maintenance fees.