Analyzing The Microsoft Sender ID Patent

I am not a lawyer. I do have a little knowledge and experience in dealing with patents, but be warned: a little knowledge can be dangerous. Take it for what it's worth.

Here's a link to the recently disclosed patent Microsoft filed for Sender ID. As I mentioned yesterday, the patent and the license terms Microsoft is giving to IETF are causing a controversy, that threatens (if not dooms) the standarization of sender authentication. If you've never read a patent application before, this one is quite typical. It is broken into individual numbered claims, which progress from general to specific. A specific claim references the preceding general claims by number to keep things from getting too wordy. (As it is, typical claims are already wordy enough!) . Microsoft follows this pattern, and some of the general claims definitely do cover the territory of SPF (which is the public domain sender authentication proposal that Microsoft added their own Caller ID ideas to in order to come up with Sender ID).

Claims 22, 27 - 30, and 46 - 48 seem to me to be of some concern. Here they are:

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.

27. The method as recited in claim 22, wherein the act of querying a name server for a list of network addresses authorized to send electronic messages for the sending domain comprises an act of querying a Domain Name Services server for a list of network addresses authorized to send electronic messages for the sending domain.

28. The method as recited in claim 27, wherein the act of querying a Domain Name Services server for a list of network addresses authorized to send electronic messages for the sending domain comprises the act of querying a Domain Name Services for a list of Internet Protocol addresses authorized to send electronic mail message for the sending domain.

29. The method as recited in claim 22, further comprising: an act of receiving a list of network addresses that are authorized to send electronic messages for the sending domain.

30. The method as recited in claim 29, wherein an act of receiving a list of network addresses that are authorized to send electronic messages comprises an act of receiving one or more DNS TXT records.

46. 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 sending domains, the computer program product for implementing a method for determining if a sending messaging server is authorized to send electronic messages for a sending domain, 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 purportedly sent from the sending domain; examine a plurality of parameter values of the electronic message to attempt to identify an actual sending side network address corresponding to the sending computer system; query a name server for a list of network addresses authorized to send electronic messages for the sending domain; determine if the actual sending side network address is authorized to send electronic messages for the sending domain; and provide 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.

47. The computer program product as recited in claim 46, wherein computer executable instructions that, when executed by a processor, cause the receiving domain to examine a plurality of parameter values of the electronic message to attempt to identify an actual sending side network address comprise computer executable instructions that, when executed by a processor, cause the receiving domain to examine a plurality of parameter values wherein at least one of the plurality of parameter values is selected from among a first Resent-Sender header value, a first mailbox value in the Resent-From header, a Sender header value, or a first mailbox value in the From header.

48. The computer-program product as recited in claim 46, further 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 a list of network addresses that are authorized to send electronic messages for the sending domain.

Claims 22 and 46 are broad claims. They are not making earlier claims more specific. Claim 22 is a method claim that covers just about any conceivable sender authentication system anyone could ever build. A method claim is so general that it could even cover a process that is executed by humans in control of a computer. Claim 46, although not written to refer to claim 22, is really a device claim for the case where a computer program is used to implement the method of claim 22. Claim 46 is still general enough to cover any practical sender authentication system. Claims 27 through 30 are more specific claims based on claim 22, each narrowing it down further, such that the method described is pretty much exactly what SPF does. Claims 47 and 48 do the same for claim 46, narrowing it down to the point where it describes what a program that implements SPF does.

The thing is, claim 31 is a narrowing down of claim 30, covering the use of XML in the sender authentication protocol, which was legitimately (as far as I know) a Microsoft proposal. Also, claim 49 narrows down claim 46 to include Microsoft's XML proposal. My understanding is that this is just the way patents are written, and even if claims 22, 27 - 30, and 46 - 48 were all invalidated by the prior art of SPF (as I presume they would be), the rest of the patent, including claims 31 and 49 as well as others that describe some mail server handshaking that is outside of the scope of what was in SPF, would be valid if there is no other prior art.

Again, I'm not a lawyer, but it's not clear to me that there's any problem here. Sure, I'd rather that Microsoft had not written broad claims that include technlogy that is clearly unpatentable, but the truth is that this is the way that patents are written, for a number of practical reasons. One is to make sure that claims are easily separable in case of dispute, and the other is that it's simply a well-understood, precise, and concise (if you're used to it) way of describing complicated things.

On the other hand, apart perhaps from the use of XML, I'm really not sure if there's anything patentable here at all. I haven't looked at this very closely yet, but it seems to me that the claims related to the handshaking protocol that are described in the patent might be so general that Lotus Notes and Domino would be prior art -- because Notes has always used a handshaking mechanism to authenticate connections between mail servers. Notes and Domino use a cryptographic handshake, but it's a handshake... and it might meet the criteria spelled out in the claims. The interpretation of the term "address validation data", which is not defined anywhere in the patent filing, doesn't necessarily have to refer to an IP address. A Domino server's unique certified signature could conceivably be considered "address validation information". I'm going to have to look at that. I wish Charlie Kaufman didn't work for Microsoft, otherwise I'd ask him about it, but I'm guessing that he couldn't comment on a Microsoft patent claim.