Software has a split personality in the sense that it can be protected both as a creative work of authorship under copyright law and as a patent protectable invention under our patent laws. The basic difference between these two statutory schemes of protection is that patent law protects the functional reduction to practice of an idea, whereas copyright law protects the artistic expression of an idea. As an illustrative example, consider the situation where there exists a copyright on the blueprint of a machine. Copyright law only prevents others from making unauthorized copies of the blueprint not from building the machine; the latter is the province of patent law.
Unfortunately, the application of this dual system has led to some confusion as between what patent and copyright law protects and where those lines should properly be drawn. More fundamentally, we are not clear as to whether or not or to what degree software-based inventions should even qualify as patentable subject matter. The reason for this anti-software patent bias is based largely on the fact that most of the patents that are being used by so-called “patent trolls” to sue big and small companies for infringement, are in this software-based questionable validity category. Patent Trolls, also referred to as Patent Assertion Entities, acquire patents from others, typically at a large discount, as through a bankruptcy, and try to use such patents to obtain royalty payments under the threat of infringement litigation. The real abuse perpetrated by Trolls is to also pay scant attention to whether or not their patent is actually infringed and to pursue hundreds of alleged infringers. Such lawsuits are taking up a disproportionate percentage of federal district court time and resources and are forcing small companies to settle and pay royalties they should not have to pay because they cannot afford the high cost of litigation. Big companies that can afford the litigation will also often settle because the trolls are smart enough to price their license well below the cost of a suit so the large business finds it easier to pay to make them go away. There is also an old-fashioned antipathy towards software being patentable because it is not as “tangible” as a physical machine, a chemical compound or a traditional process that involves mechanical, physical and/or chemical steps.
To understand where we may have erred, and what can be done to improve the situation we must first look at how we define patents and copyrights. Interestingly, inventions and works of art and authorship were considered so important by our founding fathers that their protection is provided for in our Constitution. Specifically pursuant to the enumerated powers of Section 8 of Article 1 of the Constitution, Congress has the power “ To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.” From this clause Congress has created our copyright laws under United States Code Title 17, and our patent laws, under United States Code Title 35. (Emphasis supplied.)
Section 102 of Title 17 describes what can be copyrighted by stating, as follows:
(a) Copyright protection subsists, in accordance with this title, in original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device.
(b)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. (Emphasis supplied.)
35 USC Section 101 defines what is patentable by stating:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. (Emphasis supplied.) It is important to note also that case law has determined that products and laws of nature, physical phenomena, abstract ideas, human performable mental acts and mathematical equations, are not patentable.
There are two other important hurdles that an invention must overcome in order to be patentable:
35 USC Section 102 requires that to be patentable an invention must be novel, i.e. not previously invented. (There should be no benefit for re-invention.)
35 USC Section 103 requires that in addition to being novel an invention must be nonobvious. Section 103 can be understood to stand for the proposition that patents will not be granted to small improvements over the prior art. In other words, if the invention would be obvious to a person skilled in the particular technology it would not be significant enough to justify a 20 patent year term of exclusion.
Looking initially at copyright protection of software, the US Copyright Office first allowed for the registration of software programs in the mid 1960’s and the propriety of such registrations was given formal support in the 1976 Copyright Act. Software can generally be defined as a set of instructions consisting of lines of code that, in the context of a computer/microprocessor of some sort, can act on inputs to calculate or produce certain outputs. Typically, it is the human readable source code that is registered, however it does not possess the type of creative artistic merit we think of with respect to a novel, a painting or a play. That said, software code is statutorily considered a “literary” work in that it is deemed to possess at least the minimal level of artistic creativity required for copyright protection. That minimal level is also attributed to other “pedestrian” copyright protected works, such as, catalogues, reference books, business information forms and the like. And, most people agree that, due to the ease with which software can be copied precisely and quickly, it is important that we have some form of protection in place that, at a minimum, prevents others from making verbatim copies. Thus, since we had a copyright law in existence with a well-developed body of case law surrounding it that prevented illegal copying of works of authorship, and as software is a “work” that is “authored”, it was at least somewhat logical to use that statutory framework to provide for software copy protection.
However, problems arise when we begin to apply the logic of copyright infringement case law analysis to software as was developed for works of art. The difficulty is not so much in situations where another is making exact copies, but where the alleged copyist has made less than a 100% copy. It was early on recognized that to have any value copyright protection had to not only prevent exact duplication, but also had to prohibit making copies that, even though not identical, amounted to a taking of the original author’s rights. Determining the point at which a line is crossed into illegitimate copying has always been a problem for judges and juries. The difficulty is that there can be no hard and fast rule as the cases are highly fact dependent and the answer can only be arrived at on a case by case basis. Factors taken into consideration are such things as the nature of the work, what percentage is copied, what was the importance to the work of the portion copied, the level of detail and creativity of the copied work, and so forth. This approach to infringement analysis essentially involves analyzing the work to determine which elements of it are original and protectable and which are unoriginal and not, and then comparing it with the alleged infringing work to see what of the original portion was copied. Clearly, the more the alleged infringing work copies the original parts of a work the greater the chance it would have of constituting an infringement.
Courts have developed the concepts of “scénes à faire” and “merger” to assist them in filtering out material that is common or not creative. Scénes à faire can be thought of as elements of a work that are in the public domain and free for anyone to use such as basic plot lines, locations and descriptions. For example, anyone writing a novel about the American wild west would be free to write a story about a gang of evil cattle rustlers, a saloon having a hard-bitten woman proprietor, a drunken sheriff and a stranger riding into town that ultimately helps to save it from the gang of outlaws. These characters and plot lines are standard “fare” and free for anyone to include in a new creative work.
The merger doctrine is used to remove elements as being non-creative where the idea and how it is expressed are said to merge because the idea can be expressed in only one or a very few ways. For example, where a literary work and its alleged infringer both describe a scene concerning heart bypass surgery to the main character, it would not be surprising, at least at a basic level of abstraction, for there to be a high degree of similarity in how that medical procedure is described. But of course, at a more detailed level there would be an almost infinite variety of ways the scene such as that could unfold and it would be these unique aspects that would be scrutinized for similarity. The merger doctrine is more practically applied in a more densely factual context where, for example, two text books are being compared as to how they teach the Pythagorean theorem or review the basics of the periodic table of the elements. Clearly, the alleged infringing work can be shielded by the merger doctrine to the extent that teaching of such topics is somewhat limited in descriptive range. That said, copying will be found if it is essentially verbatim and certainly if any accompanying tables, graphs or other pictorial matter accompanying the text is copied.
Applying the foregoing analysis logic to software as we break it down into its individual elements we see various routines or algorithms that themselves may contain sub-routines and ultimately individual lines of code. It is probably safe to say that many if not most of the routines used in any particular software program are scénes à faire in that they constitute very well known or standard techniques found in the public domain and used for many years by computer programmers to accomplish certain computational tasks. And software is typically written in one of a variety of particular languages, each being highly specific as to how the code is written and how a routine must be expressed to accomplish a particular calculation or result. Thus, much of what is contained in a software program can be eliminated on either a scénes à faire or merger basis. After that filtering process we are then left with, a residue of creative algorithms or at least a novel combination of known algorithms. So far so good, but herein lies the problem: The algorithms that make up a software program are completely functional, like gears in a transmission, and are completely devoid of, and not amenable to, artistic expression or embellishment. Therefore, being completely functional, we know that under Title 17, Sec. 102 subparagraph b, recited above, these algorithms cannot be protected under copyright law. In other words, uniquely functioning software can only be protected, if at all, under patent law. If we nevertheless find the unique part of a software program protectable as having been “copied” under the filtering procedure created for copyright law protection of artistic works, we are then improperly substituting copyright protection for patent protection. And, since copyrights can extend for decades longer than the twenty years allowed for patents, we would be providing defacto patent protection for much longer than is provided under our patent laws. More importantly, I believe this confusion about how software should be protected under patent and copyright law is preventing us from tackling the problem directly and obtaining the consistent and rational results that the software industry needs.
Copyright Protection: The best route here is to relegate copyright infringement of software primarily to instances of verbatim copying. Where the copy is one that is almost identical then it might be possible to resort to the copyright registration deposit copy or other indicators that the software had been essentially literally copied such as by reviewing the overall similarity in any visual or auditory output in terms of any graphical user interfaces or streaming video content. If the deposit copy is not sufficient to show copying then a plaintiff should be able to discover and review, or have it independently reviewed by a court appointed expert, possibly 10% to 20% or more of the defendant’s code assuming the deposit copy is less than that percentage and/or does not demonstrate copying.
Software Patents: Some software is highly specialized and tied to the operation of a specific machine, from an MRI scanner to the engine management system in a car, and can operate from a generalized computing platform like a PC or from a highly specialized circuit board and processor environment. And such software can be designed to interact and react to human input through a monitor and a keyboard whereas other software operates autonomously receiving non-human originated inputs from sensors in the environment in which it operates. The problem with such software-based inventions has not been primarily with the software that contributes to the function and capabilities of a particular machine or device, as the utility of the machine is apparent and as the novelty of the invention generally resides in a combination of the software and the machine. The harder question is where the “physicality” of the invention resides only in the computing hardware needed to run the software and where the novelty resides essentially exclusively in the “calculations” that the software makes. Even here, most people understand the value of permitting patenting of software applications that perform complex tasks and that provide some new and useful service or capacity, such as word processing, video editing, web browsing, email management and the like. Where the most disagreement arises is when the software in question appears to be making a series of essentially mathematical calculations relative to a body of data which calculations arrive at results that provide, for example, insights to guide future investment decisions. This type of software is often then referred to as “business method” software. In the “State Street” case the Court of Appeals for the Federal Circuit, (CAFC) found a computer implemented business method of pooling investment funds in a way that provided some economies of scale and partnership tax advantages, to be eligible for patent protection. See generally, State Street Bank & Trust Co. v. Signature Financial Group Inc., 149 F. 3d 1368, 47 USPQ2d 1596 (Fed. Cir. 1998). The court decided that the invention did fall within the definition of patentable subject matter under section 101 of the patent laws because it produced a “useful, concrete and tangible result.” However, the CAFC went in a different direction in a subsequent case involving a software implemented business method for the computation of hedging risk, by finding the patent claims directed to non-patent eligible subject matter. See, In re Bilski, 545 F .3d 943, 88 U.S.P.Q.2d 1385 (Fed. Cir. 2008). In this case the CAFC relied on the “machine or transformation” test to find that the claims were not directed to patentable subject matter. The court was not clear whether a general computer would suffice for fulfilling the specific machine test, but found that the invention did not transform any article into a different state or thing. This decision was appealed to the Supreme Court where the decision of the CAFC rejecting the claims as unpatentable was upheld however on different grounds. The Supreme Court found the claims of the patent to be unpatentable as encompassing the abstract idea of hedging. See generally, Bilski v. Kappos, 130 S. Ct. 3218 (2010). However, the Supreme Court rejected any idea that the “machine or transformation” test is the sole test for determining the patent eligibility of a process and also rejected any categorical exclusion of business method patents from patent eligibility. Many commentators have also made it clear that in our “information age” we have to be forward thinking and able to adjust to any new forms of invention and not tied to the old fashioned idea that an invention must have some mechanical or physically transformative aspect or result.
Unfortunately, the foregoing cases do not provide the software industry with sufficient guidance as to when and how to apply the various tests for determining the existence or not of patentable subject matter to software-based inventions and particularly where a business method is involved. The question of software patentability for a business method is currently under review again by the US Supreme Court in a case entitled “Alice Corporation Pty. Ltd. v. CLS Bank International”. In this case the Supreme Court is not only considering whether or not a patent that covers a system and method for reducing settlement risk in financial transactions embodies patentable subject matter but is reviewing more broadly the larger question of software patent eligibility.
The business method in the Alice case has been criticized based on the idea that the computer is technically unnecessary in the sense that the calculations/manipulations of data could be accomplished by hand with a pencil and paper – at least theoretically and given sufficient time. I do not see this rationale as constituting a legitimate argument against patentability as there are many machines that have been invented over the years for the express purpose of extending what humans are capable of doing both physically and mentally. Thus, why should a software program be per se patent ineligible, especially when it provides tangible results, such as, accomplishing a complicated task more quickly and accurately? It can also be imagined that a process of human hand calculation could be so slow that results once arrived at would no longer be of any usefulness, particularly where a time constraint exists that would render those results of little or no value, i.e. the invention could not be accomplished by hand to achieve the same results. More importantly, saying that a sequence of calculations could have been performed by hand provides no insight relative to the novelty of the invention or nonobviousness thereof with respect to the various equations, the interaction thereof and/or the sequence of the calculations performed, the data used in the equations as well as the selection process for that data. Also, the exclusion under Sec. 101 of mathematical equations would be an overly broad interpretation thereof in a situation where the invention is not drawn to mere mathematical calculations but includes, as stated, a multiplicity of equations, the interactions thereof as well as the question of any data selection constraints or criteria. In other words, exclusion of software under Sec. 101 in the Alice case may constitute an unwarranted and overly broad interpretation of the court made exclusions under Sec. 101 based either on human performable mental acts or the prohibition against the patenting of mathematical equations.
Hopefully, the Supreme Court in Alice realizes the problems inherent in broadening the court made demarcations of non patentable subject matter and accepts the per se patentability of all software-based inventions, including business methods. Further support for this approach is seen in Sec. 101 itself as it is written broadly to include “any new and usefulprocess, machine, manufacture, or composition of matter, or any new and useful improvement thereof”. Certainly, a novel and nonobvious manipulation of a body of information that produces new insights has utility. And the fact that this new information can be acted upon to improve business performance or optimize a business or other result should fit within a broad definition of a tangible result. And, as mentioned earlier, we must be always be open to new types of inventions and particularly in our current information age. Additionally, our constitution requires that we promote the progress of the sciences and the useful arts. Thus, it would seem we are obligated to err on the side of providing software patent applicants with the chance to prove that what they have invented is in fact promoting that progress. Therefore, we must narrowly construe the judicial interpretations of Sec. 101 as to what constitutes non patentable subject matter so they are not expanded to prevent patent protection for legitimate inventions.
Software Patent Examination: Of course, if software is considered per se patentable, then we are going to need to rely on a proper novelty and obviousness analysis and the USPTO will have to ensure that task is being done properly in the first place. If we do not have a sufficient number of patent examiners to give enough time to reviewing patents in the software art area then more need to be hired. It should also be noted that more examiners could also, without impacting quality, reduce the pendency time of software patent applications which is critical in this art area due to the rapid rate at which software evolves. If there is also difficulty in retaining experienced software examiners then salary increases have to be considered as well. Of course, if examiners do not have a robust software prior art database with which to make solid novelty and obviousness determinations, then we have to find where there may be holes and see what can be done to fill them in. The examination process might also benefit from an approach where software is viewed in a more mechanical sense. Where, for example, the routines and subroutines are seen as being analogous to machine components, such as gears, ball bearings and shafts. Thus, as invention can be found with machines in the novel arrangement of known elements and/or in the use of a new element, it then follows that software novelty can reside in the unique combination of known elements, i.e. routines, and/or in the development of new routines.
In conclusion, to question the patentability of software simply because certain software-based patents have issued that should not have or because certain types of software patents appear to be clogging the courts due to very questionable behavior of certain patent owners or that software fails to meet some sort of metaphysical :”concreteness” requirement, is, I believe, to miss the point entirely. All software inventions, including business methods, have the potential for achieving results that benefit society and do so in a way that is novel and nonobvious and should not be obstructed by Sec. 101 due to other factors not the fault of the software applicant. Additionally, we need to be aware of the fact that software is used to run essentially everything in modern society, including, cell phones, automobiles, and personal computers and not to mention mission critical systems that impact our national security such as our electrical energy and communications networks. Thus, to deny or to call into question patent protection for software generally, or even for a subset thereof, would be unwise as it may hinder an industry that is critical to our technological and economic future. For these reasons I think we have to assume the per se patentability of software, rely on a good novelty and obviousness determination to prevent the issuance of software patent applications not deserving of allowance and move ahead with making any improvements that are required to our system for assessing the patentability of such technology. I think this approach will be far more productive and efficient in the long run as compared to any attempt at drawing patentability subject matter lines between various classes of software based inventions. More importantly, to do otherwise would be to shirk our duty under the constitution to “promote the progress of Science and useful Arts” .
Sten E. Hakanson is Senior Patent Counsel for the national law firm of Foley & Mansfield. he can be reached at 612-338-8788 or via e-mail at email@example.com.