ietf-mxcomp
[Top] [All Lists]

IPR: analysis of Microsoft patent applications

2004-09-17 16:51:38

I have read the two Microsoft patent applications published yesterday
and analyzed the claims.  I'm not a patent lawyer or patent agent, but
I have read enough patents over the years that I think I can do an
adequate job of figuring out what their claims cover.

Visit http://appft1.uspto.gov/netahtml/PTO/search-bool.html and search
for 60/454517, the serial number of the provisional application from
which they both derive, or you can download PDF versions from my web
site at http://www.taugh.com/20040181571.pdf and
http://www.taugh.com/20040181585.pdf

Patents consist of a narrative description of the invention, followed
by claims.  A claim can be independent, standing on its own, or
dependent, based on a previous claim.  Dependent claims are generally
minor tweaks to independent claims, so I'll look at each independent
claim and all of its dependent claims as a group.

* Application 20040181571

This application is the less troublesome of the two.  About 2/3 of it
deals with methods of detecting IP spoofing, which aren't relevant
here (or, if you ask me, anywhere else since TCP stacks started
randomizing sequence numbers.)  The rest describes what is essentially
Caller ID.

Claims 1-8 and 10-21 cover anti-IP-spoofing techniques.  (There's
no claim 9.  Oops.)

Claims 22-38 cover Caller ID.  Claim 22 says:

22. In a receiving domain that is network connectable to one or more
    sending domains, the receiving domain including one or more
    receiving messaging servers configured to receive electronic
    messages from sending domains, a method for determining if a
    sending messaging server is authorized to send electronic messages
    for a sending domain, the method comprising: 

    an act of receiving an electronic message purportedly sent from
    the sending domain;

    an act of examining a plurality of parameter values of the
    electronic message to attempt to identify an actual sending side
    network address corresponding to a sending computer system;
    
    an act of querying a name server for a list of network addresses
    authorized to send electronic messages for the sending domain;

    an act of determining if the actual sending side network address
    is authorized to send electronic messages for the sending domain;

    and an act of providing results of the determination to an message
    classification module such that the message classification module
    can make a more reliable decision as to classifying the received
    electronic message.

Note the word "plurality" in clause 3, which is patent-speak for "more
than one".  I believe that SPF classic, which only checks a single
message parameter, the bounce address, isn't covered here.  SPF may
also check the HELO domain, but that's not a parameter of the message,
it's a parameter of the connection.  Yes, this is hair-splitting.
Welcome to the wonderful world of patents.

Claims 39-41 and 42-45 cover anti-IP-spoofing.

Claims 46-49 cover Caller ID again, phrased in a different way.  They
also refer to a "plurality of parameter values of the electronic
message".

* Application 20040181585

The claims in this application are breathtakingly broad.  Along with a
lot of computational puzzles, which we don't care about, they cover a
wide class of sender verifications and, as an afterthought, scoring
spam filters.

Claims 1-18 cover sender verification.  Claim 1 is extremely broad:

1. In a receiving domain that is network connectable to one or more
   sending domains, the receiving domain including one or more
   receiving messaging servers configured to receive electronic
   messages from sending domains, a method for determining a sending
   domain's electronic message transmission policies, the method
   comprising:

   an act of receiving an electronic message from the sending domain;

   an act of receiving one or more electronic message transmission
   policies corresponding to the sending domain;

   an act of parsing relevant electronic message transmission policies
   from the one or more received electronic message transmission
   policies;

   and an act of providing the relevant electronic message
   transmission policies to a message classification module such that
   the message classification module can make a more reliable decision
   when classifying the received electronic message.

To me, that covers SPF, Caller ID, Sender ID, and any plausible
variation on them that calls back to the message domain for advice on
handling the message.  By some readings it might also cover CSV, but
from the narrative text it's clear that they're talking about message
domains, not host domains.  Paul Vixie's original domain verification
proposal was published in May 2002 and he said it wasn't new at that
time, so I have my doubts about the novelty of this claim.

Claims 19-20 roughly restate claim 1.

Claims 21-35 and 36-44 cover puzzles.

Claim 45 is similar to claim 1.

Claims 46 and 47 are about puzzles.

Claims 48-49 come out of left field and cover scoring spam filters:

48. A computer program product for use in a receiving domain that is
    network connectable to one or more sending domains, the receiving
    domain including one or more receiving messaging servers
    configured to receive electronic messages from the sending
    domains, the computer program product for implementing a method
    for generating inputs to be provided to a message classification
    module, the computer program product comprising one or more
    computer-readable media having stored thereon computer executable
    instructions that, when executed by a processor, cause the
    receiving domain to perform the following:

    receive an electronic message;

    utilize one or more of a plurality of different mechanisms for
    attempting to determine if the received electronic message is an
    unwanted or an unsolicited electronic message; 

    and provide results of each of the one or more different
    mechanisms to a message classification module such that the
    message classification module can make a more reliable decision
    when classifying the received electronic message.

Since Spamassassin 1.0 was published in Sept 2001 and did exactly
this, classify messages based on several criteria, I find it hard to
understand how they'd claim this as new in a 2003 patent application.
Surely they are familiar with Spamassassin.

* Summary

Keep in mind that these are just applications, and we don't know
whether the USPTO will issue a patent and if so which if any of the
claims would be allowed.  I assume that their other applications are
similar, and we don't know what if anything will issue in other
countries.

The issue that concerns me most is that the claims in these
applications, particularly in '585, are much broader than what
Microsoft's IPR disclosed.  Note that since the IPR documents are
written by lawyers, not techs, I'm not faulting any of the MS
employees who have been participating in MARID and don't get to set
their employer's policies.

If '585 issues as a patent in anything like its current form and
Microsoft's license doesn't change, it would make SPF or any other
similiar system legally very risky since the MS license only lets you
implement Sender-ID, not other things that are like Sender-ID.
Regardless of what the MS IPR said, their patent rights depend on
what's in the patent, and if you look at cases where patents were
broader than the IPR disclosure in the standards process, the results
can be really ugly.  Google for RAMBUS JEDEC for a notorious example.

At this point, I see a variety of unappetizing alternatives.  One is
to wait and see what patents issue, but that could take years.
Another is to standardize only what MS is willing to license.  Or we
could decide that the '585 claims are implausible and ignore them, at
our peril.

My personal inclination is to say that none of the domain/IP
verification schemes are good enough to be worth this much heartburn,
put them all back on the shelf, do CSV and BATV, and turn our
attention to MASS.

Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet 
for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.