|
|
|
| Authored by: Anonymous on Wednesday, January 09 2013 @ 08:40 AM EST |
The discussion is about an example of software that is physical... which is a
question set in the discussion of how we should interpret patent
law.
To restate the idea: The software HDL definition of a CPU creates
a physical thing in the same way that a software procedural program creates an
executable program.
The comment I am responding to is mostly a
distraction from this discussion of what Software is. It refers to patent law in
circular ways, and asserts what patent policy should be. I will respond once,
out of politeness, but circular arguments and assertions of what should be do
not in general respond to reasoned debate.
How is software
patentable? MPEP 2106, I. THE FOUR CATEGORIES OF STATUTORY SUBJECT MATTER ,
Non-limiting examples of claims that are not directed to one of the statutory
categories: " vi. a computer program per se, Gottschalk v. Benson, 409 U.S. at
72;".
ii. Machine – a concrete thing, consisting of parts, or
of certain devices and combination of devices. Burr v. Duryee, 68 U.S. (1 Wall.)
531, 570, 17 L. Ed. 650 (1863). This includes every mechanical device or
combination of mechanical powers and devices to perform some function and
produce a certain effect or result. Corning v. Burden, 56 U.S. 252, 267, 14 L.
Ed. 683 (1854).
Software is patentable because, IIRC, the
Supremes have ruled that software running on a computer can create
a machine for the purposes of section ii above.
It a bit strange to refer to it
in this discussion without acknowledging that your interpretation of it does not
agree with the authoritative one.
An idea can be patented
only when novel and useful ( MPEP 2107, II. EXAMINATION GUIDELINES FOR THE
UTILITY REQUIREMENT, “useful invention” (“utility”) requirement, "(2) Ensure
that the claims define statutory subject matter (i.e., a process, machine,
manufacture, composition of matter, or improvement thereof)". Software by itself
isn't useful. The CPU itself can be novel and useful, a machine worthy of patent
protection. The software can only be a component.
The CPU of my
example passes all of these tests, and the software HDL that serves as its
construction blueprint is the normal means of designing it. Stating that the HDL
representation is NOT the CPU and hence not patentable is true - but only in the
sense that the machine drawings for an invention are not patented, the patent
only applies to the thing that is constructed from the drawings.
This seems to
be a contrived objection, as the HDL very directly generates the physical thing;
be it an ASIC, an FPGA bitstream or a simulation engines datafile. Some of
these things are so concrete that you can pack them in boxes and ship them
around the world...
Making the software eligible by itself would
have various deleterious effects. An analyzed, elaborated and simulated VHDL
model is not a concrete thing. Running it as a virtual machine (a simulation) is
not a concrete thing. Should we be vulnerable to patents in Second Life?
This is a policy question that is completely disjoint from the
interpretation question we started with.
In many ways I agree with you, but
you can not formulate policy without first understanding the real world that it
is meant to control.
Asserting that Software is abstract and hence not the
means of defining the sorts of inventions that patents should protect is naive
when Software is the means of defining all high-density integrated circuits,
almost all PCBs, buildings, planes and etcetera.
Protecting
software in and of itself is the domain either of copyright or trade
secret. {my emphasis}
Patents are a device constructed to
reduce the need for trade-secrets; as trade secrets do not efficiently
contribute to the benefit of society as a whole.
The need for trade-secrets
to protect HDL software is a strong argument that patent law is incorrectly
formulated for this industry; it is not an argument that patent law should never
apply to this industry.
Copyright protects copying the entire work, and
to a certain extent the making of derivatives of the work.
Patents protect an
invention that enables a novel class of works to be constructed.
There is
no reason that both forms of protection could not be applied to the same work by
the inventor - in the same way that a Lawyer might claim three defences.. "I was
not there; I did not do it; You did not see me."
This is called
semiosis, in semiotics merging the sign with the thing it signifies, a form of
word magic equating the abstract (the sign, your software) with something
concrete (the CPU). I'm a CPU designer, a chip guy, a VHDL guru and write CAD
tools as a hobby.
Thanks for the background, it adds greatly to my
understanding of your argument.
To successfully produce silicon we
require semiosis, that our specification, behavioral and structural models and
implementation prove equivalent. I don't have a working chip without doing so,
failing formal proof covering device physics.
If I understand
correctly, semiosis means that the HDL definition can be materialised in
the chosen process and function as the definition requires.
I understand (from
reading the trade press) that this is a difficult engineering problem,
especially in leading edge process nodes.
With FPGAs we can skip
some of the intermediate equivalency proofs because of low 'manufacturing'
risk.
Your model description describes behavior and isn't the behavior itself.
The huge variation of failure cost for building an FPGA instance
of the CPU and an ASIC instance leads to differing investments in simulation to
investigate the likely correctness of result before the physical device is
built.
Similarly, traditional software that is functionally similar but has
dramatically different failure costs tends to be tested differently. A software
engineering team that is building a flight simulator for windows will not apply
the same level of testing as a software team that is developing the software for
micro-controllers in a fighter jet.
In particular, mathematical models of
software correctness were applied to the avionics field a long time ago...
This
seems to be another way in which HDL design of digital circuits is analogous to
the development of procedural software to run on computers.
A reason
for not using UML to describe patents, being objected oriented and enabling
merging of sign and referent in a manner worthy of Plato's 'the name is the
thing'. Names are abstracts and not concrete.
I routinely deal
with interlocking abstractions in the process of writing software. UML is an
unambiguous way of communicating designs (abstractions). Abstractions are in
general good, as they allow you to think about the real world in powerful
ways.
As I said, abstractions are powerful things. Requiring all
patents to be expressed in concrete terms is an interesting, but I fear flawed,
way of handicapping patent lawyers.
However, the legalese they currently
use is really NOT suited for analysis by engineers and a way of expressing the
contents of patents that is more suitable for practitioners would appear to be a
good thing.
[ Reply to This | Parent | # ]
|
|
|
|
|
