Should your next "software" application include at least one embodiment that is a machine-specific "electronic process"?
With all the confusion about Section 101 and how it includes or excludes computer software inventions, or what level of disclosure constitutes “structure” for the purposes of 35 U.S.C. Section 112, it may help to take a quick step back and look at exactly what “software” is. While Wikipedia is far from a perfect source to quote, I like its definition of software: “Computer software, or just software, is a collection of computer programs and related data that provide the instructions for telling a computer what to do and how to do it. In other words, software is a conceptual entity which is a set of computer programs, procedures, and associated documentation concerned with the operation of a data processing system.” (http://en.wikipedia.org/wiki/Software)
In other words, “software” constitutes both a definition of specific electronic operations to be performed by an electronic computing system, and also, at its base level, actual instructions, in the form of electrical logic signals, to cause the computer to perform the electronic operations. Generally, software can be divided into two categories: low-level software that constitutes instructions in the form of digital logic elements that can be read by the computer, transformed into digital signals usable by the computer’s electronic circuits, and executed from a collection of possible machine operations. Different combinations of these electronic operations can be used to accomplish a multitude of modern data processing results.
High-level software is software that can be used, by compilation or by interpretation using a computer itself, to produce the low-level software needed to program/cause the computer to perform desired electronic operations. A computer, suitably programmed, can read high-level software to produce the low-level software and in turn electronic operations required to cause a computer to perform electronic computer operations.
High-level software itself if often represented by a flowchart, which itself typically describes a sequence of desired computer operations, at the electronic level, to perform a given computerized process. In some cases, a flowchart can represent exactly the precise, lowest level electronic operations performed by a processor, such as peforming add functions, shift functions, load functions, bus functions, etc… Such a flowchart would also serve as an exact specification for the construction of a fully hardware electronic device, i.e., one in which no software was involved, but rather all functionality was built into the electrical architecture/design of the electronic device.
Higher level flowcharts by nature and perhaps by definition, define less precisely exactly how a particular processor will perform the desired sequence of electronic operations, and as such omits the details of such operations. However, the ultimate result or functionality to be achieved by whatever exact sequence is chosen is defined. Where such “high level functionality” is novel, it could meet the test of non-obviousness.
Interestingly, cases such as In re Aoyama, discussed in a previous posting, suggest that some such software inventions can be described too generally to constitute “structure” under 35 U.S.C. § 112 ¶ 6, and as such claims directed to such functionality in a means plus function format are unpatentable as indefinite under 35 U.S.C. § 112 ¶ 2. This begs the question, what constitutes “structure” in a software environment. Certainly, if the software is low-level, in that it exactly describes an exact electronic process, i.e., sequence of computer operations to be peformed, it must constitute an acceptable level of structure or else it is not possible to achieve a means plus function claim for a software invention. When the description of functionality is at such a high level that a multitude of different low-level software-specified processes are possible for achieving the defined functionality, it can be said that constraints on “equivalents” under 35 U.S.C. § 112 ¶ 6 can only be applied at the high level of the software description, since there is no low-level definition. If the high-level description is a series of high level functions or steps, then one could argue that the specific means to achieve each function or step is unconstrained, and that the only constraint on equivalents is whether the high level functionality, i.e, the high level functions or steps, are equivalent.
The majority in In re Aoyama seems to be suggesting that where a software process is claimed under 35 U.S.C. § 112 ¶ 6, a machine-specific implementation must be provided, i.e., an implementation that describes with particularlity how the low level electronic operations available in a particular type of computer are used to perform the claimed operation. This description would provide the most definitive description of software structure possible to describe, and therefore would have to pass muster or software description ever could.
In the end, software practicioners need to be aware that the safest grounding for a software case is in the actual electronic operations performed by a computer in response to the software. The more examples of how high-level software can be implemented by low-level code, the more bullet proof a software application will be from the perspective of 35 U.S.C. § 112. While one would think that actual source code (and the compiler or interpreter to be used) or object code may be overkill in this day and age, when it is available, submission of such code in an appendix may be the easiest way to always provide at least one very specific implementation in low-level software that is unassailably as structural as one can achieve.
Back to All Resources