The software patent debate is the argument about the extent to which, as a matter of public policy, it should be possible to patent software and computer-implemented inventions. Policy debate on software patents has been active for years.[1] The opponents to software patents have gained more visibility with fewer resources through the years than their pro-patent opponents.[2] Arguments and critiques have been focused mostly on the economic consequences of software patents.
One aspect of the debate has focused on the proposed European Union directive on the patentability of computer-implemented inventions, also known as the "CII Directive" or the "Software Patent Directive," which was ultimately rejected by the EU Parliament in July 2005.
There are several arguments commonly given in defense of software patents or defense of the patentability of computer-implemented inventions.
Patents protect functionality. Copyright on the other hand only protects expression. Substantial modification to an original work, even if it performs the same function, would not be prevented by copyright. To prove copyright infringement also requires the additional hurdle of proving copying, which is not necessary for patent infringement.
Copyright law protects unique expressions, while patent law protects inventions, which in the case of software, are algorithms; copyright cannot protect a novel means of accomplishing a function, merely the syntax of one such means.[7]
This means that patents incentivize projects that are unique and innovative in functionality rather than simply form. Copyrights, in turn, only incentivize uniqueness in form.[8]
Software patents can afford smaller companies market protection by preventing larger companies from stealing work done by a smaller organization, leveraging their greater resources to go to market before the smaller company can.[9]
Hardware and software are sometimes interchangeable. If people can patent hardware, then ideas describing software implemented by that hardware should also be patentable.[10]
Opponents of software patents argue that:
A program is the transcription of an algorithm in a programming language. Since every (Turing-complete) programming language implements Church's lambda calculus by virtue of the Church-Turing thesis, a program is thus the transcription of a mathematical function. Math is not patentable. Therefore, neither is software.[11]
A patent thicket is a dense web of patents that companies must decipher to develop new technology. There are various types of patent thickets such as when a single innovation is protected by multiple patent holders or when a product is covered by numerous patents. The consequences of patent thickets are increased difficulty of innovation, complex cross-licensing relations between companies, and discouragement of newcomers from entering the software industry.[12]
Several Supreme Court decisions since 2000, as well as the Federal Circuit and district court decisions interpreting and implementing them, have dramatically impacted the status of software patents in the United States. They have particularly affected many thousands of business-method patents that issued as a result of Federal Circuit decisions in the 1990s. The two principal Supreme Court decisions were Bilski v. Kappos and Alice v. CLS Bank, the latter of which confirmed the applicability of the earlier decision Mayo v. Prometheus to computer-related inventions in which a computer was used to implement an abstract principle or preexisting business practice. (These cases are the subject of separate Wikipedia articles, which discuss the background and rulings in these cases in more detail, and supply authorities supporting the generalizations about those cases that follow. Additional detail is found in the Wikipedia article Software patents under United States patent law, along with supporting citations not repeated in this summary of those articles.)
The Bilski case involved a patent application on methods for hedging against commodity price fluctuations, which the PTO had rejected. The Federal Circuit, in In re Bilski, upheld the PTO's rejection on the grounds that the claims failed the machine-or-transformation test, which the court held should be used as the sole test of patent eligibility. The court did not hold that all business methods are patent ineligible, though a minority of the judges would have ruled that business methods are not properly the subject of patents.
The Supreme Court affirmed the judgment of ineligibility, in Bilski v. Kappos, but on more general, and less articulated in detail, grounds of undue abstractness. It rejected the Federal Circuit's elevation of the machine-or-transformation test as the sole test of patent eligibility, saying that rather it was simply a "useful clue." The 5-4 majority refused to hold that all business methods were incapable of being patented, but four justices would have established such a rule. A concurring opinion pointed out that the Court was unanimous, however, as to many issues in the Bilski case, including a rejection of the Federal Circuit's late 1990s State Street Bank decision, which allowed patents on any advance, technical or nontechnical (and in that case a numerical financial calculation of stock price changes) that produces a "useful, concrete and tangible result."
The Supreme Court's Bilski decision was criticized because of its lack of detailed guidance on how to determine whether a claim was directed to an abstract idea. Nonetheless, it provided some clarification and affirmed the Federal Circuit's taking a new direction in its software-related patent cases.
In Mayo v. Prometheus, the Supreme Court invalidated a patent on a diagnostic method, because it non-inventively implemented a natural principle; the Court drew on cases involving computer software and other abstract ideas. In this case, the Court was much more detailed in describing how to recognize a patent-ineligible claim to an abstract idea. The Mayo methodology has come to dominate patent-eligibility law. It revived the approach of the Flook and Neilson cases, which is to treat the underlying principle, idea, or algorithm on which the claimed patent is based as if it were part of the prior art and to make patent eligibility turn on whether the implementation of it is inventive. This led to the "two-step" Alice test described next.
At the time the Mayo case was decided, there was some uncertainty over whether it applied only to natural principles (laws of nature) or more generally to patent eligibility of all abstract ideas and general principles, including those involved in software patents. The Alice decision confirmed that the test was general. The Alice case involved patents on electronic methods and computer programs for financial-trading systems on which trades between two parties who are to exchange payment are settled by a third party in ways that reduce the risk that one party performs while the other does not. The patents cover what amounts to a computerized escrow arrangement.
The Court held that Mayo explained how to address the problem of determining whether a patent claimed an unpatentable abstract idea or instead a potentially patentable practical implementation of an idea. This requires using a "two-step" analysis.
In the first step, the court must determine whether the patent claim under examination contains an abstract idea, such as an algorithm, method of computation, or other general principle. If not, the claim is potentially patentable, subject to the other requirements of the patent code. If the answer is affirmative, the court must proceed to the next step.
In the second step of the analysis, the court must determine whether the patent adds to the idea "something extra" that embodies an "inventive concept." If there is no addition of an inventive element to the underlying abstract idea, the court finds the patent invalid under section 101. This means that the implementation of the idea must not be conventional or obvious to qualify for a patent. Ordinary and customary use of a general-purpose digital computer is insufficient; the Court said—"merely requiring generic computer implementation fails to transform [an] abstract idea into a patent-eligible invention."
The ruling continued with these points:
The Alice decision met a mixed reception, but profoundly affected U.S. patent law. In its wake, as explained in the Wikipedia article on the case, courts invalidated vast numbers of so-called software and business-method patents (the overwhelming majority of those the United States Court of Appeals for the Federal Circuit considered) and the number of such patents issued has drastically fallen. The Alice decision has been widely criticized for its failure to specify in detail the boundaries of patent eligibility, but it has also been defended because its unanimity tends to stabilize decisional law in the field.[33]
After Alice, the Federal Circuit and district courts invalidated large numbers of business-method and software patents based on those courts' interpretations of Alice. Federal Circuit Judge William Bryson summed this up in these terms:
In short, such patents, although frequently dressed up in the argot of invention, simply describe a problem, announce purely functional steps that purport to solve the problem, and recite standard computer operations to perform some of those steps. The principal flaw in these patents is that they do not contain an “inventive concept” that solves practical problems and ensures that the patent is directed to something “significantly more than” the ineligible abstract idea itself. [Citing Alice and Mayo.] As such, they represent little more than functional descriptions of objectives, rather than inventive solutions. In addition, because they describe the claimed methods in functional terms, they preempt any subsequent specific solutions to the problem at issue. [Citing Alice and Mayo.] It is for those reasons that the Supreme Court has characterized such patents as claiming “abstract ideas” and has held that they are not directed to patentable subject matter. [34]
|title=
(help)
By: Wikipedia.org
Edited: 2021-06-18 18:05:17
Source: Wikipedia.org