SOFTWARE PROTECTION–INTEGRATING PATENT, COPYRIGHT AND TRADE SECRET LAW

SOFTWARE PROTECTION--INTEGRATING PATENT, COPYRIGHT AND TRADE SECRET LAW

by Gregory J. Maier ^*

In intellectual property terms, software is a true hybrid. Although software has its origin in writing, it also possesses functionality, a property that clearly distinguishes it from ordinary writings. To write software, is to formulate instructions for reconfiguring a collection of electronic logic gates and memory cells into a virtual structure capable of accomplishing a predetermined objective. Thus what begins intellectually as a form of coded writing ultimately operates as an electronic network. The same, certainly, cannot be said of other types of writings, which are simply not capable of reconfiguring logic gates, but only of expressing intellectual concepts. Similarly, other types of electronic networks are not capable of existing entirely in the form of writings. Software is a hybrid because it both expresses intellectual concepts and has the power to physically implement them with the aid of a computer.

It is the hybrid nature of software that causes its failure to fit neatly into any one existing category of intellectual property, resulting in seemingly endless confusion as to how it may best be protected. The purpose of this article is not to place software into any particular category of intellectual property protection, but rather to identify the hybrid nature of software and to demonstrate that the very different intellectual property concepts embodied within software can be coextensively protected by patent, copyright, and trade secret. This article advocates a prospectively straightforward approach to protecting the various types of intellectual property found in software: an approach in which patents protect functioning implementations of concepts, copyrights protect modes of expression, and trade secrets protect functional aspects when patent protection is unavailable or undesirable.

As patent protection for software has experienced a more troubled legal history than copyright or trade secret protection, somewhat more emphasis is placed on historical development in this area than in the other areas.

Patent Protection

Misinformation concerning patent protection for software is widespread. Many programmers still believe that software cannot be protected by patent.¹ Pamphlets and publications make erroneous statements such as: "There is little chance in obtaining a patent for software"² and "[T]he great majority of software does not qualify for patent protection."³ The academic community also misperceives the utility of patent protection. A recent law review comment states that case law "suggests that processes that use computers may be patented, but that protection does not extend to software programs themselves,"⁴ and that "there continues to be no protection under current patent law for the large number of computer programs that are neither embodied in firmware nor related to a process of production."⁵

Confusion regarding the nonpatentability of software is not the fault of academic writers, but has its origin in case law.

The most troubling aspect of the case law is the part played in its development by the Patent and Trademark Office (PTO) because one would think that the PTO, the nation's only agency empowered to issue patents, would have had an interest in encouraging, rather than discouraging, the patenting of new technology. Early decisions of the Court of Custom and Patent Appeals (the predecessor of the Court of Appeals for the Federal Circuit) strongly suggested that the CCPA judged software patentable by the same standards as any other technology.⁶ It was the PTO that originated the theory that software did not fall within the broad statutory classes of patentable technology set forth in 35 U.S.C. 101.⁷ Sadly, this theory had its origins in bureaucratic concerns over workload, rather than in careful theoretical analysis.⁸ In the early 1970's, the PTO anticipated a deluge of software applications at a time when it did not have the resources to hire skilled software examiners.⁹ Worry about workload and backlog motivated the PTO to lead the fight against software patentability.

The fight was against the respected logic of the CCPA and led to several rather tentative Supreme Court decisions.¹⁰

The first such decision was Gottschalk v. Benson¹¹ which involved a method for converting binary coded decimal numerals directly into binary numerals for use with a general purpose digital computer. The court stated that, since the mathematical formulas in the claimed process involved had no application except in connection with a computer, any patent "would wholly preempt the mathematical formula and in practical effect would be a patent on the algorithm itself."¹² Despite the courts' noble attempt at a theoretical explanation of its preemption theory, its conclusion was influenced more by the cry for help from the PTO¹³ than by sound principles of intellectual property law. In its opinion, the court cited the PTO's lack of classification techniques and search files to handle the supposed burden of examining software applications.¹⁴ The court, persuaded by the PTO, felt that there was sufficient growth in the software industry without need for patent protection.¹⁵ Thus the Supreme Court, instigated by the PTO, relied as much upon bureaucratic economic arguments as legal principles in foreclosing one of the fastest growing areas of technology from adequate patent protection.

The CCPA resisted the Supreme Court's questionable logic and there ensued a further conflict between the courts.¹⁶ Subsequently in Parker v. Flook, involving a method for updating alarm limits during catalytic conversion processes, the Supreme Court set forth its "point of novelty test" that a claim as directed to unpatentable subject matter if the point of novelty lay in the formula or algorithm recited in the claims.¹⁷ Conventional or obvious post solution activity was not sufficient to transform an unpatentable principle into a patentable process.¹⁸ The court again considered the PTO's interest in not having to process "thousands of additional patent applications."¹⁹

This case truely marks the low point for patent protection of software inventions. The court's approach improperly imported into its analysis of eligibility of subject matter for patent protection (under § 101) the considerations of novelty and "inventiveness" which are the proper concerns of §§ 102 and 103.²⁰ The point of novelty test is wholly inconsistent with the conventional view that a patent claim must be considered as a whole.

Just prior to Flook, the CCPA had expressed its opinion that the "point of novelty" approach was inappropriate,²¹ and had set forth its two step (Freeman) analysis for determining whether a claim preempts nonstatutory subject matter as a whole:

First, it must be determined whether the claim directly or indirectly recites an algorithm in the Benson sense of the term, for a claim which fails even to recite an algorithm clearly cannot wholly preempt an algorithm. Second, the claim must be further analyzed to ascertain whether in its entirety it wholly preempts that algorithm.²²

The Freeman court addressed the confusion regarding the word "algorithm." The Benson court had defined an algorithm as "A procedure for solving a given type of mathematical problem."²³ In Freeman, the CCPA rejected a broader definition of an algorithm as "a step-by-step procedure for solving a problem or accomplishing some end."²⁴ Such a definition, said the court, is "unnecessarily detrimental to our patent system and leads to reading the word 'process' out of the statute."²⁵ The CCPA interpreted Benson as concerned only with mathematical algorithms.²⁶

Following Flook, the CCPA once again rejected the "point of novelty" approach.²⁷ The CCPA did not read Flook as adopting a "point of novelty" test (despite the fact that this is exactly what the Supreme Court had done) because it could not believe that "the Supreme Court has acted in a manner so potentially destructive."²⁸ The CCPA restated the second step of the Freeman test:

If it appears that the mathematical algorithm is implemented in a specific manner to define structural relationships between the physical elements of the claim (in apparatus claims) or to refine or limit claim steps (in process claims), the claim being otherwise statutory, the claim passes muster under § 101.²⁹

Finally, in Diamond v. Diehr, the Supreme Court changed direction and upheld the eligibility for patent protection for claims drawn to a process for curing synthetic rubber.³⁰ The Diehr Court rejected the "point of novelty" approach by saying,

In determining the eligibility . . . for patent protection[,] . . . claims must be considered as a whole. It is inappropriate to dissect the claims into old and new elements and then to ignore the presence of the old elements in the analysis. . . . The question therefore of whether a particular invention is novel is wholly apart from whether the invention falls into a category of statutory subject matter.³¹

The confusion between the requirements of § 101 and those of §§ 102 and 103 was at last resolved. The court also addressed the confusion regarding the term "algorithm," rejecting the broad definition espoused by the PTO³² and affirming the narrow definition set forth in Benson.³³

Though the majority in Diehr attempted to distinguish Diehr from Flook on the grounds that Flook's claimed invention contained insignificant post-solution activity while Diehr's claimed invention transformed or reduced an article to a different state or thing,³⁴ this distinction is questionable in technical terms. Stevens' dissent in Diehr provides an excellent analysis of the striking similarity in the method of updating the curing time calculation in Diehr and the method of updating the alarm limit in Flook.³⁵ His analysis concludes that the most significant difference between the cases was not in the characteristics of the inventions, but rather the manner in which the claims were drafted.³⁶ If this analysis is accepted as accurate, it is clear that the Flook and Diehr cases should have been decided the same way,³⁷ in favor of eligibility for patent.

Later in Diamond v. Bradley, the Supreme Court affirmed the CCPA in holding that there was no "algorithm" in an invention relating to a firmware module which directs data transfers between registers and memory.³⁸ This solidified the narrow definition of the term "algorithm" adopted in Benson.

The CCPA further clarified the meaning of the term "algorithm," holding in In re Pardo that the applicants' use of the term "algorithm" to describe the invention is not an admission of nonstatutory subject matter.³⁹ The court found no mathematical formula or calculation present in the claims in the case.⁴⁰

The CCPA again refined and finalized the Freeman software patentability test in the case In re Abele⁴¹ stating: "Thus, if the claims would be 'otherwise statutory,' id., albeit inoperative or less useful without the algorithm, the claim likewise presents statutory subject matter when the algorithm is included."⁴² The court found some claims ineligible for patent protection because they were "no more than the calculation of a number and display of the result, albeit in a particular format,"⁴³ while other similar claims were deemed eligible for patent protection.

The inescapable conclusion to be drawn from this case law is that all software claims are eligible for patent protection unless they simply involve the use of mathematical formula to calculate and display a number.⁴⁴

Software patentability is a de facto reality today, as the PTO now commonly issues patents for software inventions. Examples of patented software inventions include a process for a management control system for multiprogrammed data processing,⁴⁵ a method of constructing a task program for operating a word processing system,⁴⁶ a program that checks for spelling errors,⁴⁷ and a program that converts one programming language into another (an RPG to COBOL compiler).⁴⁸

A patent for an AC current control system is an example of how close claims can come to reciting calculations and still be accepted by the Patent Office.⁴⁹ Patents for software systems involving artificial intelligence have also been granted.⁵⁰

Perhaps the best known software patent was issued to Merrill Lynch for a Securities Brokerage and Cash Management System.⁵¹ This patent was the subject of a court action which resulted in an opinion denying a motion for summary judgment of invalidity under 35 U.S.C. § 101 for not claiming patentable subject matter.⁵² The decision, following earlier CCPA precedent, rejected the contention that a computer program is inherently an algorithm⁵³ and found no direct or indirect recitation of a procedure for solving a mathematical problem.⁵⁴

This initially favorable court action, together with the issuance of software patents by the PTO, lends considerable support to the premise that software is now generally patentable subject matter.

Stating that software is "patentable" is somewhat misleading because, as has been explained, software is a complex hybrid in terms of the intellectual property concepts it embodies. More accurately, the intellectual property embodied in the functional aspects of the software is protected by patent. The mode of expression embodied in the code that comprises the software is not specifically protected by patent, but the basic organization of the software and the manner in which it operates are in principle protectable by patent -- assuming all other standard requirements for patentability are met. Thus, while a patent may not protect against copying the mode of expression found in a software code, it would provide the legal right to prevent others from making, using, or selling the claimed software invention. On the other hand, it is difficult to imagine a situation in which copying a software code would not also result in patent infringement.⁵⁵

One of the important advantages of patents over copyrights is that patents protect against independent development, while copyrights only protect against derivation from protected works. Thus, a broadly claimed software patent could provide protection against a range of independently developed software, including programs achieving similar results with differing code structures, while copyright would provide no protection.

The patent's advantage in broader protection is, to an extent, offset by the significantly higher cost and levels of difficulty in securing protection relative to the simplicity and low cost of obtaining a copyright. When basic or valuable software concepts are at stake, however, the cost and effort involved in obtaining patent protection are minor compared to the insurance value of the rights obtained.

Copyright Protection

Copyright protects original works of authorship,⁵⁶ meaning the intellectual property embodied in the mode of expression by which intellectual concepts are conveyed.⁵⁷ The copyright law expressly prohibits copyright protection of any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described.⁵⁸ A Copyright therefore, as applied to software, would appear to protect only the intellectual property embodied in software as a mode of expression.⁵⁹ Copyright arms its owner with the legal right to prevent copying of the protected work, to prevent the distribution of copies, and to prevent the preparation of derivative works;⁶⁰ all of which are valuable rights, since software is easily copied.

The originality and creativity of a computer program may lie in the appearance and presentation of software, known as the "look and feel."⁶¹ Many have favored extending copyright to protect the mode of expression embodied in the "look and feel"⁶² as well as the literal text of software.

To constitute copyright infringement, there must be substantial similarity between the accused work and the work copyrighted, and that similarity must have been caused by the infringer "copying" the copyright owner's work.⁶³ Those in favor of protecting the "look and feel" of software by copyright adopt the position that two works are substantially similar if the "total concept and feel" of the works are alike.⁶⁴

The farthest extension of copyright protection of computer programs can be found in Whelan Associates, Inc. v. Jaslow Dental Lab.,⁶⁵ a recent landmark decision holding that copyright protection of computer programs may extend beyond the programs' literal code to their structure, sequence, and organization. The court of appeals affirmed a holding which broadly defined the expression of an idea in a computer program as "the manner in which the program operates, controls and regulates the computer in receiving, assembling, calculating, retaining, correlating, and producing information either on a screen, print-out or by audio communication."⁶⁶ This case is very significant in extending the scope of copyright protection to methods of operation, procedures, and processes which would appear to have been expressly excluded from copyright protection under 17 U.S.C.102(b)and which are perhaps better protected by patent.⁶⁷

The rationale relied upon in favor of extending copyright protection for computer programs includes: 1) the belief that computer programmers deserve some form of protection for the intellectual property they create, and 2) the assumption that there exists no other adequate means of protection.⁶⁸ In Whelan the court was concerned with providing the "proper incentive for programmers by protecting their most valuable efforts."⁶⁹ (Since patent protection was not considered applicable at the time the software was created.)

The expansive definition of "expression" in Whelan could be interpreted as extending copyright protection to the internal workings of a computer, not the traditional subject of copyright,⁷⁰ and suggesting a substantial area of overlap between patent and copyright protection.

In effect, copyright protection has been stretched in Whelan to fill the gap left when the courts denied software inventions patent protection. Stretching copyright protection is understandable, from an equitable point of view, to protect software authors/inventors who were discouraged from seeking patent protection due to the changing status of the law regarding the patentability of software inventions. The equities are particularly important in cases involving misconduct. Prospectively, however, as the intellectual property community accepts the notion that software is patentable, there may ultimately be little need to so stretch the bounds of copyright protection.

It should be noted further that there is no central appeals court for copyrights as there is for patents. Thus, the scope of copyright law in protecting software may vary among the circuit courts of appeals. This fact, and the unusual circumstances of Whelan, suggest that it may not be prudent to conclude that copyright protection will be applied with the same breadth as in Whelan by other courts faced with other factual circumstances. Nonetheless, Whelan is an important precedent when one must rely exclusively upon copyright in software litigation.

One must not suppose that copyright and patent protection are in any way at odds. Copyright protection can mesh very neatly with patent protection to provide a unique continuum of intellectual property protection in the software environment. Copyright protects against literal copying and against slavish imitation of code or mode of expression.⁷¹ Patent protects against infringing use, whether through derivation or independent development, of the broader functional aspects of software. Thus the combination of available copyright and patent protection would appear to make software the most protectable of all technology -- a far cry from its position a decade ago.

Trade Secret Protection

Trade Secret law has also been relied upon to partially fill the void left when software was denied patent protection by the courts. The Uniform Trade Secret Act presents the following definition of a trade secret:

Trade secret means information, including but not limited to, a formula, pattern, compilation, program, device, method, technique, or process, that:

1. Derives independent economic value, actual or potential, from not being generally known to, and not being readily ascertainable by proper means by, other persons who can obtain economic value from its disclosure or use, and

2. Is the subject of efforts that are reasonable under the circumstances to maintain its secrecy.⁷²

Under this basic definition of trade secret, it is clear that a computer program including logic, structure, and organization can qualify for trade secret protection as long as it is not generally known.⁷³ Where major software is developed by corporations for internal use, or where a very limited distribution of software is anticipated, the traditionally required level of secrecy is easily maintained. Similarly, if software is developed for sale on a limited basis, contractual or licensing provisions can easily be provided to maintain trade secret protection. But in mass marketing software to over-the-counter customers, it is certainly questionable as to whether an adequate degree of secrecy can be maintained,⁷⁴ or whether any contractual trade secrecy provisions can be enforced to the extent traditionally required for trade secret protection.⁷⁵

The concept of "shrink-wrap licensing" was developed in an intriguing attempt to accommodate the situation. Due to the dubious common law basis for enforcing shrink-wrap trade secret clauses,⁷⁶ states such as Louisiana have enacted laws to give these clauses legal effect.⁷⁷

Just as in the area of copyrights, the "shrink-wrap" extension of trade secret law to protect mass marketed software might be interpreted as a response to a perceived lack of adequate protection by patent. Given that many software authors/inventors have been discouraged from seeking patent protection, it is understandable that techniques such as shrink-wrap licenses including trade secret clauses would be developed in order to obtain at least a modicum of intellectual property protection. Indeed, in some circumstances such as low cost, short life span or unpatentable software, such inexpensive protection may be all that is economically justified or available. But for more valuable, more unique software where patent protection is available, shrink-wrap licenses may be needed only while patents are pending, or not at all.

Trade Secrets and Patent Disclosure

Patent protection may, of course, coexist with trade secret protection.⁷⁸ Trade secret protection may be important during the pendency of a patent application, and may even protect undisclosed details of an invention during the term of, or after the expiration of, the patent. As trade secret protection is relinquished to the extent an invention is disclosed in a patent application, there is sometimes motivation to minimize the disclosure made in a patent application in order to obtain broad patent protection and yet retain significant trade secret protection. In software terms, this can mean a patent disclosure that does not reveal any code.

Under 35 U.S.C. § 112, first paragraph, one must disclose the invention "in such full, clear, concise and exact terms as to enable any person skilled in the art to which it pertains . . . to make and use" it.⁷⁹ The best mode of carrying out the invention must also be disclosed.⁸⁰ A present issue of controversy is whether a program listing or other detailed code disclosure must be made in order to satisfy these statutory requirements. In the case of In re Sherwood,⁸¹ disclosure of the listing of the program was found unnecessary to satisfy the best mode requirement because an outline of the methodology used was provided, and detail of the code was considered to be within the ability of typical programmers. On the other hand, in White Consolidated⁸² a patent was invalidated for failure to comply with the disclosure requirements under 35 U.S.C. § 112 because key software was not disclosed. However, in White Consolidated no effort was made to disclose the missing software, other than an attempt to incorporate it into the patent by reference. Since the software in question was considered a trade secret and was not publicly available, the Court correctly concluded that the patent was invalid. Had the patent included a software disclosure of the level found in the Sherwood case, it may be assumed that the patent in White Consolidated would have been found valid.

Regarding this disclosure question, it is well established law that there is no need to describe any invention in the detail needed for direct production.⁸³ Reasonable experimentation may be required to make and use an invention disclosed in a patent specification. To require an applicant for a software patent to provide a complete program listing would raise the standard of disclosure for software inventions far above that for any other technology.⁸⁴ Such a requirement would require that an invention be disclosed so that a person of virtually no programming experience would be able to make and use it. Furthermore, all trade secrets in the program listing would be lost through publication. In general, therefore, it is consistent with well established law that complete program listings should not be required to satisfy statutory disclosure requirements in software patent applications. Disclosure of algorithms and techniques of attaining results sought must be described, but nothing further, as long as an ordinary skilled programmer could be expected to draft a workable code with no more than a reasonable degree of difficulty based upon the disclosure.

Block diagrams, flow charts and top-down diagrams are presently considered the preferable means of disclosing a program, as a person does not have to understand any particular computer language to understand such diagrams.⁸⁵ Whether or not a program listing is provided, a detailed and clearly written narrative of the program is required, since most patent examiners are not enthusiastic about disecting computer listings and normally will not issue patents on inventions they don't understand.⁸⁶

Happily, the disclosure questions for software inventions appear to be resolving themselves to a degree. Disclosure must be sufficient for one of ordinary skill in the art, at the time of the invention, to make and use the invention without "undue experimentation."⁸⁷ What is considered "undue experimentation" depends upon the nature of the invention and the level of "ordinary skill" in the art.⁸⁸ As the experience of nearly all technically educated people with software is increasing rapidly, it becom