On June 28, 2010, the United States Supreme Court issued its long-awaited decision in Bilski v. Kappos, No. 08-964, slip op. (June 28, 2010). The Supreme Court was presented with the issue of whether the Federal Circuit’s “machine or transformation” test is the sole test for determining whether a process is patentable under 35 U.S.C. § 101, and more generally, whether business methods can be patentable. The patent application which was the subject of the case tried to patent methods for hedging risk in the field of commodities trading. The claims were classic “business method” claims: they recited steps that were performed as part of a business operation. The patent application was rejected by the Patent and Trademark Office and lost on appeal to the Court of Appeals for the Federal Circuit.
Although the Bilski decision was expected to have a dramatic effect on the patent world and, in particular, the patentability of software, the decision is surprising for how little it decided. The Supreme Court split into a majority opinion and two concurring opinions. The majority of the Supreme Court agreed only on three points: (1) the Federal Circuit’s machine-or-transformation test is not the exclusive test for patent subject matter eligibility; (2) business methods are not categorically unpatentable; and (3) the invention at issue in Bilski is an unpatentable abstract idea.
The critical part of the decision is as follows:
Today, the Court once again declines to impose limitations on the Patent Act that are inconsistent with the Act’s text. The patent application here can be rejected under our precedents on the unpatentability of abstract ideas. The Court, therefore, need not define further what constitutes a patentable “process,” beyond pointing to the definition of that term provided in §100(b) and looking to the guideposts in Benson, Flook, and Diehr.
And nothing in today’s opinion should be read as endorsing interpretations of §101 that the Court of Appeals for the Federal Circuit has used in the past. See, e.g., State Street, 149 F. 3d, at 1373; AT&T Corp., 172 F. 3d, at 1357. It may be that the Court of Appeals thought it needed to make the machine-or-transformation test exclusive precisely because its case law had not adequately identified less extreme means of restricting business method patents, including (but not limited to) application of our opinions in Benson, Flook, and Diehr. In disapproving an exclusive machine-or-transformation test, we by no means foreclose the Federal Circuit’s development of other limiting criteria that further the purposes of the Patent Act and are not inconsistent with its text. http://www.supremecourt.gov/opinions/09pdf/08-964.pdf
The majority opinion was not revolutionary, but more of a course correction. The Supreme Court affirmed the Federal Circuit’s judgment that the business method was not patentable. At the same time, it found that the Federal Circuit had an improperly narrow view of patent subject matter eligibility. After dismissing the Federal Circuit’s machine or transformation test as the sole test for determining patentability of process inventions, the Supreme Court refrained from offering any alternative tests or any guidance.
The decision strongly suggests that software remains patentable, although the Supreme Court was careful to state that it was not deciding that any class of technology was patentable. In fact, the most interesting results in the decision come from analysis of the concurring opinions. In a very perceptive comment, the PatentlyO blog http://www.patentlyo.com/patent/2010/06/bilski-v-kappos-and-the-anti-state-street-majority.html, notes that by combining the votes of the justices in the two concurring opinions, five justices have rejected the State Street test of useful/concrete/tangible-result. As the PatentlyO blog notes State Street was the broadest formulation of the scope of patentability and it is rejected by five of the justices (although not formally disavowed in the majority opinion). The other interesting result of analyzing the votes in the concurring opinions is that four justices were prepared to find that business methods are not patentable. Those four justices need only one more vote to have a majority for excluding business methods from patent protection. Both of these results suggest the way in which future cases may be decided.
The decision is likely to increase the use of eligibility of patent subject matter as a litigation defense, but will have a less clear effect on patent prosecution. Given the lack of guidance on the standards of patentability, the Patent and Trademark Office will need to find to develop its own tests. Patent law is likely to remain uncertain in this area for some time to come.
As I noted in my earlier post http://lawandlifesiliconvalley.com/blog/?p=468 about the recent German Supreme Court decision, Bilski should encourage software companies to include patents as an important part of their intellectual property strategy.
Patents are becoming increasingly available to cover software and software companies need to include a patent strategy as part of their larger intellectual property strategy. This growth in the protection of software was emphasized by a recent ruling in the German Supreme Court. German courts have long denied the application of patents to software. However, the court decided that a software program which automatically generates dynamic documents is a patentable invention. This decision is a major change in German law. The decision can be found at: http://juris.bundesgerichtshof.de/cgi-bin/rechtsprechung/document.py?Gericht=bgh&Art=en&nr=51989&Frame=1.
My partner, Thomas Jansen, from DLA Piper’s Munich office explains the decision and its significance: in the past software patents in Germany were only considered valid under very limited circumstances. Under the new Supreme Court ruling, software will be patentable as long as the software is innovative and solves a technical problem with technical means.
In the case, the German Supreme Court decided that software is basically of a technical nature which differs from past decisions and which is significant for patentability. The court found that the software economizes technical resources of a computer and consequently solves a technical problem. The ruling creates a presumption that the software is patentable when it has an effect on the technical method of the operation of a computer. Nonetheless, it is still unclear which attribute of a software program is relevant to comply with this requirement. However, the ruling represents a departure from prior decisions which considered virtually every software patent as invalid because of the failure to fulfill these requirements.
The new ruling significantly simplifies the protection of software inventions by patent in the future. However, certain critical issues such as the type of technical requirements remain uncertain. However this decision emphasizes the importance of companies including patent protection for software as part of their intellectual property strategy.
The Mozilla Foundation has started the process of revising the Mozilla Public License (“MPL”) and has published the first drafts in the process. You can read the proposed changes to definitions and licenses and comment on them. https://mpl.co-ment.com/text/KVR6Y3hsirl/view/. I am very familiar with the MPL because we used it as the base for the CDDL which I drafted with Sun’s lawyers for the open sourcing of the Solaris operating system.
The changes are a welcome simplification to the MPL definitions and license grant. In particular, the definition of “Modifications” has been changed to delete the phrase “any addition to or deletion from the substance or structure of either the Original Code or any previous Modifications” and the definition of Modification is now based solely upon “files”. This change is very important because of the vagueness of the deleted phrase.
Mozilla has also spent significant effort in revising the terms of the patent license to use a more traditional approach, clarifying the license grant and the definition of patent claims. However, the modifications do not appear to have modified the scope of the license grants. Most of these changes represent moves of phrases from the license grant in the current MPL to the definition of “Patent Claim” in the new version. The patent licenses are now reciprocal, instead of having separate licenses for the Initial Developer and, then, for Contributors. In fact, the new definitions have deleted the definition of Initial Developer and now incorporates the concept in the definition of “Contributor”.
In addition, the new draft has deleted the requirement to provide notice of any third party patent claims in a Modification or Contributor API which is known to the Contributor (this requirement in Section 3.4 of the current version of MPL):
(a) Third Party Claims.
If Contributor has knowledge that a license under a third party’s intellectual property rights is required to exercise the rights granted by such Contributor under Sections 2.1 or 2.2, Contributor must include a text file with the Source Code distribution titled “LEGAL” which describes the claim and the party making the claim in sufficient detail that a recipient will know whom to contact. If Contributor obtains such knowledge after the Modification is made available as described in Section 3.2, Contributor shall promptly modify the LEGAL file in all copies Contributor makes available thereafter and shall take other steps (such as notifying appropriate mailing lists or newsgroups) reasonably calculated to inform those who received the Covered Code that new knowledge has been obtained.
(b) Contributor APIs.
If Contributor’s Modifications include an application programming interface and Contributor has knowledge of patent licenses which are reasonably necessary to implement that API, Contributor must also include this information in the LEGAL file.
This deletion is important because of the difficulty of complying with this obligation.
I look forward to reviewing the rest of the modifications. I am particularly interested in whether Mozilla will modify the “patent peace” provision in the current version of the MPL which has proved a problem for many large companies.
8.2. If You initiate litigation by asserting a patent infringement claim (excluding declatory judgment actions) against Initial Developer or a Contributor (the Initial Developer or Contributor against whom You file such action is referred to as “Participant”) alleging that:
(a) such Participant’s Contributor Version directly or indirectly infringes any patent, then any and all rights granted by such Participant to You under Sections 2.1 and/or 2.2 of this License shall, upon 60 days notice from Participant terminate prospectively, unless if within 60 days after receipt of notice You either: (i) agree in writing to pay Participant a mutually agreeable reasonable royalty for Your past and future use of Modifications made by such Participant, or (ii) withdraw Your litigation claim with respect to the Contributor Version against such Participant. If within 60 days of notice, a reasonable royalty and payment arrangement are not mutually agreed upon in writing by the parties or the litigation claim is not withdrawn, the rights granted by Participant to You under Sections 2.1 and/or 2.2 automatically terminate at the expiration of the 60 day notice period specified above.
(b) any software, hardware, or device, other than such Participant’s Contributor Version, directly or indirectly infringes any patent, then any rights granted to You by such Participant under Sections 2.1(b) and 2.2(b) are revoked effective as of the date You first made, used, sold, distributed, or had made, Modifications made by that Participant.
Section 8.2(b) has made many large companies reluctant to contribute to MPL licensed software because of its potential to limit the flexibility of a contributor in using its patent portfolio against products and software other than the MPL licensed software.
MPL has the opportunity to play an important role as the license of choice between pure copyleft (such as GPLv2) and pure permissive (such as BSD and Apache). However, it has not been able to fulfill that role because of the concerns raised by the ambiguity of its scope (the Modifications definition and notice obligations) and its expansive approach to “patent peace”. I hope that these revisions will make the MPL attractive to a broader set of users.
I congratulate the Mozilla Foundation for taking the initiative and hope that the result will be a more attactive alternative between GPL and Apache. I encourage the community to participate actively in the revision to make the new version of the MPL as valuable as possible!