Introduction
Since the first decisions on the legal protection of computer software
beginning more than twenty years ago,
the legal world has constantly bickered over the proper intellectual property
law mechanism, patent or copyright, for protecting computer software.
From time to time, and seemingly more so as of late, the computer world
has chimed in with their own informed opinions on the matter.
For better or for worse, the only conclusion the avid student of this
debate can draw with certainty is that this surely is not an
underwritten-about area of intellectual property law.
Every Tom, Dick, Jane, and Harry intellectual property attorney,
professor, and student has seemingly entered the fray at one time or another.
With all this serving as a backdrop, the studious reader will no doubt
be puzzled at the lack of scholarship on the nature of computer software
itself, and the clues it proffers for the legal protection of software.
Few theorists and commentators have bothered probing into the technical
nature of software.
Even fewer have attempted to draw conclusions about how software should
be protected, based on its underlying nature.
Most oddly, none have acknowledged the changing nature of
software in the past twenty years, and how this may in fact explain -- as well
as have instigated -- the shift in legal protection of computer software from
a copyright-centric to a patent-centric regime.
This is a curious hole in the literature on computer software.
As any empiricist worth her salt will tell you, understanding the thing
that law sets out to regulate will aid in regulating it correctly.
With that lofty goal in mind, this Article attempts to plug this gap in
the scholarship on computer software. We
study how the nature of software itself has changed over the years, how the
legal protection of software has shifted during this same time period, how the
latter phenomena is consistent with the former phenomena, and how the latter
may even have come about as a result of the former.
In Section I., the historical nature of software is examined,
introducing the reader to the Turing model of computer software.
After the model is fleshed out in sufficient detail, we quickly usher
in the legal implications of this model, discovering how it conforms with a
copyright regime for legally protecting software.
In Section II., we fast-forward to the modern-day nature of software,
dissecting in great detail the latest buzzword enthralling the computer
industry, object-oriented programming. The
legal conclusions reached under this model are discussed, acquainting the
reader with object-oriented programming's consistency with a patent scheme for
legally protecting software. We
end with Section III., drawing some final conclusions on how patent and
copyright might interact to adequately protect software, based on both the
Turing and object-oriented models.
I. From
Copyright . . .
A. The
Turing Model
Not widely understood by most legal
theorists, but readily acknowledged -- implicitly or explicitly -- by nearly
all computer scientists, programmers, and engineers, is the vast
transformation computer software has undergone over the past twenty years.
The early copyright decisions, for example, dealt with simplistic
software that is a far cry from the complex software of today.
Early software is a horse-and-buggy carriage when compared to the
automobile of modern-era software. An
understanding of the historical nature of software, and how it fits into the
legal regime protecting intellectual property, will prove fruitful in later
justifying how the law currently treats computer software.
In the pioneer days of computer
programming, before there were even that many computers to program, in the
1930's and 1940's, computer theorists set up a model of what a computer
program "is" that only began to erode in the 1980's.
Alan Turing, one of the early pioneers in the field of computing
theory, perhaps most elegantly laid out what a computer program "is"
when he described his "Turing machine", a conceptual model for a
computational machine, or a computer.
Turing's model accentuated the procedural, serialized approach to
computers.
Under this approach, computer programs have
a set and definable beginning, and a set and definable end.
Each program has a goal, and a list of computer instructions that, if
constructed properly, will achieve that goal when completed in a step-by-step
manner. A computer processing
such a computer program will start at step one, go to step two, then step
three, etc., until it has exhausted all the given steps on a program.
That Turing and other first-generation
computer scientists conceived of computer programs in this way makes complete
sense. Most of these computer
scientists were formally trained in mathematics, and therefore brought with
them their mathematics-intensive approaches when tackling the new problem of
computer programming. The
construction of computer programs was nothing more than a "mathematical
activity".
Programs were driven through "mathematical insight, calculation,
and proof, using algebraic laws as simple and elegant as those of elementary
arithmetic."
That mathematicians were responsible for
the early model of computer software is instrumental in understanding why
their model would ultimately have to change as the computer software industry
matured. Computer science must
yield to computer engineering when it comes to determining how to reduce
theory into practice. Science is
not engineering, although the two are intertwined.
As businesses began adopting on a wide-scale basis the use of computers
in their operations, they demanded attention to goals different than those of
computer scientists. Whereas
computer scientists concentrate on the cutting edge of technology, centering
more on the theoretical than the practical, computer engineers focus on the
practical, concentrating their efforts more towards making software more
efficient and reliable.
From the simple Turing model of a computer
program, several things quickly became clear as founded in this basic theory.
The first is the clear distinction between "code" and
"data", the two constituents of a program.
The code is the set of steps a computer will go through, step-by-step,
in order to achieve a wanted result. Conversely,
data is that information either fed into the code of a program, used by the
code, or generated by the code, in order to assist the code in reaching a
program's desired goal. In
lawyerly like terms, computer theorists have thought of code and data as
separate from one another "as strictly as Church and State."
For example, consider the simplistic
program of achieving the goal of adding three whole numbers.
The user of this program would feed into the code data consisting of
three whole numbers. Call these
numbers A, B, and C. Step one of
such a program would add numbers A and B, calling the result D.
Step two of such a program would add numbers D and C, labeling the
result E. The data of the program
in this example are the numbers A, B, C, D, and E.
The code consists of the two steps, first adding numbers A and B, and
then adding numbers C and D. In
other words, the program's code is the machinery of a program, whereas the
data is the raw material processed by the machine.
Most legally oriented people -- and indeed
most computer programmers and theorists until the mid to late 1980's -- have
trouble appreciating what a big conceptual leap the code/data distinction
really is. After all,
conventional thinking goes, to separate data from code, and code from data,
seems so intuitive. Moreover, the
alternative does not make much sense on first impression: how can code be
data, or data be code?
In part, this reflects how powerful and entrenched Turing's conceptual
model is. From its creation in
the late 1930's and early 1940's, forty years passed before even computer
experts could fathom an alternative model of computer software, let
alone rigorously formulate one.
Before going on to other important features
of the Turing conception of computer software, one pragmatically driven aspect
of the Turing model, borne out of necessity when composing large programs and
not entirely required by the model itself, should be acknowledged.
Among computer programmers and scientists, Turing-type models of
computer programs are called procedural models.
The difference between these modern-day incarnations of the Turing
model and the original model is primarily an accommodation of the length to
which programs have grown. Turing
perhaps would not have predicted that today some 100 billion lines of computer
code are in use across the United States.
With programs quickly reaching such great lengths, computer scientists
had to figure out how to write programs in such a way so that programmers
could easily understand them, both while and after the program is written.
What the scientists ultimately came up with
was a tweaking of the original Turing model, rather than a complete overhaul.
Programs were still written for processing by a computer in a
step-by-step manner, but now each individual step could itself encompass many
steps. For example, many computer
programs have to print data to the screen, where the user can view it.
For the purposes of this example, say that this process requires twenty
processing steps. Under the
unmodified Turing model, this means that every time something has to be
printed to the screen, the programmer would have to insert these twenty lines
of code. An easier way would be
to group all twenty steps of code in what is called a "procedure",
or "subroutine", and then, whenever the program has to print
something to the screen, merely "call" the print-to-screen procedure
rather than having to insert over and over the same twenty steps.
The addition of these procedures, or
subroutines, to the basic Turing model does not detract from any of the
conclusions and observations that have been drawn, or that will be drawn,
about the model itself. Where, as
in Turing's time, programs do not exceed 100 lines in length, the use of
procedures is unwarranted. However,
when, as today, programs routinely exceed 10,000 lines, the use of procedures
is necessary in order to impose some semblance of order on program-composition
processes. Whatever the label,
procedural, program decomposition, etc.,
the model itself still remains fundamentally the same.
The second integral aspect of the Turing
model is its "verb-object" approach to manipulating data.
The code is primary and is emphasized first; it is the
"verb". Dynamically,
the computer proceeds from one step of the code to another, acting on the
data, which statically remains in place, as directed by the code.
The data is emphasized only secondarily, and is the "object"
of the code's actions. In other
words, the Turing model conceives of data as sitting in one place, while
various lines of code do things to the data.
This emphasis on
code over data almost necessarily follows from a conception of a computer
program consisting of lines of code, and its extraordinary impact on the way
computer software is designed is again sometimes easily lost on legally
oriented people. If a program is
a collection of lines of code that manipulates data, then, put that way, code
does seem more important than data. A
programmer writes code, not data; she spends most of her time with the active
-- the code -- and not the passive -- the data.
Data is but a means to an end, an entity processed by the code in order
to reach the desired goal of a program.
In fact, many times how the data is structured is nothing more than an
afterthought, focused upon only after the code has been written.
The verb-object approach of the Turing model thus serves to wildly
overemphasize one half of the code/data dichotomy, to the denigration of the
other.
Again, the attraction to this aspect of the
Turing model is largely intuitive. When
we say that "programmers program programs", we usually mean that
"programmers compose code". The
alternative does not make much sense: what does it mean for a programmer to
instead compose data? Even if we
do not understand the lines of code themselves, we can still admire the
intellectual achievement of writing 10,000 lines of code.
In many ways, a program is like a book; the programmer has sat down and
actually written something. Data
is a different story. It is much
harder to appreciate the intellectual capital that has gone into, say,
constructing a list of 10,000 telephone numbers.
Once more, this reflects how powerful and entrenched the Turing model
is -- until recently, most computer programmers would agree that the bulk of
programming is -- as well as it should be -- writing code, not designing data.
The problem with the verb-object approach
of the Turing model becomes apparent when a line of code expects one type of
data but receives another.
For example, in the hypothetical program that adds three numbers A, B,
and C, the step of the program that adds numbers A and B and puts the results
in D expects that A and B are indeed numbers.
However, an error on the part of the user of this program may instead
result in the word "alpha" being placed in A.
The computer may just assume A to be zero, it may crash, or it may do
something totally unexpected. Now,
this specific problem is so trivial it will probably never happen.
However, one can imagine the problem arising where one line of code
expects a person's state to be listed in the form of a two-letter U.S. Post
Office abbreviation (CT, MN, etc.), and another expects it to be listed in the
form of a generally accepted abbreviation (Conn., Minn., etc.).
The legal theorist's solution to this
problem -- and the solution most favored by computer experts until recently --
may be just to take more care and exercise greater caution when writing a
program. After all, so the
argument goes, there is nothing inherent in the Turing model that forces a
programmer to utilize the verb-object approach in such a way as to
overemphasize the code of a program at the expense of the data.
In other words, even though the verb-object approach is an integral
component of the Turing model, this in itself does not excuse the programmer
from poorly designing the data component of the program.
Reality, however, frequently falls short of the ideal when push comes
to shove, in an era of multiple-authored programs and tight deadlines.
This is especially true where the model itself is biased in favor of
code over data, and thus doctrinally albeit subtly nudges the programmer to
ignore data.
To this end, the verb-object approach and its corresponding emphasis on
code are an integral aspect of the Turing model of computer software.
The final significant aspect of the Turing
conception of computer software is the way in which it relates to how
programmers writing programs so conceptualized view themselves.
This is important, because how programmers view themselves and their
craft frequently becomes the nonprogrammers' perception of what it actually is
programmers do.
To reuse an previous analogy, a programmer is the author of her
artistic work; she is the composer to the program's symphony.
The programmer
strives for elegant and beautiful code. She
pores over the available computer languages, picking the one that best suits
her needs as a writer chooses a different writing style for composing a book
than for writing a poem. The
programmer then carefully constructs her artistry line-by-line, placing
commands in the most optimal way, just as a good writer picks just the correct
verb that conveys the correct meaning, but which does not overly bog down the
rest of the sentence.
Above all else, the programmer is a craftsman, steeped in the part-art
and part-science of computer programming as a blacksmith was in the days
before the Industrial Revolution.
The nonprogrammer reader may find this
description a bit far-fetched. It
may very well be. But the
perception on the part of programmers themselves of what it is they did
historically is very close to the author/craftsman metaphor described above.
The fact of the matter is most programmers feel a kinship with their
brothers and sisters in the arts, more so than with members of the engineering
and scientific community.
To ignore this is ignore a greater reality.
Programmers believe that they are artists first and engineers second.
This perspective shapes the way in which they approach problems, and
more importantly, the way in which programs are actually written.
For example, programmers believe their
craft to be domain-independent, in that so long as they are knowledgeable in
computer programming, they can apply their craft to any problem, without first
becoming versed in the scientific background underlying the problem.
Other engineering and scientific disciplines do not operate this way.
Mechanical engineers may feel competent in designing bridges or brake
systems for cars, but not both, even though the underlying mechanical laws are
the same for both problems. Theirs
is a tangible, I-can-touch-it discipline; when you get right down to it, a
bridge is quite different than a car. Conversely,
programmers do not feel that theirs is a tangibility-oriented craft; rather,
theirs is a "solitary, mental, abstract" activity.
They are composing something intangible, not building "tangible,
commercial goods."
So long as they know their "computer stuff," it does not
matter that they are writing a word-processing program or a stock-trading
program -- these are distinctions without a difference.
In sum, Turing programmers operate in a
pre-Industrial Revolution time period.
As artists carefully constructing their programs line by line, they
crafted each individual program no differently than skilled gunsmiths crafted
each individual rifle before Eli Whitney invented interchangeable parts.
In short, they were part-artist and part-mathematician.
Because programming involved creativity unfounded in mathematics, and
probably because the world of arts is more glamorous than the world of
science, they perceived themselves more as artists than engineers.
Their work, like that of all artists, was imprecise, intangible, and
something that could not be reduced to a mere set of rules or guidelines so
that others could become as proficient as they in their craft.
Programmers were born, not made. They
strove for elegance and simplicity in their programs, many times placing these
goals above efficiency and reliability. The
result of their work was as intangible and abstract as they thought it should
be; in short they packed the desired conclusion into their starting premise.
B. Legal
Protection Under the Turing Model
Until at least 1986, with the decision of Whelan
Assocs., Inc. v. Jaslow Dental Lab., Inc.,
the high-water mark of the era, legal protection of computer software was
principally accomplished through copyright law, not patent law.
More recent legal developments stressing patent law over copyright law
have left legal theorists scrambling to explain why copyright law is no longer
adequate to protect software, or to argue that copyright law never was
adequate in the first place to protect software.
This much is certain, however: historically, meaning from the early
1970's through the mid 1980's, copyright law was viewed as the primary legal
protection scheme for computer software.
When compared to the backdrop provided by
the Turing model of computer software,
copyright law easily emerges as the most logical and consistent legal
mechanism with which to protect computer software -- especially when compared
to its distant cousin, patent law. Several
aspects of the Turing model
compel this conclusion. For
example, the code/data distinction and the accompanying verb/object approach
and its emphasis on code over data play right into the strengths of copyright
law. The data component of the
code/data dichotomy can be conceptualized in one of two ways: as raw data
itself (e.g., a list of phone numbers), or as a data structure in which raw
data can be placed (e.g., to organize the states in a mailing list according
to either their two-letter U.S. Post Office abbreviation -- CT, MN, etc. -- or
conversely by their commonly used four-letter abbreviation -- Conn., Minn.,
etc.). Either way, copyright law
does not extend protection to data.
In the former instance, raw data itself is
not protectable under the reasoning provided by Feist Publications, Inc. v.
Rural Tel. Serv. Co., Inc.
In Feist, Justice O'Connor, writing for the majority of the
Supreme Court, held that the white pages of a telephone directory is not
statutory subject matter under copyright law.
Spurning "sweat of the brow" analysis, which explains that
copyright protection is given to the collector of data because of the great
effort expended by that collector, O'Connor found this analysis contrary to
the sine qua non of copyright law, creativity.
Because the collection and arrangement of raw data in an obvious matter
exacts less than the modicum of creativity required by copyright law, data is
uncopyrightable. Data stored by
computer programs and manipulated by the code found in such programs is no
different.
In the latter instance, the data structure
used by a computer program to store raw data is not protectable under the
reasoning provided by Baker v. Selden.
In Baker, the Supreme Court held that a specially designed
accounting form was uncopyrightable.
This is because, pursuant to the idea/expression dichotomy in copyright
law wherein only the expression, and not the idea underlying the expression,
is copyrightable, the value in such a form lies not in the specific form
itself, but in the idea of making such a form in the first place.
In other words, a competitor is prohibited under copyright law from
exactly copying the specific form itself (the expression), but not from
designing similar such forms (the idea).
Similarly, the data structure utilized by a particular computer program
is protected under copyright law only to the extent of its specific
expression, which is generally trivial; the idea of using a novel type of data
structure, the idea behind the expression, is not protected.
Copyright therefore encourages programmers
to deemphasize data. Similar to
the historical nature of software, which deemphasizes the data component of a
computer program, copyright law also shies away from extending protection to
data. A computer programmer only
concerned about obtaining copyright protection for her program would not want
to expend too much effort on the program's data component, because she knows
that copyright will afford little protection to the data.
Similarly, if she is steeped in the Turing model of computer software
then she will naturally favor the code component of a program over the data
component. In other words, if she
starts composing her program only with the thought that she definitely wants
copyright protection for it, she would focus her attention on the code
component, and even if she does not, she still will arrive in the same place,
because following the Turing model will take her there.
Copyright law is consistent with and parallel to the Turing model's
deemphasis of the data component of computer software.
Even more consistent with copyright law is
how computer programmers approach writing the code segment of a computer
program. Copyright law was
originally meant to protect literary works, like books, works of art, music,
and, later, films and videos.
When the National Commission on New Technological Uses of Copyrighted
Works (CONTU)
originally proposed that copyright law should be expanded to protect computer
software, one of the more significant opposing arguments was that software is
a technology, and therefore different than books, works of art, and music.
To get around this -- and, indeed, this was perhaps the original appeal
of providing copyright protection to computer software in the first place --
proponents successfully focused on the other aspect of the hybrid nature of
computer software,
that besides being a technology, it is also a literary medium, or a text.
The concept that software has a dualistic
nature is important, since it underlies much of the disagreement over what
legal protection scheme, copyright or patent, is better situated to protect
it. Software is the first
technology that has this dual nature, although it may very well not be the
last.
Unlike other technology of a more physical nature, like electricity,
chemistry, or materials science, its construction medium "happens to be
text."
Unlike other literary works whose construction medium is also text,
computer software is a technology.
This puts intellectual property law in a conundrum.
Because computer software is both literary work and technology, it
"straddles a boundary long assumed by intellectual property law to be
unbridgeable."
In a legal regime where patents protect technology and copyrights
protect literary works and never the two shall meet, computer software at once
fits in both the round socket of patent law, and the square socket of
copyright law.
It is quite "protean"
indeed.
Since computer programmers see themselves
as more artist than engineer under the Turing model of computer software
development, copyright law is especially cogent in protecting software.
How programmers express themselves in their programs directly relates
to the protection that copyright will afford them.
Under the Turing model, programmers express themselves in code, and
therefore it is the code that programmers expect to receive protection.
Copyright law is consistent with this view; as stated above, it does
not protect data and data structures. More
specifically, copyright law complements the conclusion drawn from the Turing
model that programmers engage in "solitary, mental, abstract"
activity.
Copyrightable subject matter is expressed in programs at relatively
high levels of abstraction.
Thus, where the programmer thinks of her craft as abstract, copyright
law concurs by dispensing protection in accordance to a given level of
abstraction within the program.
The significance of this cannot be
understated. Under the Turing
model, computer programmers view their work as intangible, abstract creations
similar to literary works -- exactly what the copyright regime means to
protect. A programmer composes a
program through careful construction of computer language commands, each
thoughtfully chosen in order to achieve just the effect the programmer wishes
to convey. It is no accident,
then, that copyright was chosen first, over patent, to protect computer
software. The persons receiving
these freshly given copyrights seemed no different than other artisans, except
that their medium was digital, not physical.
Copyright all along has rewarded those harboring creativity; above
everything else, it is this that programmers share with their artist brothers
and sisters.
In addition to the process by which Turing
programs are created meshing with copyright law, the subject matter, too, is
ripe for copyright protection. In
other words, once data is sifted out of a program, justifying protecting the
code of a computer program via copyright does not end by pointing out the
similarities between programmers and others who routinely receive copyright
protection. This would be
incongruous, insofar as it is the subject matter, and not the creator of the
subject matter, that is the determinative factor in whether a copyright will
be granted. Here, too, copyright
law emerges as the clear and consistent choice when compared against the
backdrop provided by the Turing model of computer software.
Ultimately, the code of a computer program
under the Turing model is a text, a literary work like any other.
To be sure, this view is incomplete,
because of software's inherently dualistic nature.
But at least on one level, this is what it is.
Because protecting text is to large extent what copyright law is all
about, it is natural for it to protect computer software as well.
Therefore, copyright law is well prepared to protect a media so closely
associated with other subject matter it has protected honorably throughout the
ages. Its vocabulary and concepts
are well steeped in protecting traditional textual works, such as novels and
poems. It is but a small step to
include the code of computer software under this umbrella of protection.
In short, copyright law is well suited to protect computer software as
understood under the Turing model. Like
the Turing model, copyright law deemphasizes the importance of data.
The programming process under the Turing model, abstract and
craftsman-like, fits well with traditional notions of copyright law.
Finally, the code of a computer program under the Turing model is like
any other text protectable by copyright.
This, of course, is only half the story.
Besides understanding how Turing computer software meshes with
copyright law, an effort must also be made to investigate why patent law
spurned computer software initially -- that is, why courts originally
determined that computer software was not best protected under a patent
regime. Luckily, here, too, the
Turing model presents us clear answers. The
Supreme Court decisions on the patentability of computer software, Gottschalk
v. Benson,
Parker v. Flook,
and Diamond v. Diehr,
left the intellectual property community believing that at worst software was
unpatentable and at best was only with great difficulty patented.
Thus, their preoccupation with copyright is understandable.
Today patent law is being increasingly turned to for protecting
computer software.
Patent law's initial refusal to protect computer software,
however, has much to do with the historical nature of software, as understood
under the Turing model.
Under the Turing model, first-generation
computer scientists perceived the construction of computer programs as little
more than an abstract, intangible mathematical activity.
Their computer programs were a series of mental steps, intangible in
nature, borrowing heavily from all that they had learned before in
mathematics. Although they were
more artist than scientist in constructing their programs, the programs
themselves were primarily mathematical and algorithmic in nature.
Programs were driven through mathematical calculation and proof,
plodding along a step-by-step analysis reminiscent of a mathematician plodding
along a step-by-step solution to a problem.
Put this way, it is not surprising that patent law spurned computer
software.
For example, in Gottschalk v. Benson,
Benson unsuccessfully tried to claim an algorithm for BCD
to binary conversion, without regard to any application for which it might be
used.
Similar to any program under the Turing model, Benson's was abstract
and intangible. He did not link
it to any specific physical device, but instead claimed an invention that was
quintessentially a Turing machine: numbers were fed into his program, and
numbers came out of his program -- with no regard at all for what those
numbers meant. Because
"abstract ideas, scientific principles, and laws of nature are not
patentable,"
the Supreme Court had little choice but to deny Benson's patent application.
Under the "mental steps" doctrine, processes that can be
performed using pencil and paper -- and thus are nothing more than an
embodiment of a collection of mental steps -- are unpatentable.
That patent law and the Turing model of computer software are
inconsistent is therefore quite obvious.
Patent law frowns upon protecting the abstract, the intangible, and
that which is nothing more than mathematical algorithm.
Under the Turing model, however, computer software essentially is just
that.
Subsequent Supreme Court decisions show
that patent would only protect computer software when software departed from
the Turing model. In Diamond
v. Diehr,
the Court approved of Diehr's process claim involving the use of an algorithm
in a rubber molding process. Diehr
was not claiming solely the mathematical algorithm at issue in his patent
application, but only how the algorithm related to the also disclosed rubber
molding process. In this way, he
removed his program from the Turing model of computer software.
His was more than mere intangible, mathematical activity; it was in
fact a tangible, physical activity only rooted in intangible, mathematical
activity. Diehr was not
attempting to claim that his approach was the end-all and know-all to any
scientific problem. Rather,
unlike Turing model programmers who believe their programs are applicable to
any problem, without regard to the underlying scientific background of that
problem,
he only claimed competence in computer programs relating to a specific domain,
rubber molding. The Supreme Court
approved his patent application, because Diehr did not preempt the use of his
mathematical algorithm by others outside of the rubber molding field.
The Freeman-Walter-Abele
test, a two-step test for determining the patentability of computer software
that evolved through the decisions In re Freeman,
In re Walter,
and In re Abele,
passed down by the Court of Claims and Patent Appeals, also supports patent's
inconsistency with the Turing model of computer software.
The basic test is that first a court must determine whether an
invention contains a mathematical algorithm.
If it does, it is patentable only if it passes the second step, which
is to remove the mathematical algorithm from the claimed invention, and then
analyze what remains for patentability. The
gist of the test is to render unpatentable those inventions whose essence and
primary focus are only a mathematical algorithm.
If all that is claimed is a Turing computer
program, then the patent application will be denied under the Freeman-Walter-Abele
test. Because a computer program
under the Turing model is nothing more than a mathematical algorithm carried
out by a computer, under the second step of analysis removal of the algorithm
from the claimed invention will eliminate the heart and soul of the invention,
resulting in an empty unpatentable claim.
Note that the clever claim writer is also frustrated by the test if she
tries to satisfy Freeman-Walter-Abele by merely including
a specific domain in which the program can operate, but one to which it
has no inextricable relation. In
Walter, for example, even though a specific end use was cited in the
claim, seismology, the Court, determining that ultimately the claim was
nothing more than a collection of mere calculations, denied the patent
application.
These decisions all point to the
proposition that "a claim that incorporates a mathematical algorithm and
defines the solution to a specific problem, and not merely the solution to a
mathematical formula, will define patentable subject matter."
Under the Turing model of computer software, however, a computer
program does not define a solution to a particular problem.
Computer programmers adhering to the Turing model believe that their
knowledge is distributable across any domain, and need not be restrained to
any one particular tangible domain -- the software, intangible, the programmer
not an engineer but a quasi-artist. If
the programmer believes that her work cuts across physical, tangible
boundaries, then patent law cannot afford her protection.
It protects specific solutions to specific problems, and cannot
tolerate a proposed solution that solves all problems of its type,
regardless of application. The
Turing model, in other words, compels conclusion that the patent regime is
incompatible with computer software, as conceived under the model.
If software is the work of an artist, not an engineer, if software is
intangible, not tangible, if software is but nothing more than a series of
mental steps, patent will not -- because it cannot --protect it.
II. To
Patent . . .
A. The
Object-Oriented Model
A revolution underway in how software is
constructed, and what software "is", is changing for the better the
fields of computer science and software engineering.
Those unattuned with this revolution -- a group that includes most
legal theorists -- are largely ignorant of what these changes are, and what
they have in store for how legal protection is afforded to computer software.
The revolution is a sea change, rendering inapplicable all past
metaphors used in relation to computer software, including the Turing model.
This new paradigm of computer software is called "object-oriented
programming", or OOP, for short.
Object-oriented programming came onto the computer software scene in
the 1980's.
Its introduction represented a "massive shift in programming
paradigms," and portends eventually a more dramatic impact on computer
programmers and computer programming than almost any other event in the short
history of computer science.
The basic object-oriented programming model
of computer software departs significantly from the historical Turing model.
Under the Turing model, a programmer thinks of code as text, sitting
down to write a program book-style -- the program has a clear beginning, and a
clear end. For example, a
rudimentary word processing program might allow a user to accomplish two
things, entry of text by a user, and output of text to a printer.
The Turing computer programmer would have these two goals in mind as
she writes the word processor, line-by-line.
The completed program would consist of a number of lines of code, to be
processed by a computer in a step-by-step manner, which would proceed
sequentially through the lines of code, until it reached the last line.
The object-oriented computer programmer
would approach composition of this word processing program very differently.
Rather than conceptualizing the program as one program consisting of a
serial set of lines of code written in order to accomplish two goals, she
would instead conceptualize the word processor as encompassing two
"objects," a data-entry object, and an output-to-printer object.
Rather than writing one computer program, she essentially would write
two smaller programs. A computer
processing this program would, instead of going through a program
sequentially, step-by-step, flit the data a user is working on -- the document
to be written: a letter, say, or a law review article -- between the two
objects as stipulated by the user.
A primary advantage of the object-oriented
model of computer softwares comes when the software must be changed.
A common feature of word processors is the ability to check a document
to ensure that it contains no spelling errors.
The Turing word processor discussed above would be difficult to modify.
A programmer would have to examine the lines of code she has already
written, and attempt to insert more lines to incorporate a spell checker
within the word processor, without disturbing the text-entry and
output-to-printer features already implemented.
This may be very difficult, especially if the program is
"long," i.e., has many lines of code, or if the programmer adding
the spell checker is not the same person who originally wrote the word
processor. In very complex
programs, understanding what someone else has written and then trying to
modify it is many times more difficult and time-consuming than writing a
brand-new program from scratch.
That the Turing model is difficult to
modify is not difficult to grasp. The
programmer writing the original word processor has only two set goals in mind,
text entry and output to printer. Her
finished product is like a bound book. Adding
pages later is difficult to accomplish, and in any case, even if physically
possible, the new pages will rarely mesh well with the old pages such that the
new book has as consistent a flow as the old book did.
An author wanting to update the book is better off publishing a
brand-new book, based on the old one but largely rewritten, even if some of
the sentences from the old book are retained.
Compare this to the object-oriented word
processor. There, the programmer
does not have any set goals when creating the original word processor, so
nothing in the original word processor has to be reconsidered, rewritten, or
modified in order to add a spell checker.
Rather, the programmer only has to add a new spell-checking object to
the mix. The computer processing
this word processor now has one more object among which to flit a document;
the user of this program can now choose among three methods to manipulate
text, instead of the previous two ways.
In other words, the object-oriented
programmer would not have to examine the lines of code -- the two other
objects -- she has already written. These
two objects would remain undisturbed; the programmer would not have to figure
out how to insert a spell checker in the midst of a program that already works
well, and thus does not take the chance of upsetting the balance of the word
processor as it already stands. If
the programmer adding the spell-checking object is not the same person who
constructed the original two objects, this is of little consequence; the
original objects are little more than "black boxes"
to the subsequent programmer -- she only has to know what they do
(externally), not how they do it (internally).
The object-oriented word processor is not a book, but a binder.
A programmer has only to click open the binder and add new objects,
without fear of upsetting the objects it already contains.
This, in a nutshell, is what
object-oriented programming is all about.
The object-oriented programmer sets out her task not by delineating
goals that one monolithic program will accomplish, but rather decomposes the
problem into cooperating objects, the sum total of which comprise the program.
The objects themselves are discrete components, building blocks that
fit together to constitute larger applications.
The object-oriented programmer is not a sculptor who creates a program
by starting with a raw slab of marble and after chipping away at it enough
ends with a finished statute -- as is a Turing programmer -- but rather is an
architect who creates a program by starting with bricks and wooden boards and
after putting them together in the right way ends with a finished house.
Object-oriented software is not crafted individually like muskets in
Revolutionary days, but rather assembled like Eli Whitney's muskets, using
interchangeable parts.
The paradigm shift represented by
object-oriented programming results in conclusions regarding computer software
much different than those reached under the Turing model.
Unlike under the Turing model, under the object-oriented model
"neither code nor data is paramount."
In object-oriented terminology, the code of an object is called a
method.
Both code and method are welded together in an object.
That code is important in a computer program is intuitively obvious,
and in any case was witnessed under the Turing model.
To wit, a programmer writes code, so it has to be of
significance. However, the appeal
of elevating data to equal prominence with code is not so intuitively clear.
The legal reader, though, must satisfy herself that this is indeed the
case, or she will miss the sea change that object-oriented programming
exemplifies.
For example, we talked about the
object-oriented word processing program having three objects: the data-entry
object, the output-to-printer object, and the spell-checking object.
This is an accurate description of an object-oriented word processor,
but is an incomplete characterization of how such a word processor would
operate in an object-oriented computer system, or environment.
In other words, it does not totally explain exactly what an object
"is". The
object-oriented word processor's objects each consists of a method -- the code
to do a specific task: data entry, output to printer, spell checking, etc. --
as well as a data structure that is specifically described and standardized.
This is how different objects can interact with one another so
seamlessly -- inevitably, they all look at data in the same way, i.e., they
all have the same structure.
Now, when a user begins work on a new text
document within this word processor, she creates another object -- a
data-only object that has the same specific data structure as do the word
processor's objects. The data in
her object therefore fits hand in glove with any of the word processor's
objects, or any other objects having an identically structured data structure.
When she wants to print her document, the computer sends the object
containing her document to the output-to-printer object.
Because the data in her object is structured exactly as the
output-to-printer object expects it to be, the method in the output-to-printer
can simply do what it has to do to the data in the user's object in order to
send the document to the printer. The
computer system or environment in which object-oriented computer programs are
run is the referee in this entire process, ensuring that one object will only
run its methods on the data of another object if both have the same defined
data structures.
Put this way, even the nonprogrammer reader
should be able to appreciate the importance the object-oriented model places
on data. The code, or method, of
an object is never run until it is ensured that the object's data structure is
compatible with that of another object's data structure.
An object-oriented programmer designing an object, therefore, picks a
preexisting data structure first -- or develops a new one -- before
even beginning to write the object's method.
In some ways, then, data is even more important than code under the
object-oriented model of computer software.
Under no circumstances can a programmer simply ignore data until after
she has written the code. The
object-oriented model forces her to consider data issues first.
This deeper understanding of what objects
are all about should also dissuade the nonprogrammer reader from making the
common mistake of conceptualizing objects under the object-oriented model as
identical to procedures or subroutines under the Turing model of computer
software. Under the Turing model,
often repeated lines of code are frequently grouped together in a procedure or
subroutine; rather than listing over and over again the same twenty lines, a
programmer can first group and then "call" the code rather than
relist it.
An object is much more than grouped lines of code.
More important than its code (method) by far is an object's data
structure, which has no analog in a procedure.
A subroutine is also what its name implies: it is dependent on the main
routine, or main part of the computer program.
An object is co-equal among objects within a program.
In fact, there is no "main routine" that "calls"
objects; although the analogy is not particularly apt, to whatever extent
there is a "main routine" in an object-oriented program, the objects
themselves comprise it. That
the differences between object-oriented and Turing programs are so vast
diminishes the significance of the coincidence that both subroutines in Turing
programs and objects in object-oriented programs have "groups" of
code.
Another conceptual aspect of
object-oriented programs bears this out as well.
In contrast to the "verb-object" approach of the Turing
model, the object-oriented model has an "object-verb" approach to
manipulating data.
Unlike under the Turing model, where data is static, staying in one
place while the code of the program around it dynamically manipulates it,
under the object-oriented model the data flits from one method to another,
which themselves are visualized as static.
"Programmers no longer think of 'printing an object;' instead they
send a message to an object saying, 'Go print yourself.'"
In other words, under the Turing model, data is an elementary school
student who sits at the same desk throughout the day as different teachers, or
code, come to the student's classroom to teach her different subjects.
Under the object-oriented model, data is the more advanced high school
student who throughout the day goes from one classroom to another, to learn
subjects from teachers, or code, who always stay in the same room.
With the former, data is static and code is dynamic; with the latter,
data is dynamic and code is static.
Because an object-oriented computer program
is just that -- object-oriented, and not data- or code-oriented
-- a program's data is coequal with a program's code.
Whereas under the Turing model of computer software, the verb-object
approach accentuates the overemphasis of code, under the object-oriented
model, there is no verb-object approach.
Object-oriented's object-verb approach may be seen as another way in
which the model strives for evenhandedness in the treatment given by
programmers to both data and code. By
forcing a programmer to consider data issues before writing code, the model
ensures that the programmer cannot relegate data to the backbench and start
with the usually more exciting code aspect of a program.
Problems of the data-mismatch type,
where a program expects a number but receives a letter, for example, do not
occur in an object-oriented computer program.
The environment in which object-oriented computer programs operate
ensures that objects only manipulate data that they were designed to
manipulate. Understanding this
downside to the Turing model, the developers of the object-oriented model
designed accordingly so it would not rear its ugly head in object-oriented
programs.
The final significant aspect of the
object-oriented model of computer software relates to the concerns the
developers of the paradigm had when formulating it, and, more crucially, how
programmers writing object-oriented programs view themselves and their craft.
Unlike Turing programmers, today's programmers view themselves as more
engineer than poet, more professional than craftsman.
Engineering has supplanted craft.
Until recently, the term "software engineering" was
considered almost an oxymoron;
only with object-oriented programming techniques does the software industry
appear to close to making it a reality.
Now, however, software engineering is becoming more product-centered
than process-centered,
concentrating more on customers' specifications for programs than on the
programmers' own feelings towards computer programs and programming.
The software engineer, like all engineers,
distinguishes between routine design and innovative design.
Where a specification calls for the solution of familiar problems --
sending text to the printer, getting input from the user, etc. -- the software
engineer can merely pick an object that has already been constructed, rather
than reinventing a wheel. This is
routine design and is what spares more time for innovative design, formulating
solutions to what are truly unique and never before solved problems.
"Original designs are much more rarely needed than routine
designs, so the latter is the bread and butter of engineering."
The hallmark of routine design, and
therefore the hallmark of software engineering, is reuse of code.
Reusing the fruit of other engineers' labor means that an engineer
does not have to rewrite everything herself.
The object-oriented model of computer software lends itself
particularly well for reuse -- objects are discrete units of software that can
be transferred from one program to the next with minimal difficulty.
A software engineer writing an object-oriented word processing program,
for example, would not have to build from scratch an output-to-printer object,
which is a very standard object. Instead,
she would just take if "off the shelf" and plug it into her program.
Reusing objects, not rewriting code, is an advantage that separates
the object-oriented model from the Turing model of computer software.
Ultimately, a primary goal of the emerging
software engineering discipline is to have "software IC's."
Just as electronics manufacturers buy electrical components (integrated
circuits, or "IC's") as commodities, and add value by connecting
them in different and customized ways, so would software manufacturers buy
software components, and connect them in unique ways to add value.
In this way, "applications can be largely constructed, rather than
programmed."
A software engineer would not so much write code as assemble various
software components, in order to create a computer program.
This emphasis on reuse separates software
engineers following the object-oriented paradigm from computer programmers
following the Turing model of computer software.
Turing programmers are hell-bent on not reusing code.
After all, they are artists, not scientists, and would "no more
reuse code than Hemingway would have reused other authors' paragraphs."
As with other artists, the Turing programmer does not believe that what
she knows is an easily transferrable skill to others.
Programmers are born, not made.
Conversely, software engineers follow standard engineering
practices that enable even ordinary practitioners to create sophisticated
systems that work, unspectacularly, but reliably.
The difference between software engineers
and Turing programmers extends to the types of problems which they believe
they have a competence for solving. The
Turing programmer believes her programming knowledge is intangible and
therefore can be applied across any application domain.
The software engineer, however, understands that specific
application-domain knowledge is an important factor in whether she will be
able to reliably and efficiently apply her programming knowledge to that
domain.
A software engineer, for example, specializing in developing computer
programs for designing bridges will realize that although it is "all just
computer software," she is unqualified for developing programs for, say,
analyzing highly complex chemical structures.
In short, the differences between software
engineers and Turing programmers exemplifies the sea change between the
object-oriented model and the Turing model for computer software.
The former are product-centered, focusing on their customers, whereas
the latter are process-centered, focusing on themselves.
The software engineer attempts to reuse code wherever possible,
whereas the Turing programmer never reuses code.
The object-oriented model of computer software compels the programmer
to think of herself as an engineer above everything else; the Turing model
compels the programmer to think of herself as an artist above everything else.
It is this difference in perception that is typical of the paradigm
shift in going from a Turing model to an object-oriented model of computer
software.
B. Legal
Protection Under the Object-Oriented Model
Legal protection of computer software has
now swung from a mostly copyright-intensive to a mostly patent-intensive
scheme.
Although many in the computer industry do not like software patents,
the truth of the matter is that they are here to stay.
This does not mean that the kinks of the software-patenting process
have all been completely worked out; they have not.
Recent uproar over a single software patent granted to Compton's
NewMedia of Carlsbad, Calif.,
and its subsequent withdrawal for reexamination, unusual in that the PTO
Commissioner himself instigated the reexamination,
is proof that more work has to be done on the mechanics of the process.
The computer industry is also unaccustomed to software-patent battles;
the press reports news of them in a "what does it mean" sort of way.
This will all soon pass, however, and patents and their litigation will
become everyday occurrences in the usual course of the software industry.
When compared to the backdrop provided by
the object-oriented nature of computer software,
copyright law recedes as the primary or exclusive legal mechanism by which to
protect computer software. Whereas
first-generation software decisions, such as Whelan v. Jaslow,
extended protection to both the literal elements -- basically, the code or
text of a computer program -- and nonliteral elements -- everything else -- of
a program, second-generation software decisions, such as Computer Assocs.
Int'l, Inc. v. Altai, Inc.,
reeled in copyright protection as covering only the literal elements.
Copyright law works when the subject of protection is a literary work,
such as a Turing computer program. The
essence of Turing software, after all, is the code.
The focus is on writing the code, and therefore Turing software fits
well in a copyright scheme meant foremost to protect code.
However, object-oriented software is so
much more than code. Under an
object-oriented model of software, much more important than the code or text
of a program is the program's "behavior," for lack of a better term.
Programs are written to bring about a specific variety of behavior.
The focal point of object-oriented software is not so much their code,
but the relationships among the various objects of a program.
Software engineers, unlike Turing programmers, are results-oriented,
and write software to bring about a definite, tangible result, caring little
about the program as an end unto itself.
Against such a perspective of computer
software, copyright has little to offer in the way of protection.
Copyright protects artists from infringement of their works. This
presupposes that their works are an end unto themselves.
When, however, the works are not the primary focus, but instead but a
means through which to fulfill their goal, copyright has greater difficulty
satisfactorily protecting software. For
example, copyright law easily protects the code of a word processing program's
output-to-printer object. This,
however, is not what a word-processor "is"; it is not even what an
output-to-printer object "is".
A word processing program is greater than even the sum total of its
individual constituent objects, encompassing the objects themselves as well as
how those objects interrelate. An
object is more than just its code, rather enveloping its method, code, how
they interrelate, and how the object relates to other objects.
It is this view of computer software that
informed the Second Circuit's decision in Computer Associates v. Altai.
Although not claiming to settle the exact contours of copyright
protection for nonliteral elements of software,
the Second Circuit did state that the "highly dynamic technology" of
computer software causes software to fit into the fabric of copyright law like
a "square peg in a round hole."
To this end, in their judgment the decision they handed down would
narrow the scope of copyright protection given to computer software.
In other words, although not saying so in as many words, the Second
Circuit in Altai realized that a computer program is much more than
what it is under the Turing model -- as under the object-oriented model,
software goes beyond the literal boundaries of its code.
Therefore, the way in which computer
programmers construct software under the object-oriented model belies
software's protection under copyright law.
Copyright law does not extend protection to data and data structures.
However, object-oriented programmers recognize data as coequal with
code.
Indeed, the object-oriented model compels a programmer to first
formulate the data structure she will use for a given program, before writing
any code.
Because the object-verb approach of object-oriented programming
means that code is no longer the sole or even primary aspect of a computer
program, copyright law looms as an incomplete legal solution to protecting
computer software. It can protect
the code of objects, but has difficulty extending beyond that to encompass an
object's code, the relationship between an object's code and method, and the
relationship among objects of a program.
Also inconsistent with copyright law is how
computer programmers approach constructing computer software under the
object-oriented model. The
object-oriented programmer is a software engineer who purveys what the scope
of her program entails in the way of already existing objects, chooses these
objects, and then writes new objects only if already existing ones do not
satisfy her specifications. In
other words, routine design of computer software is more about assembling
software components to construct a program than it is writing code.
That copyright is not well suited to protect software constructed this
way is easy to see.
First of all, copyright is meant to protect
the works of artists -- books, sculptures, films, etc. -- not the works of
scientists and engineers.
This does not mean that it cannot protect the works of software
engineers, but surely the spirit of the copyright system cuts against the
grain of the way in which the object-oriented model informs computer software
development. Copyright law
anticipates a small number of artists, frequently a sole artist, lovingly
crafting a work of art that is an end unto itself;
a film, for example, does not aid the filmmaker as a means to a further end --
it is the end. Conversely,
copyright law does not anticipate teams of software engineers, usually not
working alone, methodically and monastically constructing a computer program
piece by piece, and who do not even care about the program itself, since it is
but a means to achieve an end -- the customer's specification.
Copyright law has difficulty determining
the proper scope of protection for works that are more assembly of preexisting
works than original creation. Much
easier it is to protect a Turing program, where most assuredly the programmer
reused little if any code written by another programmer, than it is to protect
an object-oriented program, based as it is on the presumption that code should
be reused.
Again, this does not mean that copyright law cannot stretch to
encompass object-oriented program, although it may burst at the seams.
Where software is not a unique creation of an artist, but rather the
routine product of an engineer,
copyright does not fit so well. The
copyright solution to object-oriented software protection is much messier than
the copyright solution to Turing software protection, involving as it does all
the second-order considerations of copyright -- derivative works, etc. --
rather than the first-order consideration of creativity.
In a nutshell, copyright does not elegantly wrap around object-oriented
software as it does Turing software.
This conclusion also follows from the
object-oriented programmer not thinking of herself as engaging in
"solitary, mental, abstract" activity, as does the Turing
programmer.
The object-oriented programmer thinks of her activity as rooted in a
specific knowledge domain, not something that easily transcends all
application domains.
This is antithetical to copyright; at the very least there is not much
room in copyright law to accommodate such a position.
The idea/expression dichotomy found in copyright law may allow for
distinctions based on the level of abstraction present in a given literary
work,
but this does not translate well into allowing for distinctions based on the
application to which a particular computer program has been put.
In part, this is because the whole concept of "applying"
something protected by copyright is foreign to basic principles of copyright
law. As stated earlier, copyright
presumes that its subject matter is an end unto itself.
Where instead a computer program operates specifically in one problem
domain, copyright will not be preclude a finding of infringement for a similar
program that operates in a different domain.
In short, copyright does not take into account these differences.
This leaves the engaged reader wondering if
patent picks up the slack where copyright has let it loose in the protection
of computer software. Luckily,
the object-oriented nature of computer software fits well under a scheme of
patent protection, and serves to explain and justify why the computer industry
has increasingly turned to patent for protecting computer software.
If the sine qua non of copyright is creativity,
then the sine qua non of patent is invention.
This enables patent law to permeate an object-oriented program and
protect its inventive features, whether or not those features are creative.
