Analysis of Microsoft Patent Applications Pertaining to Sender ID

IPR: Analysis of Microsoft Patent Applications

Date:      17 Sep 2004 23:51:42 -0000
From:      John Levine <johnl@iecc.com>
To:        ietf-mxcomp@imc.org
Subject:   IPR: analysis of Microsoft patent applications

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
    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

Regards,

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

Prepared by Robin Cover for The XML Cover Pages archive. Context: see "Apache Software Foundation Rejects Microsoft Patent License Agreement for Sender ID."

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	Analysis of Microsoft Patent Applications Pertaining to Sender ID IPR: Analysis of Microsoft Patent Applications Date: 17 Sep 2004 23:51:42 -0000 From: John Levine <johnl@iecc.com> To: ietf-mxcomp@imc.org Subject: IPR: analysis of Microsoft patent applications 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 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 Regards, John Levine, johnl@iecc.com Primary Perpetrator of "The Internet for Dummies" Information Superhighwayman wanna-be http://www.johnlevine.com Mayor "More Wiener schnitzel, please", said Tom, revealingly. Prepared by Robin Cover for The XML Cover Pages archive. Context: see "Apache Software Foundation Rejects Microsoft Patent License Agreement for Sender ID."