Patent Application
20050182735
The problem of spam email on the internet has become epidemic and very annoying to users of email. Every day, users of e-mail have to waste time deleting unwanted emails to keep their inboxes from filling up with thousands of messages and wasting their hard disk capacity. Some junk emails are embarassing in terms of the products they are attempting to sell such as Viagra. Other emails are just plain annoying such as emails from sellers of tickets for concerts and other events because they take a long time to load and will not let the user abort the loading process nor delete the email until it is done loading.
Junk email is sent by “spammers” who buy email mailing lists with hundreds of thousands or millions of email addresses. The problem was described in the Nov. 24, 2003 issue of Newsweek (pp. 66-68). That article describes a 32 year old former restaurateur, turned spammer whose company clears $2 million in sales every month by sending out 80 million email advertisements every day. These emails hawk diet pills, porn sites, sexual aids and miracle “As seen on Oprah” products.
This spammer sees nothing wrong with unsolicited bulk commercial email, and notes that spammers are relatively immune to lawsuits because they can “set up in another country within an hour.” Thus, by escaping the jurisdiction of the U.S. courts, personal jurisdiction cannot be obtained, and judgments cannot be collected, if any are successfully obtained. The 32 year old spammer notes that there are people in other countries who “would love to sell us bandwidth.” This spammer is so overconfident, that he lists his phone number on his web site.
Worse still, most virus attacks on the internet are arriving by email. Viruses arrive in the form of unsolicited email with an intriguing subject line which causes an unsuspecting user to open the email or open an attachment to it. The attachment contains a virus program which can damage their data, take over their computer and turn it into a robot or zombie doing the bidding of the attacker or making copies of itself and sending itself to everybody in the user's address book.
The unpleasant fact of life in the cat and mouse game of internet spamming is that the spammers are winning and the contest is not even close.
Annoying email users is not the only problem with spam. In the past two years, spam has congested the internet threatening to overwhelm internet service providers. Spam is now approximately 58% of all email traffic according to Gartner Group as of December 2003. That figure is up from 38% as of December 2002. Ferris Research says spam puts a 9 million dollar drag on productivity every year as workers waste time deleting unwanted email. Some unwanted emails are promoting financial scams such as most emails from Nigeria.
The forces who say they hate spam such as politicians, technology companies, beleagured email users and anti-spam vigilantes who spend their own time and money trying to clean up the net, have not as yet managed to even make a dent in the problem. Current approaches are not working. Even though home users and many companies began filtering their email two years ago, the overall amount of junk mail has ballooned exponentially. Filtering and antivirus companies always seem one step behind the nefarious spammers.
Most individual lawsuits against spammers have been defeated under freedom of speech grounds, settled or concluded with penalties levied against the spammers going unpaid and their email operationg going on unscathed. Efforts in Congress to pass legislation against spammers have been neutered by mainstream companies who wish to preserve the internet for advertising.
Prior attempts to solve this problem have failed. Filtering software is available and some providers such as Earthnet provide filtering functions to put suspected spam in a separate folder that the user can deal with at will. This does not solve the problem because the spam is still on the provider's servers taking up space and otherwise wreaking havoc. The email servers of AOL and microsoft sag under the weight of a billion blocked spam messages every day. Smaller ISPs that get fewer messages suffer even more. For example, the owner of The World, a small New England ISP arrived at work one day in November 2003 to spend three hours personally sifting through his jammed email server and deleting thousands of messages his filters caught.
Filtering out messages from known spammer addresses only works for known spammers, and more pop up every day. Further, known spammers are constantly setting up new email addresses from which to send their spam.
Filtering on content does not work reliably either. CipherTrust, an Atlanta-based, anti-spam firm uses a combination of technology in its filtering products: it hunts for specific words; blocks the addresses of repeat offenders and analyzes information at the top of a message to look for telltale signs of spam. These techniques block many spam messages from getting to the user, but some messages masquerading as legitimate messages get through and some legitimate messages which happen to use a blocked word do not get through such as emails advertising a walk to raise money for breast cancer research. As a more dangerous example, a message masquerading as an upgrade from Microsoft and carrying a virus successfully got through the CipherTrust filter. This virus attack email looked like a legitimate customer service message, and was thus impossible to detect by filtering software which looks for betraying words or phrases. It also was not sent by any known spammer, so address blocking did not work. Further, CipherTrust had not previously seen any other messages like it, so there was no filter template or pattern recognition software available to catch it either. The virus that got through the Ciphertrust filter was a new and deleterious kind of attack. It sought to turn a PC into an unwitting bulk email generator that remotely does the spammer's bidding.
In November 2003, more and more of these so-called zombie virus attacks have occurred on college campuses. After a recent football game at Texas Christian University, network administrator Bryan Lucas returned to his office to find his campus servers pumping out a hundred thousand emails for prescription drugs. He tracked the problem back to the laptop of the football team's bewildered punter who has unwittingly downloaded the zombie attack virus. Lucas stated that this was the fourth such attack in the fall semester of 2003.
Prosecution and litigation has not worked out either. First, sending out bulk commercial email is legal and protected by the First Amendment. However, zombie attacks are clearly illegal. Why aren't spammers who engage in these types of illegal attacks going to jail? First, it is nearly impossible to trace the original spammer through the hijacked computers to other computer locations that usually have long since been abandoned. A spammer can get an IP address from a DHCP server anywhere in the world, and the DHCP server does not know the physical location of the IP addresses it doles out. Furthermore, at law enforcement computer crime agencies, spammers are lower in priority than kiddie porn operators and identity theft rings. Recently, a spammer was arrested for opening Earthlink accounts with stolen credit card numbers, but no resolution of that case has happened as of now, and that is the only known case of prosecution of a spammer as of the time of the Newsweek article.
Private action against spammers has not been effective either. For example, for the past five years, Alan Ralsky has used email to pitch diet pills, hair tonic and other sundries, working mostly from networks in China. Anti-spam vigilante groups constantly have tried to convince these networks to kick him off, but when they do, he simply switches to another Chinese company. Ralsky spent 70 hours over 4 days doing just that in November of 2003.
Verizon tried to stop Ralsky for good in 2001, suing him twice in Virginia for 37 million dollars for twice paralyzing the Verizon network with junk email. Last year, after mounting legal bills on both sides, the parties agreed to settle the case. Ralsky paid an undisclosed sum and only promised to stop spamming Verizon customers leaving him free to resume spamming other networks. Other civil suits have led to large judgments, but spammers rarely pay them and survive with operations intact since if they resume operations outside the U.S., they cannot be touched by U.S. courts to enforce the judgments and only assets in the U.S. can be reached.
ISPs are still committed to the courtroom and are continuing to pursue lawsuits in an attempt to scare spammers out of business. However, the outlook is not promising.
Another possible solution is a new federal get-tough-on-spam law. The problem is that not everybody concerned with the issue can agree what spam is. Companies like Microsoft think the internet should be open to send advertisements to everyone who has used their products in the past. That is just about everybody with a computer. Through organizations like Direct Marketing Association, Microsoft and others have lobbied legislators against more stringent measures which would allow individual computer users to sue bulk emailers, and which would limit spammers from sending messages to anyone who did not consent to receive them.
The result of these lobbying efforts is a bill called the CAN-Spam Act, which recently passed the Senate with a 97-0 vote, and is awaiting a vote in the House. It would enforce certain etiquette (emailers must be truthful in subject lines and must honor remove requests) and lay the groundwork for a “Do not Spam” list similar to the “Do not Call” list. It would also allow ISPs, states and the Federal Trade Commission to sue spammers. The problem with a “Do not Spam” list is that the spammers cannot have access to it as only the government will have the list. One might ask then how does one enforce the list if the spammers do not know who they cannot spam. The answer is that the government will sell the list. Therefore, if spammers do get access to the list by buying it (and they are at their peril if they do not buy the list), they then have a list of valid email addresses upon which to base their operations and they then must be sued or arrested to enforce the list.
These are major reasons why the Do not Spam list will not work any better than private litigation. Many of the spammers work from servers which are offshore and beyond the jurisdiction of U.S. courts. Further, it is hard to find them since they hide their true addresses.
Almost everybody familiar with the spam problem and the CAN-Spam Act believes that the act will do little if any good. Some believe that the act lays too much responsibility at the doorstep of the already overworked Federal Trade Commission. Some believe that spam will increase after the government blesses commercial email and the big companies like Microsoft crank up their own advertising by email servers.
The basic problem with filtering and most other prior art approaches to controlling spam is that they put the cost of dealing with spam on the receiver of the spam or the ISPs. Filtering software is an expense and even when the filter is provided by the ISP, the receiver still needs to go through the suspect email folder and spend time making sure no legitimate messages they want to receive are in the suspect email folder.
Some new approaches are starting to appear. Some believe that the spam problem may only be solved by changing the architecture of email itself by revising the code for delivering mail so that ISPs can check whether incoming email is faking its origin. Such changes would take years to trickle down to every network on the internet around the world.
Challenge/response systems offer some relief. These systems let users send email only to people who have the user's email address in their address book. When a user emails a stranger, the recipient's computer sends back a puzzle that only a human and not an automated spam program can solve. If the sender gives the correct response, the email goes through. Typically, these systems work as follows. If an unknown person sends an email to you, he is directed to a website and asked to type in a displayed number. Computer generated spam programs cannot do this.
Another system called micropayments, would charge a tiny amount for each email sent and would add up to large sums only for bulk email spammers and effectively block them. The micropayment approach conflict with the original open and free-of-charge spirit of the internet, but ultimately, it is among the few reliable ways to foil out-of-control spammers and fraud artists. One way of getting around the “its not free” problem with micropayments is to allow each email user to maintain a “white list”. Any other correspondent who is on a white list of a particular user may send email to that user for free. However, white lists still have problems because they are not kept up to date by their users and they give the user just one more thing to do in a world where almost everybody is already too busy to want to bother with maintaining their white list. Even if a user does maintain the white list, there is still a problem of legitimate users who are not on a recipient's white list and who the recipient might not even know such as persons who see an advertisement for the business of the recipient and want to contact the recipient by email. If potential customers have to pay to send email to a business, they may go elsewhere.
One micropayments approach was proposed by Van Alstyne of the University of Michigan and which was presented at the MIT spam conference on Jan. 15, 2004. The Van Alstyne approach is a filter which puts a price tag on incoming email. Email senders set a prices the would be willing to pay for email recipients to read their missive: anything from, say, $2 to a penny. Recipients set a monetary filter for email they are willing to receive. Messages with postage above that which a recipient has set in his filter get through, and recipients can claim the reward. Of course, the higher the filter price, the less spam they will receive. This restores control to the individual—the recipient can set a low threshold and get paid for reading the email or set a high threshold and receive few if any spam messages. Users can set up a “trusted” list and senders on the trusted list can send email free of payments. No evidence of a secure centralized server to process the stemps and assist the recipient in decrypting them is present in this idea.
Tracking down spammers is difficult even if one wishes to sue a spammer. Spammers hide their identities by forging information in email headers making it seem like the spam is coming from a legitimate source. Antispam software can cross-check the forced address with additional information in the message to determine if the message is real. However, as noted above, sometimes virus attacks still get through filtering software masquerading as a legitimate message.
Content filtering based on key words like viagra does not work because spammers change the spelling such that humans still recognize the word but computers do not. For example, viagra will be spelled v*i*a*g*r*a.
Traffic watching software can spot spam if the text has been altered by finding that it is bulk email sent to multiple people. Each email has a digital ID. This ID is compared with other emails on a computer network. If the same ID shows up in several places on a network, the message is deemed to be spam.
Most of these approaches in the prior art put the burden of spam on the recipients or ISPs. This is not where it should be. Therefore, a need has arisen for a system and process to effectively block spam without filtering out desired, legitimate email even from persons who the recipient does not know. Such a system should use the micropayments approach and automate as much as possible the process of maintaining a white list.
The Receiver Process Genus
This genus is defined by two common characteristics: (1) all species will sense the presence of a stemp; and (2) all species determine if the postage encoded in the stemp is adequate either locally or by communication with a micropayments server; (3) all species allow the message to be viewed if the postage is adequate.
The Sender Process Genus
The genus of the sender process (a process separate from the normal email client which sends and receives email but which works with the email client or is integrated into it to carry out the micropayments protocol) is defined by the following common characteristics: (1) all species must have the ability to request an encrypted stemp from a micropayments server; (2) all species must have the ability to receive back a message from the micropayments server with an encrypted stemp and place the encrypted stemp somehow in the email to be sent in a way which will not interfere with normal processing of the packets in the internet or by the receiver process other than to block the email in predetermined circumstances defined herein.
The Micropayments Server Process
The genus of the micropayments server process is defined by the following characteristics: (1) all species must be able to communicate with potential subscribers to set up postage accounts and/or affinity donation accounts; (2) all species must be able to communicate with sender processes to receive requests for stemps, authenticate the sender process, check for an account and sufficient account balance, and send back an encrypted stemp, debit the account balance, and know the key used to encrypt the stemp for each particular email; (3) all species must be able to communicate with receiver processes so as to assist the receiver process to block spam or extract payments to view the email, the payments to be deposited into the recipients account or an account of an affinity entity such as a charity. This can be done in a variety of ways disclosed above and equivalent ways such as: carrying out a challenge-response protocol with the sender process and sending a message to the recipient computer telling it if the challenge is not responded to or not responded to correctly; inviting the sender to subscribe to a micropayments account and send a message to the recipient computer if the subscription is not entered; and/or maintain a white list for each recipient.
Referring to
Some embodiments do not use a server 24 and simply rely upon sending and receiving software in each computer 10 and 12 to implement the micropayments protocol. The problem with this approach is that every sender is also a receiver so spammers will receive the receiving process software and be able to decompile the program that implements the micropayments protocol and figure out a way around it. By using a server 24, the computer and software that gates the email messages based upon the presence or absence of micropayments is not in the hands of the spammers.
In some embodiments, the server 24 will process the entire email to determine is a micropayment is present and forward the email if a micropayment is present as was done by Critical Path. However, as usage of the system grows, this presents the potential for bottleneck at the server. Therefore, in the preferred embodiment, the server 24 only processes the header portion of email packets to determine if a micropayment is present and gates the email through if a proper micropayment is present. The micropayment server 24 only processes the stamps to implement the protocol, and the email itself is still addressed to the email address of the recipient. Other prior art systems such as that implemented by Critical Path required all email to be addressed to the Critical Path servers. Since everybody already has their domain set up and email address established, the Critical Path approach was not ideal because it required everybody to change their email address to an address on the Critical Path server. This approach also required all emails to be stored on the Critical Path servers. Thus, the Critical Path servers became a bottleneck.
Referring to
Step 26 represents the process of composing an email for sending to one or a few people by a legitimate sender who has a micropayment account on the server 24. Step 28 represents the process of preparing an email, perhaps with a virus attached, by a spammer with no micropayments account with the intent to send it to millions of people. In step 30, the legitimate sender's computer 10 holds the email addressed to recipient computer 12 in abeyance while it sends a message to server 24. This message is a request for a micropayment stamp, and contains data which says in effect, “I am the computer of sender account #xxxx. I need postage for an email.”
In step 34, the spammer's computer sends the spam email across the internet without attaching any postage.
In step 32, the micropayments server 24 receives the message from the legitimate sender computer 10 and authenticates the user and checks the user's micropayments account balance. Authentication can be by any known means. For example, the micropayments server can verify the domain name of the server from which the message came to verify that it is the correct domain for the user if the user is legitimate. In some embodiments, other elements in the message which get added as the message traverses the internet from the legitimate user's computer 10 to server 24 can be checked (these elements act as a sort of electronic DNA or fingerprint for the message) against known correct elements if the message came from the user the message purports to come from. The simplest and probably the most reliable authentication process is for the server 24 to check for correctness a user name and password that only the legitimate user knows and which is included in the message sent in step 30. If the user name or password do not match store records of the user name and password of the user from whom the message purports to come, the message is rejected as not authentic. Another way of authenticating the message sent in step 30 is to use a public key/private key encryption process with a prior public key exchange between the server 24 and the computer 10 of each legitimate user which has a valid account. In this embodiment, the server 24 sends its public key to each legitimate user. Each user generates a public key and a private key when he sets up an account, and the public key is sent to the server 24. The sender process of sender 10 encrypts the message (or some field therein) sent in step 30 using its private key and the public key of the server 24. This message can only be decrypted with the public key of sender 10 and the private key of the server 24. In step 32, if the micropayments server 24 can successfully decrypt the message sent in step 30, the server 24 knows that the message came from computer 10.
In step 36, the server 24 sends back a message to sender computer 10 that contains an encrypted micropayment “stemp” if the user is authenticated and the account balance is adequate to cover the postage. Each email is assigned a serial number or some kind of identifier, and the key which is used to encrypt the stemp is recorded along with this serial number or identifier. The serial number may be assigned by the server 24 and sent back with the encrypted stemp. The serial number may be the checksum of some critical fields in the header of the email which the micropayment server gets. Likewise, the identifier may be the checksum of certain critical fields of the header or of the main body of the email message, said checksum calculated by the sender process and sent to the micropayments server 24 with the message requesting a stemp. Likewise, the sender process can assign a serial number in any other way that will guarantee the serial number to be unique to this email and send the serial number to the micropayment server.
In step 38, the sender process in computer 10 receives the message with the encrypted stemp (and the serial number or other identifier in embodiments where the micropayments server assigns or calculates the identifier) and writes the encrypted stemp into the email being held in abeyance. The encrypted stemp (and serial number or identifier in some embodiments where the recipient computer does not calculate the identifier from the received email main body or header) are placed in the X-envelope field of the email message header. There is a header in every email that is visible to the recipient computer but not the user of the email client. That is the preferred location for the encrypted stemp. In some embodiments, the encrypted stemp (and serial number or identifier in some embodiments) are placed in user definable fields in the TCP or IP header of the email packets. In some embodiments, the identifier is not sent with the email message but is calculated by the recipient computer receiver process.
In step 40, the sender process of computer 10 send the email with the encrypted stemp (and serial number or identifier in some embodiments) to the recipient computer 12 via the internet in a conventional way. The email packets get routed through the internet routers just like any other email packets. SMTP and POP protocols are unchanged and work in the same way they have always worked.
In step 42, a receiver process running in computer 12 receives the email and attempts to retrieve the encrypted stemp (and serial number or identifer in some embodiments). In other embodiments, the receiver process receives the email and retrieves the encrypted stemp from the message header and then calculates a checksum of the same critical fields of the header or of the main body using the same checksum algorithm as was used by the micropayments server or sender process to calculate the identifier of the message. The incoming email might be from a spammer and have no stemp or serial number, as represented by path 44, or it might be a non spam email sent from a user with a micropayment account, as represented by path 46. A third possibility exists represented by step 48 and path 50. Step 48 represents the process of a non spam sender without a micropayments account composing and sending an email without a stemp. The arrival of this email at the receiver computer 12 is represented by path 50.
Test 52 represents the process of determining whether the email has an encrypted stemp and serial number. If the incoming email does not have a stemp and serial number, it could either be from a spammer, or from a person not on the recipient's white list and not having a micropayments account, or from a person on the recipient's white list and not having a micropayments account, or from a person with a micropayments account.
If the incoming email is from a person with a micropayments account, it will have a stemp and a serial number, and processing will proceed to step 54. There, the receiver computer sends a message to the micropayments server 24 with the serial number or identifier of the email and authentication data for the recipient computer. This message asks for the key to decrypt the stemp. The authentication information can be any information used for any authentication process over the internet known from the prior art as was the case for the authentication of the sender computer 10 by the server 24. In step 56, the micropayment server 24 receives the key request message, authenticates the recipient computer, looks up the key using the serial number in the key request message and sends back the key (encrypted using the public key of the recipient computer in some embodiments) to the recipient computer 12.
In step 56, the receiver process in the recipient computer receives the key reply message, decrypts the key if necessary, and uses the key to decrypt the stemp to ascertain the amount of postage attached to the email.
In step 60, the receiver process determines if the decrypted postage amount is adequate. If so, the receiver process passes the email message to the user's mail client process for viewing, as symbolized by step 62. In alternative embodiments, the amount that the stemp value is compared to is a variable threshold. The threshold value may be programmable by the user in some embodiments, or may be set in a table with the threshold value selected based upon the sender identity. In some embodiments, step 60 compares the sender identity, as established by the sender's email) to the names on a white list of senders who are allowed to send email for free or for very low postage amounts to the recipient and picks the threshold from the threshold value established for the user on the white list.
If the postage is inadequate, the receiver process either deletes the message or sends back a “rejected” message to the sender or saves the message in a folder of the mail client reserved for “questionable-possible spam” messages, as symbolized by step 64. In some embodiments, which of these three things it does is controlled by configuration data that the user can set. In other embodiments, the receiver process does just one of these three things so the list defines three separate alternative embodiments.
Returning to the consideration of step 52, if the email that came in does not have a stemp, it may be from a spammer or it may be from a person on the recipient's white list who does not have an account for micropayments. It may also be from a potential customer who saw the recipient's email address on a website or an advertisement and who chose to contact the recipient by email but who does not have a micropayments account. It may also be from the secretary or some other assistant or friend of a known associate of the recipient, the assistant not being on the white list and not having a micropayments account. If an email comes in which does not have a stemp, step 66 is performed by the receiver process of the recipient computer to determine if the sender is on the white list of the recipient. If the sender is on the white list, processing proceeds along path 68 to step 62 carried out by the recipient computer 12 to pass the email to the email client for viewing on the recipient computer.
In alternative embodiments, step 66 is carried out by the micropayments server 24 which maintains white lists for all users who have established accounts. The advantage of having the white list on the micropayments server is that there is no synchronization problem if the user uses multiple machines to retrieve email such as a desktop machine in the office, another desktop machine at home, and a laptop while on the road. If a user does use multiple machines to retrieve email and the white list is kept on the local machine, all white lists on the multiple machines the user uses should be kept synchronized (all containing the same entries and same threshold stemp values in embodiments where different postage values are used for different users).
Another advantage to maintaining the whitelist for each user on the micropayments server is that the micropayments server could use the white list for each user to act as a filter so that only emails which have proper stemp postage or which are from senders on the recipient's white list are approved for sending by the micropayments server 24.
If the sender is not on the white list of the recipient, processing proceeds to step 70. Step 70 represents processing which can be performed by several different species or embodiments. In one embodiment, configuration data set by the recipient establishes how the recipient computer responds to incoming email without a stemp which is from a sender which is not on the recipient's white list. The recipient can set this configuration data to automatically delete the email or put the email into a questionable-possible spam folder of the email client or carry out a challenge response protocol and pass the email to the email client for viewing if the response comes back correct. The challenge response protocol has the recipient computer send a challenge message back to the recipient which poses a question which only a human can answer. Such a challenge might be “tell me the number which is displayed in the following dot matrix” or “tell me who the first president of the United States was” or “tell me the name of the person displayed on the US five dollar bill”. The question must be something that a human can easily answer but which a spammer's computer would not be able to answer for lack of senses and memory and cognitive ability. If a response comes back which is right, which it would if the sender was a potential customer or somebody the recipient wanted to receive mail from who happens not to be on the recipient's white list, the email is passed to step 62 for viewing.
Step 70 also represents alternative embodiments that do only one of the three listed things. The preferred embodiment would be to just carry out a challenge-response protocol since this would foil spammers but not preclude humans not on the white list and not having a micropayment account from getting their emails through to the recipient.
Referring to
In some alternative embodiments represented by
Returning to the consideration of the protocol of
The sender computer responds in step 82 by either doing nothing or by sending back a reply which may say the sender does want to establish an account or does not want to establish an account, all possibilities being represented by line 84.
The micropayments server responds in step 86 by determining if the sender sent a message indicating a desire to establish an account or indicating no desire to establish an account or if the sender did not respond to message 80 at all. If the sender did not respond or indicated no desire to establish an account, the server sends message 88 telling the recipient computer receiver process to send the no stemp email to the trash, as represented by step 90. If test 86 determines that the sender indicated he or she does want to establish an account, then the server carries out step 92 to enter a subscription and deduct the amount of the stemp postage and send a “subscription entered message” 94 to the recipient computer.
The recipient computer responds in step 96 by sending the email to the email client of the recipient computer for viewing.
In step 104, server 24 selects a simple challenge question which only a human can answer from a list of challenge questions stored in the server. The server 24 preferably does not send the same challenge every time. All the challenges are easy such as “type the number displayed in the following dot matrix display?”, or “Who was the first president of the U.S?” (that one might not be so easy for foreigners), or “What is the denomination of the smallest paper money bill the U.S. treasury issues?”, or “What is the first name of the patriarch of the cartoon Simpson family?” Since survey evidence proves that Bart Simpson is the most famous American worldwide, that question should work well overseas. This challenge question is then sent in a message to the email address of the sender, as represented by message 106.
The sender computer's receiver process (if it has one—available free for download from the assignee of the present invention) receives the challenge message and recognizes it as a challenge message from unique information in the message body or in the header that labels the message as a challenge, as represented by step 108. The receiver process then displays the challenge to the user of the sender computer. If the sender computer is a spammer's server, no human will ever see the challenge, and no response will be issued. The spammer's server will not be able to automatically respond to the challenge because the challenge requires human cognitive ability. If the sender computer's operator is a legitimate non-spammer person, the human operator will see the challenge, answer it and give the send reply command. A response message 110 will then be sent back to the server 24 with the answer to the challenge question. No message 110 results if the sender computer is a spam server.
The server 24 monitors for a response message 110 as symbolized by step 112. If step 112 determines that a response came back to the challenge message and the response was correct, it sends a “response correct” message 112 to the recipient computer 12. Receipt of the “response correct” message causes the recipient computer to carry out step 114 to send the email in question to the email client of the recipient computer for viewing.
If step 112 determines that no response came back from the sender to the challenge message, or that the response that came back was incorrect, message 116 is sent to the recipient computer saying “no correct response received”. Receipt of the “no correct response received” message causes the recipient computer to carry out step 118 to send the email in question to the trash automatically before the email client ever receives it. In alternative embodiments, the email message may be stored in a “suspected spam” folder for the email client.
In the processes of
Step 126 represents the process of the recipient computer receiving an email with an encrypted stemp. In step 128, the recipient computer decrypts the stemp with the stored key and compares the value of the postage to a threshold value. Step 130 vectors processing to the appropriate routine based upon the comparison in step 128 of the postage to the threshold value. If the postage is equal to or more than the threshold value, the email is sent to the email client for viewing in step 132. If the postage is inadequate, the email is discarded without viewing or a message is sent back to the sender saying insufficient postage, as represented by step 134. Sending back a message to the sender is not preferred since that gives a potential spammer information that the email address is valid. Step 134 represents two different subspecies within each of the species represented by steps 118, 122 and messages 120 and 124.
If the amount of the postage is adequate, processing is vectored to process 148 to generate and send a “postage OK” message 150 to the receiver process. This causes the receiver process to carry out step 152 to send the email to the email client for viewing.
The difference in the protocol of
Step 190 represents a step carried out by the recipient process to determine if an incoming message is a transfer value message. Such messages will be uniquely identified in their headers.
If a recipient receives a value transfer message directly from another user, step 192 is performed on the recipient computer by the receiver process to display a message to the user that sender Mr. xxxxx has just transferred or desires to transfer whatever the amount transferred is to the user's stemp account, or to the account of an entity of the recipient's choosing such as a charity. Step 192 also sends message 194 to the micropayments server requesting that the transferred stemp value be added to the recipient's account, or to the account of another of the recipient's choosing such as a charity, and sending authentication information to the micropayments server so it can identify and authenticate the sender of message 194. The micropayments server determines in step 196 whether a value transfer message has been received.
The server can receive value transfer messages directly from a sender or the value transfer message may be received from a recipient of email who has itself received a value transfer message from the sender indicating the sender wishes to transfer a micropayment amount to the recipient or some other entity designated by the recipient on condition that the recipient not block the sender's email or will at least open the email. The value transfer message preferably also contains enough information to identify and authenticate the sender. This means that if a sender sends a value transfer message directly to a recipient, that sender should also send information with the value transfer message which is adequate to authenticate the sender. This may be implemented by having a value transfer password of the sender which is different than any other password of the sender and which can be used only to authenticate the sender for purposes of transferring a micropayment amount from the sender's account to the recipient's account (or an account designated by the recipient) and cannot be used to obtain encrypted stemps or for any other purpose.
In the case of a value transfer message sent directly to a recipient, the receiver process on the recipient computer will send message 194 to the micropayment server asking the micropayment server to add the micropayment amount to the receipient's account, or the account of another designated by the recipient, on the occurrence of a specified condition such as not blocking the email or opening it. Step 196 is performed after step 74.
If no value transfer message has been received by the server, processing vectors on line 198 to step 78 which is identical to the like numbered step in
If step 196 determines that the micropayments server has received a value transfer message, the server executes step 200 to authenticate the sender of the value transfer message (the one who wants to give the money to another user), check the account balance for that sender, debit the appropriate amount from the account if the value transfer message came directly to the server from a sender (a process to be discussed next), and send back an encrypted stemp to the sender if the value transfer message came directly from a sender process (as opposed to a receiver process of a recipient). Then step 202 is performed to add the transferred stemp value to the recipient's stemp account or to the account of another designated by the recipient, and send a message 204 to the receiver process of the recipient indicating the amount of the transferred value. Message 204 causes the recipient's computer in step 192 to display a message to the user indicating how much stemp value has been added to the recipient's account or the account of another designated by recipient on the server and who the donor was. The recipient computer then performs step 206 to wait for the next email or value transfer message and performs step 72 if it receives a no stemp email and step 190 if it receives a transfer stemp value message.
Some senders of commercial email may want to prioritize their email for recipients by giving the user an incentive to read it or just open it and not send it to the trash. This can be done by including with the email some stemp value which gets transferred into the recipient's postage account or somebody else's account on the server and which causes the server to send a message to the recipient saying who donated what amount to which account (message 204 discussed above). For example, tickets.com may want to send an advertisement to its mailing list of customers and may wish to encourage the customers to read it. Suppose, the threshold stemp value to send an email to a recipient is one cent. A user of a Tickets.com server may cause its sender process in step 192 to request a stemp with a special message 194 that requests a stemp, and requests that an excess amount over the required value of the stemp be transferred to the recipient's stemp account. This message 194 contains the regular information needed to authenticate the requester and request an encrypted stemp, but also contains a request to debit some amount from the sender's stemp account which is more than the required value of the stemp and transfer the excess to the recipient's stemp account or to the account of another designated by the recipient. Message 194 is detected by the server in step 196 and causes the server to perform step 200 to authenticate the sender, check the account balance for that sender, debit the amount requested in message 194 from the sender's account, check the threshold amount to send an email to the intended recipient of the message for which the stemp was requested, subtract the threshold amount from the debited amount and supply the difference to step 202, and send back an encrypted stemp (along with an email identifier for the email message the sender wants to send in embodiments where the server assigns the message ID or serial number). This message including the encrypted stemp is represented by line 208 and causes the sender computer in step 210 to include the encrypted stemp and message ID or serial number in the email addressed to the recipient and send the email by normal channels.
After step 200 is performed, step 202 is performed to add the difference value received from step 200 to the intended recipient's stemp account or to the account of another designated by the recipient. Then message 204 is sent to the recipient as previously described which causes the recipient computer to display a message in step 192 indicating how much was added to the recipient's account or to the account of another designated by the recipient and who the donor was.
If the sender elects in step 192 to not transfer value to the recipient, step 210 is performed after step 192. Step 210 sends a request message 212 to the server saying, “I am user xx. I need a stemp for an email to recipient yyy.” This causes the server to execute step 200 to authenticate the sender, check the account balance, debit the amount needed to send an email to this recipient (in some embodiments, there is an exchange of messages to the effect, “This recipient requires a postage amount of $z.zz to receive a message from you. Do you still want to send this message?”), assign an ID for the email (in embodiments where the server assigns the email serial number or identification codes) and send back an encrypted stemp (along with the ID assigned to the email in some embodiments). The encrypted stemp and ID are message 208. This causes the sender process to put the encrypted stemp and ID in the email and send it by normal channels. Receipt of the email with encrypted stemp causes the recipient computer to execute one of the other protocols described herein for receipt of an email with a stemp.
The transfer value functionality described above can be added to any of the other embodiments described herein to generate more species within the overall genus. An important alternative embodiment of the transfer value process involving transfer only if the recipient opens the message is comprised of the following steps:
Although many embodiments were disclosed herein, three genera may be defined into which all species of the sender process, micropayments server process and receiver process fall. Each of the three genera are defined by the common characteristics which all species in the genus share.
The Receiver Process Genus
This genus is defined by two common characteristics: (1) all species will sense the presence of a stemp; and (2) all species determine if the postage encoded in the stemp is adequate either locally or by communication with a micropayments server; (3) all species allow the message to be viewed if the postage is adequate.
The Sender Process Genus
The genus of the sender process (a process separate from the normal email client which sends and receives email but which works with the email client or is integrated into it to carry out the micropayments protocol) is defined by the following common characteristics: (1) all species must have the ability to request an encrypted stemp from a micropayments server; (2) all species must have the ability to receive back a message from the micropayments server with an encrypted stemp and place the encrypted stemp somehow in the email to be sent in a way which will not interfere with normal processing of the packets in the internet or by the receiver process other than to block the email in predetermined circumstances defined herein.
The Micropayments Server Process
The genus of the micropayments server process is defined by the following characteristics: (1) all species must be able to communicate with potential subscribers to set up postage accounts; (2) all species must be able to communicate with sender processes to receive requests for stemps, authenticate the sender process, check for an account and sufficient account balance, and send back an encrypted stemp, debit the account balance, and know the key used to encrypt the stemp for each particular email; (3) all species must be able to communicate with receiver processes so as to assist the receiver process to block spam. This can be done in a variety of ways disclosed above and equivalent ways such as: carrying out a challenge-response protocol with the sender process and sending a message to the recipient computer telling it if the challenge is not responded to or not responded to correctly; inviting the sender to subscribe to a micropayments account and send a message to the recipient computer if the subscription is not entered; and/or maintain a white list for each recipient.
Although the invention has been disclosed in terms of the preferred and alternative embodiments disclosed herein, those skilled in the art will appreciate possible alternative embodiments and other modifications to the teachings disclosed herein which do not depart from the spirit and scope of the invention. All such alternative embodiments and other modifications are intended to be included within the scope of the claims appended hereto.
