I thought people might get a kick out of this. I have been looking
for a Java development environment that would give me both native
code compilation and fix-and-continue, just like CommonLisp systems.
Well, I found one: SuperCede. When I saw on their web site that
they claim the technology was patented, I got curious and looked up
their patent on the IBM patent server:
http://www.patents.ibm.com/details?pn=US05764989__&language=en
It looks like they believe they invented fix-and-continue
debugging for native code compilation (the sample embodiment
they describe seems a bit cumbersome, but if they reinvent
a few more years, I'm sure that will get better :-).
Other techniques they seem to have rediscovered are tree shaking, code
patching, and backwards stepping. There are no references to any of the
widely used prior art in their patent as far as I can tell. Even if they
overlooked Lisp, many aspects of this can also be found in SML implementations
(in particular, backwards stepping), Smalltalk, and Forth.
It's nice that some of those techniques finally make it systems
besides Lisp. But for the company to ignore decades
of computer science knowledge and history seems
pretty silly. At the very least, reading a bit more about some
of those "old" Lisp implementations might save them design effort,
as well as spending lots of money on a patent that cannot possibly
be valid (I hope).
Tom.
PS: Another amusing bit about the patent is that it claims to
be copyrighted.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Bradley Yearwood
Subject: Re: patent on fix and continue
Date:
Message-ID: <742hor$8ru@crl3.crl.com>
In article <············@nnrp1.dejanews.com>, <·······@my-dejanews.com> wrote:
>I thought people might get a kick out of this. I have been looking
>for a Java development environment that would give me both native
>code compilation and fix-and-continue, just like CommonLisp systems.
>
>Well, I found one: SuperCede. When I saw on their web site that
>they claim the technology was patented, I got curious and looked up
>their patent on the IBM patent server:
>
> http://www.patents.ibm.com/details?pn=US05764989__&language=en
>
>It looks like they believe they invented fix-and-continue
>debugging for native code compilation (the sample embodiment
>they describe seems a bit cumbersome, but if they reinvent
>a few more years, I'm sure that will get better :-).
>
>Other techniques they seem to have rediscovered are tree shaking, code
>patching, and backwards stepping. There are no references to any of the
>widely used prior art in their patent as far as I can tell. Even if they
>overlooked Lisp, many aspects of this can also be found in SML implementations
>(in particular, backwards stepping), Smalltalk, and Forth.
>
>It's nice that some of those techniques finally make it systems
>besides Lisp. But for the company to ignore decades
>of computer science knowledge and history seems
>pretty silly. ...
Parts of the patent might be valid, but fortunately, those parts
shouldn't chill any really useful work. Many of the claims do seem
to have been allowed in total ignorance of Lisp machine art of at least
15 years ago.
Grand independent claim 1 seems to be totally covered by LispM practice. So
do dependent claims 2, 4, and 5 (which seems to be some sort of arcane
restatement of 4).
This leaves only 3, which is 1 narrowed by "... utilizing a jump instruction
as the first instruction of the runtime code objects... ." I don't think
this is going to be a great obstacle to anyone unless they happen to be
desperate to save something on the order of one memory reference at runtime.
At least one of the dependent claims (#6) refers to "further step of
implementing the persistent symbol table as an object-oriented database."
This is amusing, as claims 3 and thence 1 upon which this depends, make
no mention of a persistent symbol table. Maybe they're allowed implicit
reference back to the specification on this, but "the persistent symbol
table" seems to me like it needs to refer to something previously stated
in the claims. Am I naive, or did the examiner doze on #6?
I started nodding off on #7 and its dependents, but a cursory reading
doesn't seem to bring up anything which would cause a Lispm to retroactively
infringe :-), especially if one is allowed to read "persistent symbol table
implemented in persistent memory" as "save a world". Besides, unless
I'm too dumb or lazy to understand what the following element of #7 means, I
think it's not hard to detonate #7 as claiming ambiguous gobbledygook as
an essential element:
coordinating the program image with the computer program.
The last of the great independent claims is #13. It is very specific
about what it wants to be happening: "first and second internal processes",
"incremental builder", "incremental imager introducing a branch instruction
at the beginning of each of said runtime code objects", "a runner ... said
runner finalizing said program image and executing said program image in said
second internal process", "a probe module". Next time I'm interested in
constructing a 3-legged 5-eared blue sheep, I might start to worry. Seeing
as 14-17 are refinements upon said sheep, no extra worry is generated.
I cannot be too irritated at the Supercede people for trying, and perhaps
even succeeding at building a really nice sludge (C++) pump and trying to
protect it, though I try to stay away from sludge.
I can be irritated at what appears to be a woeful ignorance by the PTO of
non-patent prior art in software. One might also question whether the
apparent similar ignorance of attorneys and agents is real and whether
applicants are themselves either similarly ignorant of prior art, or
fail to recognize their duty (37 CFR 1.56) to disclose it.
Then again, I've just been a programmer stoking the code furnaces for the past
25 or so years. What do I know?
Brad Yearwood ···@crl.com
Cotati, CA
Bradley Yearwood <···@crl3.crl.com> wrote:
+---------------
| I can be irritated at what appears to be a woeful ignorance by the PTO of
| non-patent prior art in software. One might also question whether the
| apparent similar ignorance of attorneys and agents is real and whether
| applicants are themselves either similarly ignorant of prior art, or
| fail to recognize their duty (37 CFR 1.56) to disclose it.
+---------------
Unfortunately, the notion of "prior art", while legally unchanged if it
gets to a lawsuit, in recent years seems to have degenerated in the patent
*application* phase to being interpreted as meaning only "prior patents".
So there's *LOTS* of totally-obvious garbage being patented these days,
some of which was old *decades* ago!!! But since patent-mania didn't rule
back then [people were more interested in *shipping* stuff than patenting
it], it wasn't patented, and doesn't show up in a cursory "prior art" search.
Of course, if it ever gets to court, the non-patent-holder *may* be able
to produce adequate evidence that the thing in question is really "prior
art", but that's only if the defendant has enough money to survive that
long...
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
My opinion is that patents on software algorithms make about as much
sense as patenting math. I wish software would be excluded from being
able to receive a patent.
--
David Steuber (ver 1.31.3a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.
May the source be with you...