Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20080120378 A2
Publication typeApplication
Application numberUS 10/447,593
Publication dateMay 22, 2008
Filing dateMay 29, 2003
Priority dateMay 29, 2003
Also published asUS7657599, US20040243678
Publication number10447593, 447593, US 2008/0120378 A2, US 2008/120378 A2, US 20080120378 A2, US 20080120378A2, US 2008120378 A2, US 2008120378A2, US-A2-20080120378, US-A2-2008120378, US2008/0120378A2, US2008/120378A2, US20080120378 A2, US20080120378A2, US2008120378 A2, US2008120378A2
InventorsSteven Smith
Original AssigneeMindshare Design, Inc.
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Systems and Methods for Automatically Updating Electronic Mail Access Lists
US 20080120378 A2
Abstract
A system and method for permitting a sender to provide electronic mail (email) to a recipient, said method comprising providing a recipient email address to the sender; requesting of the recipient that the sender be allowed to send email to the recipient; determining whether the request is acceptable based on at least one of: 1) a sender identity verification method; 2) user input; and 3) third party information; adding the sender to an email access list if the request is acceptable; and wherein the email access is used to determine whether or not email from the sender is permitted to reach the recipient.
Images(7)
Previous page
Next page
Claims(63)
1. A method for permitting a sender to provide electronic mail (email) to a recipient, said method comprising:
providing a recipient email address to the sender;
requesting of the recipient that the sender be allowed to send email to the recipient;
determining whether the request is acceptable based on at least one of: 1) a sender identity verification method; 2) user input; and 3) third party information;
adding the sender to an email access list if the request is acceptable; and
wherein the email access is used to determine whether or not email from the sender is permitted to reach the recipient.
2. The method of claim 1, further comprising:
providing confirmation of the determination to the sender if the sender requested such confirmation.
3. The method of claim 1 wherein:
the step of providing the recipient email address to the sender is a result of a Web-based interaction between the recipient and the sender.
4. The method of claim 1 wherein:
the sender identity verification method can be used by the recipient to verify that an email message is from the sender.
5. The method of claim 1 wherein:
the sender identity verification method is one of: 1) an email header “From” address; 2) a password; 3) an Internet Protocol (IP) address; and 4) a digital signature.
6. The method of claim 1 wherein:
the request is provided to a Web browser.
7. The method of claim 6 wherein:
the Web browser can identify the request based on a Multipurpose Internet Mail Extension (MIME) type.
8. The method of claim 1 wherein:
the step of determining whether a request is acceptable utilizes at least one rule, wherein the at least one rule is evaluated against the request.
9. The method of claim 1, further comprising:
prompting a user for a decision regarding whether or not to accept the request.
10. A method for permitting a sender to provide electronic mail (email) to a recipient, said method comprising:
providing a recipient email address to the sender;
providing a petition to the recipient, wherein the petition includes a sender identity verification method;
determining whether the petition is acceptable based on at least one of: 1) the sender identity verification method; 2) user input; and 3) third party information; and
adding the sender to an email access list if the petition is acceptable; and
wherein the email access list is used to determine whether or not email from the sender is permitted to reach the recipient.
11. The method of claim 10, further comprising:
providing confirmation of the determination to the sender if the sender requested such confirmation.
12. The method of claim 10 wherein:
the step of providing the recipient email address to the sender is a result of a Web-based interaction between the recipient and the sender.
13. The method of claim 10 wherein:
the sender identity verification method can be used by the recipient to verify that an email message is from the sender.
14. The method of claim 10 wherein:
the identity verification method is one of: 1) an email header “From” address; 2) a password; 3) an Internet Protocol (IP) address; and 4) a digital signature.
15. The method of claim 10 wherein:
the petition is provided to a Web browser.
16. The method of claim 15 wherein:
the Web browser can identify the petition based on a Multipurpose Internet Mail Extension (MIME) type.
17. The method of claim 10 wherein:
the step of determining whether a petition is acceptable utilizes at least one rule, wherein the at least one rule is evaluated against the petition.
18. The method of claim 10, further comprising:
prompting a user for a decision regarding whether or not to accept the petition.
19. A method for adding a sender to an electronic mail (email) access list for a recipient, said method comprising:
providing a recipient identifier to the sender;
providing a petition to the recipient;
determining whether to add the sender to the access list based on at least one of: 1) user input; 2) the petition; and 3) third party information; and
adding the sender to the access list if it was so determined.
20. The method of claim 19, further comprising:
providing confirmation of the determination to the sender if the sender requested such.
21. The method of claim 19 wherein:
the recipient identifier is an email address of the recipient.
22. The method of claim 19 wherein:
the petition includes a sender identity verification method.
23. The method of claim 20 wherein:
the identification method is one of: 1) an email header “From” address; 2) a password; 3) an Internet Protocol (IP) address; and 4) a digital signature.
24. The method of claim 19 wherein:
the petition is provided to a Web browser.
25. The method of claim 24 wherein:
the Web browser can identify the petition based on a Multipurpose Internet Mail Extension (MIME) type.
26. The method of claim 19 wherein:
the step of providing the identifier to the sender is a result of a Web-based interaction between the recipient and the sender.
27. The method of claim 19 wherein:
the step of determining whether to add the sender to the access list utilizes at least one rule, wherein the at least one rule is evaluated against the petition.
28. The method of claim 19, further comprising:
prompting a user for a decision regarding whether or not to add the sender to the access list.
29. A method for accepting a communication from a sender, comprising:
determining if the communication includes an acceptable method to verify that an electronic mail (email) message is from the sender;
determining if the sender is already on an email access list;
determining whether to place the sender on the access list based on at least one of: 1) user input; 2) a sender identity verification method included in the communication; and 3) third party information; and
adding the sender to the access list if it was so determined.
30. The method of claim 29, further comprising:
providing confirmation to the sender of the determination of whether to place the sender on the email access list if the communication indicated such confirmation was required.
31. The method of claim 29, further comprising:
prompting a user for a decision regarding whether to add the sender to the access list, wherein the prompting can be based on user preferences.
32. The method of claim 29, wherein:
the step of determining whether to place the sender on the access list is based on the evaluation of at least one rule.
33. The method of claim 32 wherein:
the at least one rule can be specified in a natural language.
34. The method of claim 29 wherein:
the step of determining whether the communication includes an acceptable identity verification method is based on evaluation of at least one rule.
35. The method of claim 29 wherein:
the third party information includes whether or not the sender is trusted.
36. A system comprising:
means for providing a recipient email address to the sender;
means for requesting of the recipient that the sender be allowed to send email to the recipient;
means for determining whether the request is acceptable based on at least one of: 1) a sender identity verification method; 2) user input; and 3) third party information; and
means for adding the sender to an email access list if the request is acceptable; and
wherein the email access is used to determine whether or not email from the sender is permitted to reach the recipient.
37. A system for adding a sender to an electronic mail (email) access list for a recipient, said system comprising:
the recipient including:
a petition processor to accept a petition and maintain an access list based on the petition;
a browser to accept the petition from the sender and automatically provide the petition to the petition processor; and
wherein the access list determines if the sender is permitted to provide email to the recipient;
the sender including:
a server; and
a petition generator coupled to the server, the petition generator to produce a petition.
38. The system of claim 37 wherein:
the petition processor can provide a confirmation to the sender.
39. The system of claim 37 wherein:
the petition processor executes on a first computing device;
the access list is maintained on a second computing device; and
wherein the first computing device and the second computing device are not the same.
40. The system of claim 37 wherein:
the access list is accessible to the petition processor through a remote mail provider that is distinct from the recipient.
41. The system of claim 37 wherein:
the petition includes a sender identity verification method that can be used by the recipient to verify that an email message is from the sender.
42. The system of claim 41 wherein:
the sender identification method is one of: 1) an email header “From” address; 2) a password; 3) an Internet Protocol (IP) address; and 4) a digital signature.
43. The system of claim 37 wherein:
the browser can identify the petition based on a Multipurpose Internet Mail Extension (MIME) type.
44. The system of claim 37 wherein:
the petition processor determines whether or not to accept a petition and add the sender to the email access list of the recipient.
45. The system of claim 44 wherein:
such determination is based on at least one of: 1) input from a user; 2) a sender identity verification method included in the petition; and 3) third party information.
46. The system of claim 37 wherein:
the server provides the petition to the browser.
47. A system for adding a sender to an electronic mail (email) access list for a mail provider wherein the mail provider is accessed by a recipient, said system comprising:
the recipient including:
a browser to accept a petition from the sender;
the mail provider including:
a petition processor to accept the petition and maintain an access list based on the petition; and
wherein the access list determines if the sender is permitted to provide email to the recipient;
the sender including:
a server; and
a petition generator, wherein the petition generator can produce a petition.
48. The system of claim 47, further comprising:
an email proxy coupled to the browser, the proxy to accept the petition from the browser and provide the petition to the mail provider;
49. The system of claim 47 wherein:
the petition processor can provide a confirmation to the sender.
50. The system of claim 47 wherein:
the petition processor executes on a first computing device;
the access list is maintained on a second computing device; and
wherein the first computing device and the second computing device are not the same.
51. The system of claim 47 wherein:
the petition includes a sender identity verification method that can be used by the recipient to verify that an email message is from the sender.
52. The system of claim 51 wherein:
the sender identification method is one of: 1) an email header “From” address; 2) a password; 3) an Internet Protocol (IP) address; and 4) a digital signature.
53. The system of claim 47 wherein:
the browser can identify the petition based on a Multipurpose Internet Mail Extension (MIME) type.
54. The system of claim 47 wherein:
the petition processor determines whether or not to accept a petition and add the sender to the email access list.
55. The system of claim 54 wherein:
such determination is based on at least one of: 1) input from a user; 2) a sender identity verification method included in the petition; and 3) third party information.
56. The system of claim 47 wherein:
the server provides the petition to the browser.
57. A memory for storing data for access by an application program being executed on a computing device, comprising:
an email recipient identifier stored in the memory;
an email sender identifier stored in the memory;
an email sender identification method stored in the memory; and
wherein the sender identification method can be used to verify that email is from the sender.
58. The memory of claim 57, further comprising:
at least one additional sender identification method stored in the memory.
59. The memory of claim 57 wherein:
the recipient identifier is an electronic mail (email) address.
60. The memory of claim 57 wherein:
the sender identification method is one of: 1) an email header “From” address; 2) a password; 3) an Internet Protocol (IP) address; and 4) a digital signature.
61. A machine readable medium having instructions stored thereon that when executed by a processor cause a system to:
provide a recipient electronic mail (email) address to the sender;
request of the recipient that the sender be allowed to send email to the recipient;
determine whether the request is acceptable based on at least one of: 1) a sender identity verification method; 2) user input; and 3) third party information; and
add the sender to an email access list if the request is acceptable; and
wherein the email access is used to determine whether or not email from the sender is permitted to reach the recipient.
62. A computer data signal embodied in a transmission medium, comprising:
a code segment including instructions to provide a recipient electronic mail (email) address to a sender;
a code segment including instructions to provide a petition to the recipient, wherein the petition includes a sender identification method, wherein the identification method can be used by the recipient to verify that an email message is from the sender;
a code segment including instructions to determine if the petition is acceptable based on at least one of: 1) sender credentials; 2) user input; and 3) third party information;
a code segment including instructions to add the sender to an email access list if the petition is acceptable; and
wherein the email access is used to determine whether or not email from the sender is permitted to reach the recipient.
63. A method for generating a request that can be used to determine if a sender should be added to a recipient email access list:
including at least one sender identification method in the request, wherein the identification method is at least one of: 1) an email header “From” address; 2) a password; 3) an Internet Protocol (IP) address; and 4) a digital signature.
including a sender name in the request;
including a recipient name in the request;
providing the request to a processing that will make a determination of whether the sender should be added to the email access list.
Description
  • [0001]
    This application is related to the following co-pending applications which are hereby incorporated by reference in their entirety: SYSTEMS AND METHODS FOR AUTOMATICALLY UPDATING ELECTRONIC MAIL ACCESS LISTS, U.S. application Ser. No. 10/619,726, Inventors: Steven J. Smith et al., filed on Jul. 15, 2003. (Attorney's Docket No. MNDSH-1004US0); SYSTEMS AND METHODS FOR AUTOMATICALLY UPDATING ELECTRONIC MAIL ACCESS LISTS, U.S. application Ser. No. 10/721,044, Inventors: Steven J. Smith et al., filed on Nov. 21, 2003. (Attorney's Docket No. MNDSH-1006US0).
  • COPYRIGHT NOTICE
  • [0002]
    A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
  • FIELD OF THE DISCLOSURE
  • [0003]
    The present disclosure relates to systems and methods for automatically updating electronic mail access lists.
  • BACKGROUND
  • [0004]
    Electronic mail (email) addresses are commonly provided by customers when interacting with a company's website. For example, customers often use their email address to serve as their login name, to receive an electronic receipt of a purchase, shipping updates, promotional materials and newsletter subscriptions. As is often the case, however, a customer's email address can fall into the hands of third party organizations that use it to deliver unsolicited email, or “spam”.
  • [0005]
    Internet service providers (ISPs), email service providers (ESPs), and email software companies are employing various strategies to restrict and/or filter incoming email with the aim of reducing the amount of spam received by recipients. A side effect of such strategies is that legitimate email is often discarded, blocked or incorrectly deposited in “bulk mail” folders. As such, some solutions which block and/or filter email enable recipients to specify specific email senders that are allowed to bypass these protections. Such lists of explicitly enabled senders are often called “whitelists”. Likewise, it is common to allow recipients to specify “blacklists”—lists of individual senders prohibited from sending email to the recipient. Email coming from blacklisted senders is automatically blocked, filtered, or restricted accordingly.
  • [0006]
    Manually maintaining whitelists and blacklists can represent a significant inconvenience on the recipient's part. Some systems require the recipient to separately open an application which manages their access lists and manually specify the sender's email address. Another approach requires that the recipient open the application which manages his or her access list and generate a special, unique tracking email address which circumvents the normal challenge/response mechanism. Some so-called “challenge/response” solutions put the burden of maintaining a recipient's whitelist on the senders themselves, by requiring previously unknown senders to authenticate themselves by responding to a “challenge” question designed to be only practically answerable by a human sender. Upon correctly answering the “challenge” question, the sender is deemed to be legitimate (by virtue of being a human sender rather than an automated system), and is added to the recipient's whitelist. However, this process will unwittingly filter out legitimate email that happens to have been sent by a mail program rather than by a person. From either the recipient's or the sender's perspective, a more convenient approach to managing email access lists is desired.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0007]
    FIG. 1 is a system diagram illustrating one embodiment.
  • [0008]
    FIG. 2 is a flow chart illustrating petition generation in one embodiment.
  • [0009]
    FIG. 3 is a flow chart illustrating petition processing in one embodiment.
  • [0010]
    FIG. 4 is system diagram of an embodiment including a remote mail provider.
  • [0011]
    FIG. 5 is system diagram of an embodiment including a remote mail provider.
  • [0012]
    FIG. 6 is system diagram of an embodiment including a remote mail provider.
  • DETAILED DESCRIPTION
  • [0013]
    The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
  • [0014]
    In the following description, various aspects of the present invention will be described. However, it will be apparent to those skilled in the art that the present invention may be practiced with only some or all aspects of the present invention. For purposes of explanation, specific numbers, materials and configurations are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the present invention.
  • [0015]
    FIG. 1 is a block diagram illustrating an embodiment of the present invention. Although this diagram depicts objects as functionally separate, such depiction is merely for illustrative purposes. It will be apparent to those skilled in the art that the objects portrayed in this figure can be arbitrarily combined or divided into separate software, firmware or hardware components. Furthermore, it will also be apparent to those skilled in the art that such objects, regardless of how they are combined or divided, can execute on the same computing device or can be arbitrarily distributed among different computing devices connected by one or more networks.
  • [0016]
    Referring to FIG. 1., sender 100 includes server 104, access list petition generator 106 and petition information 108. By way of a non-limiting example, petition information (and any other information) can be stored and accessed through a number of means including but not limited to relational databases, digital files, random access memory, read-only memory, caches, and look-up tables. By way of a non-limiting example, the server can be a web server and/or application server. The server can accept HTTP (Hypertext Transfer Protocol) requests from various recipients and can provide Web pages 110 (e.g., files containing Hypertext Markup Language and possibly other information) in response. The petition generator can create an access list petition request (or “petition”) and provide it to a recipient. In one embodiment, a petition can be used by the recipient for, among other things, to add the sender to the recipient's whitelist. The petition generator can utilize data from the petition information, the server, web pages and/or other sources to create a petition. In one embodiment, petition information can include descriptive information about the sender including identification information. Although the present disclosure is not limited by or restricted to any particular implementation, in one embodiment the petition generator logic can be incorporated partially or entirely into the server or into a web page (e.g., via JavaServer Pages™, available from Sun Microsystems, Inc. of Mountain View, Calif.).
  • [0017]
    Recipient 102 can include Web browser 112, petition processor 114, access list information 116, and user preferences information 118. The browser can display web pages provided by the server. In one embodiment, the browser is Microsoft Internet Explorer, available from Microsoft Corp. of Redmond, Wash. The petition processor processes petitions produced by the petition generator. In one embodiment, a petition is provided to the web browser, which then provides it to the petition processor. In processing the petition, the petition processor can utilize the access list, user preferences information and other information pertaining to security settings/polices for an email client or email provider. The access list information can include one or more whitelists and/or one or more blacklists. User preferences can include security polices and run-time settings that dictate how the petition processor operates. In one embodiment, the petition processor can be incorporated partially or entirely into an email client program (not shown) such as Microsoft Outlook™, available from Microsoft Corp. of Redmond, Wash. In another embodiment, the petition processor can be incorporated into a challenge/response mechanism (not shown) such as “Mailblocks”, available from Mailblocks, Inc. of Los Altos, Calif. It is important to note, however, that the present disclosure is not limited to any particular email client program, challenge/response mechanism, or any other type of mail program and/or spam filter. Furthermore, the present disclosure is not limited to any particular email protocol or email address format.
  • [0018]
    The recipient and the sender may reside on the same computing device or on different computing devices. By way of a non-limiting example, a computing device can include a personal computer, portable computer, personal digital assistant, mobile phone, wearable digital device, wrist watch, digital music player and a mainframe computer. Recipients and senders can communicate over communication link 120. In one embodiment the communication link may include one or more networks (e.g., the Internet, Wide Area Network, Local Area Network, wireless network, and satellite network). In another embodiment, the communication link can be realized as shared memory (e.g., random access memory and read-only memory), a shared object/data structure, a file system, a distributed object (e.g., a JavaBean, CORBA object, .Net Object, and a Web service), and/or an inter-processor data conduit in a multi-processor (e.g., parallel) computer. In another embodiment, the communication link can be based on any combination of the above embodiments. Although this disclosure is not limited by or restricted to using a particular communication protocol, one embodiment allows the recipient and the sender to communicate using HTTP over the Internet.
  • [0019]
    FIG. 2 is a flow chart illustrating petition generation in one embodiment. Although this figure depicts functional steps in a particular order for purposes of illustration, the process is not limited to any particular order or arrangement of steps. One skilled in the art will appreciate that the various steps portrayed in this figure could be omitted, rearranged, combined and/or adapted in various ways.
  • [0020]
    A sender can utilize a petition generator to create a petition that will (potentially) allow the sender to add itself to a recipient's whitelist. In one embodiment, this can happen as a result of receiving the recipient's email address. By way of a non-limiting example, the recipient's email address can be obtained by the sender in conjunction with a Web-based purchase (i.e., a purchased transacted over the World Wide Web), a newsletter subscription, etc. In Step 200, the petition generator uses the recipient's email address in concert with data drawn from the petition information to produce a petition. Petition information can include the sender's descriptive information (e.g., name, description, address, etc.), identification methods and confirmation information. These will be discussed below. The petition information can also keep track of whether or not a particular recipient has added the sender to their whitelist (e.g., whether or not a petition was accepted by a given recipient). In such a case, the sender need not generate a petition.
  • [0021]
    For discussion purposes, a petition will be illustrated as plain text. However, the present disclosure is not limited by or restricted to any particular representation. Suitable representations include but are not limited to, plain text, XML (eXtensible Markup Language), binary data, encrypted data, and/or any combination of these. In one embodiment, a petition can include lines of text wherein each line includes an element name and one or more associated values. The format of petition data is flexible and extensible. Minimally, it can consist of the recipient's email address, the sender's name, and the sender's identification method and/or credentials. By way of a non-limiting example, such a petition might appear as follows (wherein colons separate elements from corresponding values):
  • [0022]
    Recipient: steve@xyzcompany.com
  • [0023]
    Sender: City Tribune Newspaper
  • [0024]
    Identification: from-address newsletter@citytribunepaper.com
  • [0025]
    In this example, the recipient element has email address “steve@xyzcompany.com” as its value. This element specifies the email address that the sender is petitioning for permission to use. The sender element identifiers the sender as “City Tribune Newspaper”. In one embodiment, a petition can contain a plurality of sender elements. By way of a non-limiting example, such a situation may arise if a sender is petitioning for inclusion on the recipient's whitelist on behalf of itself and other senders.
  • [0026]
    A recipient may require that a sender support one or more sender identification methods which are used by the recipient to verify that an email message is from the given sender. Senders tell the recipient which methods they support through the identification element. In the above example, the identification method is “from-address”That is, email from City Tribune Newspaper is verified when the email header “From” address equals “newsletter@citytribunepaper.com”. This is a simple but potentially inadequate method for identifying senders since the “From” address is easily forged. But the present invention is not limited by or restricted to any particular identification method. As new and improved identification methods are developed, they can be included in the petition without impairing the operation of existing verification methods.
  • [0027]
    By way of a non-limiting example, consider the following petition:
  • [0028]
    Recipient: steve@xyzcompany.com
  • [0029]
    Sender: City Tribune Newspaper
  • [0030]
    Identification: from-address newsletter@citytribunepaper.com
  • [0031]
    Identification: header-password 294305828
  • [0032]
    Identification: IP-address 192.168.5.0 255.255.255.0
  • [0033]
    Identification: public-key F349SBF28ZKFWO
  • [0034]
    In this example, the sender has specified four identification methods. The first method (“from-address”) was discussed above. The “header-password” method specifies a password (“294305828”) that the sender will include with the header portion of an email message sent to the recipient. In one embodiment, the password can be assigned to the sender by the recipient and provided to the recipient via a confirmation (see below). Another way to identify a sender is by its Internet Protocol (IP) address. The “IP-address” identification method allows a sender to specify an IP address and subnet mask address which identifies a range of source IP addresses from which it will send mail to the recipient. A more secure identification method than those already discussed is the use of public-key encryption technology to digitally “sign” an email message. The “public-key” identification method allows a sender to specify a public key (“F349SBF28ZKFWO”) which can be used by the recipient to decrypt a digital signature accompanying the sender's email. By way of a non-limiting example, if the value of the decrypted signature equals the value of the email header produced by a message digest algorithm, the sender's identity is verified.
  • [0035]
    Additional petition elements are possible since the format of a petition is flexible and naturally extensible. Such elements can include sender contact information (e.g., postal address, telephone number, Web page address, etc.), the sender's business category (e.g., retail, non-profit organization, entertainment, etc.), the nature of the sender's email (e.g., newsletter, promotions, transaction receipts, shipping updates, etc.), a description of the sender, and instructions to the recipient regarding confirmation of the outcome of the petition. By way of a non-limiting example, consider the following petition:
  • [0036]
    Recipient: steve@xyzcompany.com
  • [0037]
    Sender: City Tribune Newspaper
  • [0038]
    Identification: from-address newsletter@citytribunepaper.com
  • [0039]
    Identification: header-password 294305828
  • [0040]
    Identification: IP-address 192.168.5.0 255.255.255.0
  • [0041]
    Identification: public-key F349SDF28ZKFWO==
  • [0042]
    Description: Daily email version of the City Tribune newspaper
  • [0043]
    Sender-category: Media
  • [0044]
    Sender-email-category: newsletter
  • [0045]
    Petition-success: URL http://wwwwwww
  • [0046]
    Petition-denied: URL http://xxxxxxx
  • [0047]
    Petition-success: URL http://yyyyyy
  • [0048]
    Petition-denied: URL http://zzzzzz
  • [0049]
    In this example, the sender has included a description of itself in the petition (“Daily email version of the City Tribune newspaper”). The sender has also specified that its business category is “Media” and that the nature of its email to the sender is “newsletter”. In one embodiment, if a recipient accepts a sender's identification method(s), then the recipient implicitly trusts that the sender is not misusing the Sender-category and Sender-email-category elements in order to increase the likelihood that the sender will be added to the recipient's email access list. The petition may also optionally include instructions for the petition processor to communicate a confirmation of the outcome of the petition (e.g., whether the sender was added to the recipient's whitelist or not) back to the petition generator so that the recipient's email address may be appropriately dealt with by the sender. A sender, by way of a non-limiting example, may wish to disallow finalization of registration on its website in cases where the recipient does not accept the sender's petition. The instructions for confirmation can include the method for confirmation of the outcome and details of how to execute the confirmation. The petition format is extensible such that new methods may be used as they are made available. In addition, the petition format also allows multiple confirmation methods to be specified for the same sender, allowing for backward-compatibility as new confirmations methods are deployed.
  • [0050]
    In one embodiment, a confirmation method allows the recipient to access a URL (Uniform Resource Locator) on the sender's server which has been pre-configured by the sender to affect the desired action for the given result. In the example above, the sender has specified two pairs of confirmation methods:
  • [0051]
    Petition-success: URL http://wwwwwww
  • [0052]
    Petition-denied: URL http://xxxxxxx
  • [0053]
    Petition-success: URL http://yyyyyy
  • [0054]
    Petition-denied: URL http://zzzzzz
  • [0055]
    Each pair specifies a URL for the recipient to access upon acceptance of the petition (“Petition-success”) and rejection of the petition (“Petition-denied”). In the case where the petition is accepted, the recipient will access URLs http://wwwwwww” and “http://yyyyyy”. In the case where the petition is rejected, the recipient will access URLs “http://xxxxxxx” and “http://zzzzzz”.
  • [0056]
    The petition processor may be configured to not honor some or all requests for confirmation, based on user preferences, security policies determined by an email client provider or an email service provider, or due to programming simplifications in the design of the petition processor.
  • [0057]
    The present disclosure is not limited by or restricted to any particular confirmation method. As new confirmation techniques are developed, they can be integrated into petitions using the Petition-success and Petition-denied elements while maintaining backwards compatibility with existing confirmation methods.
  • [0058]
    Referring again to FIG. 2., in Step 202 the petition generator automatically provides the petition to the recipient. In one embodiment, the petition generator provides the petition to the server. The server tags the petition data with a specially designated MIME (Multi-purpose Internet Mail Extension) type and sends it to the recipient web browser via the HTTP protocol. The browser can be configured to associate the specially designated MIME type with the petition processor. This association can be configured upon installation of the petition processor so as to not require additional manual configuration by the recipient. Upon receipt of a petition, the web browser automatically provides it to the petition processor. The web browser can also automatically launch the petition processor if it is not already running. In another embodiment, the petition processor can be configured as a web browser “plug-in”.
  • [0059]
    In another embodiment, the petition can be associated with an object, such as an image in the web page provided to the browser by the server. The web page can include JavaScript (or other code) which, when executed by the browser, can determine if the recipient's browser supports the specially-designated MIME type. If not, the JavaScript can prevent the image from being rendered. Otherwise, the image can be rendered and the petition data associated with it provided to the petition processor. In another embodiment, the petition can be requested as a result of a redirection of an initial confirmation page to a new URL. One method of accomplishing such a redirection is by using the “meta” HTML tag:
    <meta HTTP-EQUIV=“refresh”
    CONTENT=“5;URL=http://www.sendersite.com/cgi-bin/petreq.pl”>
  • [0060]
    In a further embodiment, the petition may be sent as an additional URL specified in a separate frame in an HTML page, or in a separate window.
  • [0061]
    Step 204 determines whether the sender will receive confirmation of the petition from the recipient. If the petition generator did not include conformation instructions (see Step 200) in the petition, the process concludes. Otherwise, confirmation of the success or denial of the petition by the recipient can be automatically provided to the sender in Step 206 if the petition processor chooses to do so. In one embodiment, if confirmation was requested by the sender but never received, the sender can assume that the petition was denied by the recipient.
  • [0062]
    FIG. 3 is a flow chart illustrating petition processing in one embodiment. Although this figure depicts functional steps in a particular order for purposes of illustration, the process is not limited to any particular order or arrangement of steps. One skilled in the art will appreciate that the various steps portrayed in the figure could be omitted, rearranged and/or adapted in various ways.
  • [0063]
    In Step 300, a determination is made as to whether there are acceptable identification method(s) in the petition. The user preferences information can specify the identification method(s) that are required of potential senders. In one embodiment, the required identification method(s) can be articulated as an expression that is evaluated dynamically against elements and values in the petition. By way of a non-limiting example:
    (from-address AND header-password AND IP-address) OR (from-
    address AND public-key).
  • [0064]
    The identification method expression above declares that a petition must support either from-address, header-password, and IP-address, or from-address and public-key identification methods. This feature allows a flexible approach to identity verification. In another embodiment, the user preferences information can include rules that can be used to dynamically determine the identification methods required based on information in the petition. In one embodiment, rules can be specified in a natural language.
  • [0065]
    If the petition does not support the required identification method(s), the petition is denied in Step 316. Next, in Step 318 it is determined whether or not the sender requires a confirmation. If confirmation is required, it is provided in Step 320. Otherwise, processing concludes.
  • [0066]
    In Step 302, a determination is made regarding whether or not the sender (as identified by an acceptable identification method) is already on an email access list. If this is the case, no action will be taken. Processing continues at Step 318 which determines whether or not the sender requires confirmation. If confirmation is required, it is provided in Step 320 according to the instructions in the petition.
  • [0067]
    In one embodiment, if the sender is not currently on an access list, the recipient end-user can be prompted for input regarding whether to grant access to the sender based upon the petition. In one embodiment, the prompt can allow the end-user to choose whether to add the sender to a whitelist, a blacklist or to simply deny the petition. In another embodiment, the prompt can allow the user to discover if the sender is listed in a third party registry of trusted senders. User preferences and/or security policies determined by the email client vendor or email service provider can specify whether the end-user should always be prompted, never be promoted, or only prompted sometimes (based on rules that are dynamically evaluated against information in the petition). In one embodiment, rules can be specified in a natural language. By way of a non-limiting example, consider the following rule:
    if (Sender not equal “Amazon.com” OR
    Identification = from-address) then
    prompt user.
  • [0068]
    This rule states that if the Sender is not Amazon.com or the sender's identification method is only “from-address”, then the recipient end-user will be prompted as to what action to take.
  • [0069]
    If the sender is not already on an access list, processing continues at Step 304. Step 304 determines based on user preferences whether or not to consult one or more third-party registries of trusted senders. In one embodiment, a third party registry can be provided by TRUSTe of San Francisco, Calif. This information may either be provided to the recipient end-user for consideration when determining whether to grant access, or used by the petition processor directly to automatically make access granting decisions without recipient consultation. In one embodiment, this behavior can be configured as a user preference. User preferences and/or security policies determined by the email client vendor or email service provider can specify whether third-party registries should always, never or sometimes be consulted (based on rules that are dynamically evaluated against information in the petition). In one embodiment, rules can be specified in a natural language. By way of a non-limiting example, consider the following rule:
    if (Identification = public-key) AND
    (Sender in registry (“TRUSTe”)) then
    add sender to whitelist.
    else
    Prompt_ser;
  • [0070]
    This rule states that if the sender is identified with a public key and the sender is contained in the “TRUSTe” third party registry, the sender can be added to the whitelist without prompting, otherwise the recipient should be prompted to make the determination of how the sender should be handled. If such registries are to be consulted, this can take place in Step 306. Otherwise, processing continues at Step 308.
  • [0071]
    Step 308 determines the level of access that will be provided to the sender based on the information in the petition, any end-user input, and any input from third party registries. If in response to a prompt, the end-user specified that the sender should be included on the whitelist, such is accomplished in Step 310. If in response to a prompt, the end-user specified that the sender should be included on the blacklist, such is accomplished in Step 312. If in response to a prompt, the end-user specified that the petition should simply be denied, this is accomplished in Step 316. If there was no end-user input, rules in the user preferences information can be consulted regarding what action to take. These so-called action rules can be dynamically evaluated against the results of consulting third-party registries and the information contained in the petition. In one embodiment, rules can be specified in natural language. By way of a non-limiting example, consider the following four rules:
      • (1) If (Sender-category=pornography) then add sender to blacklist.
      • (2) If (Sender identification method=public-key) and Sender in third-party registry, then add Sender to whitelist.
      • (3) If (Sender in third-party known spammer list) then add sender to blacklist.
      • (4) Default: Prompt_user;
  • [0076]
    In the above example, rule (1) specifies that if the sender category is pornography, automatically add the sender to the blacklist regardless of any other information in the petition. Rule (2) specifies that if the sender is identified by public-key encryption and is in a third-party registry of trusted senders, add the sender to the whitelist. Rule (3) specifies that if the sender is in a third-party list of known spammers, add the sender to the black list. Finally, a default rule (4) specifies that if no other rule applies, prompt the user to determine how to handle the petition.
  • [0077]
    Processing continues at Step 318 which determines whether or not the sender requires confirmation. If confirmation is required and the petition processor chooses to allow it, it is provided in Step 320 according to the instructions in the petition.
  • [0078]
    Web-based email providers, such as Hotmail (http://www.hotmail.com) or Yahoo (http://www.yahoo.com) introduce an environment where a recipient's access lists are located on the remote systems of the web mail provider rather than on the recipient. As such, a petition processor on the recipient will need to read and modify access information on the mail provider. This situation is addressed by the system of FIG. 4.
  • [0079]
    FIG. 4 is system diagram of an embodiment including a remote mail provider. Although this diagram depicts objects as functionally separate, such depiction is merely for illustrative purposes. It will be apparent to those skilled in the art that the objects portrayed in this figure can be arbitrarily combined or divided into separate software, firmware or hardware components. Furthermore, it will also be apparent to those skilled in the art that such objects, regardless of how they are combined or divided, can execute on the same computing device or can be arbitrarily distributed among different computing devices connected by one or more networks.
  • [0080]
    Referring to FIGS. 1 and 4, sender 100 includes server 104, petition generator 106, petition information 108 and web pages 110. Mail provider 400 includes server 402, access list information 116, and user preferences information 118. By way of a non-limiting example, the mail provider can support one or more of the following email protocols: SMTP, MIME, POP and IMAP. Recipient 404 includes web browser 112 and petition processor 406. A request to add the sender to the mail provider's email access list begins with the recipient's email address being provided to the sender. Based on this email address and the petition information, the petition generator produces a petition which is automatically provided to the recipient's petition processor. In order to process the petition, the petition process needs to read and update the access lists and user preferences information. However, unlike the system of FIG. 1, this information is no longer local to the recipient. In one embodiment, a simple request/reply protocol can used to exchange this information between the petition processor and the mail provider. By way of a non-limiting example, the petition processor can send requests to the mail provider that identify a data source (e.g., whitelist, blacklist, user preferences, etc.) and an operation to take on that data source (e.g., read, update, delete, etc.). The mail provider can respond with the appropriate data and/or a confirmation of the operation.
  • [0081]
    However, if the petition processor is also located on the mail provider, a different approach can be taken. FIG. 5 is system diagram of an embodiment including a remote mail provider. Although this diagram depicts objects as functionally separate, such depiction is merely for illustrative purposes. It will be apparent to those skilled in the art that the objects portrayed in this figure can be arbitrarily combined or divided into separate software, firmware or hardware components. Furthermore, it will also be apparent to those skilled in the art that such objects, regardless of how they are combined or divided, can execute on the same computing device or can be arbitrarily distributed among different computing devices connected by one or more networks.
  • [0082]
    Referring to FIGS. 1 and 5, sender 100 includes Web/application server 104, petition generator 106, petition information 108 and web pages 110. Mail provider 500 includes server 502, petition processor 114, access lists 116, and user preferences information 118. Recipient 504 includes Web browser 112 and email proxy 506. The proxy is associated with the petition MIME type such that when a petition is received by the browser, the browser automatically provides it to the proxy. The proxy then automatically forwards the petition to the mail provider petition processor. In one embodiment, Yahoo! Default Email Application, available from Yahoo (http://www.yahoo.com), can serve as the proxy. The petition processor can use the web browser as its GUI for recipient end-user interaction (e.g., prompts). Petition confirmations need not communicate with the recipient, and may be made directly from the petition processor on the mail provider to the petition generator on the sender.
  • [0083]
    FIG. 6 is another system diagram of an embodiment including a remote mail provider. Although this diagram depicts objects as functionally separate, such depiction is merely for illustrative purposes. It will be apparent to those skilled in the art that the objects portrayed in this figure can be arbitrarily combined or divided into separate software, firmware or hardware components. Furthermore, it will also be apparent to those skilled in the art that such objects, regardless of how they are combined or divided, can execute on the same computing device or can be arbitrarily distributed among different computing devices connected by one or more networks.
  • [0084]
    Referring to FIGS. 1 and 6, sender 100 includes Web/application server 104, petition generator 106, petition information 108 and web pages 110. Mail provider 600 includes server 602, petition processor 114, access lists 116, and user preferences information 118. Recipient 604 includes Web browser 112. The petition processor is invoked via the recipient's web browser when it accesses a special URL on the mail provider's server, where part of the URL is the Internet location of the petition processor, and part of the URL is an encoded version of the petition data. The part of the URL containing the Internet location of the petition processor can be stored in a variable or object accessible with JavaScript or another web page scripting language, and the part of the URL containing the encoded petition data can be generated by the petition generator as part of an HTML confirmation page (e.g., as provided by the sender's server to the recipient's browser). The HTML confirmation page can also contain Javascript or another web page scripting language to check for the presence of such a petition processor URL, and if it exists, add the encoded petition data, and cause the browser to access the petition processor URL. Such an access can take place in a variety of ways, including but not limited to, in a separate frame, in a separate window, or as a redirection of the existing window.
  • [0085]
    One embodiment may be implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
  • [0086]
    One embodiment includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the features presented herein. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
  • [0087]
    Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and applications.
  • [0088]
    The foregoing description of the preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. Embodiments were chosen and described in order to best describe the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention, the various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US4723212 *Feb 27, 1987Feb 2, 1988Catalina Marketing Corp.Method and apparatus for dispensing discount coupons
US5377354 *Jun 8, 1993Dec 27, 1994Digital Equipment CorporationMethod and system for sorting and prioritizing electronic mail messages
US5424724 *Mar 27, 1991Jun 13, 1995International Business Machines CorporationMethod and apparatus for enhanced electronic mail distribution
US5487100 *May 17, 1994Jan 23, 1996Motorola, Inc.Electronic mail message delivery system
US5502636 *Jan 31, 1992Mar 26, 1996R.R. Donnelley & Sons CompanyPersonalized coupon generating and processing system
US5504897 *Feb 22, 1994Apr 2, 1996Oracle CorporationMethod and apparatus for processing electronic mail in parallel
US5619648 *Nov 30, 1994Apr 8, 1997Lucent Technologies Inc.Message filtering techniques
US5740549 *Jun 12, 1995Apr 14, 1998Pointcast, Inc.Information and advertising distribution system and method
US5761662 *May 8, 1997Jun 2, 1998Sun Microsystems, Inc.Personalized information retrieval using user-defined profile
US5793497 *Apr 6, 1995Aug 11, 1998Infobeat, Inc.Method and apparatus for delivering and modifying information electronically
US5793972 *May 3, 1996Aug 11, 1998Westminster International Computers Inc.System and method providing an interactive response to direct mail by creating personalized web page based on URL provided on mail piece
US5797128 *May 14, 1997Aug 18, 1998Sun Microsystems, Inc.System and method for implementing a hierarchical policy for computer system administration
US5819261 *Mar 21, 1996Oct 6, 1998Canon Kabushiki KaishaMethod and apparatus for extracting a keyword from scheduling data using the keyword for searching the schedule data file
US5835762 *Sep 29, 1997Nov 10, 1998Oracle CorporationMethod and apparatus for processing electronic mail in parallel
US5862325 *Sep 27, 1996Jan 19, 1999Intermind CorporationComputer-based communication system and method using metadata defining a control structure
US5864684 *May 22, 1996Jan 26, 1999Sun Microsystems, Inc.Method and apparatus for managing subscriptions to distribution lists
US5893099 *Nov 10, 1997Apr 6, 1999International Business MachinesSystem and method for processing electronic mail status rendezvous
US5903723 *Dec 21, 1995May 11, 1999Intel CorporationMethod and apparatus for transmitting electronic mail attachments with attachment references
US5919247 *Jul 24, 1996Jul 6, 1999Marimba, Inc.Method for the distribution of code and data updates
US5930479 *Oct 21, 1996Jul 27, 1999At&T CorpCommunications addressing system
US5937162 *Sep 24, 1996Aug 10, 1999Exactis.Com, Inc.Method and apparatus for high volume e-mail delivery
US5944787 *Apr 21, 1997Aug 31, 1999Sift, Inc.Method for automatically finding postal addresses from e-mail addresses
US5948061 *Oct 29, 1996Sep 7, 1999Double Click, Inc.Method of delivery, targeting, and measuring advertising over networks
US5970469 *Mar 26, 1996Oct 19, 1999Supermarkets Online, Inc.System and method for providing shopping aids and incentives to customers through a computer network
US5990886 *Dec 1, 1997Nov 23, 1999Microsoft CorporationGraphically creating e-mail distribution lists with geographic area selector on map
US5999932 *Jan 13, 1998Dec 7, 1999Bright Light Technologies, Inc.System and method for filtering unsolicited electronic mail messages using data matching and heuristic processing
US5999967 *Aug 17, 1997Dec 7, 1999Sundsted; ToddElectronic mail filtering by electronic stamp
US6014634 *Aug 4, 1997Jan 11, 2000Supermarkets Online, Inc.System and method for providing shopping aids and incentives to customers through a computer network
US6023723 *Dec 22, 1997Feb 8, 2000Accepted Marketing, Inc.Method and system for filtering unwanted junk e-mail utilizing a plurality of filtering mechanisms
US6038668 *Jul 22, 1998Mar 14, 2000Science Applications International CorporationSystem, method, and medium for retrieving, organizing, and utilizing networked data
US6044205 *Feb 29, 1996Mar 28, 2000Intermind CorporationCommunications system for transferring information between memories according to processes transferred with the information
US6044395 *Sep 3, 1997Mar 28, 2000Exactis.Com, Inc.Method and apparatus for distributing personalized e-mail
US6052709 *Dec 23, 1997Apr 18, 2000Bright Light Technologies, Inc.Apparatus and method for controlling delivery of unsolicited electronic mail
US6072942 *Sep 18, 1996Jun 6, 2000Secure Computing CorporationSystem and method of electronic mail filtering using interconnected nodes
US6112227 *Aug 6, 1998Aug 29, 2000Heiner; Jeffrey NelsonFilter-in method for reducing junk e-mail
US6138162 *Feb 11, 1997Oct 24, 2000Pointcast, Inc.Method and apparatus for configuring a client to redirect requests to a caching proxy server based on a category ID with the request
US6161130 *Jun 23, 1998Dec 12, 2000Microsoft CorporationTechnique which utilizes a probabilistic classifier to detect "junk" e-mail by automatically updating a training and re-training the classifier based on the updated training set
US6167435 *Oct 30, 1998Dec 26, 2000Netcreations, Inc.Double opt-in™ method and system for verifying subscriptions to information distribution services
US6173311 *Feb 13, 1997Jan 9, 2001Pointcast, Inc.Apparatus, method and article of manufacture for servicing client requests on a network
US6185541 *May 12, 1999Feb 6, 2001Supermarkets Online, Inc.System and method for providing shopping aids and incentives to customers through a computer network
US6195698 *Apr 13, 1998Feb 27, 2001Compaq Computer CorporationMethod for selectively restricting access to computer systems
US6199102 *Aug 26, 1997Mar 6, 2001Christopher Alan CobbMethod and system for filtering electronic messages
US6216127 *Sep 16, 1998Apr 10, 2001Oracle CorporationMethod and apparatus for processing electronic mail in parallel
US6226684 *Oct 26, 1998May 1, 2001Pointcast, Inc.Method and apparatus for reestablishing network connections in a multi-router network
US6249805 *Aug 12, 1997Jun 19, 2001Micron Electronics, Inc.Method and system for filtering unauthorized electronic mail messages
US6266692 *Jan 4, 1999Jul 24, 2001International Business Machines CorporationMethod for blocking all unwanted e-mail (SPAM) using a header-based password
US6272536 *Jan 13, 1999Aug 7, 2001Marimba, Inc.System and method for the distribution of code and data
US6289372 *Jul 2, 1997Sep 11, 2001Samsung Electronics, Co., Ltd.Method for transmitting and processing group messages in the e-mail system
US6341316 *Apr 28, 2000Jan 22, 2002Avantgo, Inc.System, method, and computer program product for synchronizing content between a server and a client based on state information
US6343327 *Nov 12, 1997Jan 29, 2002Pitney Bowes Inc.System and method for electronic and physical mass mailing
US6353852 *Jan 27, 1999Mar 5, 2002Adc Telecommunications, Inc.Enhanced telephone service system with secure system and method for E-mail address registration
US6367075 *Jun 30, 1999Apr 2, 2002Marimba, Inc.Method and apparatus for producing instructions describing the removal of updates to a computer system
US6377936 *Jan 27, 2000Apr 23, 2002At&T Corp.Method for performing targeted marketing over a large computer network
US6381631 *Jun 3, 1999Apr 30, 2002Marimba, Inc.Method and apparatus for controlling client computer systems
US6393464 *May 10, 1999May 21, 2002Unbound Communications, Inc.Method for controlling the delivery of electronic mail messages
US6421709 *Jul 7, 1999Jul 16, 2002Accepted Marketing, Inc.E-mail filter and method thereof
US6421717 *Apr 28, 2000Jul 16, 2002Avantgo, Inc.System, method, and computer program product for customizing channels, content, and data for mobile devices
US6430608 *Feb 9, 1999Aug 6, 2002Marimba, Inc.Method and apparatus for accepting and rejecting files according to a manifest
US6438584 *Mar 7, 2000Aug 20, 2002Letter Services, Inc.Automatic generation of graphically-composed correspondence via a text email-interface
US6449635 *Apr 21, 1999Sep 10, 2002Mindarrow Systems, Inc.Electronic mail deployment system
US6463462 *Feb 2, 1999Oct 8, 2002Dialogic Communications CorporationAutomated system and method for delivery of messages and processing of message responses
US6546416 *Dec 9, 1998Apr 8, 2003Infoseek CorporationMethod and system for selectively blocking delivery of bulk electronic mail
US6553412 *Apr 28, 2000Apr 22, 2003Avantgo, Inc.System, method, and computer program product for web content aggregation and development, and web content delivery to clients
US6640301 *Jul 8, 1999Oct 28, 2003David Way NgThird-party e-mail authentication service provider using checksum and unknown pad characters with removal of quotation indents
US6671715 *Jan 21, 2000Dec 30, 2003Microstrategy, Inc.System and method for automatic, real-time delivery of personalized informational and transactional data to users via high throughput content delivery device
US7039949 *Dec 10, 2001May 2, 2006Brian Ross CartmellMethod and system for blocking unwanted communications
US7072942 *Feb 4, 2000Jul 4, 2006Microsoft CorporationEmail filtering methods and systems
US7146009 *Feb 5, 2002Dec 5, 2006Surety, LlcSecure electronic messaging system requiring key retrieval for deriving decryption keys
US7249175 *Apr 12, 2000Jul 24, 2007Escom CorporationMethod and system for blocking e-mail having a nonexistent sender address
US20010042093 *Jun 8, 1998Nov 15, 2001Masahiko ShiraiInformation processing system capable of file transmission and information processing apparatus in the system
US20010051979 *May 25, 2001Dec 13, 2001Avantgo, Inc.System, method, and computer program product for placement of channels on a mobile device
US20020023135 *May 16, 2001Feb 21, 2002Shuster Brian MarkAddressee-defined mail addressing system and method
US20020026484 *Apr 9, 2001Feb 28, 2002Smith Steven J.High volume electronic mail processing systems and methods
US20020032722 *Sep 12, 2001Mar 14, 2002Avantgo, Inc.Method, system, and computer program product for synchronization of similar data objects with event information
US20020035607 *May 23, 2001Mar 21, 2002Daniel CheckowayE-mail gateway system
US20020049610 *Oct 1, 2001Apr 25, 2002Gropper Robert L.Auto update utility for digital address books
US20020052781 *May 25, 2001May 2, 2002Avantgo, Inc.Interactive advertisement mechanism on a mobile device
US20020116463 *Feb 20, 2001Aug 22, 2002Hart Matthew ThomasUnwanted e-mail filtering
US20020120496 *May 9, 2000Aug 29, 2002Scroggie Michael C.System and method for providing shopping aids and incentives to customers through a computer network
US20020143879 *Mar 28, 2001Oct 3, 2002Peter SommererMethod and system for automatically updating electronic mail address information within an electronic mail address database
US20020152245 *Apr 5, 2001Oct 17, 2002Mccaskey JeffreyWeb publication of newspaper content
US20020152272 *Apr 12, 2001Oct 17, 2002Rahav YairiMethod for managing multiple dynamic e-mail aliases
US20020198950 *Apr 10, 2002Dec 26, 2002Leeds Robert G.Junk electronic mail detector and eliminator
US20020199095 *May 22, 2002Dec 26, 2002Jean-Christophe BandiniMethod and system for filtering communication
US20030014414 *Dec 7, 2000Jan 16, 2003Newman Bruce D.Personcast - customized end-user briefing
US20030028580 *May 22, 2001Feb 6, 2003Murray KucherawyE-mail system with methodology for accelerating mass mailings
US20030131073 *Oct 22, 2001Jul 10, 2003Lucovsky Mark H.Schema-based services for identity-based data access
US20040015554 *Jul 16, 2002Jan 22, 2004Brian WilsonActive e-mail filter with challenge-response
US20040034694 *Aug 15, 2002Feb 19, 2004International Business Machines CorporationSystem, method, and computer program product in a data processing system for blocking unwanted email messages
US20040049696 *Apr 3, 2001Mar 11, 2004Baker Stuart D.Privileged communication system with routing controls
US20040122730 *Jan 2, 2001Jun 24, 2004Tucciarone Joel D.Electronic messaging system and method thereof
US20040153512 *Feb 5, 2003Aug 5, 2004Friend Jeffrey EdwardDynamic online email catalog and trust relationship management system and method
US20040177120 *Mar 7, 2003Sep 9, 2004Kirsch Steven T.Method for filtering e-mail messages
US20040205124 *Mar 27, 2003Oct 14, 2004Limprecht Rodney T.Availability and scalability in a messaging system in a manner transparent to the application
US20040205133 *Jul 18, 2001Oct 14, 2004Yaron AdlerSystem and method for intelligent transmission of digital content embedded in electronic mail messages
US20040225572 *May 7, 2003Nov 11, 2004Tenenbaum David M.System and method for interrelating and storing advertisements, tearsheets, and invoices
US20040243847 *Mar 3, 2004Dec 2, 2004Way Gregory G.Method for rejecting SPAM email and for authenticating source addresses in email servers
US20040258044 *May 22, 2003Dec 23, 2004International Business Machines CorporationMethod and apparatus for managing email messages
US20070204043 *Apr 1, 2007Aug 30, 2007Espinosa Claudia LMethod, system and apparatus for rejecting unauthorized or SPAM e-mail messages.
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7693943 *Apr 6, 2010International Business Machines CorporationClassification of electronic mail into multiple directories based upon their spam-like properties
US7720091Jan 10, 2006May 18, 2010Utbk, Inc.Systems and methods to arrange call back
US7764612 *Jun 16, 2005Jul 27, 2010Acme Packet, Inc.Controlling access to a host processor in a session border controller
US8125931 *Jan 10, 2006Feb 28, 2012Utbk, Inc.Systems and methods to provide availability indication
US8380793 *Sep 5, 2008Feb 19, 2013Microsoft CorporationAutomatic non-junk message list inclusion
US8539547 *Aug 18, 2011Sep 17, 2013Certes Networks, Inc.Policy selector representation for fast retrieval
US9106473Mar 28, 2007Aug 11, 2015Yellowpages.Com LlcSystems and methods to connect buyers and sellers
US20050165895 *Jan 23, 2004Jul 28, 2005International Business Machines CorporationClassification of electronic mail into multiple directories based upon their spam-like properties
US20060285493 *Jun 16, 2005Dec 21, 2006Acme Packet, Inc.Controlling access to a host processor in a session border controller
US20070011247 *Jul 8, 2005Jan 11, 2007Bayon Paul WCertified email system
US20070160076 *Jan 10, 2006Jul 12, 2007Scott FaberSystems and methods to arrange call back
US20070161386 *Jan 10, 2006Jul 12, 2007Scott FaberSystems and methods to provide availability indication
US20070287488 *Mar 28, 2007Dec 13, 2007Utbk, Inc.Systems and methods to connect buyers and sellers
US20070291783 *Mar 28, 2007Dec 20, 2007Utbk, Inc.Systems and Methods to Provide Real Time Communication Connections
US20100064011 *Sep 5, 2008Mar 11, 2010Microsoft CorporationAutomatic Non-Junk Message List Inclusion
US20120096512 *Aug 18, 2011Apr 19, 2012Certes Networks, Inc.Policy selector representation for fast retrieval
Classifications
U.S. Classification709/206
International ClassificationH04L12/58, G06F15/16
Cooperative ClassificationH04L51/12, H04L12/585
European ClassificationH04L12/58F
Legal Events
DateCodeEventDescription
Aug 7, 2003ASAssignment
Owner name: MINDSHARE DESIGN, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SMITH, STEVEN J.;REEL/FRAME:014356/0703
Effective date: 20030711
Owner name: MINDSHARE DESIGN, INC.,CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SMITH, STEVEN J.;REEL/FRAME:014356/0703
Effective date: 20030711
Nov 30, 2010CCCertificate of correction
Sep 13, 2013REMIMaintenance fee reminder mailed
Feb 2, 2014LAPSLapse for failure to pay maintenance fees
Mar 25, 2014FPExpired due to failure to pay maintenance fee
Effective date: 20140202