Source: http://www.google.com/patents/US7711786?dq=6,274,924
Timestamp: 2016-02-13 00:55:22
Document Index: 741408915

Matched Legal Cases: ['Application No. 60', 'art 412', 'art 414', 'art 422', 'art 424', 'art 424', 'art 414', 'art 422', 'art 412', 'art 422', 'art 422', 'art 462', 'art 464', 'art 472', 'art 474', 'art 474', 'art 464', 'art 472', 'art 462', 'art 462']

Patent US7711786 - Systems and methods for preventing spam - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsSystems and methods are disclosed for preventing spam, including email spam and telephone spam, through the use of dynamic passcodes or dynamic signatures included with transmitted messages. Both the dynamic passcodes and dynamic signatures may be changed periodically or continually, according to an...http://www.google.com/patents/US7711786?utm_source=gb-gplus-sharePatent US7711786 - Systems and methods for preventing spamAdvanced Patent SearchPublication numberUS7711786 B2Publication typeGrantApplication numberUS 12/017,692Publication dateMay 4, 2010Filing dateJan 22, 2008Priority dateAug 6, 2007Fee statusPaidAlso published asUS20090044013Publication number017692, 12017692, US 7711786 B2, US 7711786B2, US-B2-7711786, US7711786 B2, US7711786B2InventorsYunzhou ZHU, Xuebin JIANGOriginal AssigneeZhu Yunzhou, Jiang XuebinExport CitationBiBTeX, EndNote, RefManPatent Citations (21), Non-Patent Citations (7), Referenced by (21), Classifications (27), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetSystems and methods for preventing spam
US 7711786 B2Abstract
The present application claims priority to U.S. Provisional Application No. 60/954,190, filed Aug. 6, 2007, and entitled “Dynamic Passcode and Signature to Prevent Spam,” which is hereby incorporated by reference in its entirety as if fully set forth herein.
A recurring problem for current email systems is that unsolicited email has become a nuisance for users. These unsolicited emails are commonly referred to as “spam”. Indeed, due to the low cost of sending emails and due to the ease with which email addresses may be harvested, some individuals or businesses send spam to a large number of individuals. Spam not only occupies much of the storage space, computing resources, and traffic bandwidth of email systems, but it also wastes the recipient's time in downloading, reading, and deleting the spam. In addition, spam can also be used for phishing scams or for virus attacks. These phishing scams may involve leading unsuspecting users to counterfeit websites to obtain financial information such as usernames, passwords, and account numbers. Likewise, virus attacks may include virus, Trojan, malware, and other programs designed to harm the user's computer.
The use of the dynamic signatures may be supported by a graylist. For example, a graylist of each account owned by the authorized user (“recipient”) may be used to store the profiles of selected legitimate senders, or qualified senders, for that account. Accordingly, the qualified sender, whose profile is in the graylist of an account, may not need to use the passcode of that account. Rather, the dynamic signatures of the sender may be included in the messages sent by the qualified sender. Another feature of the graylist of an account may be to limit the number (e.g., quantity) of messages sent by the qualified senders in a specified time period though the qualified senders could be authenticated based on their signatures. This feature may block spam sent by the legitimate businesses that send both legitimate message and spam. For example, an on-line shopping web site may send emails to the customers to confirm the ordering and delivering, and may also send emails about discount information, or other commercials.
According to an aspect of the invention, a dynamic tag may be stored in an extra field such as a “Dynamic tag” filed of the messages for email communication, PSTN telephone communication, cellular phone communication and SIP communication. Alternatively, for email communication, the dynamic tag may be embedded in a dynamic destination email address. According to another aspect of the invention, an account owner can predetermine the maximum number of messages accepted in a specified time period to the qualified senders to limit their message sending. According to yet another aspect of the invention, an account owner may optionally pre-charge with a fee to the non-qualified sender to request the dynamic passcode of the account. The fee may be refunded, perhaps by default, if the accepted message is determined to not be spam.
The sender's MTA 112 may likewise be a computer or processor-based device capable of communicating with the email sender 111 computer, the recipient's MTA 113 (e.g., mail server), or other computing or network device via one or more networks, including network 110. The sender's MTA 112 may include a processor 162 and a computer-readable medium, such as memory 164, coupled to the processor 162. The processor 162 may execute computer-executable program instructions stored in memory 164. Computer-executable program instructions stored in memory 164 may include a transfer module 166, which may generally provide for sending, forwarding, and receiving emails between senders and recipients. The transfer module 166 may be operative to determine which emails may be accepted into an email box for the incoming emails. The transfer module 166 can also process and transmit outgoing emails to the respective email MTA 113. According to an embodiment of the invention, the transfer module 166 may determine whether the sender is a qualified sender for a particular recipient and automatically provide dynamic destination email addresses of recipients for a qualified sender. In determining whether the sender is a qualified sender for a particular recipient, the transfer module 166 may access a database 169 or other memory that stores profiles of recipients (a “graylist” as described in detail below) that the sender is qualified to send emails to. In an alternative embodiment of the invention, the message module 156 may instead determine whether the sender is a qualified sender for a particular recipient and automatically provide dynamic destination email addresses of recipients for a qualified sender.
Like the sender's MTA 112, the recipient's MTA 113 may be a computer or processor-based device capable of communicating with the sender's MTA 112, the recipient 114 computer, or other computing or network device via one or more networks, including network 110. The recipient's MTA 113 can include a processor 182 and a computer-readable medium, such as memory 184, coupled to the processor 182. The processor 182 can execute computer-executable program instructions stored in memory 184. Computer-executable program instructions stored in memory 184 can include a transfer module 186, which may generally provide for sending, forwarding, and receiving emails between senders and recipients. The transfer module 186 may be operative to determine which emails may be accepted into an email box for the recipient. The transfer module 186 can also process and transmit outgoing emails to the respective MTA 112. According to an embodiment of the invention, the transfer module 186 may determine whether an email received is from a qualified sender. If the email received is from a qualified sender, then the email may be accepted into the receptive recipient's email box on the MTA 113. In determining whether an email has been received from a qualified sender, the Transfer module 186 may access a database 189 or other memory that stores a list of profiles of senders (a “graylist”) that may send emails to the recipient. In addition, the transfer module 186 may also provide or otherwise update the dynamic passcode provider 135 with information used in generating dynamic email addresses or dynamic content for one or more recipients with email boxes on the MTA 113.
FIG. 2A illustrates some example fields of an email header 210, according to an example embodiment of the invention. In FIG. 2A, the “Date:” field 211 may be the date that the email was sent. The “From:” field 212 may provide the sender's name and email address, and may be entered by the sender or the sender's exchange entity or MTA. The “To:” field 213 and the carbon copy (“Cc:”) field 214 may show the destination email addresses and/or names of one or more recipients. As described herein, an email message that specifies more than one destination email address in the “To:” and/or “Cc:” field may be referred to as a group email message. The “Subject:” field 215 may be the title of the email. It will be appreciated that while some fields have been illustrated in FIG. 2A, other fields may also be utilized without departing from example embodiments of the invention.
FIG. 2B illustrates some example fields of a SIP message 220, according to an example embodiment of the invention. The SIP message may include a “To:” field 221 and a “From:” field 222. The sender of the SIP message may provide a destination SIP message address in the “To:” field 221 and a source SIP message address in the “From:” field 222. It will be appreciated that while some fields have been illustrated in FIG. 2B, other fields may also be utilized without departing from example embodiments of the invention.
Referring to FIG. 3, on Day one at starting time 00:00:00 AM, a node/exchange entity initially generates a random secret key “492ac93bc329343f33ea3 . . . ” of length 2000 bytes. This generated random key may be stored as the current secret key (KEY). The prior secret key (OLD_KEY) may have a null value, as illustrated in FIG. 3.
After 24 hours (e.g., in accordance with PERIOD_TIME), on Day two, the node/exchange entity may create a new random secret key “2ae146b27f85e42a47b346c9 . . . ” that may be stored as the current secret key (KEY) while the prior value of the current key may be stored as the prior secret key (OLD_KEY). Accordingly, the value of the prior secret key (OLD_KEY) may be “492ac93bc329343f33ea3f3 . . . ”, as illustrated in block 320.
After another 24 hours, on Day three, the node/exchange entity may create a new random secret key “e36c2a78d3e4f38cb3f786e1 . . . ” that may be stored as the current secret key (KEY) while the prior value of the current key may be stored as the prior secret key (OLD_KEY). Accordingly, the value of the prior secret key (OLD_KEY) may be “2ae146b27f85e42a47b346c9 . . . ”, as illustrated in block 330.
For a destination account, there may be two or more kinds of senders, including qualified senders and non-qualified senders, according to an example embodiment of the invention. The owner of the destination account (e.g., a recipient) may typically determine and maintain a list of qualified senders to his account. According to an example embodiment of the invention, this list may be referred to as a “graylist.” Qualified senders may be those senders that are authorized by the owner of the destination account according to the graylist. For example, the qualified senders may be acquaintances, friends, or business partners of the owner of the destination account. Likewise, those senders who communicate with the destination account frequently may typically be classified as the qualified senders of the destination account. On the other hand, senders who are not qualified senders of the destination account may be referred to as non-qualified senders of the destination account. According to an example embodiment of the invention, senders who are not in the graylist or other qualified sender list may be non-qualified senders. In another example embodiment of the invention, a list separate from the graylist may also be utilized to explicitly identify non-qualified senders.
According to an example embodiment of the invention, the dynamic tag may be provided in a new field of a message, perhaps in a “Dynamic tag” field or another field. For example, according to an example embodiment of the invention, the dynamic tag may be provided in a header of the message. According to another example embodiment of the invention, the dynamic tag may be embedded in the destination address of the message, or the source address of the message, provided that the newly formed addresses comply with the naming specifications of the communications protocol. Additionally, a delimiter such as “..”, “——”, or other character(s), may be used to indicate which portion of the embedded source or destination address corresponds to the dynamic tag. It will be appreciated that the original source or destination address may be referred to as the static address while the new address with the embedded dynamic tag may be referred to as a dynamic address. Because the dynamic address may be an extension of a static address, the dynamic address may maintain uniqueness within the communications protocol.
FIG. 4A illustrates a static email address 410 for a recipient and a corresponding example of a dynamic email address 420 for the same recipient, according to an example embodiment of the invention. In FIG. 4A, the static email address 410 may include a local part 412 and a domain part 414. Similarly, the dynamic email address 420 may also include a local part 422 and a domain part 424. The domain part 424 of the dynamic email address 420 for the recipient may be the same as the domain part 414 of the static email address 410 for the recipient. The local part 422 may include a static portion 425 a and a dynamic portion 425 b, according to an example embodiment of the invention. The static portion 425 a may be the same as the local part 412, according to an example embodiment of the invention. However, the dynamic portion 425 b may change for each instance of the dynamic email address. In addition, according to an example embodiment of the invention, the dynamic email address 420 may further include a delimiter 425 c for separating the static portion 425 a from the dynamic portion 425 b. The delimiter 425 c may be a variety of characters or sequences of characters, including “..” or “——”, according to an embodiment of the invention. However, in other embodiments of the invention, no delimiter 425 c may be necessary where the dynamic portion 425 b may be a fixed number of characters at a known position within the local part 422 of the dynamic email address 420. For example, the dynamic portion 425 b may be six characters at either the beginning or end of the local part 422, according to an example embodiment of the invention. In addition, according to an example embodiment of the invention, dynamic portion 425 b may be further subdivided into a dynamic code 427 and a counter 428. As will be described in further detail below, the counter 428 may be used in verifying the dynamic code 427.
FIG. 4B illustrates a static telephone number 430 and its corresponding dynamic telephone number 440, according to an example embodiment of the invention. In particular, the static telephone number 430 is “17703466598”. The dynamic telephone number 440 may include a static portion 442 a and a dynamic portion 442 b (e.g., dynamic tag) that are separated by a delimiter 442 c (e.g., “#”). In an alternative embodiment of the invention, no delimiter 442 c may be necessary. The static portion 442 a may be identical to the static telephone number 430. The dynamic portion 442 b (e.g., “6545982”) may include a dynamic code 444 (“654598”) and a counter 445 (e.g., “2). As will be described in further detail below, the counter 445 may be used in verifying the dynamic code 444.
FIG. 4C provides an example of a static SIP address 450 and a corresponding dynamic SIP address 460, according to an example embodiment of the invention. The static SIP address 450 may include a local part 462 (e.g., sip:bob345) and a domain part 464 (e.g., “dom.com”). In the dynamic SIP address 460, there is a local part 472 and a domain part 474. The domain part 474 of the dynamic SIP address 460 may be the same as the domain part 464 of the static SIP address 450. The local part 472 may include at least a static portion 475 a (e.g., “sip:bob345”) and a dynamic portion 475 b (e.g., “r5pwdp3”). The static portion 475 a may be the same as the local part 462, according to an example embodiment of the invention. In addition, according to an example embodiment of the invention, the dynamic SIP address 460 may further include a delimiter 475 c for separating the dynamic portion 475 a from the dynamic portion 475 b. The delimiter 475 c may be a variety of characters or sequences of characters, including “..” or “——”, according to an embodiment of the invention. However, in other embodiments of the invention, no delimiter 475 c may be necessary where the dynamic portion 475 b may be a fixed number of characters at a known position within the local part 462 of the dynamic SIP address 460. In addition, according to an example embodiment of the invention, the dynamic portion 475 b may be further subdivided into a dynamic code 477 (e.g., “r5pwdp”) and a counter 478 (e.g., “3”). As will be described in further detail below, the counter 478 may be used in verifying the dynamic code 477.
It will be appreciated that other strings, characters, or signs may be used as delimiters, according to example embodiments of the invention. It will also be appreciated that some embodiments of the invention may not include any delimiters. Furthermore, different lengths of the dynamic portions or values may be utilized according to various security requirements. Likewise, other positional numeral systems with bases other than 10 may be used in the counter of the dynamic portion (e.g., dynamic tag) without departing from embodiments of the invention. Additionally, the dynamic portion (e.g., tag) or at least a part thereof may be embedded in the message in other places besides the static address. For example, the dynamic portion (e.g., dynamic tag) could alternately be placed or embedded in the display name of the email with a delimiter. For example, the string in “To:” field of an email typically may be “Adam Smith <adam493@yyhh.com>”. After adding a dynamic tag “b3wd9e12” as the postfix of the display name with the delimiter “..”, the displayed name may now be “Adam Smith..b3wd9e12<adam493@yyhh.com>”. It will also be appreciated that telephone/cell phone messages can transfer dynamic tag interactively in a challenge-response manner, according to an example embodiment of the invention.
Local seed 520 (e.g., LOCAL_SEED): Generated by the owner of the current account, and may be shared with the qualified sender specified by the qualified static address 511, for use in generating the dynamic tag for inclusion in the outgoing message. Local index 521 (e.g., LOCAL_INDEX): The last counter of the dynamic tag (e.g., dynamic signature) in the outgoing message sent by the owner of the current account as the qualified sender to the email address in the qualified static address 511. Local maximum index 522 (e.g., LOCAL_MAXINDEX): Generated by the owner of the current account to limit the local index 521, and may be shared with the qualified sender specified by the qualified static address 511. The local maximum index 522 may define a maximum number used in the counter of the dynamic tag for the outgoing message. Local hashing function 523 (e.g., LOCAL_HASH): A hash function or one-way function specified by the owner of the current account, and may be shared with the qualified sender specified by the qualified static address 511. The local hashing function may be used for generating the dynamic tag (e.g., dynamic signature) of the outgoing message with destination address QUALIFIED_ADDRESS. Local chaining function 524 (e.g., LOCAL_CHAIN): Specified by the owner of the current account, and may be shared with the qualified sender specified by the qualified static address 511, for computing the new local seed based on the current local seed 520 (e.g., LOCAL_SEED) when local index 521 exceeds the local max index 522. According to an example embodiment of the invention, it will be appreciated that qualified seed 512 (e.g. “bdhi93bdk93 . . . ”) of the profile 510 a in the current account may become a local seed 512 in the graylist of account adam.smith493@yyhh.com. For example, for user A and B, user A's Qualified fields for user B may be user B's Local fields for user A, and user B's qualified fields for A may be A's Local fields for B. It will also be appreciated that in accordance with an example embodiment of the invention, one or more of the graylist profile records 510 may have an associated expiration date 525. Accordingly, a graylist profile record 510 may become invalid after the expiration date 525. Likewise, the graylist profile records 510 may specify not only the qualified senders of the account, but also how many messages may be sent by a qualified sender in a particular time period.
Let LOCAL_SEED be “shdfk5yp8er”.
Referring now to FIG. 6, according to an example embodiment of the invention, a history list in block 610 may include one pair (492ac93bc3 . . . , 2) at a first time period when system key KEY=“492ac93bc329343f33ea3f3 . . . ” and OLD_KEY=null. In block 620, the history list may include pairs (2ae146b27f . . . , 1), (2ae146b27f . . . , 2) and (492ac93bc3 . . . , 2) at second time period when KEY=“2ae146b27f85e42a47b346c9 . . . ” and OLD_KEY=“492ac93bc329343f33ea33 . . . ”. When KEY=“e36c2a78d3e4f38cb3f786e1 . . . ” and OLD_KEY=“2ae146b27f85e42a47b346c9 . . . ” in a third time period, the history list in block 630 may include pairs (e36c2a78d3 . . . , 1), (2ae146b27f . . . , 1) and (2ae146b27f . . . , 2) associated only with current KEY and OLD_KEY. The pair (492ac93bc3 . . . , 2) associated with the old value of OLD_KEY may be deleted, according to an example embodiment of the invention. Accordingly, the size of a history list may be maintained at a manageable size, according to an example embodiment of the invention.
According to an example embodiment of the invention, the dynamic passcode provider may also store a query pre-charge indicator for each account. The query pre-charge indicator for each account on the dynamic passcode provider may be synchronized with a similar pre-charge indicator for each account in the node/exchange entity. As will be described in further detail below, the query pre-charge indicator may have a value of NONYES or 0/1, according to an example embodiment of the invention. A value of “NO” or “0” may indicate that the non-qualified sender would not be pre-charged for performing a query on the dynamic passcode provider for a destination account. On the other hand, a value of “YES” or “1” may indicate that the non-qualified sender may be pre-charged for performing a query on the dynamic passcode provider for the destination account. According to an example embodiment of the invention, if the non-qualified sender is to be pre-charged for performing a query and obtaining a dynamic passcode, the payment may be made from an account funded by the non-qualified sender. If the recipient receives the message with the dynamic passcode, and the message is not spam, then the non-qualified sender may be refunded the pre-charge amount. Accordingly, the use of the pre-charge may increase the costs for and otherwise deter spammers or unauthorized senders attempting to obtain dynamic passcodes.
According to an example embodiment of the invention, the dynamic signature in the received message may be stored in a “Dynamic tag” field or otherwise embedded in the field of the incoming message. The node/exchange entity may obtain the dynamic signature from the incoming message. As described above, the dynamic signature may include a dynamic code (e.g., DC) and a counter (e.g., COUNTER). According to an example embodiment of the invention, the dynamic signature may be of a predefined fixed length. In addition to obtaining the dynamic signature from the incoming message, the node/exchange entity may also retrieve the graylist profile such that: (1) the account of the graylist matches the static destination address of the incoming message, and (2) the graylist profile record 510 has a qualified static address 511 matching the static source address of the incoming message.
It will be also appreciated that at least a portion of the message, or its digest, may be concatenated in a parameter string of a hash function to generate and verify the dynamic code. This may prevent a spammer from replacing the body of the transmitting message but keeping the addresses in a “man-in-the-middle” (MITM) attack, according to an example embodiment of the invention.
According to an example embodiment, a pre-charge as described herein may have been required in order for a non-qualified sender to obtain a dynamic passcode from the dynamic passcode provider. As described herein, the pre-charge may be required if the pre-charge indicator associated with the recipient account has a value of “YES” or “1”. According to an example embodiment of the invention, the query pre-charge fee for the non-qualified sender may be refunded by default if the delivered message is not spam. According to another example embodiment of the invention, the recipient may need to provide an indicator to the recipient's node/exchange entity in order to release or refund the query pre-charge fee.
According to an example embodiment of the invention, a dynamic tag may be embedded in the destination account address of the message. As an example, the dynamic tag may be embedded in the destination email address in the field “To” and/or “Cc” of the email message to form a dynamic destination address, according to an example embodiment of the invention. With the use of a dynamic tag in a dynamic destination address, an MTA may be able to filter email spam sent by non-qualified senders from other MTAs that do not support dynamic tag but use other authentication technologies, such as DomainKeys, to sign the outgoing emails. According to an example embodiment of the invention, it may be appreciated that a recipient's MTA may be able to filter email spam immediately after it received “MAIL FROM” and “RCPT TO” commands from the sender if dynamic destination email address is utilized in “RCPT TO” command in Simple Mail Transfer Protocol or another similar protocol. In this case, the spam may be blocked before it is sent. While dynamic tag field approach must see at least the tag field, so the entire message must be transmitted.
In block 800 of FIG. 8, a qualified sender for a destination email account enters the static email address of the destination email account into the “To” or “Cc” destination field of the header of an outgoing email, according to an example embodiment of the invention. In other embodiments of the invention, the qualified sender may provide multiple destination email addresses within a single outgoing email addresses. In block 805, the qualified sender's client program that is in communication with the sender's MTA may provide the qualified sender's static email address in the “From” source field.
In block 810, the client program in communication with the qualified sender's MTA may determine if the sender identified by the “From” source field is a qualified sender with respect to one or more of the static destination email addresses in the outgoing email. As described herein, the sender may be a qualified sender to the static destination email address if (1) the static destination address matches one of the qualified static address attributes in a graylist profile record of the account owned by the sender; (2) the direction type of the matched graylist profile record includes a value of OUTGOING_QUALIFIED or MUTUAL_QUALIFIED; and (3) the matched graylist profile record is not expired. Upon passing the qualified sender checking, the sender's client program or MTA may automatically compute the dynamic signature for each destination email address, and embed the dynamic signature into the corresponding static destination email address.
In block 815, the sender's MTA may transmit the email with the dynamic destination email address. According to an example embodiment of the invention, the sender's MTA may transmit the email utilizing a “RCPT TO” command based on the original static destination email address embedded in the dynamic destination email address, or based on the newly generated dynamic destination email address. According to an example embodiment of the invention, after sending the outgoing email with the dynamic signature, the local index (e.g., LOCAL_INDEX) for each destination email address may be updated, perhaps by being increased by 1 or reset value. Furthermore, the local seed (e.g., LOCAL_SEED) for each destination email address may be updated if it recomputed by local chaining function, according to an example embodiment of the invention.
In block 900, a non-qualified sender may obtain the dynamic destination email address, including the dynamic passcode, of the destination account by querying a dynamic passcode provider (e.g., a Web site). In block 905, the dynamic destination email address may be entered in the “To” or “Cc” destination field of the email. In block 910, the static email address of the non-qualified sender may be entered in the “From” source field.
Still referring to FIG. 9, in block 915, the sender's MTA may send the mail, perhaps using a “RCPT TO” command, based on the original static destination email address embedded in the dynamic destination email address, or based on the dynamic destination email address. The recipient's MTA may receive the transmitted email. In block 920, the recipient's MTA may obtain the static destination email address embedded in the dynamic destination email address, and may select the corresponding destination email account. In block 925, the dynamic code (e.g., DC) and the counter (e.g., C) may be obtained from the dynamic passcode of the dynamic destination email address. In block 930, the system hashing function H at the recipient's MTA may be used to determine a first fixed-length verifier dynamic code VDC_KEY by hashing a first concatenated string that may include the following or variations thereof:
An email having more than one destination email addresses in its “To” and/or “Cc” destination header field may be referred to as a group email. A sender who generates the initial group email may be referred to as an originator, according to an example embodiment of the invention. According to an example embodiment of the invention, two extra header fields “Originator” and “Originator forward” may be added into the email header for conveniently replying the group emails by the group email recipients.
The “Originator” field may store the static email address of the originator, according to an example embodiment of the invention. The “Originator forward” field may store an indicator set by the group email recipients when they reply the group emails, according to an example embodiment of the invention. If the “Originator forward” field is set when a group email is replied, then the replying email may be sent only to the originator, and the dynamic tag for the originator may be needed, according to an example embodiment of the invention. When the originator accepts a replying group email with “Originator forward” field set, the MTA of the originator may automatically forward the replying group email to all others in “To” or “Cc” fields, except for the sender of the replying email, according to an example embodiment of the invention. Indeed, according to an example embodiment of the invention, this method may be useful when the originator is the qualified senders to all recipients in the group email, but these recipients may not qualified senders each other.
FIG. 10 illustrates an example flow diagram for sending, replying and forwarding a group email, according to an example embodiment of the invention. In FIG. 10, Ava may be a qualified sender to Bob, Christy, and Alice in term of their email accounts. However, Bob, Christy, and Alice may not be qualified senders to each other. Referring to FIG. 10, now Ava sends a group email to Bob, Christy, and Alice. The “Originator” field of the group email may include Ava's static email address ava@home.com, according to an example embodiment of the invention. The static destination email addresses include bob@city.com, Christy@county.com, and alice@state.com. The dynamic signatures may be added into the static destination email addresses if dynamic destination email address approach is adopted, according to an example embodiment of the invention According to another embodiment of the invention, the dynamic signatures may be stored at the extra field “Dynamic tag” of the email.
Still referring to FIG. 10, after receiving the group email with “Originator” ava@home.com, Christy may want to reply to all. In this situation, Christy may set the field “Originator forward” indicator, and reply to the group email. The MTA of Christy may send the email to originator ava@home.com only without querying the passcodes of Bob and Alice. Once the replied group email of Christy is received, the MTA of Ava may automatically forward the email to Bob and Alice with correct dynamic signatures, according to an example embodiment of the invention.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5787271 *Jun 26, 1996Jul 28, 1998Mci CorporationSpare capacity allocation toolUS5973696 *Aug 8, 1997Oct 26, 1999Agranat Systems, Inc.Embedded web serverUS6023723Dec 22, 1997Feb 8, 2000Accepted Marketing, Inc.Method and system for filtering unwanted junk e-mail utilizing a plurality of filtering mechanismsUS6266692Jan 4, 1999Jul 24, 2001International Business Machines CorporationMethod for blocking all unwanted e-mail (SPAM) using a header-based passwordUS6321267Nov 23, 1999Nov 20, 2001Escom CorporationMethod and apparatus for filtering junk emailUS6427234 *Jun 11, 1999Jul 30, 2002University Of WashingtonSystem and method for performing selective dynamic compilation using run-time informationUS6456308 *Nov 17, 2000Sep 24, 2002Agranat Systems, Inc.Embedded web serverUS6546416Dec 9, 1998Apr 8, 2003Infoseek CorporationMethod and system for selectively blocking delivery of bulk electronic mailUS6654787Dec 31, 1998Nov 25, 2003Brightmail, IncorporatedMethod and apparatus for filtering e-mailUS6732157Dec 13, 2002May 4, 2004Networks Associates Technology, Inc.Comprehensive anti-spam system, method, and computer program product for filtering unwanted e-mail messagesUS6957259Jun 25, 2001Oct 18, 2005Bellsouth Intellectual Property CorporationSystem and method for regulating emails by maintaining, updating and comparing the profile information for the email source to the target email statisticsUS6986049Sep 24, 2003Jan 10, 2006Yahoo! Inc.Method and system for authenticating a message sender using domain keysUS7054906Dec 29, 2000May 30, 2006Levosky Michael PSystem and method for controlling and organizing EmailUS7181498Mar 1, 2004Feb 20, 2007Yahoo! Inc.Community-based green list for antispamUS7237010Mar 18, 2004Jun 26, 2007International Business Machines CorporationMethod, system and computer program product for generating and processing a disposable email addressUS7240366May 17, 2002Jul 3, 2007Microsoft CorporationEnd-to-end authentication of session initiation protocol messages using certificatesUS7293065Nov 18, 2003Nov 6, 2007Return PathMethod of electronic message delivery with penalties for unsolicited messagesUS7406593 *May 2, 2003Jul 29, 2008Shieldip, Inc.Method and apparatus for protecting information and privacyUS20050086211 *Aug 9, 2004Apr 21, 2005Yaron MayerSystem and method for searching, finding and contacting dates on the Internet in instant messaging networks and/or in other methods that enable immediate finding and creating immediate contactUS20060248063 *Apr 18, 2006Nov 2, 2006Raz GordonSystem and method for efficiently tracking and dating content in very large dynamic document spacesUS20080040285 *Feb 16, 2007Feb 14, 2008John WankmuellerMethod And System For Authorizing A Transaction Using A Dynamic Authorization Code* Cited by examinerNon-Patent CitationsReference1Leyden, J., Spammers Embrace Email Authentication, The Register, Sep. 3, 2004, 2 Pages, http://www.theregister.co.uk/2004/09/03/email-authentication-spam/print.html.2Leyden, J., Spammers Embrace Email Authentication, The Register, Sep. 3, 2004, 2 Pages, http://www.theregister.co.uk/2004/09/03/email—authentication—spam/print.html.3Resnick, P., Internet Message Format, The Internet Society, Qualcom Incorporated, Apr. 2001, http://tools.ietf.org/html/rfc2822.4Session Initiation Protocol, Sep. 26, 2007, http://www.ietf.org/html.charters/sip-charter.html.5U.S. Department of Homeland Security, The Crimeware Landscape: Malware, Phishing, Identitiy Theft and Beyond, A Joint Report of the U.S. Department of Homeland Security-SRI International Identity Theft Technology Council and the Anti-Phishing Working Group, Oct. 2006, p. 1-31, http://www.antiphishing.org/reports/APWG-CrimewareReport.pdf.6U.S. Department of Homeland Security, The Crimeware Landscape: Malware, Phishing, Identitiy Theft and Beyond, A Joint Report of the U.S. Department of Homeland Security—SRI International Identity Theft Technology Council and the Anti-Phishing Working Group, Oct. 2006, p. 1-31, http://www.antiphishing.org/reports/APWG—CrimewareReport.pdf.7Webroot Spyware, Inc., State of Spyware Q2 2006: A review and analysis of the impact of spyware on consumers and corporations, 2006, 22 pages, http://www.antyspyware.com.pl/state-of-spyware/2006-q2-sos.pdf.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7882189 *Oct 29, 2007Feb 1, 2011Sonicwall, Inc.Using distinguishing properties to classify messagesUS8108477Jul 13, 2009Jan 31, 2012Sonicwall, Inc.Message classification using legitimate contact pointsUS8112486Sep 20, 2007Feb 7, 2012Sonicwall, Inc.Signature generation using message summariesUS8266215Sep 11, 2012Sonicwall, Inc.Using distinguishing properties to classify messagesUS8271603Jun 16, 2006Sep 18, 2012Sonicwall, Inc.Diminishing false positive classifications of unsolicited electronic-mailUS8325900Sep 26, 2011Dec 4, 2012Google Inc.Telephone call classification utilizing a social network graphUS8392514 *Mar 4, 2009Mar 5, 2013Dion EmamiVCC software enhancement systemUS8463861Jan 30, 2012Jun 11, 2013Sonicwall, Inc.Message classification using legitimate contact pointsUS8484301 *Jan 27, 2011Jul 9, 2013Sonicwall, Inc.Using distinguishing properties to classify messagesUS8688794Jan 30, 2012Apr 1, 2014Sonicwall, Inc.Signature generation using message summariesUS8935348Jun 8, 2013Jan 13, 2015Sonicwall, Inc.Message classification using legitimate contact pointsUS9088532 *Jan 18, 2013Jul 21, 2015Twitter, Inc.Device independent message distribution platformUS9189516 *Jun 6, 2013Nov 17, 2015Dell Software Inc.Using distinguishing properties to classify messagesUS20040167968 *Feb 20, 2003Aug 26, 2004Mailfrontier, Inc.Using distinguishing properties to classify messagesUS20060235934 *Jun 16, 2006Oct 19, 2006Mailfrontier, Inc.Diminishing false positive classifications of unsolicited electronic-mailUS20080021969 *Sep 20, 2007Jan 24, 2008Sonicwall, Inc.Signature generation using message summariesUS20080104184 *Oct 29, 2007May 1, 2008Mailfrontier, Inc.Using Distinguishing Properties to Classify MessagesUS20100228828 *Sep 9, 2010Dion EmamiVcc software enhancement systemUS20110184976 *Jul 28, 2011Wilson Brian KUsing Distinguishing Properties to Classify MessagesUS20130117396 *Dec 24, 2012May 9, 2013Hoshiko LlcMessage filtering methods and systemsUS20130275463 *Jun 6, 2013Oct 17, 2013Sonicwall, Inc.Using distinguishing properties to classify messages* Cited by examinerClassifications U.S. Classification709/206, 709/224, 713/150, 715/760, 709/227International ClassificationG06F15/16, G06F3/00Cooperative ClassificationH04L51/12, H04L9/3236, H04M2215/7826, H04L9/0891, H04L12/585, G06Q10/107, H04M15/8221, H04M15/47, H04L2209/38, H04M2215/0148, H04M15/8088, H04L2209/80European ClassificationG06Q10/107, H04M15/82D, H04M15/47, H04M15/80M, H04L9/08T, H04L51/12, H04L9/32L, H04L12/58FLegal EventsDateCodeEventDescriptionNov 4, 2013FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services