Subject: RE: IC's patent-pending technology
From: "Lawrence Rosen" <lrosen@rosenlaw.com>
Date: Mon, 25 Sep 2006 16:25:20 -0700
Mon, 25 Sep 2006 16:25:20 -0700
And so, under the circumstances, please address the issue:

 

FSB might instead help us understand how such patent claims (assuming they
are valid) might affect free software businesses. 

 

Grousing about the process or the term of the patent doesn't answer that
question. Would you just have us wish patents away, or have us give ours
away as an example of charity?

 

/Larry

 

  _____  

From: Thomas Lord [mailto:lord@emf.net] 
Sent: Monday, September 25, 2006 4:16 PM
To: lrosen@rosenlaw.com
Cc: 'Free Software for Business'; 'Rob Cameron'; mbeinschlag@rosenlaw.com
Subject: Re: IC's patent-pending technology

 

Lawrence Rosen wrote: 

 

Here are a few slides that introduce the technology:

www.rosenlaw.com/IC-Technology-Overview.pdf


This is not the forum to decide obviousness or originality but I would like
to comment that, personally, I find this non-obvious enough to deserve a
reward yet obvious enough to not deserve a 20 year reward.   You correctly
identify the "key concept" in these slides -- from which all else follows
quite mechanically.   Turning up that key concept in a search for ways to
speed up UTF-8 processing is, frankly, also a fairly mechanical result.

(Have you ever heard of a "superoptimizer"?   I think the idea was promoted
by Tjorborn Grandlund.   Given a problem specification and some constraints
on search space, a superoptimizer discovers optimal small-instruction-count
algorithms via a brute-force search.   Refinements of superoptimization
would trim the brute-force search to consider only semantically plausible
sequences.   Within less than 20 years, generating most of the algorithms
that Cameron has come up with -- given the "key concept" -- is a problem for
machines to solve.   The "key concept" itself is something that a competent
technician would come up with as input to a superoptimizer.)

Nevertheless, it is clever, original, and a non-trivial amount of work.
5-6 figures for a public license feels about right to me (in the sense of
paying off 2x or more of what it took to come up with, at market rates for
labor.)   Toss in a really good, reusable reference implementation and I
think you're clearly into six figures and possibly even in the upper half of
that range.    Sell private licenses while waiting for a transaction to
create a public license to be organized and I would expect an invention like
this to have a chance of netting in the low seven figures.

But, try to lock this up for 20 years?   No, not enough there.   Bad trade.
Fight it tooth and nail -- it's "XOR" all over again.






 

Please don't confuse this with a business method patent. And we're not
patenting XML! We're patenting very fast and very efficient methods for
processing XML and other character streams. Existing software continues to
work without any risk from our patents. It is only new or modified software
that can benefit.


King Moore also makes a 20 year lock-up somewhat absurd, from the business
plan perspective.







 

You know by now that International Characters has submitted its patent
applications for review through the Community Patent Review project. That's
the place where we will deal with questions of validity of our patent
claims. We will actively solicit evidence of prior art there because we only
want our valid patent claims to issue.


And I respect that and don't think we can or should try to decide a review
here.   I only mean to point out that this particular invention is a bit
shaky from the conventional review standpoint but that a more modest patent
claim could easily be seen as quite just.







 

FSB might instead help us understand how such patent claims (assuming they
are valid) might affect free software businesses. 


So long as there are commercial restrictions on the use of the invention, no
purely free software or open source business can practice the patent in a
way that involves distributing code.   Period.  (At least as relates to FSF
and OSI definitions.)

That is a strength and a weakness of the open source and free software
movements.    It is a strength because code which satisfies OSI and FSF
definitions is clearly a non-rival commodity, pure and simple, and that is a
fantastic enabler.   It's a weakness because the obligation of community
participants to immediately place all of their work under such terms does,
indeed, destroy incentive (and, indeed, actively invite the unjust
exploitation of labor).

I don't think you can finesse it.   I think you are better off if you (join
me in) challenging mandatory OSI/FSF licensing as normative for the
community.   *Inevitable* (not *immediate*) OSI/FSF licensing is a better
norm *if* it can be combined with the creation of incentives to create.
Hence, my "limited patents" proposal.





 

The one thing that worries me a lot is the resistance that some have to even
learning about good technology for fear that a future patent might hurt
them. Ignorance hurts worse. It leads to some of the silly discussions on
here about how dangerous patents are, and it can lead to a refusal to
implement good technology even when it is available for free. This reminds
me of the fear that some used to have about free and open source software. A
clear paper at the Community Patent Review site should allay your fears that
it might be dangerous for you to learn about the technology in our patent
applications. (See
http://cairns.typepad.com/peertopatent/2006/09/willful_infring.html.) 

 



Yes, it's clear.   It's clearly bogus.

I happen to have rather extensive experience hacking Unicode.   I was one of
the very first implementors of a highly optimized Unicode regular expression
engine.   I've spent months on tasks like optimizing in-core representations
of various Unicode tables and extracting sane semantics for string libraries
from Unicode specifications.  

I'm 100% confident that, had the practical need confronted me, I'd have
reinvented much of Cameron's work with, at most, a few months of effort.
The "key concept" is on the short-list of things to check out and, given
that, the rest simply falls out.

The mere recollection of the "key concept" -- which isn't a very surprising
concept in the slightest -- would be enough to streamline my work
considerably.  And so now, assuming your patent is granted, I'm screwed.   I
didn't learn anything I couldn't have figured out in a short amount of time
but, should I use this knowledge, you've got a willful infringement claim
against me.   I can't even practice this idea in GPL'ed code without risk!

-t







Larry Rosen

 



And so, under the circumstances, please address the issue:

 

FSB might instead help us understand how such patent claims (assuming they are valid) might affect free software businesses.

 

Grousing about the process or the term of the patent doesn't answer that question. Would you just have us wish patents away, or have us give ours away as an example of charity?

 

/Larry

 


From: Thomas Lord [mailto:lord@emf.net]
Sent: Monday, September 25, 2006 4:16 PM
To: lrosen@rosenlaw.com
Cc: 'Free Software for Business'; 'Rob Cameron'; mbeinschlag@rosenlaw.com
Subject: Re: IC's patent-pending technology

 

Lawrence Rosen wrote:

 

Here are a few slides that introduce the technology:

www.rosenlaw.com/IC-Technology-Overview.pdf


This is not the forum to decide obviousness or originality but I would like to comment that, personally, I find this non-obvious enough to deserve a reward yet obvious enough to not deserve a 20 year reward.   You correctly identify the "key concept" in these slides -- from which all else follows quite mechanically.   Turning up that key concept in a search for ways to speed up UTF-8 processing is, frankly, also a fairly mechanical result.

(Have you ever heard of a "superoptimizer"?   I think the idea was promoted by Tjorborn Grandlund.   Given a problem specification and some constraints on search space, a superoptimizer discovers optimal small-instruction-count algorithms via a brute-force search.   Refinements of superoptimization would trim the brute-force search to consider only semantically plausible sequences.   Within less than 20 years, generating most of the algorithms that Cameron has come up with -- given the "key concept" -- is a problem for machines to solve.   The "key concept" itself is something that a competent technician would come up with as input to a superoptimizer.)

Nevertheless, it is clever, original, and a non-trivial amount of work.   5-6 figures for a public license feels about right to me (in the sense of paying off 2x or more of what it took to come up with, at market rates for labor.)   Toss in a really good, reusable reference implementation and I think you're clearly into six figures and possibly even in the upper half of that range.    Sell private licenses while waiting for a transaction to create a public license to be organized and I would expect an invention like this to have a chance of netting in the low seven figures.

But, try to lock this up for 20 years?   No, not enough there.   Bad trade.   Fight it tooth and nail -- it's "XOR" all over again.




 

Please don't confuse this with a business method patent. And we're not patenting XML! We're patenting very fast and very efficient methods for processing XML and other character streams. Existing software continues to work without any risk from our patents. It is only new or modified software that can benefit.


King Moore also makes a 20 year lock-up somewhat absurd, from the business plan perspective.





 

You know by now that International Characters has submitted its patent applications for review through the Community Patent Review project. That's the place where we will deal with questions of validity of our patent claims. We will actively solicit evidence of prior art there because we only want our valid patent claims to issue.


And I respect that and don't think we can or should try to decide a review here.   I only mean to point out that this particular invention is a bit shaky from the conventional review standpoint but that a more modest patent claim could easily be seen as quite just.





 

FSB might instead help us understand how such patent claims (assuming they are valid) might affect free software businesses.


So long as there are commercial restrictions on the use of the invention, no purely free software or open source business can practice the patent in a way that involves distributing code.   Period.  (At least as relates to FSF and OSI definitions.)

That is a strength and a weakness of the open source and free software movements.    It is a strength because code which satisfies OSI and FSF definitions is clearly a non-rival commodity, pure and simple, and that is a fantastic enabler.   It's a weakness because the obligation of community participants to immediately place all of their work under such terms does, indeed, destroy incentive (and, indeed, actively invite the unjust exploitation of labor).

I don't think you can finesse it.   I think you are better off if you (join me in) challenging mandatory OSI/FSF licensing as normative for the community.   *Inevitable* (not *immediate*) OSI/FSF licensing is a better norm *if* it can be combined with the creation of incentives to create.    Hence, my "limited patents" proposal.



 

The one thing that worries me a lot is the resistance that some have to even learning about good technology for fear that a future patent might hurt them. Ignorance hurts worse. It leads to some of the silly discussions on here about how dangerous patents are, and it can lead to a refusal to implement good technology even when it is available for free. This reminds me of the fear that some used to have about free and open source software. A clear paper at the Community Patent Review site should allay your fears that it might be dangerous for you to learn about the technology in our patent applications. (See http://cairns.typepad.com/peertopatent/2006/09/willful infring.html.)

 



Yes, it's clear.   It's clearly bogus.

I happen to have rather extensive experience hacking Unicode.   I was one of the very first implementors of a highly optimized Unicode regular expression engine.   I've spent months on tasks like optimizing in-core representations of various Unicode tables and extracting sane semantics for string libraries from Unicode specifications. 

I'm 100% confident that, had the practical need confronted me, I'd have reinvented much of Cameron's work with, at most, a few months of effort.   The "key concept" is on the short-list of things to check out and, given that, the rest simply falls out.

The mere recollection of the "key concept" -- which isn't a very surprising concept in the slightest -- would be enough to streamline my work considerably.  And so now, assuming your patent is granted, I'm screwed.   I didn't learn anything I couldn't have figured out in a short amount of time but, should I use this knowledge, you've got a willful infringement claim against me.   I can't even practice this idea in GPL'ed code without risk!

-t





Larry Rosen