The USPTO admits that it does not have enough qualified employees to properly analyze all of the patent claims submitted, and EDA patents are often arcane for even the most informed generalist. Wally Rhines, chairman and CEO of Mentor Graphics and chairman of the Electronic Design Automation Consortium (EDAC), says that, “It’s extremely difficult for any agency to acquire sufficient expertise to appropriately evaluate technology that is as complex and specialized as EDA.”
Just because a professional has a degree in electronic engineering or physics does not mean that he can decide whether constant delay synthesis, for example, is a method, an ordered sequence of algorithms, or a philosophy. Adding to this dilemma, by choosing to protect software with patents, the EDA industry has forced the USPTO and the courts to artificially modify an outdated patent definition that was never intended to apply to the protection of abstract entities like algorithms.
Shortcoming of patents as a protection method for software
Patents in the software field constitute a gray area. The U.S. government codified most of the definition of what can be patented and what constitutes a patent before the invention of the computer and software programs. Thus, the courts have had to adapt the existing definition to cover software. In order for a software program to be a candidate for patent protection it has to be defined as a process software.
IP attorney Gregory J. Kirsch, in an article first published on www.GigaLaw.com, states that, "Software operating on a computer causes the computer to perform a process, and the process can usually be represented by any one of a multitude of different (even if functionally equivalent) sequences of software code."
Kirsch goes on to justify the use of patents to protect the software on this basis. Two things are important in this statement. First, since the software causes the execution of a process, it falls within the definition of a patentable invention. Second, other developers can reproduce the same process by developing equivalent but different source code. If the second point is true, then any computer scientist will agree that neither program can be patented since they do not uniquely represent a process. Or, to take the other side of the argument, both can receive a patent. This latter argument would mean that every computer program, by its own nature, would receive a patent upon its release without having to apply to the USPTO.
In 1981, the U.S. Supreme Court in Diamond v. Diehr held that computer software is patentable provided that any claims to the software product are not merely a procedure for solving a mathematical formula. As any computer scientist can attest, the purpose of a computer program is exactly a procedure to implement the solution of a mathematical or logical problem. Congress intended that a patent would protect a unique implementation of an idea or a formula that uniquely described a natural transformation. As an increasing number of electronic products contain software, the entire electronics industry is facing ambiguities when dealing with patents.