Subject: Re: IC's patent-pending technology: Prior Art, Please
From: Thomas Lord <>
Date: Tue, 26 Sep 2006 00:35:34 -0700

Rob Cameron wrote:
> High performance XML processing has been a hot area of
> research in recent years.   UTF-8 to UTF-16 transcoding is
> frequently cited as a major bottleneck, often 30% or more
> of XML processing cost.   None of the work we have seen
> indicates any awareness of the performance improvements
> that can be achieved by our methods let alone awareness
> of our methods.    

Well, hang on there.   How much of the work you are looking at
is targeted specifically at HW platforms with the features you need
vs. how much is done in portable code?    I suspect you are making
a bit of an apples and oranges comparison.

It's one thing to implement <string.h> or GMP in portable C.

It's another thing to talk about the complex question of how
performance of said libraries impacts the economics of
system design including HW purchases.

It's a third thing, where you are, to add "#ifdef"s or other
configuration hacks and optimize for specific hardware.
That you only claim to average 20x improvement pretty
sharply limits the economic significance of your invention.
One needs *that* bottleneck and *that* hardware choice
to benefit.    That's a pretty narrow sweet spot.

It's a big leap from such circumstance, plus the lack of
specific prior art, to a claim of 20 years worth of profundity
of insight.

You anticipated something of value: granted.

You've done/are doing work to make that value easy to collect: granted.

You should get some reward: no argument.

A 20 year monopoly?  Get real.

> The problem of UTF-8 validation is only the first step, and
> not nearly the most difficult, in UTF-8 to UTF-16 transcoding
> using our methods.   Note that UTF-8 and UTF-16 code units
> are not in one-to-one correspondence. 

The Unicode standard provides a very carefully developed
vocabulary.   Please use it with care.

I *guess* that you mean UTF-8 can encode any Unicode codepoint
and that there is not a 1:1 correspondence between codepoints
and UTF-16 code values -- but that is a trivial observation not
something to "note".

I *guess* that you mean *conversion* from UTF-8 to UTF-16 --
which is *not* an example of "transcoding" -- is complicated by
the need to encode some code points using pairs of UTF-16
code values.

But regardless of what you mean, it's hard to make sense of what
you've written in the "Note that...".   Yes, it's trivial that there are
more 16 bit numbers than 8 bit numbers -- why would you ask us
to note that fact?   I'm sure I can't tell what your point is.

> Our high-performance transcoding software requires

"Encoding form conversion software"

> a few hundred instructions on today's processors.   This is
> well beyond the capabilities of any supercompilation technology.

any *brute force* supercompilation technology, naively applied, sure.  So?
Your comment here is not responsive to previous comments on 

Remember, I'm kinda sorta on your side.    I'm guessing people would indeed
pay a few bucks to use this invention.   I'm asserting its clever and 
hard work
and its fitting the intent of the patent system to secure some reward 
for you.
I don't think current patent law makes that possible other than through bugs
in the system which I'm sure you don't mean to latch on to.