Re: Eolas - agree on the prior art .....

Hi Micah,

I've been complacent with following the laws in recent years.   I knew they
were being relaxed and I seem to recall a SPI and/or an effort to built a
diverse database of prior art was something due to the Compton patent that
was eventually reversed.   But I haven't been following up until now with
the changes. This whole episode has been a wake up call.  Mr. Doyle is
stepped into my livihood.  I have real client/server products that date back
to the 80s.  I don't depends on a "patent portfolio,"  although that will
probably change in the future.  I'm an idea man so I should be able to come
up with some silly nuisance software patents in a heart beat!

Here is an another example on how the inexperience of the patent examiners
have allowed an Anti-Spam patent to be issued based on an erroneous claim.

In the email business, the SMTP server "state machine"  has 5 basic steps
(commands). The sender software sends these commands:

        HELO (or EHLO)
        MAIL FROM:  <address of sender, not necessity the author>
        RCPT TO:  <recipient address>
        DATA
             actual email data/body
        QUIT

at each step, the server sends a response that contains a success or failure
response code based on standard Internet RFC specifications.  This is
example of the possible response codes:

   EHLO or HELO
      S: 250
      E: 504, 550
   MAIL
      S: 250
      E: 552, 451, 452, 550, 553, 503
   RCPT
      S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
      E: 550, 551, 552, 553, 450, 451, 452, 503, 550
   DATA
      I: 354 -> data -> S: 250
                        E: 552, 554, 451, 452
      E: 451, 554, 503
   QUIT
      S: 221

For the RCPT TO: as shown above, the internet RFC standard specifics the
following:

   RCPT
      S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
      E: 550, 551, 552, 553, 450, 451, 452, 503, 550

Now, if the mail server is going to accept the message, it sends a 250
response code.

But what if you wanted to address spammers?

The Error responses possible are 4xx and 5xx numbers.   According to the RFC
specifications, a 4xx is a "Temporary Error" which means it is ok for the
sender to try again.  The 5xx is a permanent error which means that the
sender should not try again to send the mail because it will not be
accepted.  This is straight from the RFC "Anti-Spam"  specifications:

1.6. SMTP Return Codes

   SMTP has several classes of Return Codes, see [1] for a discussion:

   o   5xx
       is a Permanent Negative Completion reply (Fatal Error) and
       results in the mail transfer being terminated and the mail
       returned to sender.

   o   4xx
       is a Transient Negative Completion reply (Temporary Error) and
       results in the mail transfer being put back on queue again and a
       new attempt being made later.

and it even has an example:

       C  RCPT To: <usr@domain.example>
       S  250 <usr@domain.example>... Recipient ok
       C  RCPT To: <foo@domain.example>
       S  451 <foo@domain.example>... Denied due to spam list
       C  RCPT To: <bar@domain.example>
       S  550 <bar@domain.example>... Denied due to spam list

The 451 error means the sender can try again. But the 550 means it should
try again for that recipient.

Well,  another "Mr. Doyle Like" person who does not even have product on the
market but rather is trying to exploit the flaws of the patent system,  has
a claim in his anti-spam patent that  he is the only one using the 550
response code because it enforces the idea to the spammer not to send mail
again, a central aspect of his patent.   I mean his web site make a BIG
highlighted point of saying:

                "WE ARE THE ONLY SYSTEM THAT DOES THIS!"

well, he's wrong.  The RFC specification clearly indicates sending a 5xx
response with the 100% technical intentions to signify to the remote client
sender software not to try again.

Now, you tell me, how as this get pass the patent examiners?   (rhetorical
question)

I only found it because of the recent email virus mess hitting the world and
me joining new efforts to combat it by changing or developing new RFC
specifications for electronic mail.   I found this guy's this "anti-spam
patent" and I was flabbergasted by this claims!   I immediately mailed him
informing him of not only prior art but also the erroneous claim about being
the only system using the 550 response code. The guy is all bothered now.
You just how to wonder how this happen in the first place.

But even then, this is like saying you have a nine-digit keypad for home
security and 1/2 of the possible numbers are patented so you can't use those
numbers!  If the patent examiners just read the RFC specs to verify his
claim, they would of voided his patent.  If a patent mentions SMTP, then it
is prudent the that examination of the patent is assigned to a person
familar with the subject.

Anyway, you got my point, I think.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office



----- Original Message ----- 
From: "Stolowitz, Micah" <MDSTOLOWITZ@stoel.com>
To: "Hector Santos" <winserver.support@winserver.com>
Sent: Tuesday, September 02, 2003 11:51 AM
Subject: RE: Eolas - agree on the prior art .....


You make a good point. And I can't imagine an experienced engineer going to
work for the PTO (yuk). Wasn't all this the purpose of the SPI? (Software
Patent Institute, I think).

-----Original Message-----
From: Hector Santos [mailto:winserver.support@winserver.com]
Sent: Tuesday, September 02, 2003 8:41 AM
To: Stolowitz, Micah
Subject: Re: Eolas - agree on the prior art .....


You would think so?   But I just proved their due diligence is lacking with
patent 6,327,617.

Obviously they didn't do a good job.  The odds are high the lawyers (and
more likely the gofers) are relatively young and do not have the diverse
engineering experience to know what to even look for.  That's been the basic
problem with the USPTO.  I'm not pulling this out of thin-air.  They
admitted long ago they need to recruit experienced engineers - they are just
not going to them.  Ask them if they even heard or seen a BBS, and the odds
are good they don't have a clue.  I don't know you, of course I could
completely off base but odds are good you don't know much about them either.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office



----- Original Message ----- 
From: "Stolowitz, Micah" <MDSTOLOWITZ@stoel.com>
To: "Richard M. Smith" <rms@computerbytesman.com>;
<public-web-plugins@w3.org>
Sent: Tuesday, September 02, 2003 11:24 AM
Subject: RE: Eolas - agree on the prior art .....



One might observe that Microsoft's legal team (and technical helpers) spent
the past three or four years, with a virtually unlimited budget, searching
for pertinent prior art.
-Micah

-----Original Message-----
From: Richard M. Smith [mailto:rms@computerbytesman.com]
Sent: Tuesday, September 02, 2003 8:18 AM
To: public-web-plugins@w3.org
Subject: RE: Eolas - agree on the prior art .....



This list looks like a good starting point, but the patent prior art
game is played a bit different than Mr. Hallam-Baker indicates.  One
must compare the operation of a product against each claim of a patent.
There has to be a close match for the claims of a patent.  If a product
operates differently than the claims section, then the product isn't
prior art.  Any search for prior art must begin with a good
understanding of the claims section of a patent to know what to look
for.

Richard

-----Original Message-----
From: public-web-plugins-request@w3.org
[mailto:public-web-plugins-request@w3.org] On Behalf Of Hemant Desai
Sent: Tuesday, September 02, 2003 11:04 AM
To: public-web-plugins@w3.org
Subject: Eolas - agree on the prior art .....



Mail from Phillip M. Hallam-Baker (hallam@w3.org)
which has the following date :

Date: 1995/08/22

There is a long list of prior art on the inclucsion of executable
content
within the Web. This includes:

tkwww    (Published prior to October 1992)
Viola    (Demonstrated July 1993)
HTTP/1.0 Spec   (Published 1992)
emacs-www   (1992? 1993?)
Mosaic/ application/x-csh (1992, 1993)
www/ application/postscript (1991)
www-talk   (1992 threads on executable content)

The Web is simply another hypertext application though. The inclusion of
a
feature from another hypertext system is therefore obvious. Thus the
following
are also of relevance :-

DEC LinkWorks    (communication PHB->TBL, 1992)
Xanadu    (Ted Nelson, 1970 ->)
NeWs    (Gosling et al. 1982?)


In addition the use of the term "weblet" to indicate a modular approach
to browser building is in current usage.


This type of nonsense is not the way we do buisness on the Web. The
community
has grown without Mr Doyle's assistance and will continue to do so. The
technology he claims ownership of was clearly understood to be part of
the
original concept of the Web and there is ample evidence to support this
claim.

Irrespective of the intended licensing arrangements there is simply
nothing
that adds value in the Eolas claim. I see nothing that I regard as novel
or
original. It is interesting to note that the work was performed using
Mosaic.
Many of the projects I refer to were published before the publication of
Mosaic.

Perhaps the net could compile a more complete list. Please do it in news
and do not mail me!


It seems odd that US patent law should permit the granting of a patent
merely
to use a well known technique within a famework explicitly designed to
support
extensibillity.

Received on Tuesday, 2 September 2003 15:36:01 UTC