The following patent application is a good example of the equivalences and blurry boundaries of patenting hardware and software. The patent application in general is claiming methods for designing communication data flow systems. Let's look at the claims, with a few extra claims I have written as an exercise:
United States Patent Application 20020178285
1. A method of modeling a dataflow architecture comprising the steps
of: storing in a memory indicia representative of a dataflow
architecture having components responsive to intercommunication
protocols; and processing conversions among the intercommunication
protocols to determine control structures required to implement said
dataflow architecture.
2. A method as recited in claim 1, wherein the indicia stored in
memory and the control structures are translated into a description of
an implementation of said dataflow architecture.
At this point, we just have a claim for some software to design a system. Now some might object to software patent claims such as these, preferring instead something physical to be patented, which indeed is what some of the next claims are claiming.
6. A method as recited in claim 2, where the description of an
implementation is further translated into a physical implementation of
the dataflow architecture.
Here is the "hardware" claim, since protecting the translation of something into a physical implementation is little different from protecting the physical implementation (though broader since there can be multiple translations from one description - this type of claim just avoids having to explicitly claim every such translation). Given the long history of patenting hardware, i.e., something "physical", I don't think anyone will object to claim 6.
7. A method as recited in claim 6, wherein the physical implementation
is configuration data for a FPGA.
8. A method as recited in claim 6, wherein the physical implementation
is a layout for an Application Specific Integrated Circuit (ASIC).
Certainly FPGAs and ASICs are as physical an object as you can get and therefore patentable as devices. Again, protecting the configuration data of a physical implementation is little different from protecting the physical implementation itself. Now there are multiple "FPGAs" and "ASICs" from companies such as Xilink and Altera, so do we want to waste time and money having inventors claim every specific form of physical implementation? I think not. Thus these general claims. That we are concerned about physical devices is seen in claim 10:
10. An apparatus resulting from the method recited in claim 2.
Claims 6, 7, 8 and 10, then, are claims for groups of hardware, with claim 10 being the smallest group, and claim 6 being the broadest group with subsets claims 7 and claim 8. Hard to see why any one of these claims shouldn't be allowed if any of the others are allowed. Patentability
shouldn't rise or fall on how many boring variations of claims an inventor is willing to pay for.
Now, in the circuit design world, much money is made selling and licensing hardware descriptions in EDIF/VHDL/Verilog, often as much profit as selling the physical implementation. Seems foolish to protect one form and not the other, if they are equally economically valuable and require the same amount of design and manufacturing effort to produce (that is, given the EDIF/VHDL/Verilog, you push a button to get the hardware).
Which leads to claims 3, 4 and 5:
3. A method as recited in claim 2, where the description of an
implementation is the EDIF netlisting language.
4. A method as recited in claim 2, where the description of an
implementation is structural VHDL.
5. A method as recited in claim 2, where the description of an
implementation is structural Verilog.
EDIF/VHDL/Verilog are hardware description languages, which some might not think of as programming languages for which such descriptions would be software. But SystemC is an up-and-coming hardware description language very similar to the programming language C, and Ada is a programming language very similar to VHDL, while C can be used as a hardware description language in that there are tools for converting C directly into digital circuit specifications. Assuming so, one more claim can be automatically derived:
5.' A method as recited in claim 2, where the description of an
implementation is System C, C or ADA.
To allow the patenting of any of these is to have to allow the patenting
of all of them.
However, claims 3, 4, 5 and 6 form an equivalence class, the members being the phrases that start after the phrase "... where the description of an implementation ...", an equivalence class of things that have equal economic value, have equal production requirements, etc. Not surprising
that the inventors choose to claim them equally. Now claim 6 is mostly "hardware-ish", claims 3, 4, and 5 are mostly "software-ish". Yet the inventors are putting them together in an equivalence class, a combination that seems quite reasonable.
The next claim to consider is where all of the boundaries get blurred:
9. A method as recited in claim 6, wherein the physical implementation
is object code for a general-purpose processor.
The inventors are creating another equivalence class here, comprising the a) physical implementation of an FPGA, b) the physical implementation of an ASIC, and c) the object code for a general-purpose processor. But this equivalence class has both hardware-hardware (FPGAs and ASICs) and some sort of software - the object code.
However "object code" in this context pretty much implies the existence of a processor, and ignoring (as we can in most implementations) the specific structure of the processor (its speed, word widths in bits, cache memory, etc.), we simplify claim 9 to:
9'. A method as recited in claim 6, wherein the physical implementation
is object code.
This might appear objectionable language, "object code isn't physical", but not to modern Landauer-ish physicists, to whom information is physical, and certainly object code is information.
Now object code is compiled source code, and given that "source code" implies something to be compiled, and not wanting to see a long and boring list of source code compilers (".. object code derived from a C compiler running on a Pentium .. object code derived from a Fortran compiler running on a Forth chip, etc.), we can simplify claim 9' to:
9'. A method as recited in claim 6, wherein the physical implementation
is source code.
I.e., software. Software/source code - both information - both physical, making the transition to claim 9' quite reasonable in the chain of all of these transformations.
Software descriptions that are not novel, obvious to a toadstool, and/or not enabled? Fine, deny the patent - I will be the first to support not granting patents for such specifications (and I wish it was done a lot more often). But don't deny the patent on a software description by pretending you can draw the line in the above claims (at least while sober).
