I know I raised this point twice, and was roundly ignored. Perhaps it is
because I really am wrong, or perhaps nobody read or understood what I was
saying. I am going to say it again. If you want me to shut up. Please say so.
At least I will know then that what I said wasn't just overlooked.
Regarding US Patent Application 20040181571, the one we saw first.
I am not convinced it actually describes or claims the methods used in SPF, or
even in PRA. It is very close, but perhaps not close enough.
Why?
Look at where the claims and summary get the network address (IP address in the
Intenet case) and to the language used to describe that address.
Look at where the claims and summary get the purported sending domain and the
language used there.
Pay careful attention to the words "actual" , "purported" and "purportedly".
Look at the phrases "network address" and "actual sending side network
address". Also look at the phrase "message parameters.
The way I understand it, SPF Classic and the lamented, but possibly not late,
Sender ID both take the actual sending side network address from the TCP/IP
stack, not from "message parameters" as described here. If so, then it is not
at all clear to me that claim 22 or its dependent claims or the description
paragraphs that flesh them out actually describe this situation. They have the
algorithm looking at "a plurality of message parameters" in order to determine
an "actual sending side network address". I understand that neither SPF
Classic nor Sender ID has any doubt about the actual sending side network
address and that neither has any mechanism for finding one in message
parameters at all, certainly not parsing headers to find it, since headers are
all untrustworthy.
SPF Classic and Sender ID both parse one or potentially more headers in order
to find the purported sending domain. I don't see that action in the
application. I do see, in the application, parsing headers to find an "actual
network address.
Just to help nail down terms. I take "actual sending side network address" or
"actual network addres" to mean (in the Internet case) the IP address of the
sending machine. I believe the application uses exactly that definition. I
take "purported sending domain" to mean the domain portion of an email address
contained in the message or it's headers (including SMTP headers as well as
Data headers). I believe the application uses exactly that definition
SPF Classic looks for a purported sending domain in one SMTP header. Sender ID
looks in several Data headers and possibly in one or more SMTP header.
When I read this application, I see it looking in message "parameters" which
include Data headers, and probably SMTP headers, for an "actual sending side
network address", **but not for a purported sending domain**. When it is
looking at a plurality of message parameters, it is looking for an "actual
sending side network address".
To me, the patent application and SPF/Sender ID are doing different things.
Quite possibly different enough that this application doesn't really cover
either.
Perhaps I am reading this wrong. I am, after all, using a Microsoft product to
read this patent application and it is very likely that the omniscient and all
powerful Mr. Gates programmed this product to obfuscate the meaning of this
patent application.
Mark Holm