WO2001001264A1

WO2001001264A1 - Enterprise messaging system and method

Info

Publication number: WO2001001264A1
Application number: PCT/US2000/017284
Authority: WO
Inventors: Vikram Koka; Greg Kenmitz
Original assignee: Cellmania.Com, Inc.
Priority date: 1999-06-25
Filing date: 2000-06-23
Publication date: 2001-01-04
Also published as: AU5885000A

Abstract

The enterprise messaging system in accordance with the invention is an electronic message forwarding, distribution and management system (20). Using a set of rules developed by a user (44, 46, 56), the system determines an appropriate action to take for a particular electronic message. For example, the actions may include forwarding an urgent electronic message (134) to a pager (30), blocking electronic messages (132) from certain sources such as junk email senders, forwarding electronic messages from a predetermined list of senders (136) to a first email account, and forwarding electronic messages from another predetermined list of senders to another account.

Description

ENTERPRISE MESSAGING SYSTEM AND METHOD

Background of the Invention

This invention relates generally to a system and method for routing various

types of electronic messages and in particular to a system and method for electronic

message forwarding and message management.

The use of various forms of electronic messages, such as electronic mail (e-

mail), facsimiles, or electronic voice mails has increased exponentially in the last

couple of years. Often, electronic messages have become the preferred method for

communicating with a lot of people. People often want to be able to forward these

electronic messages to one or more different mail-boxes depending on where the

individual may want to read and respond to the message. For example, an individual

may want to, after work, forward all of his/her electronic messages to a home account.

As another example, a person traveling may forward his/her electronic messages from

work to a two-way pager which can display the messages so that the person may

respond to the messages without having to use a modem to connect to his/her work.

Most electronically connected people may have five different electronic

message accounts (one at work, one at home, one for the two-way pager, etc.). It is

desirable to be able to give people a single address and then be able to filter the

incoming messages between the five accounts. Thus, it is desirable to provide some

system for managing the flow of electronic messages and for managing the distribution of the electronic messages. For example, it is desirable to provide a system which may

forward urgent electronic messages to a pager, block electronic messages that originate

from a predetermined list of junk electronic message sources, and only forward

electronic message that originate from particular sources. Thus, it is desirable to

provide an electronic message management and distribution system and it is to this end

that the present invention is directed.

Summary of the Invention

The enterprise messaging system in accordance with the invention may manage

the flow of the electronic messages and control the distribution of those electronic

messages. In particular, the system may include a list of rules, developed by the user

of the system, that indicate the correct management or distribution of certain electronic

messages. For example, one rule may state that an electronic messages from particular

sources should be forwarded to a particular user account while other electronic

messages from other sources should be forwarded to a different user account. The

rules that may be developed using the system are very flexible which permits the user

of the system to manage and distribute the electronic messages in a variety of different

manners. For example, different rules may forward urgent electronic messages to a

pager, may block electronic messages that originate from certain sources, may forward

electronic messages conforming to certain criteria to one destination while forwarding

other electronic messages conforming to other criteria to another destination. The system may also preserve the identity of the source of an electronic

message. In particular, the system may disguise the source of an electronic message so

that a user of the system could be answering the message from a pager but the recipient

sees that the message originated from the user's work account. To accomplish this, the

system may convert the electronic message address from one address to another

address. The system may also perform the various forwarding and distribution of the

electronic messages without storing the electronic message on a persistent storage

device, such as hard disk drive, so that the distribution of the messages is faster than

typical systems that perform various slow disk drive operations on the message.

Brief Description of the Drawings

Figure 1 is a diagram illustrating an electronic message distribution and

management system in accordance with the invention;

Figure 2 is a diagram illustrating more details of the electronic message

distribution and management system in accordance with the invention;

Figure 3 is a diagram illustrating electronic message forwarding in accordance

with the invention;

Figure 4 is a diagram illustrating diskless message forwarding in accordance

with the invention; Figure 5 is a diagram illustrating an example of a home page for the electronic

message management and distribution system;

Figure 6 is a diagram illustrating an example of an account editing page in

accordance with the invention;

Figure 7 is a diagram illustrating an example of an electronic message

management rule generation page in accordance with the invention; and

Figure 8 is a diagram illustrating another example of an electronic message

management rule generation page in accordance with the invention.

Detailed Description of a Preferred Embodiment

The invention is particularly applicable to an electronic mail distribution and

management system using the Internet and it is in this context that the invention will be

described. It will be appreciated, however, that the system and method in accordance

with the invention has greater utility, such as to other types of electronic messages such

as facsimiles, voice mails and the like.

Figure 1 is a diagram illustrating an electronic message distribution and

management system 20 in accordance with the invention. The electronic message

distribution and management system (abbreviated as EMS in the remainder of this

specification) is a message forwarding, distribution and management system which

permits a user to manage one or more different electronic message accounts. The EMS 20 may include a plurality of incoming electronic messages 22, shown as electronic

mail (e-mail) in this example, a server 24 and one or more electronic message devices

26 that are recipients of the incoming electronic messages. In this example, the

electronic message devices may include a cell phone 28, a pager 30, an e-mail account

32 and a trash can 34. The cell phone, page and e-mail account may receive the

electronic messages so that the user may review and respond to them while the user

may elect to throw some of the incoming electronic messages directly into the trash

without reading them based on some information, such as the source or sender, in the

electronic message. In accordance with the invention, the choice of which electronic

message device each electronic message is forwarded or distributed to depends on a set

of rules which define the action to be taken for each electronic message as described

below in more detail. For example, the rules may specify that urgent emails are

forwarded to the pager of the user for immediate response, emails from a

predetermined list of sources or senders, such as junk email senders, are blocked and

throw in the trash, emails from a predetermined list of senders or sources (e.g.,

personal messages) are forwarded to a free email account (at Yahoo!, AOL, etc) for

later viewing and other emails (e.g., business related) from a second list of senders are

forwarded to a corporate account.

As described above, the system 20 may manage, distribute and forward any

type of electronic message including, for example, e-mails, digital voice mail messages

and facsimile messages. As described below, the system may include an identity preservation feature so that the actual address of the recipient is hidden from the sender

even after the recipient responds to the forwarded message from a different forwarding

addresses. The system may also include a diskless forwarding feature as described

below that permits message forwarding and management without using a hard disk

drive (e.g., completely in the random access memory of the server) thereby providing

significant performance and cost advantages. Now, the architecture of the system will

be described in more detail.

Figure 2 is a diagram illustrating more details of the electronic message

distribution and management system 20 and the server 24 in accordance with the

invention. The system may include a simple mail transfer protocol (SMTP) daemon 40

that receives the incoming messages, an message content manager 42, a rule engine 44

within the content manager, a rule/profile manager 46, a scheduler 48, a notification

queue manager 50, a sendmail notifier 52, a direct phone notifier 53 and a database 54.

The database 54 may include a profile/rule data 56, scheduled event data 58 and a

notification queue 60. The elements shown in the diagram are preferably one or more

software applications that are executed by the server's CPU and may be stored in the

persistent storage and memory of the server. For example, the SMTP daemon may be

a background process which runs in the background while the server is performing

other functions.

The SMTP daemon 40 may receive the incoming e-mail message packets and

generate the message from the incoming e-mail packets. The SMTP daemon may forward received e-mails to another e-mail address based upon instructions from the

content manager 42. The SMTP daemon may also forward all messages not being sent

to another e-mail address to the content manager 42. The content manager 42 may

process each incoming message using the rule engine 44. In particular, for each

message, the rule engine may compare the information about the message to one or

more rules/profiles, stored in the database 54 and managed by the rule/profile manager

46, to determine the appropriate action to take for the particular message. The content

manager, once an action is determined, may send a new action to the notification queue

manager 50 which schedules the action into the notification queue 60 stored in the

database 54. The notification queue manager may also schedule scheduled events 58

using the scheduler 48. A scheduled event may include a particular message being sent

to a list at a predetermined time. Based on the contents of the notification queue 60,

the notification queue manager 50 may forward the message to the sendmail notifier 52

or the direct phone notifier 53 depending on the destination of the message. The

notifiers 52, 53 then forward the message to the appropriate destination. Now, several

examples of the rules/profiles that are used to manage incoming messages will be

described.

The rules/profiles are stored in the database 54 and permit the content manager,

using the rule engine 44, to process each incoming message. The rules may identify

each incoming message according to various information in the message, such as source, sender, domain name, subject text, message body text, etc., and then take the

action (e.g., forwarding, distributing, deleting, etc.) specified by the rule/profile.

For example, a rule profile may state: If ((sender name in ('Greg Kemnitz',

'Neerav Berry')) and (priority = 'Urgent')) then send to my_cell and forward to

my_real_email. This profile/rule specifies that if the sender of the incoming message

matches a predetermined name and the priority of the message is urgent (which may be

determined based on the header of the message), then the message should be sent to the

user's cell phone as an alphanumeric text page and also forwarded to the user's e-mail

account.

As another example, a rule may provide: If (sender name = 'Kjirsten Koka')

then send to my_cell and forward to my_real_email. In this case, all messages which

are from a particular individual may be sent to the user's cell phone and forwarded to

the user's email account. In another example, the rule may state: If (to != 'Vikram

Koka') then delete. In this case, the rule specified that all e-mail not from Vikram

should be deleted which permits the user to filter out all other messages. In most

cases, the user may also have a default rule which governs all messages not covered by

other rules. For example, the default rule may be: forward to my_real_email so that all

messages which do not trigger any other rules are automatically forwarded to the user's

e-mail account for later review. Thus, the rules permit the user to manage the

incoming messages. The rules/profiles may be generated to use a variety of different incoming message information in order to process the messages. Now, the message

forwarding feature in accordance with the invention will be described.

Figure 3 is a diagram illustrating an example of the electronic message

forwarding in accordance with the invention which permits the identity of the

originating location to be hidden from the recipient. In particular, for privacy reasons,

recipients may not want senders to know where the recipient is responding from. For

example, a user may set up a rule to forward all his messages from his boss to his

mobile pager. The system permits the user to receive and respond to messages from

the boss without the boss being aware that he is actually receiving and/or responding

to the messages from his pager as opposed to from the office. The boss only knows

that the message responses are from the user's email address (johnfg).cellmania.com).

In this way, the user does not have to reveal his pager number to the boss or that the

responses are actually from the pager.

As shown in Figure 3, the messaging server 24 permits this privacy to be

maintained. The server 24 handles the email from the boss, Linda in this example,

to/from the user, John in this example, in the following fashion as illustrated in Figure

3. The email message from Linda at lindafg⁾.corp.com is sent to John at

john(g⁾.cellmania.com. The server 24 reads the email, validates that

john@cellmania.com is a valid user, evaluates John's rules stored in the server and

processes the incoming message based on John's rules. In this example, the EMS rule

engine 44 (shown in Figure 2) determines that John wants all email from linda@corp.com to be forwarded to his pager at 12345656@pager.com. Based on the

rule, the EMS content manager 42 (Figure 2) sets the From and Reply To fields of the

email to be linda#_#coφ.com@remail.cellmania.com. The username field is preserved

so that when John gets the message on his pager, the username is Linda but the From

and Reply To is the encoded email address so that it can be routed back to Linda

through the server 24.

When John replies to the message, it travels back to the Sendmail daemon 40

(Figure 2) at the system 20. The Sendmail daemon 40 does a reverse lookup of

1235656@pager.com in its profile engine and determines that the mail is from John. It

then decodes the destination address to linda@corp.com based on the encoded From

and Reply To fields, and sets the From and Reply To addresses to

john@cellmania.com so that Linda thinks that the message is being sent from John's e-

mail account. The EMS 20 guarantees that the entire messaging dialog between John

and Linda occurs without Linda knowing that John is replying from his pager. Now,

the diskless forwarding feature in accordance with the invention will be described.

Figure 4 is a diagram illustrating the diskless message forwarding in

accordance with the invention. In particular, the EMS server 24 operates without

writing the incoming messages to a persistent storage device, such as a hard disk. By

keeping the messages entirely in the memory of the server, the EMS system 20 is

extremely fast and scalable. For example, the EMS system may be easily scaled to

handle additional message load by adding more processors. In addition, since hard disk operations are up to 10 times slower than memory operations, the EMS system 20

is much faster. Another major advantage with the EMS system 20 over disk-based

messaging architectures is that the sender gets an immediate acknowledgement of

success or failure of the message communication since existing message forwarding

architectures that are disk based have an inherent lag time for acknowledging success

or failure of message forwarding.

Using the same messaging example as shown in Figure 3, the EMS system 20

may work in a diskless fashion as illustrated in Figure 4. In particular, an email

message from Linda at linda@corp.com is sent to John at john@cellmania.com. The

EMS server 24 may read the email and validates that john@cellmania.com is a valid

user using the profile manager 46 which in turn queries the profile data in the database

54. If the address is not a valid address, then EMS sends out a "User Unknown"

response immediately. If it is a valid address, then the EMS server 24 asks the rule

engine 44 for forwarding rules set by the user john@cellmania.com. The rule engine

44 may determine, based on the current rules, that John wants all email from

linda@corp.com to be forwarded to his pager at 12345656@pager.com. The content

manager 42 may then set the From and Reply To fields of the email to

linda#_#corp.com@remail. cellmania.com and asks a delivery manager 72 to forward

the message to the appropriate destination. The delivery manager may determine

whether to respond to the device directly or send the message on to the Sendmail

daemon for forwarding that allows for device specific forwarding protocols and message formatting to be completed. For example, some paging providers support

NNTP, TAP and other messaging protocols that are more efficient than email. In this

example, all of the steps in the processing of the message are performed without

writing the message or the message information to a persistent storage device which

increases the overall speed of the messaging system. Now, the diskless messaging in

accordance with the invention will be described in more detail.

Most conventional messaging systems tend to operate under a model in which

they: 1) receive the message (after some preliminary analysis about the destination); 2)

save the message to temporary disk storage; and 3) confirm receipt of the message to

the sender. Then later, the conventional systems: 4) analyze the message in detail (to

figure out what to do with it); 5) process the rules (if any) which apply to the message;

6) forward the message to the appropriate destination in whole or partial increments;

and 7) if any errors happen during this process, create a new message (a bounce or

error message) and send this back to the originator to indicate failure in processing.

Fundamentally, the steps above are based on a two step "store and then

forward" paradigm. Some obvious pitfalls in this two-step paradigm is the notion of

delayed asynchronous error responses which is fundamentally harder to deal with than

immediate error feedback, as well as the performance (and consequent scalability)

limitations of writing to disk as part of the handling of every message. To clarify the

performance implications, obviously writing to disk is many times slower than writing to RAM, and therefore far fewer messages can be processed by a single machine in a minute if it were writing to disk.

In accordance with the invention, in part because of our ability to handle the

whole message in RAM, the messaging model has changed to the following: 1) receive

the message; 2) analyze the message in detail (to figure out what to do with it and

which rules apply to it); 3) process the rules which apply to the message; 4) forward

the message to the appropriate destination(s) completely; and 5) confirm success or

failure (in case of errors) to the originator. This is a far more efficient model of

message propagation and scales to handle more messages better that conventional

systems, because: 1) the system does not store the message within our servers disk as

part of normal processing; 2) the system processes all the rules in real time; 3) the

system sends the message to the remote destination(s) in real time; 4) the system get a

confirmation back to the originator in real time; and 5) the system easily scales across

multiple CPUs and multiple machines. In fact, the system is currently limited by the

ability of the receiving servers (destinations) to handle our messages. Now, an

example of a Web-based EMS system will be described.

Figure 5 is a diagram illustrating an example of a home Web page 100 for the

electronic message management and distribution system. The home page permits the

user to log onto the EMS system. Once logged on, the user may select from an account

tab 102, a forwarding rule tab 104, an exception rule tab 106 and an about us tab 108.

The account tab permits the user to specify the accounts that the EMS system is managing, the forwarding rule tab and the exception rule tab permit the user to specify

the distribution, forwarding and management rules to control the processing of the

incoming electronic message and the about us tab contains information about the

company that created and supports the EMS system. The home page also includes

other information about the company that anyone who accesses the URL of the Web

page may view. Now, an account editing page will be described.

Figure 6 is a diagram illustrating an example of an account editing page 120 in

accordance with the invention. Once the user has registered for and logged onto the

EMS system, the user may access this account editing page 120. The page 120 may

include an account editing portion 122 and a current account display portion 124. The

account editing portion permits the user to add or edit account information to which the

incoming electronic messages may be forwarded depending on the rules. The account

editing portion permits the user to specify an account name , an account type (e-mail,

pager or phone) and an account address to to which the incoming messages may be

redirected. The current account portion 124 lists the current accounts to which the

incoming messages may be forwarded and distributed. Now, an electronic message

management rule generating page will be described.

Figure 7 is a diagram illustrating an example of an electronic message

management rule generation page 130 in accordance with the invention. In the page,

the user may specify the rules which are used by the rule engine to process incoming

messages. The page may include a blocking rule section 132, a priority message section 134, a forwarding section 136 and a default rule section 138. The blocking

section permits the user to specify the senders or sources of messages that should be

throw away without reading them, the priority section permits the user to specify the

senders or sources whose messages should be immediately forwarded to one of the

messaging devices of the user, the forwarding section permits the user to specify the

sources or senders whose messages should be sent to an account, such as e-mail, and

the default section permits the user to specify what happens to all other messages not

covered by the other sections. As shown in Figure 7, the user has specified that, by

default, messages are sent to the user's pager. Now, another example of an electronic

message management page will be described.

Figure 8 is a diagram illustrating another example of an electronic message

management rule generation page 150 in accordance with the invention. In this

example, the exception rules are specified which permits the user to change the normal

rules in certain situations such as during a vacation. The page has the same sections

132 - 138 as above since the user may still specify new rules for the exception period.

In addition, the page contains a section 152 that permits the user to specify a time

period during which the exception period is effective.

In summary, the EMS system permits a user with multiple different accounts to

manage the electronic messages going to each account since all of the messages are

initially sent to the EMS system which then redistributes them according to the set of rules specified by the user. The EMS system may include an identity concealment

feature and a diskless messaging system feature.

While the foregoing has been with reference to a particular embodiment of the

invention, it will be appreciated by those skilled in the art that changes in this

embodiment may be made without departing from the principles and spirit of the

invention as defined by the appended claims.

Claims

CLAIMS:

1. A system for managing the communication of one or more messages

between a user and a plurality of other entities wherein the user has one or more

different messaging accounts, comprising

a message manager for receiving incoming messages to the user;

a content manager for managing the incoming messages to the user, the content

manager comprising means for determining the distribution of the incoming messages

to the one or more messaging accounts of the user;

a delivery manager for delivering the incoming messages to one of the one or

more messaging accounts of the user based on the determination of the content

manager; and

wherein the communicated messages are not stored on a persistent storage

device during the management of the communication of the messages.

2. The system of Claim 1, wherein the content manager further comprises

a database containing one or more rules, wherein each rule specifies, based on

information in the incoming message, an action to be taken with respect to an

incoming message that satisfies the rule constraints and a rule manager for applying the

one or more rules to each incoming message in order to determine the management

action taken for each incoming message.

3. The system of Claim 2, wherein the rules comprise a rule for forwarding

an incoming message to a particular messaging account based on the information in the

incoming message, a delete rule for deleting an incoming message to a particular

messaging account based on the information in the incoming message, an exception

rule for managing the incoming messages during an exception period, and a default

rule for managing an incoming message that does not satisfy any of the other rules.

4. The system of Claim 1, wherein the one or more different messaging

accounts comprise one or more different messaging devices.

5. The system of Claim 1 further comprising means for disguising the

source of a message so that the recipient of the message cannot determine the actual

source of the message.

6. The system of Claim 5, wherein the disguising means further comprises

means for encoding the actual address of the message originator in the from and reply

to fields.

7. The system of Claim 1 further comprising a schedule manager for

scheduling events that occur at a predetermined time.

8. A method for managing the communication of one or more messages

different messaging accounts, comprising receiving incoming messages to the user;

managing the incoming messages to the user including determining the

distribution of the incoming messages to the one or more messaging accounts of the

user; and

delivering the incoming messages to one of the one or more messaging

accounts of the user based on the determination of the content manager wherein the

communicated messages are not stored on a persistent storage device during the

management of the communication of the messages.

9. The method of Claim 8, wherein the managing further comprises

applying one or more rules to each incoming message in order to determine the

management action taken for each incoming message, each rule specifies, based on

information in the incoming message, an action to be taken with respect to an

incoming message that satisfies the rule constraints.

10. The method of Claim 9, wherein the rules comprise forwarding an

incoming message to a particular messaging account based on the information in the

incoming message, deleting an incoming message to a particular messaging account

based on the information in the incoming message, managing the incoming messages

during an exception period, and managing an incoming message that does not satisfy

any of the other rules.

11. The method of Claim 8, wherein the one or more different messaging

accounts comprise distributing the incoming message to one or more different

messaging devices.

12. The method of Claim 8 further comprising disguising the source of a

message so that the recipient of the message cannot determine the actual source of the

message.

13. The method of Claim 12, wherein the disguising further comprises

encoding the actual address of the message originator in the from and reply to fields.

14. The method of Claim 8 further comprising scheduling events that occur

at a predetermined time.

15. A method of disguising the source of a message from an originator to a

user, the method comprising:

determining a messaging account to which the incoming message is forwarded

based on the originator of the incoming message;

encoding the address of the originator in the reply and from fields of a new

message being forwarded to the user at the messaging account, the new message

containing the incoming message from the originator; the user generating a second new message back to the originator in response to

the new message; and

decoding the encoded address in the second message so that the originator does

not know that the incoming message was forwarded to a different messaging account.

16. A system for managing the communication of one or more messages

different messaging accounts, comprising

a SMTP daemon for receiving incoming messages to the user;

a content manager for managing the incoming messages to the user, the content

to the one or more messaging accounts of the user, the content manager further

comprising a database containing one or more rules, wherein each rule specifies, based

on information in the incoming message, an action to be taken with respect to an

incoming message that satisfies the rule constraints and a rule engine for applying the

one or more rules to each incoming message in order to determine the management

action taken for each incoming message.

a delivery manager for delivering the incoming messages to one of the one or

more messaging accounts of the user based on the determination of the content

manager; and wherein the communicated messages are not stored on a persistent storage

device during the management of the communication of the messages.