IP Intelligence

Home | IP Intelligence

CLS Bank and Its Impact on Software Patents

Courts, commentators and clients will be struggling for some time to assess the impact on software patents of Thursday’s Supreme Court decision in Alice v. CLS Bank.  Interpreted one way, the decision kills patents directed at computer-implemented business methods.  Interpreted another way, it’s business as usual for patentees.  The Supreme Court found that using a computer to implement an abstract idea was not sufficiently inventive to justify patent protection.  It is not clear, however, whether the decision has much reach beyond the facts of the CLS Bank case itself.  Part of the problem is how miserable the patents at issue really were.  The patentee’s inspiration was to employ a third party to collect financial information on the parties to a transaction in order to verify that they had sufficient funds to close a deal.  This is otherwise known as employing an escrow agent or clearing house, and it is a method of mitigating risk in transactions that appears to be several thousand years old.  The patentee claimed their idea was eligible for a patent, however, because it used a computer program to download the financial data, perform the calculations, and send notifications regarding the financial risk (although it had never actually implemented any of the claimed systems).  The Supreme Court found that the idea to use an escrow agent in a financial transaction was an unpatentable “abstract” (and ancient) idea.  The decision to use generic computer functions to perform that role did not elevate the concept to a patentable invention.  It is easy to confine the Court’s decision to the facts of the case, mostly because the Court declined to “delimit the precise contours of the ‘abstract ideas’ category in this case.”

However, the Court made several comments in the offing that some may use to attack a broader range of software patents.  The Court found that the use of a “generic computer to perform generic computer functions” to implement an abstract idea was not a sufficiently “inventive concept” to warrant patent protection.  That much is unremarkable.  How the Court determined what counts as a “generic computer function,” however, is.  The Court determined, without the support of factual findings below, that certain computer functions were “well-understood, routine, [and] conventional,” including keeping electronic records, obtaining data, adjusting account balances, and issuing automated instructions.  What is more, the Court suggested that software patents that “purport to improve the functioning of the computer itself” or “effect an improvement in any other technology or technical field” are potentially patentable.  By contrast, those software patents that are not sufficiently technical would appear to be imperiled.  It is not clear, however, where the lines have been drawn for a computer-implemented method to be sufficiently technical, or when a non-technical method uses software in a sufficiently non-generic way.  The ambiguity is worsened by the Court’s express refusal to “delimit” what counts as an abstract idea.  What is clear is that at least some courts will give software patents greater scrutiny in the future.

Oracle v. Google and Its Impact on Software Copyright

At nearly the same time as this potential roll-back of patent protection for software, last month’s Federal Circuit opinion in Oracle v. Google may signal an expansion of copyright protection.  There the Court found that “a set of commands to instruct a computer to carry out desired operations may contain expression that is eligible for copyright protection.  … [A]n original work—even one that serves a function—is entitled to copyright protection as long as the author had multiple ways to express the underlying idea.”  This decision has challenged the perceived separation between copyright and patent law, and revealed that software developers may have more robust rights in their source code than previously thought.

Oracle v. Google involved Google’s attempt to make its Android platform compatible with programs coded in Java.  To do so, Google needed to use certain programming gateways that enable interoperability, called application program interfaces (APIs).  The APIs themselves consist of two kinds of source code— a) short phrases that identify an ensuing function called “headers” or “declarations;” and b) implementing code, often consisting of thousands of line of code, that actually performs the calculations or functions called for in the header.  Google copied the headers for 37 Java APIs, but created its own implementing code.  Oracle claimed that Google’s copying infringed Oracle’s copyright in the API’s by both—a) exactly copying the headers; and b) effectively paraphrasing (i.e. non-literally copying) Oracle’s implementing code by copying the structure, sequence, and organization (“SSO”) of the APIs.

The District Court in the case noted that “an exclusive right to a functional system, process, or method of operation  belongs in the realm of patents, not copyright.”  Keeping this separation is important because, among other things, “copyright exclusivity lasts 95 years whereas patent exclusivity lasts twenty years.”  This separation is largely maintained through the “idea/expression dichotomy,” codified at section 102(b) of the Copyright Act:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

This separation is also supported by the legal doctrine of “merger,” whereby a particular expression of an idea is not given copyright protection when there are a limited number of ways to express that idea.  Because the header lines of code had to be copied exactly to ensure proper functioning with the Java programming language, the District Court found that the merger doctrine barred copyright protection for the header code.

Also at issue in the case, however, was the overall SSO of the APIs.  Although Google had written its own implementing code, it grouped the methods at issue in the same fashion (into packages, subdivided in classes, subdivided in methods) as the Oracle APIs.  Although the District Court acknowledged that the SSO of the APIs resembled a copyrightable taxonomy, and that the SSO was original, creative, and subject to multiple forms of expression, the court nonetheless found that the SSO operated as a “command structure”—a method of operation of using a “long hierarchy of over six thousand commands to carry out pre-assigned functions.”  Because of the functional nature of the SSO, the court found it was not copyrightable under section 102(b) of the Act.  Threaded throughout the court’s decision was a concern that granting Oracle control over the API’s functionality would disrupt the widespread interoperability that defines both the internet and mobile device industries, and would give Oracle a monopoly power not intended by Congress.

The Federal Circuit reversed.  As regards the Java API headers, the Court found that the merger doctrine did not apply because there were numerous ways to express the short phrases necessary to define the ensuing method of the API—albeit numerous ways that existed when the APIs were first coded.  That is, the Court found that the merger doctrine required analysis of the options available to the software coder at the time of the coding, not those options available to an infringer many years later.  Implied in the decision is that there is no fundamental right to code in Java.  If there becomes only one way to code API headers to ensure interoperation with Java, that is Google’s tough cookies (pun intended)—Google is free to program its own Java-like language from scratch and hope that it catches on.  But because there was sufficient creative selection in the header code when Java was first coded, the merger doctrine did not apply.  Because Google admitted direct copying, it was infringer.

Even more significant, however, was the Federal Circuit’s analysis on whether the overall SSO of the APIs was protected by copyright.  Here the Court purportedly applied what is known as the “abstraction-filtration-comparison test.”  This test is an exacting analysis that requires a court to break a copyrighted down into its constituent parts, sift out non-protectable information such as ideas and facts, and then compares the remaining expressive content with the allegedly infringing program.  However, when it came time to apply this analysis to the SSO, very little filtration occurred.  Rather, the Court concluded, as noted above, that “an original work—even one that serves a function—is entitled to copyright protection as long as the author had multiple ways to express the underlying idea.”

There is an inherent tension, if not outright contradiction, in the Copyright Act between section 102(b)’s prohibition against protecting a “method of operation” and the Act’s definition in section 101 of “computer program” as a “set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.”  While the Court made some attempt to harmonize these two provisions, at the end of the day it resolved the tension by coming down solidly in favor of copyright creep—“The problem with the district court’s approach is that computer programs are by definition functional—they are all designed to accomplish some task.  … If we were to accept the district court’s suggestion that a computer program is uncopyrightable simply because it ‘carr[ies] out pre-assigned functions,’ no computer program is protectable.”

To summarize, the district court found that the Java APIs were not copyrightable because the SSO functioned as a command structure, no matter how expressive and original the expression was; the Federal Circuit found that the Java APIs were copyrightable because they were expressive and original, no matter how functional the SSO’s command structure was.

Does Copyright Fill a Void?

If one assumes that CLS Bank spells the death of computer-implemented business method patents, it does not mean that companies that create software are left unprotected for their labor.  Copyright protection is available for the software’s source code and object code.  If the Federal Circuit’s opinion in Oracle v. Google influences other courts, which it historically has in a number of important jurisdictions, there may be protection available for the command structure of the software, even if not literally copied by an infringer and even if that command structure forecloses the use of certain kinds of functionality.  There are also protections available for various user-facing elements like screen displays, user interfaces, and icon designs in copyright, but also things like design patents and trade dress as well.  And, unlike patent law, these protections will not be subject to attack simply because the software is performing “generic” functions or implements an “abstract idea.”

There remain, however, some important differences between patent and copyright law:
<ul>
	<li>Copyright law protects only “expression,” and thus only source code that was actually created.  Thus a claimant will have to actually write the code at issue.  By contrast, patent law generally extends to the idea of the invention, even if the invention has not been used in the marketplace.  The inventor in CLS Bank, for example, did not actually produce the claimed computer system.</li>
	<li>Copyright law requires a showing of access and actual copying, which necessarily requires knowledge of the existence of the source code.  By contrast a patent can be infringed even if the infringer did not know of the preexisting invention.</li>
	<li>Although copyright law will apparently extend to protect expression even if that expression is incidentally functional, it will not protect the underlying idea.  A rival could attempt to replicate a program’s functionality, so long as the rival coded from scratch and did not try and copy the SSO of the copyrighted program.  Note however that there is an advantage of being the first to market—even Google with its apparently limitless resources took 2 ½ years to create its version of the implementation code of the Java APIs.</li>
</ul>
All of this begs the question—would the plaintiff in CLS Bank have fared better if it had copyrighted its computer program rather than patented it?  No—CLS Bank created its own program with no apparent access, or even knowledge of, the Alice Corp. system.  However, companies that are actually producing software programs and placing them into the marketplace can enjoy robust protection for their work with the right intellectual property strategy in place.

What CLS Bank Taketh, Copyright May Giveth Back