Patent law's unpredictability doctrine and the software arts.

• Author: Vetter, Greg R.
• Position: Evolving the Court of Appeals for the Federal Circuit and Its Patent Law Jurisprudence

TABLE OF CONTENTS I. INTRODUCTION II. EFFORT CURVES IN TECHNOLOGY DEVELOPMENT A. The Norden Model B. Prototype in Light of Design C. Product in Light of Prototype III. Patent Disclosure & Unpredictability A. Disclosure and the Software Arts 1. Enablement 2. Best Mode 3. Claim-Defining Disclosure Doctrines a. Written Description b. Definiteness c. Means-Plus-Function ([section] 112 [paragraph] 6) Claim Limitations B. The Unpredictable Technology Doctrine IV. AN UNPREDICTABILITY DOCTRINE FOR THE SOFTWARE ARTS? A. Unpredictability and Software B. Enablement V. CONCLUSION I. INTRODUCTION

For software patents, much of the influence on the enablement doctrine and its undue experimentation proviso, including the important "unpredictable technology" factor for the proviso, arises from cases where the software technology at issue is now many decades old. For example, in the important software enablement case of Northern Telecom, Inc. v. Datapoint Corp., (1) the original filing date of the claims for a data entry terminal was in 1971. (2) The terminal used software to operate, thus raising the question whether the patent gave sufficient information to allow an artisan to make and use the disclosed technology without undue experimentation, given that the source code was not disclosed. (3) The software was tied closely to the hardware, partly because its purpose was to give the terminal its functionality, and partly because software ran closer to the hardware in the early 1970s than it does today. (4) The more the software of the 1970s ran close to the hardware, the more it might have made sense to develop a jurisprudence categorizing software as a predictable technology, akin to many areas of electrical engineering. But software and the law relating to software patents have changed dramatically since the 1970s. (5)

Using a particular model of research and development, in light of the insights above, this Article argues that the unpredictable technology doctrine should not be applied categorically. The insights of the model suggest this conclusion generally, but the article treats software as an example of the issue.

The model postulates phases for a research and development project and then presents curves representing the learning effort typically observed under each phase. (6) Developed by Peter Norden, an IBM researcher, the model remains influential in software development as a theoretical basis for software project cost estimating. (7) This Article refers to the model as the Norden model, using a stylized presentation of the model from a software engineering textbook. (8) The phases are planning, design, prototype, product, and modification. (9) The last phase, modification, is not used in this Article's application of the model.

In the Norden model, enablement is a relationship between the design and prototype effort curves. The research and development team will transition from the design phase to the prototype phase. Information transference will be comparatively efficient, assuming continuity for the research team. How difficult it is to build the prototype will depend in part on the quality of the design, and in part on the then-present character of the technology niche at which the research is aimed. Further, the current state of knowledge about the technology influences the success of design and prototyping. For successful research and development, the team works through the phases in a progressive fashion.

To map this pattern to enablement, the design information corresponds to the disclosure given in a patent instrument. The prototype is the effort of an artisan to make and use the invention. But a patent introduces an information discontinuity. Not only is the patent-reading artisan not an original developer, the nature of the patent instrument obfuscates the disclosure. (10) Legal doctrines in patent law that measure the sufficiency of disclosure are important to account for the information discontinuity.

Information is a substitute for learning effort. The patent-reading artisan was not part of the invention development team, but need not expend the effort under the design phase, because she can obtain the benefit of that effort from the disclosed design information.

Enablement, then, under the Norden model, focuses on the interrelationship between the design and prototype phases. If the effort to build the prototype is so great as to be undue, given design information disclosed in a patent, then the claim is not enabled. Norden modeled each phase of the research and development project with an effort curve, where effort rose, peaked, and then fell. (11) The curves for the phases overlap. (12) Thus, a very high and wide prototype curve, representing great effort over a long time, suggests a claim that is not enabled because the design information was insufficient. Great effort, or quantitatively large effort, is not necessarily undue experimentation because that rubric includes qualitative assessments, but the quantitative aspects of enablement correspond with the Norden model.

The model also fits well with other patent law doctrines, most notably the best mode disclosure doctrine. (13) It also helps explain the doctrines that eliminate the patentee's disclosure burden for information related to manufacturing the invention at scale or efficiently. In Norden model terms, these doctrines say that information represented by the effort under the product phase is not information that patent law obligates for disclosure, unless the claims map to that space and/or a best mode is present in that space.

Part II reviews these insights from the Norden model generally. Part III brings these insights to the disclosure doctrines for software patents, with particular emphasis on the unpredictability factor for undue experimentation within enablement. The model corresponds well with enablement and best mode but does not correspond as well with other disclosure-prompting doctrines whose role is related to defining the claim. Thus, the review in Part III of written description, definiteness, and means-plus-function ([section] 112 [paragraph] 6) claim limitations helps establish the contours of applicability for the Norden model.

The discussion of Part III also reviews the current state of the law for software patent disclosure: disclosure burdens are light and do not require disclosure of source code for the software. Thus, software patents may represent the high-water technology in patent law for having your cake and eating it too: trade secrecy protection attaches if the licensing and distribution of the software is according to proprietary licensing: distribution of object code, keeping source code secret. within this review of software patent disclosure law, the Article contrasts the continuum of possible disclosure modes with the Norden model and patent law's current requirements.

Part Iv then completes the article by arguing for a change to one of the requirements: reducing the categorical approach to unpredictability in the software arts. All of software should not be deemed predictable. Many niches are, but some are not.

Unpredictability is one of eight Wands factors that define undue experimentation, (14) but it is particularly important among the factors. Technologically, Part Iv explains potential sources for unpredictable or unreliable behavior in software systems. Pragmatically, the progression of software technology since the time of the precedent influencing enablement for software patents suggests a failure by the law to recognize the changes in the technology. Moreover, the disclosure doctrines in software patents have not responded to the expansion of patentable subject matter in the area of software patents. The discussion also helps show that patent law does not necessarily specify what it means by unpredictability, whether the unpredictable arts doctrine only attaches to ungovernable or inestimable items in nature or based on natural principles. Software is different as a discipline because it processes encoded information, where the encoding is derived from human thought. For some, this processing would not fit within a definition of what is "nature." Regardless, the Norden model suggests that an effort-based perspective on disclosure brings notions of unpredictability into the software arts in a nuanced and niche-specific manner.

2. EFFORT CURVES IN TECHNOLOGY DEVELOPMENT

   That new technology develops in phases is familiar. The phases have common concepts: a design phase, a build phase, and perhaps a commercialization phase. Also familiar is that the phases overlap. Consider software development. Much of the public understands that a beta test version of a software product is somewhere between the build and commercialization phase. A variety of labels might apply for the phases of technology development. (15) This Part presents a model for the phases of effort within a research and development project. Although the model originates from a 1958 article, (16) the model remains influential in software engineering, particularly in the area of estimating the human effort and associated cost to develop software. (17)

   1. The Norden Model

      Peter V. Norden spent his career in technology management, much of it with IBM, and "for more than forty years he was involved in research and development management and design and development in manufacturing and related industries." (18) He studied the staffing patterns of research and development (R & D) projects, and his work has been represented, in part, by Figure 1 below. (19)

      [FIGURE 1 OMITTED]

      Norden considered curves A through E in aggregate to develop insights used later by software project managers to develop models for estimating the cost of developing software. (20) Those models underlie commercial software and information products available at the time of this writing and used by licensees to help estimate the cost for large software...