US20030225850A1 - Message processing based on address patterns - Google Patents

Message processing based on address patterns Download PDF

Info

Publication number
US20030225850A1
US20030225850A1 US10/447,332 US44733203A US2003225850A1 US 20030225850 A1 US20030225850 A1 US 20030225850A1 US 44733203 A US44733203 A US 44733203A US 2003225850 A1 US2003225850 A1 US 2003225850A1
Authority
US
United States
Prior art keywords
message
address pattern
rule
address
rules
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/447,332
Inventor
Alan Teague
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US10/447,332 priority Critical patent/US20030225850A1/en
Publication of US20030225850A1 publication Critical patent/US20030225850A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • G06Q10/107Computer-aided management of electronic mailing [e-mailing]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/212Monitoring or handling of messages using filtering or selective blocking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/48Message addressing, e.g. address format or anonymous messages, aliases
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/56Unified messaging, e.g. interactions between e-mail, instant messaging or converged IP messaging [CPM]

Definitions

  • the present invention relates to network communications.
  • a message usually includes content, which can be represented by, for example, text, images, and sound.
  • a message also usually includes address information of a sender of the message as well as address information of an intended recipient of the message.
  • the sender initiates the message, and the receiver, or intended recipient, is the target or the addressee of the message.
  • a sender can be, for example, a human operator, a computer program product, and a computing system.
  • An intended recipient can likewise be any of the mentioned entities.
  • An intended recipient can be one or more entities. For example, a particular message can be addressed to an intended recipient representing a group of human operators. Senders and intended recipients are correspondents.
  • Emails There are generally different types of messages.
  • SMS short-message-service
  • voice messages voice messages
  • page messages instant messaging messages
  • facsimiles i.e., faxes
  • Email messages for example, are typically sent over networks that include email servers.
  • the email servers can use the Simple Mail Transfer Protocol (“SMTP”).
  • Faxes for example, are typically sent over networks that include fax machines. Faxes may also be sent over a network that includes computers that have fax applications.
  • Voice messages for example, are typically sent over a network that include voice mail servers.
  • the networks mentioned can be part of or include portions of the Internet.
  • a message can also be sent over an interprocess communication environment (“IPCE”), which may include one network, several networks, or a subset of a network.
  • IPCE interprocess communication environment
  • a message can be communicated between processes in different IPCEs by relaying through a process connected to two (or more) IPCEs. That is, mail can be relayed between hosts on different transport systems by a host on both transport systems.
  • a standardized form of contact information can identify one or more of the particular sender and intended recipient.
  • Emails for example, usually include standardized contact information, usually in the following form: “local_part@domain_part”.
  • Telephone numbers for voice and fax for example, also usually include standardized contact information.
  • the standardized contact information generally includes digits that represent a country, digits that represent an area code, and digits that represent a terminal device.
  • the above mentioned networks can include technology that supports a mapping of multiple addresses to a single delivery location.
  • Specific email addresses of a human operator can be linked, i.e., aliased, to an actual email account the human operator uses to connect to the network.
  • personal@BePrivate.com and business@BePrivate.com can both be aliased to alan@pop.BePrivate.com.
  • Messages sent to either of the first two addresses will be delivered to the third account.
  • different telephone numbers can map to a single telephone or facsimile machine. Message addresses that are aliased, regardless of the type of message, are referred to in this specification as contact aliases.
  • the present invention provides methods and apparatus, including computer program products, for automatic management and control of contact aliases.
  • the invention provides a computer implemented method for processing messages.
  • the method includes maintaining rules, each of which includes an address pattern key and one or more instructions for message processing, an address pattern key being an expression that specifies one or more address pattern instances.
  • the method includes receiving a first message, the first message including address information associated with the sender of the first message and address information associated with the intended recipient of the first message.
  • the method includes defining an address pattern instance of the first message, an address pattern instance of a message being a combination of address information associated with a sender of the message and address information associated with an intended recipient of the message.
  • the method includes selecting, from among the rules, a rule that includes an address pattern key with which the defined address pattern instance matches.
  • the method includes processing the first message in accordance to the one or more instructions included in the rule selected.
  • the invention features a computer program product, tangibly stored on machine readable medium, for processing messages.
  • the product includes instructions operable to cause a programmable processor to receive a first message, the first message including address information associated with the sender of the first message and address information associated with the intended recipient of the first message.
  • the product includes instructions operable to define an address pattern instance of the first message, an address pattern instance of a message being a combination of address information associated with a sender of the message and address information associated with an intended recipient of the message.
  • the product includes instructions operable to select, from among a set of rules, a rule that includes an address pattern key with which the defined address pattern instance matches, each of the set of rules including an address pattern key and one or more instructions for message processing, an address pattern key being an expression that specifies one or more address pattern instances.
  • the product includes instructions operable to process the first message in accordance to the one or more instructions included in the rule selected.
  • the invention provides a network transmitting agent for a specific type of network and associated management utilities.
  • These network specific agents use stored information to lookup appropriate behavior rules for the task at hand. These rules define criteria and processes for at least accepting, rejecting, verifying, validating, and modifying incoming and outbound communications and for adding, modifying, and deleting rules.
  • the management utilities for the network specific agents provide a means for adding, modifying and deleting rules, configuration settings, and other agent state information.
  • the invention provides a specialized SMTP server and associated management utilities for processing emails, including managing consistent use of aliases.
  • the management utilities support both a Web-based (e.g., one using HTTP(S)) and validated email interface.
  • the present invention supports SMTP, POP3, or IMAP4 compliant email clients such as Eudora, Outlook Express, and Netscape Mail without requiring source-code level changes to those applications.
  • a system as described in this specification can, for outbound messages, facilitate consistent use of aliases.
  • the system can ensure that a message outbound to a particular intended recipient includes the alias the sender has designated for use with messages addressed to the particular intended recipient.
  • the system allows one to define new aliases and change existing aliases by either passive input or active input.
  • Passive input includes inserting a new alias in a from field of a message.
  • Active input includes input received through an administrative interface, which can be Web-based.
  • the system allows users to maintain more than one email identity and yet use a single mailbox for all email they receive.
  • the identity feature is further enhanced with an automatic mapping facility allowing each externally visible identity to map onto the email addresses of one or more correspondents. Users can thus appear to have a different email address (identity) for each person with whom the user correspond, because the server automatically ensures all outbound email contains the correct identity for that particular correspondent.
  • the system can, for incoming and outbound messages, apply access and processing rules.
  • the rules can be defined to reduce spam.
  • the system can, for example, stop accepting messages from senders whom the system does not recognize while continuing to accept messages from senders whom the system does recognize. A user, thus, need not change the address at which the user receives messages to keep from receiving spam.
  • the system can include a rules engine and a database, in which the access and processing rules can be maintained.
  • the rules engine can be built on top of the database, which can be integrated into all mail transfer subsystems that govern both inbound and outbound email acceptance and outbound identity mapping.
  • the rules engine allows users to restrict exactly whom they wish to correspond with through the use of access and processing rules.
  • the rules can specify single entities or use regular expressions, allowing users to block all entities or any sub-set of the entities matching a specified pattern.
  • the rules can include default rules and customized rules.
  • the rules can be changed by the rules engine. That is, the system can be self-adapting. Further, the system can adapt the access and processing rules automatically and in real time.
  • the system can support different levels of default actions for receipt of messages sent to an intended recipient from a sender not recognized by the system (i.e., a new sender).
  • the levels include: (i) accept for delivery any messages from a new sender, reject only messages from senders the intended recipient specified; (ii) request verification from the intended recipient, i.e., ask the intended recipient whether the message is to be rejected or accepted; (iii) request confirmation from the new sender before delivering the message; (iv) request verification from the intended recipient and confirmation from the new sender; (v) block any messages from new senders, accepting messages from senders with whom the intended recipient initiates communication.
  • Sending an email to a correspondent not recognized by the system i.e., a new correspondent
  • a correspondent not recognized by the system will automatically create an identity mapping based on both the correspondent's address and either the address in the “FROM” field or the user specified default identity.
  • the new correspondent will be automatically added to the rules for that identity allowing return email to be accepted automatically.
  • Receiving email from a correspondent to a new identity will automatically create the new identity, e.g., while signing up on a website you can create a new address such as memsn.com@there.com such that the incoming promotional email from that website automatically creates the identity.
  • a user of the system can therefore accomplish fine-tuning of the rules for the system through the day-to-day use of their favorite email client.
  • the rules can be defined for multiple users of the system.
  • the database of rules can be segmented on a user by user basis. For example, rules for different users can be maintained in different tables. By being so segmented, the database is scalable. Furthermore, a user changing rules pertaining to the user locks only the user's respective segment and not segments of other users.
  • the system can use address patterns that include both sender and intended recipient address information. By doing so, the system provides a fine-grained level of control over message acceptance and processing.
  • the system uses regular expression to define groups of aliases.
  • the system controls and manages messages at the SMTP level so that client resources need not be consumed for the purposes of access control. In addition, server resources consumed for processing rejected messages are minimized.
  • the system provides users with the advantage of tracking unauthorized use of specific contact aliases by the corresponding trusted parties.
  • a contact alias need not be abandoned when it becomes the target of a large amount of unwanted messages (i.e., spam).
  • the system can reject messages that are sent from new senders and addressed to the contact alias while continuing to accept messages that are sent from previous senders and addressed to the contact alias.
  • the system can also accept messages sent from recipients of outgoing messages from the contact alias.
  • FIG. 1 shows a block diagram of a system for processing messages.
  • FIGS. 2 A- 2 C show examples of address pattern keys that are regular expressions and of a rule.
  • FIG. 3 shows a method for processing messages.
  • FIG. 4 shows another method for processing messages.
  • FIG. 5 shows an implementation of the system for processing messages.
  • FIGS. 6 A- 6 F show examples of administrative interfaces.
  • FIG. 1 shows a block diagram of a system 100 for processing messages.
  • the system includes a server 102 , a rules engine 104 , a database 106 , and a database server 108 .
  • the system can include one server where the rules engine and the database can reside.
  • the system 100 can include other computing components.
  • the system can include one or more other servers and other computer program products.
  • the rules engine 104 can maintain a rule base stored in the database 106 .
  • the rule base can include access and processing rules for messages.
  • Each of the rules can include an address pattern key and one or more instructions for message processing.
  • An address pattern key is an expression that specifies one or more address pattern instances.
  • the address pattern keys are regular expressions.
  • Each address pattern key can include two portions, one for address information associated with a sender (i.e., the sender portion) and another for address information associated with an intended recipient (i.e., the intended recipient portion).
  • Each portion can include a regular expression, which is a formula for matching strings that follow a pattern. Regular expressions similar to those that can be included in the rules are further described in Portable Operating System Interface (“POSIX®”) 1003.2, which is hereby incorporated by reference in its entirety.
  • POSIX® Portable Operating System Interface
  • the address pattern key can include one regular expression for address information associated with both a sender and an intended recipient.
  • FIG. 2A shows an address pattern key 202 that includes a sender portion 204 and an intended recipient portion 206 .
  • FIG. 2B shows an address pattern key 208 that includes an intended recipient portion 210 but not a sender portion. Address pattern keys like the address pattern key 208 are usually included in rules for alias management.
  • FIG. 2C shows an example rule 212 that include the address pattern key 202 and one or more instructions 214 . Table 1 shows examples of address pattern keys and the corresponding address pattern instances specified by, i.e., match with, the address pattern keys.
  • the messages are emails. However, the messages can be any type of messages.
  • the messages can be phone numbers, in which case the regular expressions will include numbers.
  • TABLE 1 Address Pattern Key Matching Address Pattern Instances Intended Intended Sender Portion Recipient Portion Sender Portion Recipient Portion bob ⁇ .jones@bobdomain ⁇ . bob@legal ⁇ .bobdo bob.jones@bobdomain. bob@legal.bobd com main ⁇ .com com omain.com .*@ ⁇ .* ⁇ . ⁇ bobdomain ⁇ .co bob@legal ⁇ .bobdo bob.jones@bobdomain.
  • One or more of the rules can also include one or more processing instructions.
  • the instructions can specify how messages are processed and how the rules are maintained and updated.
  • the instructions can be, for example, any combination of: accept the message for delivery, reject the message, accept the message and hold until confirmed, accept the message and hold until verified, accept the message and hold until confirmed and verified, accept the message for a duration after a particular date, accept a particular number messages and then reject, accept message until a particular date, forward messages to a particular list of locations, and define a rule.
  • Confirmation may include customized confirmation request.
  • a user of the system can have, for example, different confirmation request templates for different intended recipients. Further, the user can have different confirmation request templates for different address pattern instances.
  • the system uses a confirmation request template, in conjunction with a particular message, to generate a confirmation request for the particular message.
  • the user may customize the confirmation request templates by using an administrative interface, for example, a Web-based administrative interface. Updating includes defining a new rule, modifying an existing rule, and deleting an existing rule.
  • the instructions can relate to alias management. The instructions can, for example, specify which alias of a sender is used for a message the sender is sending to a particular intended recipient. Alias management rules can be stored separately from the access and processing rules. For example, the system can have two tables for each system user, one for alias management rules and the other for access and processing rules.
  • the rules can be, for example, IF-THEN rules, IF-NOT-THEN rules, IF-THEN-ELSE rules, and any combination thereof.
  • the system can include other types of rules.
  • the system can be connected to send and receive messages to and from networks such as the Internet, and also to send to and receive messages from clients.
  • the system can receive the message from any point in a network to which the system is connected.
  • the system can receive the message from, for example, a client computer or a server.
  • the system can include memory where the system can store messages for future delivery.
  • the system determines what action to take. After the system determines what action to take, the system can store the message in the memory for future delivery.
  • FIG. 3 shows a method 300 for processing messages.
  • a system such as the system 100 , performing method 300 receives a message (step 302 ).
  • the message can be, for example, an email, an SMS message, a fax, an instant message, and a voice message.
  • the message includes address information.
  • the address information can include address information associated with the sender of the message and address information associated with the intended recipient of the message.
  • the message can include content.
  • the content can include attached electronic documents.
  • An electronic document does not necessarily correspond to a file.
  • a document may be stored in a portion of a file that holds other documents, in a single file dedicated to the document in question, or in multiple coordinated files.
  • An address pattern instance of a message can be a combination of address information associated with a sender of the message and address information associated with an intended recipient of the message.
  • Examples of address information associated with a sender can include and are not limited to an alias of the sender, a domain of the user, a phone number of the sender, an IP address of the sender.
  • Examples of address information associated with the intended recipient similarly include and are not limited to an alias of the intended recipient, a domain of the intended recipient, a phone number of the intended recipient, an IP address of the intended recipient.
  • There is generally one address pattern instance which can be defined for a given message. Multiple messages can have the same address pattern instances.
  • the system identifies which of the processing rules includes an address pattern key to which the defined address pattern instance matches (step 306 ). There may be instances when there are no matches, in which case the system can identify a default rule. In general, however, there are one or more rules with which the address pattern instance matches, and there are one or more rules identified.
  • the system determines if there is more than one rule identified (decision step 308 ). If there is only one rule identified, then the system selects the one rule identified (step 310 ). If there are more than one rule identified, then the system selects one rule from among the rules identified (step 312 ). Criteria for the selection can be based on the specificity of the address pattern keys included in the rules.
  • the system can select, for example, the rule that include the most specific address pattern key.
  • criteria for selection can be based on an order of priority.
  • the system includes a restricted set of rules. The rules are ordered by priority, and the system selects a matching one with the highest priority.
  • the order of priority can be defined by an administrator, one or more users, or any combination of administrator and users.
  • the system processes the message in accordance to the one or more instructions included in the rule selected (step 314 ).
  • the processing can occur at a point in the network such that consumption of client computing resources are reduced or minimized.
  • Processing can occur, for example, at an SMTP server.
  • Processing can include any action or operations one can apply to a message and the rules.
  • processing can include but is not limited to: accepting a message for delivery; rejecting a message; accepting a message, requesting verification, and delivering the message upon receipt of verification; accepting a message, requesting confirmation, and delivering the message upon receipt of confirmation; accepting a message, requesting confirmation and verification, and delivering the message upon receipt of confirmation and verification; defining a new rule; or any of the above combination.
  • FIG. 4 shows a method 400 for processing messages.
  • a system such as the system 100 , performing method 400 receives an outbound message (step 402 ).
  • the message can be, for example, an email, an SMS message, a fax, an instant message, and a voice message.
  • the message includes address information.
  • the address information can include address information associated with the sender of the message and address information associated with the intended recipient of the message.
  • the message can include content.
  • the content can include attached electronic documents.
  • the system defines an address pattern instance of the message (step 404 ).
  • An address pattern instance of a message can be the address information associated with an intended recipient of the message.
  • the system identifies alias management rules that include address pattern keys with which the defined address pattern instance matches (step 406 ).
  • the alias management rules maps aliases to intended recipients. That is, an alias management rule specifies which of the sender's aliases is to be used for which of the intended recipients.
  • the system determines if there is more than one rule that includes an address pattern key with which the address pattern instance matches (step 408 ). If there is only one rule, then the system selects this rule (step 410 ). If there are more than one rule, then the system selects a rule from among those identified (step 412 ). Criteria for the selection can be based on the specificity of the address pattern keys included in the rules.
  • the system can select, for example, the rule that includes the most specific address pattern key.
  • criteria for selection can be based on an order of priority.
  • the system includes a restricted set of rules.
  • the rules are ordered by priority, and the system selects the matching one with the highest priority.
  • the order of priority can be defined by an administrator, one or more users, or any combination of administrator and users.
  • the system processes the message in accordance with the instructions of the rule selected (step 414 ). Processing includes managing aliases and ensuring consistent alias use.
  • the system can determine whether the alias currently in the message is the same as the alias specified in the rule selected, and changing the alias in the message as appropriate, for example, to be the same as the one specified in the rule selected.
  • Processing can also include defining new rules. Processing can include, for example, changing an alias specified in the rule selected to be the same as the alias of the current message. Alternatively, processing can include other actions such as, for example, those described above with respect to method 300 .
  • the system is a privacy-oriented email system that includes an integrated suite of high-performance email processing server applications and a rules engine driven by a database that contains account and configuration information. Together, these applications manage the privacy of email identities used for correspondence.
  • Each user has one mailbox that contains all of the email for all of his or her email identities. The system keeps track of which identity is used with each correspondent. Additionally, each mailbox can span multiple domains allowing a user's choice of identity to also span multiple domains.
  • a Web-based user account, domain, and identity administration application and a Web-mail application.
  • system 500 includes: an SMTPD component 502 , a POPD component 504 , a FETCH component 506 , an ADMIN component 508 , a WEB component 510 , and an AIRDB (account information & rules database) component 512 .
  • the components are connected as indicated to each other, the Internet, email clients, remote email accounts, and Web clients.
  • the SMTPD component 502 is a server for processing both inbound messages from the Internet and outbound messages from email clients.
  • the POPD component 504 is a POP3 server for establishing inbound email client connections.
  • the FETCH component 506 is a POP3 client for fetching email from remote POP3 servers.
  • the ADMIN component 508 is a computer program product that provides a Web-based interface for administering user accounts, domains, and identities.
  • the ADMIN component 508 resides on an HTTP server, for example, the Boa Webserver.
  • the WEB component 510 is a computer program product that provides a Web-based email client interface.
  • the AIRDB 512 is database of user account information used by all of the above components. The following described each component in further detail.
  • the SMTPD server 502 is a mail transfer agent utilizing the SMTP protocol standard. It acts as a server for sending and receiving the following:
  • the SMTPD server 502 is compliant with the SMTP standard, according to RFC 2821.
  • the inbound destination email address In order to receive email, the inbound destination email address must map to configured domain or sub-domain, then to an address group corresponding to a user account, and then to a mailbox. Once the inbound address has been mapped to a user's mailbox, the email will only be accepted and processed according to the email handling rules for the correspondent in the FROM address of the SMTP envelope and the specified receiving identity in the TO address of the SMTP envelope.
  • the various types of email processing instructions are as indicated below.
  • Message processing instructions include and are not limited to:
  • More complex handling rules include and are not limited to:
  • a specific person i.e., specific email address.
  • a specific group of people i.e., specific domain or sub-group within a domain.
  • a specific identity i.e., specific email address.
  • a group of identities i.e., specific prefix with a specific domain.
  • Table 2 shows an example set of actions.
  • ACVN + n - Accept and hold until confirm, then hold until verified, and then deliver message(s) and create specific rule for F:T Accept n-messages.
  • AMsrNn If the sender address part specified by ‘s’ matches the recipient part specified by ‘r’, then accept n-messages and then reject any additional.
  • AMsrEyyyymmdd If the sender address part specified by ‘s’ matches the recipient part specified by ‘r’, then accept until specified date and then reject any additional.
  • ARA-id Accept all messages and auto-reply with message ‘id’.
  • ARNn-id Accept n-messages, auto-reply to each with message ‘id’.
  • AREyyyymmdd-id Accept all messages until specified date auto-reply with message ‘id’.
  • RA + -id Create a specific rule
  • F:T Accept all messages and auto-reply with message ‘id’.
  • RN + n-id Create a specific rule
  • F:T Accept n-messages, auto-reply to each with message ‘id’.
  • ARE + n-id Create a specific rule, accept all messages until n days from now, auto- reply to each with message ‘id’.
  • the AIRDB component 512 can be updated passively through the normal use of email, and through the use of several special email addresses recognized by the system. That is, users of the system can update rules without recourse to the ADMIN Web-based administration interface. A user can add correspondents to the user's rule base in the following ways:
  • Sending an particular email to a correspondent adds a rule that accepts email having the same address pattern instance as the particular email.
  • the AIRDB component 412 can be updated actively, i.e., by input through the Web-based administrative interface.
  • the SMTPD server 502 uses a MailID field that is inserted into the subject line of each inbound email to identify which pair of identities is to be confirmed or rejected.
  • the MailID field is used to identify the specific address pattern instance for use with the REJECT and ACCEPT special addresses. This feature allows consistent behavior across all email clients.
  • This unique identifier can be added to the subject line to provide a consistent way of identifying the specific SENDER and RECIPIENT for the message.
  • the unique identifier is used by the ACCEPT and REJECT process to create the appropriate rules for the pair of FROM-TO addresses. While the SENDER and RECIPIENT information can be extracted from the headers of the message, not all email clients pass all of the headers back to the system when replying to messages. The MailID in the subject line is thus needed to ensure consistent behavior across clients.
  • SMTPD will set the preferred identity for the “TO” address to this value. This will either setup a new mapping of the identity or override a previous one.
  • the server adds an entry in an appropriate rule for the used identity to allow any future email from the “TO” address to be accepted without any further processing.
  • Email is then sent to the recipient as per normal SMTP processing
  • the SMTP server 502 implements the following properties and features.
  • a contact alias is provided that is a place holder for triggering substitution of a consistent sender-to-receiver contact alias.
  • a default sender contact alias is provided to be used if one is not specified or available, such as when the receiver sends a message to a new intended recipient.
  • a set of default rules is provided to be used for defining access and processing rules for new intended recipients with whom the sender has initiated communications.
  • Table 3 below shows an example set of the default rules.
  • a set of access and processing rules is provided for deciding what to do when inbound email is processed for specific sender contact alias and receiver contact alias pairs or patterns of such pairs.
  • a minimal set of rules is specified below.
  • a set of intended recipient contact alias or pattern to sender contact alias preference information is provided for use in maintaining a consistent sender contact alias for specific receivers or groups of receivers.
  • a set of email alias or email alias patterns to mailbox information is provided for use in processing inbound and outbound email.
  • Ntimes-N Sending email to an address authorized that address to reply back to the sending address up to N messages after which further email will be rejected
  • Expires-N Sending email to an address authorizes that address to reply back to the sending address for up to N days from the date of the initial message
  • the action for the reverse (reply) rule is: Accept - Nothing needs to be done Accept N-msgs - If empty, increase authorized message count by ‘empty-add’ Accept until - If expired, increase authorized time period by ‘expired-add’ Confirm/Verify - Add appropriate rule w/o requiring confirm or verify Pending - Convert as if confirmed/verified and deliver all pending email Reject
  • the SMTP server 502 can have at least the minimum implementation as specified in 4.5.1 Minimum Implementation, RFC 2821, “Simple Mail Transfer Protocol”, J. Kleinsin, Editor, April 2001.
  • RFC 2821 “Simple Mail Transfer Protocol”, J. Kleinsin, Editor, April 2001.
  • MAIL MAIL
  • the system can identify if the sender is a valid system user such that outbound email processing behaviors should be used.
  • RCPT a valid system user such that inbound email processing behaviors should be used.
  • outbound processing has been specified and if the sender contact alias matches the placeholder contact alias or pattern, then the system can substitute in the FROM field of the message either the sender contact alias associated with the intended recipient or the default contact alias if a previous mapping does not exist. If inbound processing has been specified, the system can find the first rule for the receiver's mailbox that matches the sender contact alias and receiver alias used by the sender and, furthermore, use the first part of the action to decide whether to reject or accept the message. If no rule is found, then the system can reject the message. If neither inbound or outbound processing has been specified, then the server should handle the relay request as per site specific configurations as specified in RFC 2821.
  • FETCH is used to regularly retrieve email from remote 3rd party POP3 servers, as configured by each user. FETCH makes use of the rules engine, so that retrieved email is subject to most of the same acceptance rules used for inbound email from SMTPD. The variations in rule processing occur because the semantics of some of the rules do not make sense when applied to retrieved email, for example:
  • POPD complies with RFC 1939 (POP3 Commands and Responses), using plain text authentication.
  • POPD is a POP3 Server that handles incoming POP3 client access according to a protocol, e.g., RFC 1939 (POP3 Commands and Responses), using either plain text or APOP authentication.
  • RFC1939 compliance ensures that POPD interoperates with the user's preferred email client (e.g., Outlook Express, Outlook, Eudora, Netscape Mail, etc.).
  • POPD does not require use of the rules engine, but does make use of AIRDB in order to confirm user access and to find the users email.
  • ADMIN User Account, Domain and Identity Administration:
  • ADMIN is a web application that supports the following:
  • the Boa HTTP Server provides the platform on which this application runs. This open source server was built with a security and performance focus.
  • the management utilities implement the following properties and features.
  • These management utilities can be implemented in both a Web-based system and an email based system.
  • the Web-based system provides authentication of the user and supports all of the above list of behaviors and properties.
  • the email based system provides as a minimum the ability to set basic rules for specific contact alias pairings as a result of forwarding or redirecting email to specific receiver contact aliases.
  • the minimal set of actions can include setting the following types of rules for the specific contact alias pairing contained in the email: Reject always; and accept always.
  • the type of rule to be created can be based on the receiver contact alias.
  • FIGS. 6 A- 6 F show examples of administrative interfaces, one or more of which can be Web-based.
  • FIG. 6A shows an example of an administrative interface for managing email domains.
  • the interface includes a list 602 of domains being managed by the system.
  • the interface includes a field 604 for adding domains to be to be managed by the system.
  • the interface includes a field 606 for checking availability of a domain name.
  • the interface includes elements, such as element 608 , for adding sub-domains to a domain.
  • the interface includes elements, such as element 610 , for specifying actions to be taken for each domain.
  • FIG. 6B shows an administrative interface for configuring an email domain.
  • the administrative interface allows a user to specify whether the new domain will be a multi-user domain or a single-user domain.
  • the administrative interface also allows the user to specify Domain Name System setup options.
  • FIG. 6C shows an example of an administrative interface for managing address groups.
  • a user can add an address group by using one of the user's own domain names, using another's domain name, and retrieving one of the user's POP account.
  • the interface includes a field 614 for adding one of the user's domain names.
  • the interface includes a field 616 for adding a domain name of another.
  • the interface includes a field 618 for retrieving one of the user's POP account.
  • FIG. 6D shows an example of an administrative interface for managing identities.
  • the interface includes an area 620 for creating new identities.
  • Area 620 includes an area 622 for defining new identities and an area 624 for defining new group identities.
  • the administrative interface includes fields, such as field 626 , for specifying actions to be taken with respect to the newly defined identities or group identities.
  • the administrative interface includes elements which actuation creates the identities and corresponding rules.
  • the administrative interface also includes lists of identities being managed by the system such as, for example, list 630 for showing group identities, list 632 for showing identities specified by the user, and list 634 for showing identities that are learned and passively created by the system in response to the user's use of the system.
  • FIG. 6E shows an administrative interface for managing aliases.
  • the administrative interface includes an area 636 for specifying the default identity.
  • the administrative interface includes an area 638 for specifying preferred identities for sending emails.
  • the administrative interface includes a list 640 of recipients (i.e., the intended recipients) and a list 642 of aliases to be used to correspond with the recipients.
  • FIG. 6F shows an administrative interface for managing accept/reject (i.e., access and processing) rules.
  • the administrative interface includes an area 644 for a display filter. The user may wish to use the filter to display a subset of the set of recipients with whom the user corresponds.
  • the administrative interface includes a list 646 of recipients.
  • the administrative interface includes a list 648 of the user's aliases to be used when corresponding with the respective recipients.
  • the administrative interface includes fields 650 of actions that specify actions to be taken for messages sent from the recipient and addressed to the alias specified.
  • the WEB application provides a standard web based email client with specific additions to make the dynamic creation of new identities easy and fast.
  • WEB provides all of the core email functionality that is required to read, write, delete, forward, reply and deal with attachments.
  • this application runs on top of the Open Source Boa HTTP server for performance, security and scalability reasons.
  • the SMTP server 402 like other SMTP mail transfer agents, is configured to handle email for particular Internet Domains.
  • Internet Domains can come in a variety of types, based on the use to which the domain will be put. Domains can either be used to serve email to a single user or to multiple users. Single user domains are known as “Catch-All” domains because all email destined for the domain (whatever the specific address used) is delivered to a single mailbox. Multiple user domains can have an unlimited number of users, each of which may have many distinct identities. Every mailbox can aggregate multiple email identities from one or more domains or sub-domains, regardless of the type of the domains. Unlike other mail systems, the system proposes to allow every user to have an unlimited number of identities, spread across a variety of Internet Domains.
  • Type A Fixed identity with a prefix for defining new identities. Each user has a specific identity like “bob@there.com” along with a prefix that they can use to create additional identities such as “bobanything@there.com”.
  • Type B Sub-domains for either groups or individuals. Each domain can have sub-domains like “sales.there.com” for handling groups of associated people, or a sub-domain may be for individual use as a “Catch-All” sub-domain such as “ceo.there.com”.
  • Type C Fixed identity with both a prefix and variable sub-domains for defining new identities.
  • Each user has a specific identity like “bob@there.com” and a prefix that they can use to create additional identities such as “bob-anything@there.com”.
  • the user can create new sub-domains like “bob@support.there.com” or bob-Yahoo@web.there.com to add even greater flexibility in defining new identities.
  • Type D Fixed sub-domain as a “Catch-All” for defining new identities.
  • Each user has a specific sub-domain like “ceo.there.com” or “bob.there.com” which is used as a “Catch-All” domain. This allows each user great freedom in defining new identities since any address that ends with their sub-domain like “sales-info@bob.there.com” will be delivered to them.
  • Type E “Catch-All” domain for defining new identities. Each user has a specific domain like “bobjones.com” which is used as a “Catch-All” domain. This allows the user great freedom in defining new identities since any address that ends with their domain like “info@bobjones.com” will be delivered to them.
  • Type F “Catch-All” domain with variable sub-domains for defining new identities. Each user has a specific domain like “bobjones.com” which is used as a “Catch-All” domain. This allows the user great freedom in defining new identities since any address that ends with their domain like “info@bobjones.com” will be delivered to them.”.
  • the user can create new sub-domains like “robert@support.bobjones.com” or “yahoo@chat.bobjones.com” to add even greater flexibility in defining new identities.
  • one implementation utilizes either a software program or hardware instantiation of the software running in the central telephone office which provides the point-of-entry for the user or a software or hardware instantiation of the software running at the end-point of the telephone connection (e.g., the user's telephone is connected to a fax/data/voice modem card which runs the server software) and associated management utilities that implements the details of the system and method of the present invention.
  • the management utilities can support both a Web-base (e.g., one that uses HTTP(S)) and voice/keypad interactive system.
  • the contact alias for voice networks is defined as a telephone number which ultimately maps to a specific telephone or centralized phone system (e.g., local phone system for an office).
  • a minimal set of rules for voice communications includes: Accept call and ring through, Forward call to voice mail, Forward call to another number, Reject the call with a specific message, Request entering of a response to a specific question and redirect call based on the answer. All of the properties of the rules specified for email are applicable for this situation.
  • one implementation utilizes either a software program or hardware instantiation of the software running in the central telephone office which provides the point-of-entry for the user or a software or hardware instantiation of the software running at the end-point of the telephone connection (e.g., the user's telephone is connected to a fax/data/voice modem card which runs the server software) and associated management utilities that implements the details of the system.
  • the management utilities in one implementation, can support both a Web-based and voice/keypad interactive system.
  • the contact alias for data networks is defined as a telephone number which ultimately maps to a specific facsimile machine or facsimile emulator or centralized phone system (e.g., local phone system for an office).
  • the minimal set of rules associated with voice communication networks would also apply to data communication networks. All of the properties of the rules specified for email are applicable for this network.
  • the invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them.
  • the invention can be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
  • a computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • a computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
  • Method steps of the invention can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by, and apparatus of the invention can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
  • FPGA field programmable gate array
  • ASIC application-specific integrated circuit
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
  • a processor will receive instructions and data from a read-only memory or a random access memory or both.
  • the essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data.
  • a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks.
  • Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices
  • magnetic disks e.g., internal hard disks or removable disks
  • magneto-optical disks e.g., CD-ROM and DVD-ROM disks.
  • the processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.
  • the invention can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.
  • a display device e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor
  • a keyboard and a pointing device e.g., a mouse or a trackball
  • Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
  • the invention can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the invention, or any combination of such back-end, middleware, or front-end components.
  • the components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.
  • LAN local area network
  • WAN wide area network
  • the computing system can include clients and servers.
  • a client and server are generally remote from each other and typically interact through a communication network.
  • the relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
  • the rules base can include rules that are based on an access control list.
  • the rules can restrict outbound mail, for example, to limit communications to an approved set of correspondents via a form of centrally-managed outbound rule base.

Abstract

Methods and apparatus, including computer program products, for message processing based on address patterns. The invention provides a method for processing messages. The method includes maintaining rules, each rule includes an address pattern key and processing instructions. An address pattern key is an expression that specifies one or more address pattern instances. The method includes receiving a first message, the first message including address information associated with the sender and the intended recipient of the first message. The method includes defining an address pattern instance of the first message, an address pattern instance of a message being a combination of address information associated with a sender and an intended recipient of the message. The method includes selecting a rule that includes an address pattern key with which the defined address pattern instance matches, and processing the first message in accordance to the instructions included in the rule selected.

Description

  • The present application claims priority from U.S. Provisional Application No. 60/383,566, filed May 28, 2002, the disclosure of which is hereby incorporated by reference in its entirety.[0001]
  • BACKGROUND
  • The present invention relates to network communications. [0002]
  • Communications sent over networks can be implemented in the form of messages. A message usually includes content, which can be represented by, for example, text, images, and sound. A message also usually includes address information of a sender of the message as well as address information of an intended recipient of the message. Generally, the sender initiates the message, and the receiver, or intended recipient, is the target or the addressee of the message. A sender can be, for example, a human operator, a computer program product, and a computing system. An intended recipient can likewise be any of the mentioned entities. An intended recipient can be one or more entities. For example, a particular message can be addressed to an intended recipient representing a group of human operators. Senders and intended recipients are correspondents. [0003]
  • There are generally different types of messages. Emails, short-message-service (“SMS”) messages, voice messages, page messages, instant messaging messages, and facsimiles (i.e., faxes) are examples of messages. [0004]
  • Different types of messages can be sent over different types of networks. Email messages, for example, are typically sent over networks that include email servers. The email servers can use the Simple Mail Transfer Protocol (“SMTP”). Faxes, for example, are typically sent over networks that include fax machines. Faxes may also be sent over a network that includes computers that have fax applications. Voice messages, for example, are typically sent over a network that include voice mail servers. The networks mentioned can be part of or include portions of the Internet. [0005]
  • A message can also be sent over an interprocess communication environment (“IPCE”), which may include one network, several networks, or a subset of a network. A message can be communicated between processes in different IPCEs by relaying through a process connected to two (or more) IPCEs. That is, mail can be relayed between hosts on different transport systems by a host on both transport systems. [0006]
  • A standardized form of contact information (e.g., a contact alias) can identify one or more of the particular sender and intended recipient. Emails, for example, usually include standardized contact information, usually in the following form: “local_part@domain_part”. Telephone numbers for voice and fax, for example, also usually include standardized contact information. The standardized contact information generally includes digits that represent a country, digits that represent an area code, and digits that represent a terminal device. [0007]
  • The above mentioned networks can include technology that supports a mapping of multiple addresses to a single delivery location. Specific email addresses of a human operator can be linked, i.e., aliased, to an actual email account the human operator uses to connect to the network. For example, personal@BePrivate.com and business@BePrivate.com can both be aliased to alan@pop.BePrivate.com. Messages sent to either of the first two addresses will be delivered to the third account. Similarly, different telephone numbers can map to a single telephone or facsimile machine. Message addresses that are aliased, regardless of the type of message, are referred to in this specification as contact aliases. [0008]
  • SUMMARY
  • The present invention provides methods and apparatus, including computer program products, for automatic management and control of contact aliases. [0009]
  • In general, in one aspect, the invention provides a computer implemented method for processing messages. The method includes maintaining rules, each of which includes an address pattern key and one or more instructions for message processing, an address pattern key being an expression that specifies one or more address pattern instances. The method includes receiving a first message, the first message including address information associated with the sender of the first message and address information associated with the intended recipient of the first message. The method includes defining an address pattern instance of the first message, an address pattern instance of a message being a combination of address information associated with a sender of the message and address information associated with an intended recipient of the message. The method includes selecting, from among the rules, a rule that includes an address pattern key with which the defined address pattern instance matches. The method includes processing the first message in accordance to the one or more instructions included in the rule selected. [0010]
  • In general, in one aspect, the invention features a computer program product, tangibly stored on machine readable medium, for processing messages. The product includes instructions operable to cause a programmable processor to receive a first message, the first message including address information associated with the sender of the first message and address information associated with the intended recipient of the first message. The product includes instructions operable to define an address pattern instance of the first message, an address pattern instance of a message being a combination of address information associated with a sender of the message and address information associated with an intended recipient of the message. The product includes instructions operable to select, from among a set of rules, a rule that includes an address pattern key with which the defined address pattern instance matches, each of the set of rules including an address pattern key and one or more instructions for message processing, an address pattern key being an expression that specifies one or more address pattern instances. The product includes instructions operable to process the first message in accordance to the one or more instructions included in the rule selected. [0011]
  • In general, in another aspect, the invention provides a network transmitting agent for a specific type of network and associated management utilities. These network specific agents use stored information to lookup appropriate behavior rules for the task at hand. These rules define criteria and processes for at least accepting, rejecting, verifying, validating, and modifying incoming and outbound communications and for adding, modifying, and deleting rules. The management utilities for the network specific agents provide a means for adding, modifying and deleting rules, configuration settings, and other agent state information. [0012]
  • In one implementations where messages are email sent over an email communication network, the invention provides a specialized SMTP server and associated management utilities for processing emails, including managing consistent use of aliases. The management utilities support both a Web-based (e.g., one using HTTP(S)) and validated email interface. The present invention supports SMTP, POP3, or IMAP4 compliant email clients such as Eudora, Outlook Express, and Netscape Mail without requiring source-code level changes to those applications. [0013]
  • The invention can be implemented to realize one or more of the following advantages. A system as described in this specification can, for outbound messages, facilitate consistent use of aliases. The system can ensure that a message outbound to a particular intended recipient includes the alias the sender has designated for use with messages addressed to the particular intended recipient. The system allows one to define new aliases and change existing aliases by either passive input or active input. Passive input includes inserting a new alias in a from field of a message. Active input includes input received through an administrative interface, which can be Web-based. [0014]
  • The system allows users to maintain more than one email identity and yet use a single mailbox for all email they receive. The identity feature is further enhanced with an automatic mapping facility allowing each externally visible identity to map onto the email addresses of one or more correspondents. Users can thus appear to have a different email address (identity) for each person with whom the user correspond, because the server automatically ensures all outbound email contains the correct identity for that particular correspondent. [0015]
  • The system can, for incoming and outbound messages, apply access and processing rules. The rules can be defined to reduce spam. The system can, for example, stop accepting messages from senders whom the system does not recognize while continuing to accept messages from senders whom the system does recognize. A user, thus, need not change the address at which the user receives messages to keep from receiving spam. [0016]
  • The system can include a rules engine and a database, in which the access and processing rules can be maintained. The rules engine can be built on top of the database, which can be integrated into all mail transfer subsystems that govern both inbound and outbound email acceptance and outbound identity mapping. The rules engine allows users to restrict exactly whom they wish to correspond with through the use of access and processing rules. The rules can specify single entities or use regular expressions, allowing users to block all entities or any sub-set of the entities matching a specified pattern. The rules can include default rules and customized rules. The rules can be changed by the rules engine. That is, the system can be self-adapting. Further, the system can adapt the access and processing rules automatically and in real time. [0017]
  • The system can support different levels of default actions for receipt of messages sent to an intended recipient from a sender not recognized by the system (i.e., a new sender). The levels include: (i) accept for delivery any messages from a new sender, reject only messages from senders the intended recipient specified; (ii) request verification from the intended recipient, i.e., ask the intended recipient whether the message is to be rejected or accepted; (iii) request confirmation from the new sender before delivering the message; (iv) request verification from the intended recipient and confirmation from the new sender; (v) block any messages from new senders, accepting messages from senders with whom the intended recipient initiates communication. [0018]
  • Each of the above described levels reduces the intended recipient's susceptibility to spam, with the fifth level eliminating all spam except that which actually comes from known correspondents. Another unique productivity-enhancing feature of the rules engine is that rules for individual correspondents and even entire Internet domains can be updated through the user's client computer itself, without recourse to using resources such as Web-based administration facility. For example, in implementations where the messages are emails: [0019]
  • Forwarding a particular email to a “REJECT” address updates the rules such that emails having the same address pattern instance as the particular email will not be accepted for delivery. [0020]
  • Sending a reply to a Verify request, which was sent in response to a particular email from a correspondent, adds a rule that accepts future email having the same address pattern instance as the particular email. In addition, the system delivers any pending emails having the same address pattern instance as the particular email. [0021]
  • Sending an email to a correspondent not recognized by the system (i.e., a new correspondent) will automatically create an identity mapping based on both the correspondent's address and either the address in the “FROM” field or the user specified default identity. In addition, the new correspondent will be automatically added to the rules for that identity allowing return email to be accepted automatically. [0022]
  • Sending an email to an old correspondent with a different “FROM” field will update the identity mapping such that “FROM” address is the new default. Additionally, the new correspondent is and automatically added to the rules for that identity. [0023]
  • Receiving email from a correspondent to a new identity will automatically create the new identity, e.g., while signing up on a website you can create a new address such as memsn.com@there.com such that the incoming promotional email from that website automatically creates the identity. [0024]
  • A user of the system can therefore accomplish fine-tuning of the rules for the system through the day-to-day use of their favorite email client. [0025]
  • The rules can be defined for multiple users of the system. The database of rules can be segmented on a user by user basis. For example, rules for different users can be maintained in different tables. By being so segmented, the database is scalable. Furthermore, a user changing rules pertaining to the user locks only the user's respective segment and not segments of other users. [0026]
  • The system can use address patterns that include both sender and intended recipient address information. By doing so, the system provides a fine-grained level of control over message acceptance and processing. In one implementation, the system uses regular expression to define groups of aliases. In one implementation, the system controls and manages messages at the SMTP level so that client resources need not be consumed for the purposes of access control. In addition, server resources consumed for processing rejected messages are minimized. By supporting the use of different contact aliases for different purposes, the system provides users with the advantage of tracking unauthorized use of specific contact aliases by the corresponding trusted parties. [0027]
  • A contact alias need not be abandoned when it becomes the target of a large amount of unwanted messages (i.e., spam). The system can reject messages that are sent from new senders and addressed to the contact alias while continuing to accept messages that are sent from previous senders and addressed to the contact alias. The system can also accept messages sent from recipients of outgoing messages from the contact alias. [0028]
  • The details of one or more implementations of the invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will become apparent from the description, the drawings, and the claims.[0029]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 shows a block diagram of a system for processing messages. [0030]
  • FIGS. [0031] 2A-2C show examples of address pattern keys that are regular expressions and of a rule.
  • FIG. 3 shows a method for processing messages. [0032]
  • FIG. 4 shows another method for processing messages. [0033]
  • FIG. 5 shows an implementation of the system for processing messages. [0034]
  • FIGS. [0035] 6A-6F show examples of administrative interfaces.
  • Like reference numbers and designations in the various drawings indicate like elements. [0036]
  • DETAILED DESCRIPTION
  • FIG. 1 shows a block diagram of a [0037] system 100 for processing messages. The system includes a server 102, a rules engine 104, a database 106, and a database server 108. Alternatively, the system can include one server where the rules engine and the database can reside. The system 100 can include other computing components. For example, the system can include one or more other servers and other computer program products. The rules engine 104 can maintain a rule base stored in the database 106.
  • The rule base can include access and processing rules for messages. Each of the rules can include an address pattern key and one or more instructions for message processing. An address pattern key is an expression that specifies one or more address pattern instances. In one implementation, the address pattern keys are regular expressions. Each address pattern key can include two portions, one for address information associated with a sender (i.e., the sender portion) and another for address information associated with an intended recipient (i.e., the intended recipient portion). Each portion can include a regular expression, which is a formula for matching strings that follow a pattern. Regular expressions similar to those that can be included in the rules are further described in Portable Operating System Interface (“POSIX®”) 1003.2, which is hereby incorporated by reference in its entirety. Alternatively, the address pattern key can include one regular expression for address information associated with both a sender and an intended recipient. [0038]
  • FIGS. 2A and 2B show example regular expressions. FIG. 2A shows an address pattern key [0039] 202 that includes a sender portion 204 and an intended recipient portion 206. FIG. 2B shows an address pattern key 208 that includes an intended recipient portion 210 but not a sender portion. Address pattern keys like the address pattern key 208 are usually included in rules for alias management. FIG. 2C shows an example rule 212 that include the address pattern key 202 and one or more instructions 214. Table 1 shows examples of address pattern keys and the corresponding address pattern instances specified by, i.e., match with, the address pattern keys. In the examples, the messages are emails. However, the messages can be any type of messages. For example, the messages can be phone numbers, in which case the regular expressions will include numbers.
    TABLE 1
    Address Pattern Key Matching Address Pattern Instances
    Intended Intended
    Sender Portion Recipient Portion Sender Portion Recipient Portion
    bob\.jones@bobdomain\. bob@legal\.bobdo bob.jones@bobdomain. bob@legal.bobd
    com main\.com com omain.com
    .*@{.*\.}bobdomain\.co bob@legal\.bobdo bob.jones@bobdomain. bob@legal.bobd
    m main\.com com omain.com
    bob.jones@private.bob bob@legal.bobd
    domain.com omain.com
    sally.jones@bobdomain bob@legal.bobd
    .com omain.com
    Any sender which ends bob@legal.bobd
    with omain.com
    “@bobdomain.com”
    Any sender which ends bob@legal.bobd
    with “.bobdomain.com” omain.com
    .*@.* bob@legal\.bobdo Any sender matches bob@legal.bobd
    main\.com this pattern omain.com
    alan@BePrivate.com bob-[{circumflex over ( )}.- alan@BePrivate.com bob-
    ]+@web\.bobdom yahoo@web.bob
    ain\.com domain.com
    alan@BePrivate.com bob-
    walmart@web.b
    obdomain.com
    alan@BePrivate.com bob-
    nyctrip@web.bo
    bdomain.com
    alan@BePrivate.com Any receiver
    which begins
    with “bob-” and
    ends with
    “@web.bobdom
    ain.com”
  • One or more of the rules can also include one or more processing instructions. The instructions can specify how messages are processed and how the rules are maintained and updated. The instructions can be, for example, any combination of: accept the message for delivery, reject the message, accept the message and hold until confirmed, accept the message and hold until verified, accept the message and hold until confirmed and verified, accept the message for a duration after a particular date, accept a particular number messages and then reject, accept message until a particular date, forward messages to a particular list of locations, and define a rule. Confirmation may include customized confirmation request. A user of the system can have, for example, different confirmation request templates for different intended recipients. Further, the user can have different confirmation request templates for different address pattern instances. The system uses a confirmation request template, in conjunction with a particular message, to generate a confirmation request for the particular message. In one implementation, the user may customize the confirmation request templates by using an administrative interface, for example, a Web-based administrative interface. Updating includes defining a new rule, modifying an existing rule, and deleting an existing rule. The instructions can relate to alias management. The instructions can, for example, specify which alias of a sender is used for a message the sender is sending to a particular intended recipient. Alias management rules can be stored separately from the access and processing rules. For example, the system can have two tables for each system user, one for alias management rules and the other for access and processing rules. [0040]
  • The rules can be, for example, IF-THEN rules, IF-NOT-THEN rules, IF-THEN-ELSE rules, and any combination thereof. The system can include other types of rules. [0041]
  • In general, the system can be connected to send and receive messages to and from networks such as the Internet, and also to send to and receive messages from clients. The system can receive the message from any point in a network to which the system is connected. The system can receive the message from, for example, a client computer or a server. The system and its implementations are further described below. [0042]
  • The system can include memory where the system can store messages for future delivery. When the system receives a message, the system determines what action to take. After the system determines what action to take, the system can store the message in the memory for future delivery. [0043]
  • Methods for Processing Messages
  • FIG. 3 shows a [0044] method 300 for processing messages. A system, such as the system 100, performing method 300 receives a message (step 302). The message can be, for example, an email, an SMS message, a fax, an instant message, and a voice message. The message includes address information. The address information can include address information associated with the sender of the message and address information associated with the intended recipient of the message. The message can include content. The content can include attached electronic documents. An electronic document does not necessarily correspond to a file. A document may be stored in a portion of a file that holds other documents, in a single file dedicated to the document in question, or in multiple coordinated files.
  • The system defines an address pattern instance of the message (step [0045] 304). An address pattern instance of a message can be a combination of address information associated with a sender of the message and address information associated with an intended recipient of the message. Examples of address information associated with a sender can include and are not limited to an alias of the sender, a domain of the user, a phone number of the sender, an IP address of the sender. Examples of address information associated with the intended recipient similarly include and are not limited to an alias of the intended recipient, a domain of the intended recipient, a phone number of the intended recipient, an IP address of the intended recipient. There is generally one address pattern instance which can be defined for a given message. Multiple messages can have the same address pattern instances.
  • The system identifies which of the processing rules includes an address pattern key to which the defined address pattern instance matches (step [0046] 306). There may be instances when there are no matches, in which case the system can identify a default rule. In general, however, there are one or more rules with which the address pattern instance matches, and there are one or more rules identified. The system determines if there is more than one rule identified (decision step 308). If there is only one rule identified, then the system selects the one rule identified (step 310). If there are more than one rule identified, then the system selects one rule from among the rules identified (step 312). Criteria for the selection can be based on the specificity of the address pattern keys included in the rules. The system can select, for example, the rule that include the most specific address pattern key. Alternatively, criteria for selection can be based on an order of priority. In one implementation, the system includes a restricted set of rules. The rules are ordered by priority, and the system selects a matching one with the highest priority. The order of priority can be defined by an administrator, one or more users, or any combination of administrator and users.
  • The system processes the message in accordance to the one or more instructions included in the rule selected (step [0047] 314). The processing can occur at a point in the network such that consumption of client computing resources are reduced or minimized. Processing can occur, for example, at an SMTP server. Processing can include any action or operations one can apply to a message and the rules. For example, processing can include but is not limited to: accepting a message for delivery; rejecting a message; accepting a message, requesting verification, and delivering the message upon receipt of verification; accepting a message, requesting confirmation, and delivering the message upon receipt of confirmation; accepting a message, requesting confirmation and verification, and delivering the message upon receipt of confirmation and verification; defining a new rule; or any of the above combination.
  • FIG. 4 shows a [0048] method 400 for processing messages. A system, such as the system 100, performing method 400 receives an outbound message (step 402). The message can be, for example, an email, an SMS message, a fax, an instant message, and a voice message. The message includes address information. The address information can include address information associated with the sender of the message and address information associated with the intended recipient of the message. The message can include content. The content can include attached electronic documents.
  • The system defines an address pattern instance of the message (step [0049] 404). An address pattern instance of a message can be the address information associated with an intended recipient of the message.
  • The system identifies alias management rules that include address pattern keys with which the defined address pattern instance matches (step [0050] 406). The alias management rules maps aliases to intended recipients. That is, an alias management rule specifies which of the sender's aliases is to be used for which of the intended recipients. The system determines if there is more than one rule that includes an address pattern key with which the address pattern instance matches (step 408). If there is only one rule, then the system selects this rule (step 410). If there are more than one rule, then the system selects a rule from among those identified (step 412). Criteria for the selection can be based on the specificity of the address pattern keys included in the rules. The system can select, for example, the rule that includes the most specific address pattern key. Alternatively, criteria for selection can be based on an order of priority. In one implementation, the system includes a restricted set of rules. The rules are ordered by priority, and the system selects the matching one with the highest priority. The order of priority can be defined by an administrator, one or more users, or any combination of administrator and users. The system processes the message in accordance with the instructions of the rule selected (step 414). Processing includes managing aliases and ensuring consistent alias use. The system can determine whether the alias currently in the message is the same as the alias specified in the rule selected, and changing the alias in the message as appropriate, for example, to be the same as the one specified in the rule selected. Processing can also include defining new rules. Processing can include, for example, changing an alias specified in the rule selected to be the same as the alias of the current message. Alternatively, processing can include other actions such as, for example, those described above with respect to method 300.
  • In one implementation, the system is a privacy-oriented email system that includes an integrated suite of high-performance email processing server applications and a rules engine driven by a database that contains account and configuration information. Together, these applications manage the privacy of email identities used for correspondence. Each user has one mailbox that contains all of the email for all of his or her email identities. The system keeps track of which identity is used with each correspondent. Additionally, each mailbox can span multiple domains allowing a user's choice of identity to also span multiple domains. As will be seen, also included in the system suite are a Web-based user account, domain, and identity administration application and a Web-mail application. [0051]
  • As shown in FIG. 5, system [0052] 500 includes: an SMTPD component 502, a POPD component 504, a FETCH component 506, an ADMIN component 508, a WEB component 510, and an AIRDB (account information & rules database) component 512. The components are connected as indicated to each other, the Internet, email clients, remote email accounts, and Web clients.
  • The SMTPD component [0053] 502 is a server for processing both inbound messages from the Internet and outbound messages from email clients. The POPD component 504 is a POP3 server for establishing inbound email client connections. The FETCH component 506 is a POP3 client for fetching email from remote POP3 servers. The ADMIN component 508 is a computer program product that provides a Web-based interface for administering user accounts, domains, and identities. The ADMIN component 508 resides on an HTTP server, for example, the Boa Webserver. The WEB component 510 is a computer program product that provides a Web-based email client interface. The AIRDB 512 is database of user account information used by all of the above components. The following described each component in further detail.
  • SMTPD—Intelligent SMTP Server [0054]
  • The SMTPD server [0055] 502 is a mail transfer agent utilizing the SMTP protocol standard. It acts as a server for sending and receiving the following:
  • Inbound email for all domains and sub-domains configured in the AIRDB component [0056] 512.
  • Relayed (outbound) email from user email clients, provided they have checked their email account from the same IP address in a specified time period, for example, the last 15 minutes. [0057]
  • Supports the extended SMTP commands for pipelining of commands and for supporting 8-bit mime types. [0058]
  • In one implementation, the SMTPD server [0059] 502 is compliant with the SMTP standard, according to RFC 2821.
  • The following describes inbound email delivery. In order to receive email, the inbound destination email address must map to configured domain or sub-domain, then to an address group corresponding to a user account, and then to a mailbox. Once the inbound address has been mapped to a user's mailbox, the email will only be accepted and processed according to the email handling rules for the correspondent in the FROM address of the SMTP envelope and the specified receiving identity in the TO address of the SMTP envelope. The various types of email processing instructions are as indicated below. [0060]
  • Message processing instructions include and are not limited to: [0061]
  • Accept all messages (Accept). [0062]
  • Accept a certain number of messages and then reject the rest (Accept Some). This is a two part action. The first determines whether to accept or reject a message based on a counter. The second decrements the counter after a message has been accepted. [0063]
  • Accept any number of messages up until a particular date and then reject the rest (Accept Until). [0064]
  • Reject all messages (Reject). [0065]
  • More complex handling rules include and are not limited to: [0066]
  • Ask the sender to send a confirmation message before delivering the message. After receiving confirmation, create a new accept always rule that includes the current address pattern instance as the rule's address pattern key. (Confirm & Create) [0067]
  • Ask the receiver to verify the sender before delivering a message (Verify). [0068]
  • Ask the sender to send a confirmation message, then ask the receiver to verify the sender before delivering a message (Confirm & Verify). [0069]
  • Accept a message from a new sender and create a new accept some rule that includes the current address pattern instance as the rule's address pattern key. (Accept & Create) [0070]
  • After a sender has either confirmed or been verified, all of their subsequent email will continue to be accepted/rejected and so forth until the user specifies otherwise. If not confirmed/verified, the email will be rejected for receipt after a timeout, for example, 7 days. [0071]
  • All of the rules support defining the sender “FROM” to be any of the following: [0072]
  • A specific person (i.e., specific email address). [0073]
  • A specific group of people (i.e., specific domain or sub-group within a domain). [0074]
  • Everyone. [0075]
  • All of the rules support defining the recipient “TO” to be any of the following: [0076]
  • A specific identity (i.e., specific email address). [0077]
  • A group of identities (i.e., specific prefix with a specific domain). [0078]
  • A entire domain's worth of identities. [0079]
  • The above described list of actions is not exhaustive. Table 2 shows an example set of actions. [0080]
    TABLE 2
     AA - Accept always and do not create a more specific rule
     AA+ - Accept always and create more specific rule
     ACA+ - Accept and hold until confirm, then deliver message(s) and create specific
    rule for F:T = Accept always.
     ACN + n - Accept and hold until confirm, then deliver message(s) and create specific
    rule for F:T = Accept n-messages.
     ACE + n - Accept and hold until confirm, then deliver message(s) and create specific
    rule for F:T = Accept until n days from receipt of initial message.
     AVA+ - Accept and hold until verified, then deliver message(s) and create specific
    rule for F:T = Accept always.
     AVN + n - Accept and hold until verified, then deliver message(s) and create specific
    rule for F:T = Accept n-messages.
     AVE + n - Accept and hold until verified, then deliver message(s) and create specific
    rule for F:T = Accept until n days from initial msg.
     ACVA+ - Accept and hold until confirm, then hold until verified, and then deliver
    message(s) and create specific rule for F:T = Accept always.
     ACVN + n - Accept and hold until confirm, then hold until verified, and then deliver
    message(s) and create specific rule for F:T = Accept n-messages.
     ACVE + n Accept and hold until confirm, then hold until verified, and then deliver
    message(s) and create specific rule for F:T = Accept until n days from receipt of initial
    message.
     ANn - Accept n-messages and then reject any additional.
     AN + n - Create specific rule for F:T = Accept n-messages.
     AEyyyymmdd - Accept until specified date and then reject all subsequent messages.
     AE + n - Create specific rule for F:T = Accept until n-days from today.
     FA(list, . . .) - Replace current recipient with the recipient addresses contained in the
    list, if at least one member of the list accepts message, then accept the message.
     FT(list, . . .) - If first item accepts the message, then accept the message. Add each
    recipient in the list to the recipient list until encountering one which rejects the message.
     R - Reject any messages.
     For all of the following, variations which include verification, confirmation or both
    confirmation and verification steps prior to messages being delivered and rules instantiated
    are supported. (‘s’ and ‘r’ can be any of the these values: P - Prefix, S - Suffix, L -
    LocalPart, D - Domain, B - Base Domain, M - Sub-Domain.)
     AMsrA: If the sender address part specified by ‘s’ matches the recipient part specified
    by ‘r’, then accept message.
     AMsrNn: If the sender address part specified by ‘s’ matches the recipient part
    specified by ‘r’, then accept n-messages and then reject any additional.
     AMsrEyyyymmdd: If the sender address part specified by ‘s’ matches the recipient
    part specified by ‘r’, then accept until specified date and then reject any additional.
     AMsrA+: If the sender address part specified by ‘s’ matches the recipient part
    specified by ‘r’, then create specific rule F:T = accept all message.
     AMsrN + n: If the sender address part specified by ‘s’ matches the recipient part
    specified by ‘r’, then create specific rule F:T = accept n-messages and then reject any
    additional.
     AMsrE + n: If the sender address part specified by ‘s’ matches the recipient part
    specified by ‘r’, then create specific rule F:T = accept until n-days from now and then reject
    any additional.
     AXNr+: Using the ‘r’ part of the recipient, create a specified rule, F:T = Accept ‘r’
    messages and then reject any additional.
     AXEr+: Using the ‘r’ part of the recipient, create a specified rule, F:T = Accept all
    messages until ‘r’ days from now and then reject any additional.
     (For the following, ‘id’ specifies either a user created or system provide template file
    which is used to generate a reply message to the sender.)
     ARA-id: Accept all messages and auto-reply with message ‘id’.
     ARNn-id: Accept n-messages, auto-reply to each with message ‘id’.
     AREyyyymmdd-id: Accept all messages until specified date auto-reply with message
    ‘id’.
     RA + -id: Create a specific rule, F:T = Accept all messages and auto-reply with message
    ‘id’.
     RN + n-id: Create a specific rule, F:T = Accept n-messages, auto-reply to each with
    message ‘id’.
     ARE + n-id: Create a specific rule, accept all messages until n days from now, auto-
    reply to each with message ‘id’.
  • The following discusses inbound automated rules update. The AIRDB component [0081] 512 can be updated passively through the normal use of email, and through the use of several special email addresses recognized by the system. That is, users of the system can update rules without recourse to the ADMIN Web-based administration interface. A user can add correspondents to the user's rule base in the following ways:
  • Sending an particular email to a correspondent adds a rule that accepts email having the same address pattern instance as the particular email. [0082]
  • Sending a reply to a Verify request, which was sent in response to a particular email from a correspondent, adds a rule that accepts future email having the same address pattern instance as the particular email. In addition, the system delivers any pending emails having the same address pattern instance as the particular email. [0083]
  • Forwarding of an inbound email to the special email addresses, used for Accept and Reject. The special email addresses are formed using accept or reject suffixes to the prefix address for an email account, for example: [0084]
  • Forwarding an email from a correspondent to my-accept@there.com adds a rule that accepts future emails from the correspondent. The rule can be made to apply to all of the user's identities (e.g., all of the user's aliases) or only to the identity specified in the email forwarded. [0085]
  • Forwarding an email from a correspondent to my-reject@there.com adds a rule that rejects future emails from the correspondent. The rule can be made to apply to all of the user's identities (e.g., all of the user's aliases) or only to the identity specified in the email forwarded. [0086]
  • Repeatedly forwarding to either of these addresses adds additional rules that are less specific than those described above. That is, each additional instance of forwarding adds a less specific rule (i.e., one having a less specific address pattern key). This generalization continues until an entire domain and any of its sub domain are accepted or rejected. [0087]
  • The [0088] AIRDB component 412 can be updated actively, i.e., by input through the Web-based administrative interface.
  • The SMTPD server [0089] 502 uses a MailID field that is inserted into the subject line of each inbound email to identify which pair of identities is to be confirmed or rejected. The MailID field is used to identify the specific address pattern instance for use with the REJECT and ACCEPT special addresses. This feature allows consistent behavior across all email clients. This unique identifier can be added to the subject line to provide a consistent way of identifying the specific SENDER and RECIPIENT for the message. The unique identifier is used by the ACCEPT and REJECT process to create the appropriate rules for the pair of FROM-TO addresses. While the SENDER and RECIPIENT information can be extracted from the headers of the message, not all email clients pass all of the headers back to the system when replying to messages. The MailID in the subject line is thus needed to ensure consistent behavior across clients.
  • The following describes outbound email processing and rules updating. In order to send email, users set their email client to point to the SMTPD Server. The server will relay email from the client provided the user has checked their mailbox in a specified period, e.g. in the past 15 minutes. SMTPD will do the following to all outbound email: [0090]
  • If the “FROM” identity: [0091]
  • Matches the user's defined replacement string (e.g. my-replaceme@there.com) then the server uses the “TO” address to find the either a preferred identity or the default identity in the case this is a new recipient, and alters the “FROM” address accordingly; OR [0092]
  • Is a valid identity for the user and is not the replacement string, then SMTPD will set the preferred identity for the “TO” address to this value. This will either setup a new mapping of the identity or override a previous one. [0093]
  • Next, the server adds an entry in an appropriate rule for the used identity to allow any future email from the “TO” address to be accepted without any further processing. [0094]
  • Email is then sent to the recipient as per normal SMTP processing [0095]
  • The SMTP server [0096] 502 implements the following properties and features.
  • A contact alias is provided that is a place holder for triggering substitution of a consistent sender-to-receiver contact alias. [0097]
  • A default sender contact alias is provided to be used if one is not specified or available, such as when the receiver sends a message to a new intended recipient. [0098]
  • A set of default rules is provided to be used for defining access and processing rules for new intended recipients with whom the sender has initiated communications. Table 3 below shows an example set of the default rules. [0099]
  • A set of access and processing rules is provided for deciding what to do when inbound email is processed for specific sender contact alias and receiver contact alias pairs or patterns of such pairs. A minimal set of rules is specified below. [0100]
  • A set of intended recipient contact alias or pattern to sender contact alias preference information is provided for use in maintaining a consistent sender contact alias for specific receivers or groups of receivers. [0101]
  • A set of email alias or email alias patterns to mailbox information is provided for use in processing inbound and outbound email. [0102]
    TABLE 3
     Possible Default Actions for outgoing email where reply email is not
     covered by an accept-variant:
     Accept: Sending email to an address authorizes that address to reply
     back to the sending address without further authorization
     Ntimes-N: Sending email to an address authorized that address to reply
    back to the sending address up to N messages after which further email
    will be rejected
     Expires-N: Sending email to an address authorizes that address to reply
    back to the sending address for up to N days from the date of the initial
    message
     If the action for the reverse (reply) rule is:
     Accept - Nothing needs to be done
     Accept N-msgs - If empty, increase authorized message count by
     ‘empty-add’
     Accept until - If expired, increase authorized time period by
     ‘expired-add’
     Confirm/Verify - Add appropriate rule w/o requiring confirm or verify
     Pending - Convert as if confirmed/verified and deliver all pending email
     Reject - Use default action for previously unspecified new recipients.
  • In one implementation, the SMTP server [0103] 502 can have at least the minimum implementation as specified in 4.5.1 Minimum Implementation, RFC 2821, “Simple Mail Transfer Protocol”, J. Kleinsin, Editor, April 2001. In response to a MAIL command, the system can identify if the sender is a valid system user such that outbound email processing behaviors should be used. In response to a RCPT command, the system can identify if the receiver is a valid system user such that inbound email processing behaviors should be used. If outbound processing has been specified and if the sender contact alias matches the placeholder contact alias or pattern, then the system can substitute in the FROM field of the message either the sender contact alias associated with the intended recipient or the default contact alias if a previous mapping does not exist. If inbound processing has been specified, the system can find the first rule for the receiver's mailbox that matches the sender contact alias and receiver alias used by the sender and, furthermore, use the first part of the action to decide whether to reject or accept the message. If no rule is found, then the system can reject the message. If neither inbound or outbound processing has been specified, then the server should handle the relay request as per site specific configurations as specified in RFC 2821.
  • After successful processing of a DATA command the following actions may be taken or they may be delayed until after the currently connected SMTP client, server or relay exits the session. If a substitution of sender contact alias was performed after the RCPT command, then the system can rewrite the affected areas of the message body to match. For inbound email, the system can execute the second part of the rule that matched. For outbound email for non-system users, the system can send the email to the receiver using standard SMTP protocols and procedures as specified in RFC 2821. [0104]
  • FETCH—POP3 Client [0105]
  • FETCH is used to regularly retrieve email from remote 3rd party POP3 servers, as configured by each user. FETCH makes use of the rules engine, so that retrieved email is subject to most of the same acceptance rules used for inbound email from SMTPD. The variations in rule processing occur because the semantics of some of the rules do not make sense when applied to retrieved email, for example: [0106]
  • Confirmation of incoming email cannot be handled since the confirmation message would be from a different email identity than the one being retrieved [0107]
  • Initially, a blanket rejection of retrieved email cannot be handled since there is no processing of outbound email on the external email account that would allow for the learning of acceptable correspondents. [0108]
  • After processing an external email account for a period of time, the user could set the rule to reject any new senders while allowing all previously authorized users to continue using that address. [0109]
  • In one implementation, POPD complies with RFC 1939 (POP3 Commands and Responses), using plain text authentication. [0110]
  • POPD—POP3 Server [0111]
  • POPD is a POP3 Server that handles incoming POP3 client access according to a protocol, e.g., RFC 1939 (POP3 Commands and Responses), using either plain text or APOP authentication. RFC1939 compliance ensures that POPD interoperates with the user's preferred email client (e.g., Outlook Express, Outlook, Eudora, Netscape Mail, etc.). POPD does not require use of the rules engine, but does make use of AIRDB in order to confirm user access and to find the users email. [0112]
  • ADMIN—User Account, Domain and Identity Administration: [0113]
  • While the user can accomplish most tasks simply using their preferred email client, there are some operations that require a more sophisticated interface. ADMIN is a web application that supports the following: [0114]
  • User account creation, payments and renewals [0115]
  • Domain email service setup and administration [0116]
  • Default identity specification [0117]
  • Creation of new domain identity groups [0118]
  • Modification of rules for specific identities and groups of identities to either increase or decrease protection for those identities [0119]
  • In one implementation, the Boa HTTP Server provides the platform on which this application runs. This open source server was built with a security and performance focus. [0120]
  • The management utilities implement the following properties and features. [0121]
  • Support system level mailbox operations: [0122]
  • Establishing of a new mailbox defining a set of email contact aliases and pattern(s) that map to the mailbox, an initial set of access and processing rules, initial values for placeholder and default-sender as describe above in the SMTP server description. [0123]
  • Modification of existing mailboxes to view, add, modify or delete existing email alias or pattern(s) that map receiver contact aliases to mailboxes. [0124]
  • Removal of the mappings and all associated files and data for a specific mailbox. [0125]
  • Support mailbox level operations: [0126]
  • View, add, modify, delete preferred sender contact alias information for target receivers or patterns of receivers. [0127]
  • View, add, modify, delete access and processing rules [0128]
  • These management utilities can be implemented in both a Web-based system and an email based system. The Web-based system provides authentication of the user and supports all of the above list of behaviors and properties. The email based system provides as a minimum the ability to set basic rules for specific contact alias pairings as a result of forwarding or redirecting email to specific receiver contact aliases. The minimal set of actions can include setting the following types of rules for the specific contact alias pairing contained in the email: Reject always; and accept always. The type of rule to be created can be based on the receiver contact alias. [0129]
  • FIGS. [0130] 6A-6F show examples of administrative interfaces, one or more of which can be Web-based. FIG. 6A shows an example of an administrative interface for managing email domains. The interface includes a list 602 of domains being managed by the system. The interface includes a field 604 for adding domains to be to be managed by the system. The interface includes a field 606 for checking availability of a domain name. The interface includes elements, such as element 608, for adding sub-domains to a domain. The interface includes elements, such as element 610, for specifying actions to be taken for each domain. FIG. 6B shows an administrative interface for configuring an email domain. The administrative interface allows a user to specify whether the new domain will be a multi-user domain or a single-user domain. The administrative interface also allows the user to specify Domain Name System setup options.
  • FIG. 6C shows an example of an administrative interface for managing address groups. A user can add an address group by using one of the user's own domain names, using another's domain name, and retrieving one of the user's POP account. The interface includes a [0131] field 614 for adding one of the user's domain names. The interface includes a field 616 for adding a domain name of another. The interface includes a field 618 for retrieving one of the user's POP account.
  • For each address group, the user can specify one or more identities for the system to manage. FIG. 6D shows an example of an administrative interface for managing identities. The interface includes an [0132] area 620 for creating new identities. Area 620 includes an area 622 for defining new identities and an area 624 for defining new group identities. The administrative interface includes fields, such as field 626, for specifying actions to be taken with respect to the newly defined identities or group identities. The administrative interface includes elements which actuation creates the identities and corresponding rules. The administrative interface also includes lists of identities being managed by the system such as, for example, list 630 for showing group identities, list 632 for showing identities specified by the user, and list 634 for showing identities that are learned and passively created by the system in response to the user's use of the system.
  • FIG. 6E shows an administrative interface for managing aliases. The administrative interface includes an [0133] area 636 for specifying the default identity. The administrative interface includes an area 638 for specifying preferred identities for sending emails. The administrative interface includes a list 640 of recipients (i.e., the intended recipients) and a list 642 of aliases to be used to correspond with the recipients.
  • FIG. 6F shows an administrative interface for managing accept/reject (i.e., access and processing) rules. The administrative interface includes an [0134] area 644 for a display filter. The user may wish to use the filter to display a subset of the set of recipients with whom the user corresponds. The administrative interface includes a list 646 of recipients. The administrative interface includes a list 648 of the user's aliases to be used when corresponding with the respective recipients. The administrative interface includes fields 650 of actions that specify actions to be taken for messages sent from the recipient and addressed to the alias specified.
  • WEB—Web Email Client [0135]
  • While a user may use their preferred email client, not all clients provide features which allow users to access all of the flexibly of the system. The WEB application provides a standard web based email client with specific additions to make the dynamic creation of new identities easy and fast. [0136]
  • WEB provides all of the core email functionality that is required to read, write, delete, forward, reply and deal with attachments. In one implementation, this application runs on top of the Open Source Boa HTTP server for performance, security and scalability reasons. [0137]
  • Domain Management [0138]
  • The [0139] SMTP server 402, like other SMTP mail transfer agents, is configured to handle email for particular Internet Domains. Internet Domains can come in a variety of types, based on the use to which the domain will be put. Domains can either be used to serve email to a single user or to multiple users. Single user domains are known as “Catch-All” domains because all email destined for the domain (whatever the specific address used) is delivered to a single mailbox. Multiple user domains can have an unlimited number of users, each of which may have many distinct identities. Every mailbox can aggregate multiple email identities from one or more domains or sub-domains, regardless of the type of the domains. Unlike other mail systems, the system proposes to allow every user to have an unlimited number of identities, spread across a variety of Internet Domains.
  • The possible configurations for providing email service to a domain are as indicated below. [0140]
  • Multiple User Domain Configurations: [0141]
    Type A Fixed identity with a prefix for defining new identities. Each
    user has a specific identity like “bob@there.com” along with a
    prefix that they can use to create additional identities such as
    “bobanything@there.com”.
    Type B. Sub-domains for either groups or individuals. Each domain can
    have sub-domains like “sales.there.com” for handling groups of
    associated people, or a sub-domain may be for individual use as
    a “Catch-All” sub-domain such as “ceo.there.com”.
    Type C. Fixed identity with both a prefix and variable sub-domains for
    defining new identities. Each user has a specific identity like
    “bob@there.com” and a prefix that they can use to create
    additional identities such as “bob-anything@there.com”. In
    addition, the user can create new sub-domains like
    “bob@support.there.com” or bob-Yahoo@web.there.com to add
    even greater flexibility in defining new identities.
    Type D. Fixed sub-domain as a “Catch-All” for defining new identities.
    Each user has a specific sub-domain like “ceo.there.com” or
    “bob.there.com” which is used as a “Catch-All” domain. This
    allows each user great freedom in defining new identities since
    any address that ends with their sub-domain like
    “sales-info@bob.there.com” will be delivered to them.
  • Single User Domain Configurations: [0142]
    Type E. “Catch-All” domain for defining new identities. Each user
    has a specific domain like “bobjones.com” which is used as a
    “Catch-All” domain. This allows the user great freedom in
    defining new identities since any address that ends with their
    domain like “info@bobjones.com” will be delivered to them.
    Type F. “Catch-All” domain with variable sub-domains for defining new
    identities. Each user has a specific domain like “bobjones.com”
    which is used as a “Catch-All” domain. This allows the user
    great freedom in defining new identities since any address that
    ends with their domain like “info@bobjones.com” will be
    delivered to them.”. In addition, the user can create new
    sub-domains like “robert@support.bobjones.com” or
    “yahoo@chat.bobjones.com” to add even greater flexibility in
    defining new identities.
  • Alternatives
  • Voice Messages [0143]
  • For voice communication networks, one implementation utilizes either a software program or hardware instantiation of the software running in the central telephone office which provides the point-of-entry for the user or a software or hardware instantiation of the software running at the end-point of the telephone connection (e.g., the user's telephone is connected to a fax/data/voice modem card which runs the server software) and associated management utilities that implements the details of the system and method of the present invention. The management utilities can support both a Web-base (e.g., one that uses HTTP(S)) and voice/keypad interactive system. The contact alias for voice networks is defined as a telephone number which ultimately maps to a specific telephone or centralized phone system (e.g., local phone system for an office). A minimal set of rules for voice communications includes: Accept call and ring through, Forward call to voice mail, Forward call to another number, Reject the call with a specific message, Request entering of a response to a specific question and redirect call based on the answer. All of the properties of the rules specified for email are applicable for this situation. [0144]
  • Data Messages [0145]
  • For data communication networks, one implementation utilizes either a software program or hardware instantiation of the software running in the central telephone office which provides the point-of-entry for the user or a software or hardware instantiation of the software running at the end-point of the telephone connection (e.g., the user's telephone is connected to a fax/data/voice modem card which runs the server software) and associated management utilities that implements the details of the system. The management utilities, in one implementation, can support both a Web-based and voice/keypad interactive system. The contact alias for data networks is defined as a telephone number which ultimately maps to a specific facsimile machine or facsimile emulator or centralized phone system (e.g., local phone system for an office). The minimal set of rules associated with voice communication networks would also apply to data communication networks. All of the properties of the rules specified for email are applicable for this network. [0146]
  • The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The invention can be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network. [0147]
  • Method steps of the invention can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by, and apparatus of the invention can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). [0148]
  • Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry. [0149]
  • To provide for interaction with a user, the invention can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. [0150]
  • The invention can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the invention, or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet. [0151]
  • The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. [0152]
  • The invention has been described in terms of particular embodiments. Other embodiments are within the scope of the following claims. For example, the steps of the invention can be performed in a different order and still achieve desirable results. The rules base can include rules that are based on an access control list. The rules can restrict outbound mail, for example, to limit communications to an approved set of correspondents via a form of centrally-managed outbound rule base.[0153]

Claims (59)

What is claimed is:
1. A computer-implemented method for processing messages, the method comprising:
maintaining rules, each of which includes an address pattern key and one or more instructions for message processing, an address pattern key being an expression that specifies one or more address pattern instances;
receiving a first message, the first message including address information associated with the sender of the first message and address information associated with the intended recipient of the first message;
defining an address pattern instance of the first message, an address pattern instance of a message being a combination of address information associated with a sender of the message and address information associated with an intended recipient of the message;
selecting, from among the rules, a rule that includes an address pattern key with which the defined address pattern instance matches; and
processing the first message in accordance to the one or more instructions included in the rule selected.
2. The method of claim 1, further comprising:
identifying which of the rules includes an address pattern key to which the defined address pattern instance matches, wherein the selecting is based on an order of priority of the rules identified.
3. The method of claim 1, further comprising:
identifying which of the rules includes an address pattern key to which the defined address pattern instance matches, wherein the selecting is based on the specificity of the address pattern keys of the rules identified.
4. The method of claim 3, wherein selecting includes:
selecting the rule having a most specific address pattern key.
5. The method of claim 4, wherein:
maintaining rules include maintaining IF-THEN rules, an IF-THEN rule specifying that if a message's address pattern instance matches with the rule's address pattern key, then the message is to be processes in accordance with the rule's instructions.
6. The method of claim 5, wherein the intended recipient of the first message is a first user, and wherein at least one of the rules includes an address pattern key that specifies address pattern instances that include address information associated with the first user as an intended recipient, the at least one of the rules further including an instruction to accept messages for delivery, the method further comprising:
defining a new rule to not accept for delivery all messages addressed to the first user, the new rule including an address pattern key that specifies address pattern instances having address information associated with anyone as a sender and address information associated with the second user as an intended-recipient, the at least one of the rules including an address pattern key that is more specific than the address pattern key of the new rule, whereby messages having address pattern instances that do not match the address pattern key of the at least one of the rules are not accepted for delivery and messages having address pattern instances that do match the address pattern key of the at least one of the rules are accepted for delivery.
7. The method of claim 6, wherein:
the sender of the first message is a second user; and
the at least one of the rules includes an address pattern key that specify address pattern instances having address information associated with the second user as a sender and address information associated with the first user as the intended recipient, whereby messages from senders not already specified in the rules are not accepted for delivery and messages from the second user are accepted for delivery to the first user.
8. The method of claim 1, wherein the intended recipient of the first message is a first user, the method further comprising:
in response to the first user sending a message to a second user, defining a new rule to accept for delivery to the first user messages from the second user, the new rule including an address pattern key that specifies the pattern instance that includes a combination of address information associated with the second user as a sender and address information associated with the first user as an intended recipient.
9. The method of claim 1, wherein maintaining rules includes:
maintaining a rule that includes an instruction to accept, for a number of instances, messages having address pattern instances that matches the address pattern key of the rule.
10. The method of claim 1, wherein maintaining rules includes:
maintaining a rule that includes an instruction to accept, until a date, messages having address pattern instances that matches the address pattern key of the rule.
11. The method of claim 1, wherein maintaining rules includes:
maintaining a rule that includes an instruction to accept, for an interval after a date, messages having address pattern instances that matches the address pattern key of the rule.
12. The method of claim 1, wherein maintaining rules includes:
maintaining a rule that includes an instruction to accept, upon confirmation, messages having address pattern instances that matches the address pattern key of the rule.
13. The method of claim 1, wherein maintaining rules includes:
maintaining a rule that includes an instruction to accept, upon verification, messages having address pattern instances that matches the address pattern key of the rule.
14. The method of claim 1, wherein maintaining rules includes:
maintaining a rule that includes an instruction to accept, upon verification and confirmation, messages having address pattern instances that matches the address pattern key of the rule.
15. The method of claim 1, wherein maintaining rules includes:
maintaining a rule that includes an instruction to define a new rule.
16. The method of claim 1, wherein maintaining rules includes:
maintaining a rule that includes an instruction to forward messages having address pattern instances that matches the address pattern key of the rule.
17. The method of claim 1, wherein:
processing the message includes processing the message at an SMTP server.
18. The method of claim 1, wherein:
receiving a message includes receiving an email, the email including address information associated with the sender of the email and address information associated with the intended recipient of the email.
19. The method of claim 18, wherein:
receiving an email includes receiving an email in which at least one of the address information associated with the sender and the address information associated with the intended recipient is a contact alias.
20. The method of claim 1, wherein:
maintaining rules includes maintaining rules that include address pattern keys include alias information.
21. The method of claim 1, wherein:
receiving a message includes receiving one of an outbound message and an inbound message.
22. The method of claim 1, wherein:
receiving a message includes receiving a short-message-service (“SMS”) message.
23. The method of claim 1, wherein:
receiving a message includes receiving a voice mail message.
24. The method of claim 1, wherein:
receiving a message includes receiving a fax message.
25. The method of claim 1, further comprising:
automatically updating the rules being maintained in response to input.
26. The method of claim 25, wherein:
automatically updating includes one of defining a new rule, modifying an existing rule, and deleting an existing rule.
27. The method of claim 25, wherein:
automatically updating in response to input includes automatically updating in response to one of receiving a message, sending a message, forwarding a message to a particular address, detecting a particular string in a message, input received through an administrative interface.
28. The method of claim 1, wherein:
maintaining rules includes maintaining rules that include address pattern keys that are regular expressions.
29. The method of claim 28, wherein:
one of the regular expressions specifies different email address domains.
30. The method of claim 28, wherein:
one of the regular expressions specifies different contact aliases for a given email address domain.
31. A computer program product, tangibly stored on a computer-readable medium, for processing messages, the product comprising instructions operable to cause a programmable processor to:
receive a first message, the first message including address information associated with the sender of the first message and address information associated with the intended recipient of the first message;
define an address pattern instance of the first message, an address pattern instance of a message being a combination of address information associated with a sender of the message and address information associated with an intended recipient of the message;
select, from among a set of rules, a rule that includes an address pattern key with which the defined address pattern instance matches, each of the set of rules including an address pattern key and one or more instructions for message processing, an address pattern key being an expression that specifies one or more address pattern instances; and
process the first message in accordance to the one or more instructions included in the rule selected.
32. The product of claim 31, further comprising instructions to:
identify which of the rules includes an address pattern key to which the defined address pattern instance matches, wherein the selecting is based on an order of priority of the rules identified.
33. The product of claim 31, further comprising instructions to:
identify which of the rules includes an address pattern key to which the defined address pattern instance matches, wherein the selecting is based on the specificity of the address pattern keys of the rules identified.
34. The product of claim 33, further comprising instructions to:
select the rule having a most specific address pattern key.
35. The product of claim 34, further comprising instructions to:
maintain IF-THEN rules, an IF-THEN rule specifying that if a message's address pattern instance matches with the rule's address pattern key, then the message is to be processes in accordance with the rule's instructions.
36. The product of claim 35, wherein the intended recipient of the first message is a first user, and wherein at least one of the rules includes an address pattern key that specifies address pattern instances that include address information associated with the first user as an intended recipient, the at least one of the rules further including an instruction to accept messages for delivery, the product further comprising instructions to:
define a new rule to not accept for delivery all messages addressed to the first user, the new rule including an address pattern key that specifies address pattern instances having address information associated with anyone as a sender and address information associated with the second user as an intended-recipient, the at least one of the rules including an address pattern key that is more specific than the address pattern key of the new rule, whereby messages having address pattern instances that do not match the address pattern key of the at least one of the rules are not accepted for delivery and messages having address pattern instances that do match the address pattern key of the at least one of the rules are accepted for delivery.
37. The product of claim 36, wherein:
the sender of the first message is a second user; and
the at least one of the rules includes an address pattern key that specify address pattern instances having address information associated with the second user as a sender and address information associated with the first user as the intended recipient, whereby messages from senders not already specified in the rules are not accepted for delivery and messages from the second user are accepted for delivery to the first user.
38. The product of claim 31, wherein the intended recipient of the first message is a first user, the product further comprising instructions to:
in response to the first user sending a message to a second user, define a new rule to accept for delivery to the first user messages from the second user, the new rule including an address pattern key that specifies the pattern instance that includes a combination of address information associated with the second user as a sender and address information associated with the first user as an intended recipient.
39. The product of claim 31, further comprising instructions to:
maintain a rule that includes an instruction to accept, for a number of instances, messages having address pattern instances that matches the address pattern key of the rule.
40. The product of claim 31, further comprising instructions to:
maintain a rule that includes an instruction to accept, until a date, messages having address pattern instances that matches the address pattern key of the rule.
41. The product of claim 31, further comprising instructions to:
maintain a rule that includes an instruction to accept, for an interval after a date, messages having address pattern instances that matches the address pattern key of the rule.
42. The product of claim 31, further comprising instructions to:
maintain a rule that includes an instruction to accept, upon confirmation, messages having address pattern instances that matches the address pattern key of the rule.
43. The product of claim 31, further comprising instructions to:
maintain a rule that includes an instruction to accept, upon verification, messages having address pattern instances that matches the address pattern key of the rule.
44. The product of claim 31, further comprising instructions to:
maintain a rule that includes an instruction to accept, upon verification and confirmation, messages having address pattern instances that matches the address pattern key of the rule.
45. The product of claim 31, further comprising instructions to:
maintain a rule that includes an instruction to define a new rule.
46. The product of claim 31, further comprising instructions to:
maintain a rule that includes an instruction to forward messages having address pattern instances that matches the address pattern key of the rule.
47. The product of claim 31, wherein:
processing the message includes processing the message at an SMTP server.
48. The product of claim 31, further comprising instructions to:
receive an email, the email including address information associated with the sender of the email and address information associated with the intended recipient of the email.
49. The product of claim 48, further comprising instructions to:
receive an email in which at least one of the address information associated with the sender and the address information associated with the intended recipient is a contact alias.
50. The product of claim 31, further comprising instructions to:
maintain rules that include address pattern keys include alias information.
51. The product of claim 31, further comprising instructions to:
receive a message that is a short-message-service (“SMS”) message.
52. The product of claim 31, further comprising instructions to:
receive a message that is a voice mail message.
53. The product of claim 31, further comprising instructions to:
receive a message that is a fax message.
54. The product of claim 31, further comprising instructions to:
automatically update the rules being maintained in response to input.
55. The product of claim 54, wherein:
automatically updating includes one of defining a new rule, modifying an existing rule, and deleting an existing rule.
56. The product of claim 54, wherein:
automatically updating in response to input includes automatically updating in response to one of receiving a message, sending a message, forwarding a message to a particular address, detecting a particular string in a message, input received through an administrative interface.
57. The product of claim 31, further comprising instructions to:
maintain rules that include address pattern keys that are regular expressions.
58. The product of claim 57, wherein:
one of the regular expressions specifies different email address domains.
59. The product of claim 57, wherein:
one of the regular expressions specifies different contact aliases for a given email address domain.
US10/447,332 2002-05-28 2003-05-28 Message processing based on address patterns Abandoned US20030225850A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/447,332 US20030225850A1 (en) 2002-05-28 2003-05-28 Message processing based on address patterns

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US38356602P 2002-05-28 2002-05-28
US10/447,332 US20030225850A1 (en) 2002-05-28 2003-05-28 Message processing based on address patterns

Publications (1)

Publication Number Publication Date
US20030225850A1 true US20030225850A1 (en) 2003-12-04

Family

ID=29584582

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/447,332 Abandoned US20030225850A1 (en) 2002-05-28 2003-05-28 Message processing based on address patterns
US10/447,716 Active 2025-10-13 US7231428B2 (en) 2002-05-28 2003-05-28 Communication system using alias management rules for automatically changing sender alias in a message based on group that includes recipient address

Family Applications After (1)

Application Number Title Priority Date Filing Date
US10/447,716 Active 2025-10-13 US7231428B2 (en) 2002-05-28 2003-05-28 Communication system using alias management rules for automatically changing sender alias in a message based on group that includes recipient address

Country Status (5)

Country Link
US (2) US20030225850A1 (en)
JP (1) JP2005528052A (en)
AU (1) AU2003243327A1 (en)
GB (1) GB2407735A (en)
WO (1) WO2003100640A1 (en)

Cited By (91)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030115280A1 (en) * 2001-12-14 2003-06-19 Pitney Bowes Incorporated Method for determining e-mail address format rules
US20050044160A1 (en) * 2003-08-22 2005-02-24 Mcelligott Adrian Method and software product for identifying unsolicited emails
US20050182938A1 (en) * 2004-01-14 2005-08-18 Brandmail Solutions Llc Method and apparatus for trusted branded email
US20050185634A1 (en) * 2004-02-24 2005-08-25 Benco David S. Method and system for providing network support for messaging between short message service (SMS) subscribers and instant messaging (IM) subscribers
US20060026438A1 (en) * 2004-07-29 2006-02-02 Microsoft Corporation Anonymous aliases for on-line communications
US20060075052A1 (en) * 2004-09-17 2006-04-06 Jeroen Oostendorp Platform for Intelligent Email Distribution
US20060136494A1 (en) * 2004-12-22 2006-06-22 Oh Haw K Auto organization hierarchy traversal in email addressees
US20060168046A1 (en) * 2005-01-11 2006-07-27 Microsoft Corporaion Managing periodic electronic messages
US20060167991A1 (en) * 2004-12-16 2006-07-27 Heikes Brian D Buddy list filtering
US20060224673A1 (en) * 2005-03-30 2006-10-05 Microsoft Corporation Throttling inbound electronic messages in a message processing system
US20070070921A1 (en) * 2005-05-05 2007-03-29 Daniel Quinlan Method of determining network addresses of senders of electronic mail messages
US20070136430A1 (en) * 2005-12-13 2007-06-14 Microsoft Corporation Delivery confirmation for e-mail
US20070204063A1 (en) * 2003-01-16 2007-08-30 Scott Banister Electronic message delivery using a virtual gateway approach
WO2007107727A2 (en) * 2006-03-17 2007-09-27 Broca Communications Limited Method and system for message distribution management
US20080075259A1 (en) * 2005-05-18 2008-03-27 Ninety9.Com Pty. Ltd. Dynamic address mapping
US20100036925A1 (en) * 2008-08-07 2010-02-11 Tactara, Llc Alias management platforms
US7669213B1 (en) 2004-10-28 2010-02-23 Aol Llc Dynamic identification of other viewers of a television program to an online viewer
US20100088753A1 (en) * 2008-10-03 2010-04-08 Microsoft Corporation Identity and authentication system using aliases
US7725421B1 (en) * 2006-07-26 2010-05-25 Google Inc. Duplicate account identification and scoring
US20100174788A1 (en) * 2009-01-07 2010-07-08 Microsoft Corporation Honoring user preferences in email systems
US7756930B2 (en) 2004-05-28 2010-07-13 Ironport Systems, Inc. Techniques for determining the reputation of a message sender
US7849142B2 (en) 2004-05-29 2010-12-07 Ironport Systems, Inc. Managing connections, messages, and directory harvest attacks at a server
US20100332601A1 (en) * 2009-06-26 2010-12-30 Walter Jason D Real-time spam look-up system
US7870200B2 (en) 2004-05-29 2011-01-11 Ironport Systems, Inc. Monitoring the flow of messages received at a server
US7870608B2 (en) 2004-05-02 2011-01-11 Markmonitor, Inc. Early detection and monitoring of online fraud
US7873695B2 (en) * 2004-05-29 2011-01-18 Ironport Systems, Inc. Managing connections and messages at a server by associating different actions for both different senders and different recipients
US20110029628A1 (en) * 2008-08-07 2011-02-03 Tactara, Llc Alias Management Platforms and Methods
US7899862B2 (en) 2002-11-18 2011-03-01 Aol Inc. Dynamic identification of other users to an online user
US7913302B2 (en) 2004-05-02 2011-03-22 Markmonitor, Inc. Advanced responses to online fraud
US7930389B2 (en) 2007-11-20 2011-04-19 The Invention Science Fund I, Llc Adaptive filtering of annotated messages or the like
US7992204B2 (en) 2004-05-02 2011-08-02 Markmonitor, Inc. Enhanced responses to online fraud
US8041769B2 (en) * 2004-05-02 2011-10-18 Markmonitor Inc. Generating phish messages
US8065404B2 (en) 2007-08-31 2011-11-22 The Invention Science Fund I, Llc Layering destination-dependent content handling guidance
US8082225B2 (en) 2007-08-31 2011-12-20 The Invention Science Fund I, Llc Using destination-dependent criteria to guide data transmission decisions
US8122137B2 (en) 2002-11-18 2012-02-21 Aol Inc. Dynamic location of a subordinate user
US20120084417A1 (en) * 2010-10-05 2012-04-05 International Business Machines Corporation Information technology for exchanging structural organizational information
US8452849B2 (en) 2002-11-18 2013-05-28 Facebook, Inc. Host-based intelligent results related to a character stream
US8577972B1 (en) 2003-09-05 2013-11-05 Facebook, Inc. Methods and systems for capturing and managing instant messages
US8682982B2 (en) 2007-06-19 2014-03-25 The Invention Science Fund I, Llc Preliminary destination-dependent evaluation of message content
US8701014B1 (en) 2002-11-18 2014-04-15 Facebook, Inc. Account linking
US8745143B2 (en) 2010-04-01 2014-06-03 Microsoft Corporation Delaying inbound and outbound email messages
US8769671B2 (en) 2004-05-02 2014-07-01 Markmonitor Inc. Online fraud solution
US8874672B2 (en) 2003-03-26 2014-10-28 Facebook, Inc. Identifying and using identities deemed to be known to a user
US20150032824A1 (en) * 2011-07-26 2015-01-29 Socialmail LLC Aggregate electronic mail message handling
US8965964B1 (en) 2002-11-18 2015-02-24 Facebook, Inc. Managing forwarded electronic messages
US8984133B2 (en) 2007-06-19 2015-03-17 The Invention Science Fund I, Llc Providing treatment-indicative feedback dependent on putative content treatment
US9026507B2 (en) 2004-05-02 2015-05-05 Thomson Reuters Global Resources Methods and systems for analyzing data related to possible online fraud
EP2884702A1 (en) * 2013-12-11 2015-06-17 Alcatel Lucent Method of sending email, and email device therefor
US9203794B2 (en) 2002-11-18 2015-12-01 Facebook, Inc. Systems and methods for reconfiguring electronic messages
US9203648B2 (en) 2004-05-02 2015-12-01 Thomson Reuters Global Resources Online fraud solution
US9203879B2 (en) 2000-03-17 2015-12-01 Facebook, Inc. Offline alerts mechanism
US9246975B2 (en) 2000-03-17 2016-01-26 Facebook, Inc. State change alerts mechanism
US9319356B2 (en) 2002-11-18 2016-04-19 Facebook, Inc. Message delivery control settings
US9374242B2 (en) 2007-11-08 2016-06-21 Invention Science Fund I, Llc Using evaluations of tentative message content
US9667585B2 (en) 2002-11-18 2017-05-30 Facebook, Inc. Central people lists accessible by multiple applications
US20170293843A1 (en) * 2007-07-19 2017-10-12 Salesforce.Com, Inc. System, method and computer program product for messaging in an on-demand database service
US20180091478A1 (en) * 2016-09-26 2018-03-29 Agari Data, Inc. Mitigating communication risk by verifying a sender of a message
US20180309768A1 (en) * 2017-04-20 2018-10-25 Bank Of America Corporation Automated authentication, validation and processing of digitized files
US10187334B2 (en) 2003-11-26 2019-01-22 Facebook, Inc. User-defined electronic message preferences
US10346449B2 (en) 2017-10-12 2019-07-09 Spredfast, Inc. Predicting performance of content and electronic messages among a system of networked computing devices
US10594773B2 (en) 2018-01-22 2020-03-17 Spredfast, Inc. Temporal optimization of data operations using distributed search and server management
US10601937B2 (en) 2017-11-22 2020-03-24 Spredfast, Inc. Responsive action prediction based on electronic messages among a system of networked computing devices
US10623365B2 (en) * 2018-05-25 2020-04-14 Binarytree.com, Inc. Message redirection protocol
US10674009B1 (en) 2013-11-07 2020-06-02 Rightquestion, Llc Validating automatic number identification data
US10715543B2 (en) 2016-11-30 2020-07-14 Agari Data, Inc. Detecting computer security risk based on previously observed communications
US10750033B2 (en) 2018-04-12 2020-08-18 Biscom Inc. Electronic package interception, parsing, and routing
US10785222B2 (en) 2018-10-11 2020-09-22 Spredfast, Inc. Credential and authentication management in scalable data networks
US10805314B2 (en) 2017-05-19 2020-10-13 Agari Data, Inc. Using message context to evaluate security of requested data
US10855657B2 (en) 2018-10-11 2020-12-01 Spredfast, Inc. Multiplexed data exchange portal interface in scalable data networks
US10880322B1 (en) 2016-09-26 2020-12-29 Agari Data, Inc. Automated tracking of interaction with a resource of a message
US10902462B2 (en) 2017-04-28 2021-01-26 Khoros, Llc System and method of providing a platform for managing data content campaign on social networks
US10931540B2 (en) 2019-05-15 2021-02-23 Khoros, Llc Continuous data sensing of functional states of networked computing devices to determine efficiency metrics for servicing electronic messages asynchronously
US10999278B2 (en) 2018-10-11 2021-05-04 Spredfast, Inc. Proxied multi-factor authentication using credential and authentication management in scalable data networks
US11019076B1 (en) 2017-04-26 2021-05-25 Agari Data, Inc. Message security assessment using sender identity profiles
US11044267B2 (en) 2016-11-30 2021-06-22 Agari Data, Inc. Using a measure of influence of sender in determining a security risk associated with an electronic message
US11050704B2 (en) 2017-10-12 2021-06-29 Spredfast, Inc. Computerized tools to enhance speed and propagation of content in electronic messages among a system of networked computing devices
US11061900B2 (en) 2018-01-22 2021-07-13 Spredfast, Inc. Temporal optimization of data operations using distributed search and server management
US11102244B1 (en) 2017-06-07 2021-08-24 Agari Data, Inc. Automated intelligence gathering
US11128589B1 (en) 2020-09-18 2021-09-21 Khoros, Llc Gesture-based community moderation
US11438282B2 (en) 2020-11-06 2022-09-06 Khoros, Llc Synchronicity of electronic messages via a transferred secure messaging channel among a system of various networked computing devices
US11438289B2 (en) 2020-09-18 2022-09-06 Khoros, Llc Gesture-based community moderation
US11470161B2 (en) 2018-10-11 2022-10-11 Spredfast, Inc. Native activity tracking using credential and authentication management in scalable data networks
US11558332B1 (en) * 2022-01-24 2023-01-17 Biscom Inc. Automated electronic package transmission method selection
US11570128B2 (en) 2017-10-12 2023-01-31 Spredfast, Inc. Optimizing effectiveness of content in electronic messages among a system of networked computing device
US11627100B1 (en) 2021-10-27 2023-04-11 Khoros, Llc Automated response engine implementing a universal data space based on communication interactions via an omnichannel electronic data channel
US11714629B2 (en) 2020-11-19 2023-08-01 Khoros, Llc Software dependency management
US11722513B2 (en) 2016-11-30 2023-08-08 Agari Data, Inc. Using a measure of influence of sender in determining a security risk associated with an electronic message
US11741551B2 (en) 2013-03-21 2023-08-29 Khoros, Llc Gamification for online social communities
US11757914B1 (en) 2017-06-07 2023-09-12 Agari Data, Inc. Automated responsive message to determine a security risk of a message sender
US11924375B2 (en) 2021-10-27 2024-03-05 Khoros, Llc Automated response engine and flow configured to exchange responsive communication data via an omnichannel electronic communication channel independent of data source
US11936652B2 (en) 2021-01-29 2024-03-19 Spredfast, Inc. Proxied multi-factor authentication using credential and authentication management in scalable data networks

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8396926B1 (en) 2002-07-16 2013-03-12 Sonicwall, Inc. Message challenge response
US7539726B1 (en) 2002-07-16 2009-05-26 Sonicwall, Inc. Message testing
US8924484B2 (en) * 2002-07-16 2014-12-30 Sonicwall, Inc. Active e-mail filter with challenge-response
US7050822B2 (en) * 2002-10-31 2006-05-23 Nokia Corporation Method for providing a best guess for an intended recipient of a message
US7299261B1 (en) 2003-02-20 2007-11-20 Mailfrontier, Inc. A Wholly Owned Subsidiary Of Sonicwall, Inc. Message classification using a summary
US7406502B1 (en) 2003-02-20 2008-07-29 Sonicwall, Inc. Method and system for classifying a message based on canonical equivalent of acceptable items included in the message
US8266215B2 (en) * 2003-02-20 2012-09-11 Sonicwall, Inc. Using distinguishing properties to classify messages
JP2005033740A (en) * 2003-07-11 2005-02-03 Nec Access Technica Ltd Load distribution network failure monitoring system of adsl router and method therefor
US7533414B1 (en) * 2004-03-17 2009-05-12 Yahoo! Inc. Detecting system abuse
US7941491B2 (en) * 2004-06-04 2011-05-10 Messagemind, Inc. System and method for dynamic adaptive user-based prioritization and display of electronic messages
WO2006017588A2 (en) * 2004-08-03 2006-02-16 Udx, Inc. Universal document exchange system and method
US20060072150A1 (en) * 2004-08-24 2006-04-06 Jim Justice Universal document exchange system and method
US9298513B2 (en) * 2004-10-07 2016-03-29 International Business Machines Corporation Method and structure for autonomic application differentiation/specialization
US20060080393A1 (en) * 2004-10-12 2006-04-13 Cardone Richard J Method for using e-mail documents to create and update address lists
US7647380B2 (en) * 2005-01-31 2010-01-12 Microsoft Corporation Datacenter mail routing
US20060242296A1 (en) * 2005-04-07 2006-10-26 Woolard Leamon M Method of adding new users to a web based portal server
RU2368555C1 (en) 2005-05-27 2009-09-27 Кирин Бир Кабусики Кайся Device for manufacturing of plastic container with gas barrier, method for manufacturing of this container and container
US20060277229A1 (en) * 2005-05-31 2006-12-07 Michihiro Yoshida Document management server, information terminal, document managing method, and program
US8161122B2 (en) * 2005-06-03 2012-04-17 Messagemind, Inc. System and method of dynamically prioritized electronic mail graphical user interface, and measuring email productivity and collaboration trends
US20070038709A1 (en) * 2005-08-11 2007-02-15 Alexander Medvedev Method and system for identifying spam email
US7882186B1 (en) * 2005-10-13 2011-02-01 Chen Sun Selectable email signatures
US7475117B1 (en) * 2005-12-15 2009-01-06 Teradata Us, Inc. Two-phase commit electronic mail delivery
US7529795B2 (en) * 2006-03-20 2009-05-05 Stragent, Llc Message board aggregator
FR2899754B1 (en) * 2006-04-06 2018-03-02 Societe Francaise Du Radiotelephone Sfr METHOD AND DEVICE FOR TRANSFORMING ELECTRONIC ADDRESSES CONTAINED IN THE HEAD OF AN ELECTRONIC MAIL
FR2899753B1 (en) * 2006-04-06 2008-12-26 Radiotelephone Sfr METHOD AND DEVICE FOR TRANSFORMING ELECTRONIC ADDRESSES CONTAINED IN THE HEAD OF AN ELECTRONIC MAIL
US7647351B2 (en) 2006-09-14 2010-01-12 Stragent, Llc Web scrape template generation
US7519602B2 (en) 2006-10-31 2009-04-14 Sap Ag Systems and methods for information exchange using object warehousing
US7865887B2 (en) * 2006-11-30 2011-01-04 Sap Ag Context based event handling and execution with prioritization and interrupt management
US7870207B2 (en) * 2006-12-21 2011-01-11 Research In Motion Limited Method and apparatus for efficient polling
US8224298B2 (en) * 2007-02-05 2012-07-17 Boadin Technology, LLC Systems and methods for mobile media services utilizing a short form command structure
US8775450B2 (en) * 2007-04-19 2014-07-08 Sap Ag Systems and methods for information exchange using object warehousing
JP2009003705A (en) * 2007-06-21 2009-01-08 Oki Data Corp Communication terminal apparatus
US20090119600A1 (en) * 2007-11-02 2009-05-07 International Business Machines Corporation System and method for evaluating response patterns
US8117225B1 (en) 2008-01-18 2012-02-14 Boadin Technology, LLC Drill-down system, method, and computer program product for focusing a search
US8117242B1 (en) 2008-01-18 2012-02-14 Boadin Technology, LLC System, method, and computer program product for performing a search in conjunction with use of an online application
US8458264B1 (en) 2008-02-26 2013-06-04 Chris Lee Email proxy server with first respondent binding
US8078397B1 (en) 2008-08-22 2011-12-13 Boadin Technology, LLC System, method, and computer program product for social networking utilizing a vehicular assembly
US8131458B1 (en) 2008-08-22 2012-03-06 Boadin Technology, LLC System, method, and computer program product for instant messaging utilizing a vehicular assembly
US8073590B1 (en) 2008-08-22 2011-12-06 Boadin Technology, LLC System, method, and computer program product for utilizing a communication channel of a mobile device by a vehicular assembly
US8265862B1 (en) 2008-08-22 2012-09-11 Boadin Technology, LLC System, method, and computer program product for communicating location-related information
US8190692B1 (en) 2008-08-22 2012-05-29 Boadin Technology, LLC Location-based messaging system, method, and computer program product
US9100435B2 (en) * 2009-04-02 2015-08-04 International Business Machines Corporation Preferred name presentation in online environments
US8185132B1 (en) * 2009-07-21 2012-05-22 Modena Enterprises, Llc Systems and methods for associating communication information with a geographic location-aware contact entry
US20120135744A1 (en) * 2009-07-21 2012-05-31 Kota Enterprises, Llc Systems and methods for generating and managing communication rules associated with geographic locations
JP5088351B2 (en) * 2009-08-05 2012-12-05 コニカミノルタビジネステクノロジーズ株式会社 E-mail transmission device and program
US20110047076A1 (en) * 2009-08-24 2011-02-24 Mark Carlson Alias reputation interaction system
US9222798B2 (en) 2009-12-22 2015-12-29 Modena Enterprises, Llc Systems and methods for identifying an activity of a user based on a chronological order of detected movements of a computing device
US9191235B2 (en) * 2010-02-05 2015-11-17 Microsoft Technology Licensing, Llc Moderating electronic communications
US9215735B2 (en) 2010-03-03 2015-12-15 Modena Enterprises, Llc Systems and methods for initiating communications with contacts based on a communication specification
US9183560B2 (en) 2010-05-28 2015-11-10 Daniel H. Abelow Reality alternate
US20120059886A1 (en) * 2010-08-30 2012-03-08 Gary Stephen Shuster Reply message handling for transient group
US20120204111A1 (en) * 2011-02-07 2012-08-09 Microsoft Corporation Higher-level e-mail address creation at signup
CN102368749B (en) * 2011-09-23 2016-08-10 上海量明科技发展有限公司 Instant communication contacts list presents the method and system of individual character pattern
US20130254830A1 (en) 2012-03-22 2013-09-26 Madhav Moganti Apparatus and method for assuring communications of corporate users
US9401886B2 (en) 2012-05-30 2016-07-26 International Business Machines Corporation Preventing personal information from being posted to an internet
US9531662B2 (en) * 2013-03-20 2016-12-27 Microsoft Technology Licensing, Llc Global email identity preferences
CN104281609B (en) * 2013-07-08 2020-03-17 腾讯科技(深圳)有限公司 Configuration method and device for voice input instruction matching rule
US10417380B1 (en) 2013-12-31 2019-09-17 Mckesson Corporation Systems and methods for determining and communicating a prescription benefit coverage denial to a prescriber
US10489552B2 (en) 2014-02-14 2019-11-26 Mckesson Corporation Systems and methods for determining and communicating patient incentive information to a prescriber
EP3002720A1 (en) * 2014-10-02 2016-04-06 Unify GmbH & Co. KG Method, device and software product for filling an address field of an electronic message
WO2016067293A1 (en) * 2014-10-28 2016-05-06 Steel Nir Systems and methods for cross-modality communication
US10142273B2 (en) * 2015-06-23 2018-11-27 International Business Machines Corporation Handling various scenarios where an email recipient is not available
US11514137B1 (en) 2016-03-30 2022-11-29 Mckesson Corporation Alternative therapy identification system
US10999224B1 (en) 2017-02-01 2021-05-04 Mckesson Corporation Method and apparatus for parsing an electronic message and constructing multiple differently prioritized messages therefrom
JPWO2018181834A1 (en) * 2017-03-30 2020-02-06 日本電気株式会社 Management server, management system, management server control method, and program
US10862832B1 (en) * 2018-07-24 2020-12-08 Mckesson Corporation Computing system and method for automatically reversing an action indicated by an electronic message
US11562437B1 (en) 2019-06-26 2023-01-24 Mckesson Corporation Method, apparatus, and computer program product for providing estimated prescription costs
US11636548B1 (en) 2019-06-26 2023-04-25 Mckesson Corporation Method, apparatus, and computer program product for providing estimated prescription costs
US11610240B1 (en) 2020-02-17 2023-03-21 Mckesson Corporation Method, apparatus, and computer program product for partitioning prescription transaction costs in an electronic prescription transaction
US11587657B2 (en) 2020-09-04 2023-02-21 Mckesson Corporation Method, apparatus, and computer program product for performing an alternative evaluation procedure in response to an electronic message

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6199102B1 (en) * 1997-08-26 2001-03-06 Christopher Alan Cobb Method and system for filtering electronic messages
US6385645B1 (en) * 1995-08-04 2002-05-07 Belle Gate Investments B.V. Data exchange system comprising portable data processing units
US20020120697A1 (en) * 2000-08-14 2002-08-29 Curtis Generous Multi-channel messaging system and method
US6519234B1 (en) * 1998-03-24 2003-02-11 Sendit Ab Method and arrangement for transferring information using an existing message based service in a digital network
US20030131063A1 (en) * 2001-12-19 2003-07-10 Breck David L. Message processor
US6606649B1 (en) * 1999-09-28 2003-08-12 Microsoft Corporation Application programming interface functions for supporting an improved message store for hand-held computers
US6606647B2 (en) * 1999-01-11 2003-08-12 Infospace, Inc. Server and method for routing messages to achieve unified communications
US20030158905A1 (en) * 2002-02-19 2003-08-21 Postini Corporation E-mail management services
US20030191969A1 (en) * 2000-02-08 2003-10-09 Katsikas Peter L. System for eliminating unauthorized electronic mail
US20030231207A1 (en) * 2002-03-25 2003-12-18 Baohua Huang Personal e-mail system and method
US6708205B2 (en) * 2001-02-15 2004-03-16 Suffix Mail, Inc. E-mail messaging system
US6779022B1 (en) * 2000-08-17 2004-08-17 Jens Horstmann Server that obtains information from multiple sources, filters using client identities, and dispatches to both hardwired and wireless clients
US6832245B1 (en) * 1999-12-01 2004-12-14 At&T Corp. System and method for analyzing communications of user messages to rank users and contacts based on message content
US6839737B1 (en) * 2000-07-19 2005-01-04 Neoplanet, Inc. Messaging system for indicating status of a sender of electronic mail and method and computer program product therefor
US20050188045A1 (en) * 2000-02-08 2005-08-25 Katsikas Peter L. System for eliminating unauthorized electronic mail
US6990513B2 (en) * 2000-06-22 2006-01-24 Microsoft Corporation Distributed computing services platform
US7058684B1 (en) * 1999-05-27 2006-06-06 Fujitsu Limited Device, method, and storage medium to block junk email
US7072942B1 (en) * 2000-02-04 2006-07-04 Microsoft Corporation Email filtering methods and systems
US7249175B1 (en) * 1999-11-23 2007-07-24 Escom Corporation Method and system for blocking e-mail having a nonexistent sender address

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6044205A (en) * 1996-02-29 2000-03-28 Intermind Corporation Communications system for transferring information between memories according to processes transferred with the information
US5283856A (en) * 1991-10-04 1994-02-01 Beyond, Inc. Event-driven rule-based messaging system
US5923848A (en) * 1996-05-31 1999-07-13 Microsoft Corporation System and method for resolving names in an electronic messaging environment
US20020061003A1 (en) * 2000-10-23 2002-05-23 Arch Wireless, Inc. Method of and system for wireless network access through server platform integration
US20030105820A1 (en) * 2001-12-03 2003-06-05 Jeffrey Haims Method and apparatus for facilitating online communication

Patent Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6385645B1 (en) * 1995-08-04 2002-05-07 Belle Gate Investments B.V. Data exchange system comprising portable data processing units
US6199102B1 (en) * 1997-08-26 2001-03-06 Christopher Alan Cobb Method and system for filtering electronic messages
US6519234B1 (en) * 1998-03-24 2003-02-11 Sendit Ab Method and arrangement for transferring information using an existing message based service in a digital network
US6606647B2 (en) * 1999-01-11 2003-08-12 Infospace, Inc. Server and method for routing messages to achieve unified communications
US7058684B1 (en) * 1999-05-27 2006-06-06 Fujitsu Limited Device, method, and storage medium to block junk email
US6606649B1 (en) * 1999-09-28 2003-08-12 Microsoft Corporation Application programming interface functions for supporting an improved message store for hand-held computers
US7249175B1 (en) * 1999-11-23 2007-07-24 Escom Corporation Method and system for blocking e-mail having a nonexistent sender address
US6832245B1 (en) * 1999-12-01 2004-12-14 At&T Corp. System and method for analyzing communications of user messages to rank users and contacts based on message content
US7072942B1 (en) * 2000-02-04 2006-07-04 Microsoft Corporation Email filtering methods and systems
US20030191969A1 (en) * 2000-02-08 2003-10-09 Katsikas Peter L. System for eliminating unauthorized electronic mail
US20050188045A1 (en) * 2000-02-08 2005-08-25 Katsikas Peter L. System for eliminating unauthorized electronic mail
US6990513B2 (en) * 2000-06-22 2006-01-24 Microsoft Corporation Distributed computing services platform
US6839737B1 (en) * 2000-07-19 2005-01-04 Neoplanet, Inc. Messaging system for indicating status of a sender of electronic mail and method and computer program product therefor
US20020120697A1 (en) * 2000-08-14 2002-08-29 Curtis Generous Multi-channel messaging system and method
US6779022B1 (en) * 2000-08-17 2004-08-17 Jens Horstmann Server that obtains information from multiple sources, filters using client identities, and dispatches to both hardwired and wireless clients
US6708205B2 (en) * 2001-02-15 2004-03-16 Suffix Mail, Inc. E-mail messaging system
US20030131063A1 (en) * 2001-12-19 2003-07-10 Breck David L. Message processor
US20030158905A1 (en) * 2002-02-19 2003-08-21 Postini Corporation E-mail management services
US20030231207A1 (en) * 2002-03-25 2003-12-18 Baohua Huang Personal e-mail system and method

Cited By (173)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9736209B2 (en) 2000-03-17 2017-08-15 Facebook, Inc. State change alerts mechanism
US9246975B2 (en) 2000-03-17 2016-01-26 Facebook, Inc. State change alerts mechanism
US9203879B2 (en) 2000-03-17 2015-12-01 Facebook, Inc. Offline alerts mechanism
US7149780B2 (en) * 2001-12-14 2006-12-12 Pitney Bowes Inc. Method for determining e-mail address format rules
US20030115280A1 (en) * 2001-12-14 2003-06-19 Pitney Bowes Incorporated Method for determining e-mail address format rules
USRE43118E1 (en) * 2001-12-14 2012-01-17 Turnpike Data Processing Llc Method for determining e-mail address format rules
US9356890B2 (en) 2002-11-18 2016-05-31 Facebook, Inc. Enhanced buddy list using mobile device identifiers
US9253136B2 (en) 2002-11-18 2016-02-02 Facebook, Inc. Electronic message delivery based on presence information
US9203794B2 (en) 2002-11-18 2015-12-01 Facebook, Inc. Systems and methods for reconfiguring electronic messages
US9171064B2 (en) 2002-11-18 2015-10-27 Facebook, Inc. Intelligent community based results related to a character stream
US9075868B2 (en) 2002-11-18 2015-07-07 Facebook, Inc. Intelligent results based on database queries
US10778635B2 (en) 2002-11-18 2020-09-15 Facebook, Inc. People lists
US10389661B2 (en) 2002-11-18 2019-08-20 Facebook, Inc. Managing electronic messages sent to mobile devices associated with electronic messaging accounts
US9075867B2 (en) 2002-11-18 2015-07-07 Facebook, Inc. Intelligent results using an assistant
US9203647B2 (en) 2002-11-18 2015-12-01 Facebook, Inc. Dynamic online and geographic location of a user
US9053175B2 (en) 2002-11-18 2015-06-09 Facebook, Inc. Intelligent results using a spelling correction agent
US9053174B2 (en) 2002-11-18 2015-06-09 Facebook, Inc. Intelligent vendor results related to a character stream
US9053173B2 (en) 2002-11-18 2015-06-09 Facebook, Inc. Intelligent results related to a portion of a search query
US9047364B2 (en) 2002-11-18 2015-06-02 Facebook, Inc. Intelligent client capability-based results related to a character stream
US10033669B2 (en) 2002-11-18 2018-07-24 Facebook, Inc. Managing electronic messages sent to reply telephone numbers
US9894018B2 (en) 2002-11-18 2018-02-13 Facebook, Inc. Electronic messaging using reply telephone numbers
US9852126B2 (en) 2002-11-18 2017-12-26 Facebook, Inc. Host-based intelligent results related to a character stream
US9774560B2 (en) 2002-11-18 2017-09-26 Facebook, Inc. People lists
US9769104B2 (en) 2002-11-18 2017-09-19 Facebook, Inc. Methods and system for delivering multiple notifications
US8965964B1 (en) 2002-11-18 2015-02-24 Facebook, Inc. Managing forwarded electronic messages
US8954534B2 (en) 2002-11-18 2015-02-10 Facebook, Inc. Host-based intelligent results related to a character stream
US9515977B2 (en) 2002-11-18 2016-12-06 Facebook, Inc. Time based electronic message delivery
US8954530B2 (en) 2002-11-18 2015-02-10 Facebook, Inc. Intelligent results related to a character stream
US9729489B2 (en) 2002-11-18 2017-08-08 Facebook, Inc. Systems and methods for notification management and delivery
US9313046B2 (en) 2002-11-18 2016-04-12 Facebook, Inc. Presenting dynamic location of a user
US8819176B2 (en) 2002-11-18 2014-08-26 Facebook, Inc. Intelligent map results related to a character stream
US8775560B2 (en) 2002-11-18 2014-07-08 Facebook, Inc. Host-based intelligent results related to a character stream
US9319356B2 (en) 2002-11-18 2016-04-19 Facebook, Inc. Message delivery control settings
US8701014B1 (en) 2002-11-18 2014-04-15 Facebook, Inc. Account linking
US9667585B2 (en) 2002-11-18 2017-05-30 Facebook, Inc. Central people lists accessible by multiple applications
US7899862B2 (en) 2002-11-18 2011-03-01 Aol Inc. Dynamic identification of other users to an online user
US8452849B2 (en) 2002-11-18 2013-05-28 Facebook, Inc. Host-based intelligent results related to a character stream
US9647872B2 (en) 2002-11-18 2017-05-09 Facebook, Inc. Dynamic identification of other users to an online user
US8954531B2 (en) 2002-11-18 2015-02-10 Facebook, Inc. Intelligent messaging label results related to a character stream
US9560000B2 (en) 2002-11-18 2017-01-31 Facebook, Inc. Reconfiguring an electronic message to effect an enhanced notification
US9621376B2 (en) 2002-11-18 2017-04-11 Facebook, Inc. Dynamic location of a subordinate user
US9571440B2 (en) 2002-11-18 2017-02-14 Facebook, Inc. Notification archive
US9571439B2 (en) 2002-11-18 2017-02-14 Facebook, Inc. Systems and methods for notification delivery
US8122137B2 (en) 2002-11-18 2012-02-21 Aol Inc. Dynamic location of a subordinate user
US20070204063A1 (en) * 2003-01-16 2007-08-30 Scott Banister Electronic message delivery using a virtual gateway approach
US7747693B2 (en) * 2003-01-16 2010-06-29 Ironport Systems, Inc. Electronic message delivery using a virtual gateway approach
US9736255B2 (en) 2003-03-26 2017-08-15 Facebook, Inc. Methods of providing access to messages based on degrees of separation
US9531826B2 (en) 2003-03-26 2016-12-27 Facebook, Inc. Managing electronic messages based on inference scores
US9516125B2 (en) 2003-03-26 2016-12-06 Facebook, Inc. Identifying and using identities deemed to be known to a user
US8874672B2 (en) 2003-03-26 2014-10-28 Facebook, Inc. Identifying and using identities deemed to be known to a user
US8321512B2 (en) * 2003-08-22 2012-11-27 Geobytes, Inc. Method and software product for identifying unsolicited emails
US20050044160A1 (en) * 2003-08-22 2005-02-24 Mcelligott Adrian Method and software product for identifying unsolicited emails
US10102504B2 (en) 2003-09-05 2018-10-16 Facebook, Inc. Methods for controlling display of electronic messages captured based on community rankings
US9070118B2 (en) 2003-09-05 2015-06-30 Facebook, Inc. Methods for capturing electronic messages based on capture rules relating to user actions regarding received electronic messages
US8577972B1 (en) 2003-09-05 2013-11-05 Facebook, Inc. Methods and systems for capturing and managing instant messages
US10187334B2 (en) 2003-11-26 2019-01-22 Facebook, Inc. User-defined electronic message preferences
US10951629B2 (en) 2004-01-14 2021-03-16 Jose J. Picazo, Jr. Separate Property Trust Method and apparatus for trusted branded email
US10298596B2 (en) 2004-01-14 2019-05-21 Jose J. Picazo, Jr. Separate Property Trust Method and apparatus for trusted branded email
US20050182938A1 (en) * 2004-01-14 2005-08-18 Brandmail Solutions Llc Method and apparatus for trusted branded email
US7457955B2 (en) * 2004-01-14 2008-11-25 Brandmail Solutions, Inc. Method and apparatus for trusted branded email
US20090013197A1 (en) * 2004-01-14 2009-01-08 Harish Seshadri Method and Apparatus for Trusted Branded Email
US11711377B2 (en) 2004-01-14 2023-07-25 Jose J. Picazo, Jr. Separate Property Trust Method and apparatus for trusted branded email
US8621217B2 (en) 2004-01-14 2013-12-31 Jose J. Picazo Separate Property Trust Method and apparatus for trusted branded email
US20050185634A1 (en) * 2004-02-24 2005-08-25 Benco David S. Method and system for providing network support for messaging between short message service (SMS) subscribers and instant messaging (IM) subscribers
US9026507B2 (en) 2004-05-02 2015-05-05 Thomson Reuters Global Resources Methods and systems for analyzing data related to possible online fraud
US9203648B2 (en) 2004-05-02 2015-12-01 Thomson Reuters Global Resources Online fraud solution
US8041769B2 (en) * 2004-05-02 2011-10-18 Markmonitor Inc. Generating phish messages
US7992204B2 (en) 2004-05-02 2011-08-02 Markmonitor, Inc. Enhanced responses to online fraud
US7913302B2 (en) 2004-05-02 2011-03-22 Markmonitor, Inc. Advanced responses to online fraud
US9684888B2 (en) 2004-05-02 2017-06-20 Camelot Uk Bidco Limited Online fraud solution
US9356947B2 (en) 2004-05-02 2016-05-31 Thomson Reuters Global Resources Methods and systems for analyzing data related to possible online fraud
US8769671B2 (en) 2004-05-02 2014-07-01 Markmonitor Inc. Online fraud solution
US7870608B2 (en) 2004-05-02 2011-01-11 Markmonitor, Inc. Early detection and monitoring of online fraud
US7756930B2 (en) 2004-05-28 2010-07-13 Ironport Systems, Inc. Techniques for determining the reputation of a message sender
US7873695B2 (en) * 2004-05-29 2011-01-18 Ironport Systems, Inc. Managing connections and messages at a server by associating different actions for both different senders and different recipients
US7870200B2 (en) 2004-05-29 2011-01-11 Ironport Systems, Inc. Monitoring the flow of messages received at a server
US7849142B2 (en) 2004-05-29 2010-12-07 Ironport Systems, Inc. Managing connections, messages, and directory harvest attacks at a server
US20060026438A1 (en) * 2004-07-29 2006-02-02 Microsoft Corporation Anonymous aliases for on-line communications
US20060075052A1 (en) * 2004-09-17 2006-04-06 Jeroen Oostendorp Platform for Intelligent Email Distribution
US8255950B1 (en) 2004-10-28 2012-08-28 Aol Inc. Dynamic identification of other viewers of a television program to an online viewer
US7669213B1 (en) 2004-10-28 2010-02-23 Aol Llc Dynamic identification of other viewers of a television program to an online viewer
US20060167991A1 (en) * 2004-12-16 2006-07-27 Heikes Brian D Buddy list filtering
US7613732B2 (en) * 2004-12-22 2009-11-03 Intel Corporation Auto organization hierarchy traversal in email addressees
US20060136494A1 (en) * 2004-12-22 2006-06-22 Oh Haw K Auto organization hierarchy traversal in email addressees
US20060168046A1 (en) * 2005-01-11 2006-07-27 Microsoft Corporaion Managing periodic electronic messages
US20060224673A1 (en) * 2005-03-30 2006-10-05 Microsoft Corporation Throttling inbound electronic messages in a message processing system
US20070070921A1 (en) * 2005-05-05 2007-03-29 Daniel Quinlan Method of determining network addresses of senders of electronic mail messages
US7548544B2 (en) 2005-05-05 2009-06-16 Ironport Systems, Inc. Method of determining network addresses of senders of electronic mail messages
US20120066335A1 (en) * 2005-05-18 2012-03-15 Ninety9.Com Pty. Ltd. Dynamic address mapping
US20080075259A1 (en) * 2005-05-18 2008-03-27 Ninety9.Com Pty. Ltd. Dynamic address mapping
US7836132B2 (en) 2005-12-13 2010-11-16 Microsoft Corporation Delivery confirmation for e-mail
US20070136430A1 (en) * 2005-12-13 2007-06-14 Microsoft Corporation Delivery confirmation for e-mail
WO2007107727A2 (en) * 2006-03-17 2007-09-27 Broca Communications Limited Method and system for message distribution management
WO2007107727A3 (en) * 2006-03-17 2007-11-15 Broca Comm Ltd Method and system for message distribution management
US8131685B1 (en) * 2006-07-26 2012-03-06 Google Inc. Duplicate account identification and scoring
US7725421B1 (en) * 2006-07-26 2010-05-25 Google Inc. Duplicate account identification and scoring
US8682982B2 (en) 2007-06-19 2014-03-25 The Invention Science Fund I, Llc Preliminary destination-dependent evaluation of message content
US8984133B2 (en) 2007-06-19 2015-03-17 The Invention Science Fund I, Llc Providing treatment-indicative feedback dependent on putative content treatment
US20170293843A1 (en) * 2007-07-19 2017-10-12 Salesforce.Com, Inc. System, method and computer program product for messaging in an on-demand database service
US8082225B2 (en) 2007-08-31 2011-12-20 The Invention Science Fund I, Llc Using destination-dependent criteria to guide data transmission decisions
US8065404B2 (en) 2007-08-31 2011-11-22 The Invention Science Fund I, Llc Layering destination-dependent content handling guidance
US9374242B2 (en) 2007-11-08 2016-06-21 Invention Science Fund I, Llc Using evaluations of tentative message content
US7930389B2 (en) 2007-11-20 2011-04-19 The Invention Science Fund I, Llc Adaptive filtering of annotated messages or the like
US20100036925A1 (en) * 2008-08-07 2010-02-11 Tactara, Llc Alias management platforms
US20110029628A1 (en) * 2008-08-07 2011-02-03 Tactara, Llc Alias Management Platforms and Methods
US20100088753A1 (en) * 2008-10-03 2010-04-08 Microsoft Corporation Identity and authentication system using aliases
US20100174788A1 (en) * 2009-01-07 2010-07-08 Microsoft Corporation Honoring user preferences in email systems
US8195753B2 (en) 2009-01-07 2012-06-05 Microsoft Corporation Honoring user preferences in email systems
US8959157B2 (en) 2009-06-26 2015-02-17 Microsoft Corporation Real-time spam look-up system
US20100332601A1 (en) * 2009-06-26 2010-12-30 Walter Jason D Real-time spam look-up system
US8745143B2 (en) 2010-04-01 2014-06-03 Microsoft Corporation Delaying inbound and outbound email messages
US8935369B2 (en) * 2010-10-05 2015-01-13 International Business Machines Corporation Information technology for exchanging structural organizational information
US20120084417A1 (en) * 2010-10-05 2012-04-05 International Business Machines Corporation Information technology for exchanging structural organizational information
US20150032824A1 (en) * 2011-07-26 2015-01-29 Socialmail LLC Aggregate electronic mail message handling
US9832151B2 (en) * 2011-07-26 2017-11-28 Socialmail LLC Aggregate electronic mail message handling
US11741551B2 (en) 2013-03-21 2023-08-29 Khoros, Llc Gamification for online social communities
US10674009B1 (en) 2013-11-07 2020-06-02 Rightquestion, Llc Validating automatic number identification data
US10694029B1 (en) 2013-11-07 2020-06-23 Rightquestion, Llc Validating automatic number identification data
US11005989B1 (en) 2013-11-07 2021-05-11 Rightquestion, Llc Validating automatic number identification data
US11856132B2 (en) 2013-11-07 2023-12-26 Rightquestion, Llc Validating automatic number identification data
EP2884702A1 (en) * 2013-12-11 2015-06-17 Alcatel Lucent Method of sending email, and email device therefor
US10992645B2 (en) 2016-09-26 2021-04-27 Agari Data, Inc. Mitigating communication risk by detecting similarity to a trusted message contact
US20180091478A1 (en) * 2016-09-26 2018-03-29 Agari Data, Inc. Mitigating communication risk by verifying a sender of a message
US10326735B2 (en) 2016-09-26 2019-06-18 Agari Data, Inc. Mitigating communication risk by detecting similarity to a trusted message contact
US10880322B1 (en) 2016-09-26 2020-12-29 Agari Data, Inc. Automated tracking of interaction with a resource of a message
US11595354B2 (en) 2016-09-26 2023-02-28 Agari Data, Inc. Mitigating communication risk by detecting similarity to a trusted message contact
US10805270B2 (en) * 2016-09-26 2020-10-13 Agari Data, Inc. Mitigating communication risk by verifying a sender of a message
US11722513B2 (en) 2016-11-30 2023-08-08 Agari Data, Inc. Using a measure of influence of sender in determining a security risk associated with an electronic message
US10715543B2 (en) 2016-11-30 2020-07-14 Agari Data, Inc. Detecting computer security risk based on previously observed communications
US11044267B2 (en) 2016-11-30 2021-06-22 Agari Data, Inc. Using a measure of influence of sender in determining a security risk associated with an electronic message
US20180309768A1 (en) * 2017-04-20 2018-10-25 Bank Of America Corporation Automated authentication, validation and processing of digitized files
US11722497B2 (en) 2017-04-26 2023-08-08 Agari Data, Inc. Message security assessment using sender identity profiles
US11019076B1 (en) 2017-04-26 2021-05-25 Agari Data, Inc. Message security assessment using sender identity profiles
US11538064B2 (en) 2017-04-28 2022-12-27 Khoros, Llc System and method of providing a platform for managing data content campaign on social networks
US10902462B2 (en) 2017-04-28 2021-01-26 Khoros, Llc System and method of providing a platform for managing data content campaign on social networks
US10805314B2 (en) 2017-05-19 2020-10-13 Agari Data, Inc. Using message context to evaluate security of requested data
US11102244B1 (en) 2017-06-07 2021-08-24 Agari Data, Inc. Automated intelligence gathering
US11757914B1 (en) 2017-06-07 2023-09-12 Agari Data, Inc. Automated responsive message to determine a security risk of a message sender
US10956459B2 (en) 2017-10-12 2021-03-23 Spredfast, Inc. Predicting performance of content and electronic messages among a system of networked computing devices
US11050704B2 (en) 2017-10-12 2021-06-29 Spredfast, Inc. Computerized tools to enhance speed and propagation of content in electronic messages among a system of networked computing devices
US11687573B2 (en) 2017-10-12 2023-06-27 Spredfast, Inc. Predicting performance of content and electronic messages among a system of networked computing devices
US11570128B2 (en) 2017-10-12 2023-01-31 Spredfast, Inc. Optimizing effectiveness of content in electronic messages among a system of networked computing device
US10346449B2 (en) 2017-10-12 2019-07-09 Spredfast, Inc. Predicting performance of content and electronic messages among a system of networked computing devices
US11539655B2 (en) 2017-10-12 2022-12-27 Spredfast, Inc. Computerized tools to enhance speed and propagation of content in electronic messages among a system of networked computing devices
US11936604B2 (en) 2017-10-17 2024-03-19 Agari Data, Inc. Multi-level security analysis and intermediate delivery of an electronic message
US10601937B2 (en) 2017-11-22 2020-03-24 Spredfast, Inc. Responsive action prediction based on electronic messages among a system of networked computing devices
US11297151B2 (en) 2017-11-22 2022-04-05 Spredfast, Inc. Responsive action prediction based on electronic messages among a system of networked computing devices
US11765248B2 (en) 2017-11-22 2023-09-19 Spredfast, Inc. Responsive action prediction based on electronic messages among a system of networked computing devices
US11061900B2 (en) 2018-01-22 2021-07-13 Spredfast, Inc. Temporal optimization of data operations using distributed search and server management
US11496545B2 (en) 2018-01-22 2022-11-08 Spredfast, Inc. Temporal optimization of data operations using distributed search and server management
US10594773B2 (en) 2018-01-22 2020-03-17 Spredfast, Inc. Temporal optimization of data operations using distributed search and server management
US11102271B2 (en) 2018-01-22 2021-08-24 Spredfast, Inc. Temporal optimization of data operations using distributed search and server management
US11657053B2 (en) 2018-01-22 2023-05-23 Spredfast, Inc. Temporal optimization of data operations using distributed search and server management
US10750033B2 (en) 2018-04-12 2020-08-18 Biscom Inc. Electronic package interception, parsing, and routing
US10623365B2 (en) * 2018-05-25 2020-04-14 Binarytree.com, Inc. Message redirection protocol
US10785222B2 (en) 2018-10-11 2020-09-22 Spredfast, Inc. Credential and authentication management in scalable data networks
US11470161B2 (en) 2018-10-11 2022-10-11 Spredfast, Inc. Native activity tracking using credential and authentication management in scalable data networks
US11601398B2 (en) 2018-10-11 2023-03-07 Spredfast, Inc. Multiplexed data exchange portal interface in scalable data networks
US10999278B2 (en) 2018-10-11 2021-05-04 Spredfast, Inc. Proxied multi-factor authentication using credential and authentication management in scalable data networks
US11805180B2 (en) 2018-10-11 2023-10-31 Spredfast, Inc. Native activity tracking using credential and authentication management in scalable data networks
US11546331B2 (en) 2018-10-11 2023-01-03 Spredfast, Inc. Credential and authentication management in scalable data networks
US10855657B2 (en) 2018-10-11 2020-12-01 Spredfast, Inc. Multiplexed data exchange portal interface in scalable data networks
US11627053B2 (en) 2019-05-15 2023-04-11 Khoros, Llc Continuous data sensing of functional states of networked computing devices to determine efficiency metrics for servicing electronic messages asynchronously
US10931540B2 (en) 2019-05-15 2021-02-23 Khoros, Llc Continuous data sensing of functional states of networked computing devices to determine efficiency metrics for servicing electronic messages asynchronously
US11729125B2 (en) 2020-09-18 2023-08-15 Khoros, Llc Gesture-based community moderation
US11438289B2 (en) 2020-09-18 2022-09-06 Khoros, Llc Gesture-based community moderation
US11128589B1 (en) 2020-09-18 2021-09-21 Khoros, Llc Gesture-based community moderation
US11438282B2 (en) 2020-11-06 2022-09-06 Khoros, Llc Synchronicity of electronic messages via a transferred secure messaging channel among a system of various networked computing devices
US11714629B2 (en) 2020-11-19 2023-08-01 Khoros, Llc Software dependency management
US11936652B2 (en) 2021-01-29 2024-03-19 Spredfast, Inc. Proxied multi-factor authentication using credential and authentication management in scalable data networks
US11627100B1 (en) 2021-10-27 2023-04-11 Khoros, Llc Automated response engine implementing a universal data space based on communication interactions via an omnichannel electronic data channel
US11924375B2 (en) 2021-10-27 2024-03-05 Khoros, Llc Automated response engine and flow configured to exchange responsive communication data via an omnichannel electronic communication channel independent of data source
US11558332B1 (en) * 2022-01-24 2023-01-17 Biscom Inc. Automated electronic package transmission method selection

Also Published As

Publication number Publication date
US7231428B2 (en) 2007-06-12
GB0426693D0 (en) 2005-01-12
JP2005528052A (en) 2005-09-15
AU2003243327A1 (en) 2003-12-12
GB2407735A (en) 2005-05-04
WO2003100640A1 (en) 2003-12-04
US20030229717A1 (en) 2003-12-11

Similar Documents

Publication Publication Date Title
US7231428B2 (en) Communication system using alias management rules for automatically changing sender alias in a message based on group that includes recipient address
US20190362316A1 (en) Method and system for centralized contact management
US7836132B2 (en) Delivery confirmation for e-mail
US20080052364A1 (en) System and method for protecting e-mail sender identity via use of customized recipient e-mail addresses
US9817979B2 (en) Private domain name registration
US6427164B1 (en) Systems and methods for automatically forwarding electronic mail when the recipient is otherwise unknown
US6957248B2 (en) System and method for forwarding electronic messages
US7305445B2 (en) Indirect disposable email addressing
US7912910B2 (en) Triggering a communication system to automatically reply to communications
US7822977B2 (en) System for eliminating unauthorized electronic mail
US7617284B2 (en) Public/private/invitation email address based secure anti-spam email protocol
US7406501B2 (en) System and method for instant messaging using an e-mail protocol
US9240904B2 (en) System and method for a messaging assistant
US20040181581A1 (en) Authentication method for preventing delivery of junk electronic mail
US20070180039A1 (en) Anonymous disposable email addressing system and method of use thereo
US20040243847A1 (en) Method for rejecting SPAM email and for authenticating source addresses in email servers
US9215202B1 (en) Online form completion and saving triggered by receipt of an email message at a final email server
CA2921806A1 (en) System and method for smtp and alternative email protocol interoperability
WO2006014396A2 (en) System and method for mailing list mediation
US20070038777A1 (en) Conversation message server
US10715475B2 (en) Dynamic electronic mail addressing
GB2481242A (en) Providing configurable auto-reply e-mail messages to selected recipients
JP4892163B2 (en) Electronic post office box system
JP2009182749A (en) Device, method, and program for distributing electronic mail
WO2001067305A1 (en) Methods and apparatus for delegating administrative capabilities to domains served by mail providers

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION