|
|
|
| Authored by: mbouckaert on Monday, October 15 2012 @ 04:26 PM EDT |
Software is math. Because it IS, rather than because of what
it does. Software programs, as text, do nothing.
For anything to be patentable, there MUST be interaction
with the physical world. Then come the tests of obviousness
etc.
Now an *execution* of a software program is a different
animal from the software itself. At the very least, the
execution interacts with two types of physical commodities:
Time and some physical representation of where the symbols
being acted on are kept.
Telling ad nauseam that software is math is insufficient.
One must also show that, in most cases (see below), the
execution of software does not, in itself, raise to the
level of patentability.
A few examples.
* Java code, compilers, language and interfaces are not
patentable. That part of Java that is software is math; the
documentation is text. Both are copyrightable. Executing
"Java" (e.g. running javac) does not, in itself, interact in
any patentable or nonobvious manner with "time" and
"memory". From that angle (economy of the physical
resources needed for the symbol manipulation to complete),
there are tons of prior art. Yes, even for JIT.
* The well-discussed rubber-curing system, which includes a
process control computer and its software algorithm, is as a
whole patentable, thanks to the software. That software had
to be economical in time resources to provide results in
time to alter the curing process. An army of human
computers wouldn't do. Now, the scope is limited, and the
execution of software may be using sortcuts or other
heuristics in the math ( = software = text ) that drives it,
and may be a borderline case for such heuristics to be
called in the patent as a limiting factor (i.e., using
different heuristics as a way not to infringe.)
* There are cases where the "economy of (physical)
resources" may be enough to raise to patentability matter,
for the execution of software-described algorithms (math) on
specific hardware (with known clock speed and memory
resources). Public-key crypto is an example. While it is
*possible* for an algorithm to break any public/private key
relationship, the physical time constraints (with current
and foreseeable hardware) makes it impractical. The math
says one thing (you can do it, here is how), the physical
world another (what good does it make to break that cypher
two thousand years from now?)
I think this should be injected in your document somehow.
Software execution comes from the marriage of math and
physical reality. It has the genes from both parents, math
and real-world.
By the way, what is heuristics except more math ?
---
bck[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Monday, October 15 2012 @ 04:39 PM EDT |
I have a technical degree, too -- a B.S. from what I understand to be a
fairly prestigious institution. If I mentioned it, you might recognize it. It
was
obtained at a time when you actually had to take a serious concentration in
mathematics. Indeed, the degree is a combined EE/CS degree, with a
concentration in analog hardware. Part of the degree includes learning a lot
about software. I've actually used the software part of the degree to earn a
living in the past writing both some pretty hairy real-world simulations and
parts of several large real-time software control systems.
To preserve my
anonymity, I will not go any further but to say that I also
have an MS degree
in a similar subject area but in a particular field of the
subject area that
required a heavy concentration in mathematics -- both
discrete and
continuous.
Did your CS degree require more than three or four years worth
of
mathematics starting with calculus, differential equations, complex
functions,
modulation, coding, detection and synchronization theory, etc.,
etc.?
What I have that you don't have is extensive experience in both
technical
and legal matters. I understand how patents work. I
understand the
difference between an embodiment of an invention and an abstract
idea. I
also understand the difference between something that is unpatentable
subject matter and what is obvious. And I understand that to confuse
obviousness and unpatentable subject matter makes patent law a complete
mess.
It is also a sign of fuzzy thinking (as opposed to fuzzy logic). Or, as
Professor Kingsfield once said in The Paper Chase,
You
come in here with a skull full of mush and you leave
thinking like a
lawyer.
It took me a long time after graduating law school to
rid myself of that
mush. But I did it, and now I can see fallacies and logical
traps on both sides
of this issue. And the idea that you can somehow cure
"software patents,"
whatever they are, by eliminating them by defining
them as a new
class of "unpatentable subject matter" is indeed one of those
fallacies. If they
are obvious, they are obvious, and patent law can handle
that. If they are not
an embodiment of an invention, they are
unpatentable under a
different section of patent law, and the law can handle
that, too.
If you define a new class of "unpatentable subject matter," you
are just
going to be litigating what that means for decades to come. And even
after
you decide what that means, you'll still be litigating particular cases
about
whether a given invention falls into that category for perhaps a hundred
or
more years to come. And what you will wind up with is a conflicting
patchwork of laws decreed by politicized court appointees or written by
legislators bought and sold by lobbyists. If you don't like uncertainty now,
just wait and see what you will get then. (Just for yucks, why don't you check
out some of the
current
Republican members of the House Committee on Science, Space, and
Technology?)
Also, go read Jennifer Kahaulelio Gregory, The
Troll
Next Door, 6 J.MARSHALL REV. INTELL. PROP.
L. 292 (2007), especially
section (III)(B), Fear of Too Many Patents
and Rampant Enforcement, at
page 307. You just might learn
something.
[ Reply to This | Parent | # ]
|
|
|
|
|
