U.S. patent application number 11/851693 was filed with the patent office on 2007-12-27 for method and apparatus for dynamically managing electronic mail messages on a remote electronic mail messaging system.
This patent application is currently assigned to AT&T BLS Intellectual Property, Inc., formerly known as BellSouth Intellectual Property Corporati. Invention is credited to Dale W. Malik.
Application Number | 20070299926 11/851693 |
Document ID | / |
Family ID | 38473343 |
Filed Date | 2007-12-27 |
United States Patent
Application |
20070299926 |
Kind Code |
A1 |
Malik; Dale W. |
December 27, 2007 |
Method and Apparatus for Dynamically Managing Electronic Mail
Messages on a Remote Electronic Mail Messaging System
Abstract
A system and method for receiving email instructions allowing
users to remotely manage email messages on a specially adapted
email server. The adapted email server comprises a registration
module and database and other programming logic for verifying the
user and determining the user's instructions for managing the email
on the server. The user may advantageously manage email messages
using any standard email client without the need to actually log in
to the server system.
Inventors: |
Malik; Dale W.; (Dunwoody,
GA) |
Correspondence
Address: |
THOMAS, KAYDEN, HORSTEMEYER & RISLEY, LLP/;AT&T BLS Intellectual Property,
Inc.
600 GALLERIA PARKWAY
SUITE 1500
ATLANTA
GA
30339
US
|
Assignee: |
AT&T BLS Intellectual Property,
Inc., formerly known as BellSouth Intellectual Property
Corporati
824 Market Street
Wilmington
DE
19801
|
Family ID: |
38473343 |
Appl. No.: |
11/851693 |
Filed: |
September 7, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09739816 |
Dec 20, 2000 |
7269624 |
|
|
11851693 |
Sep 7, 2007 |
|
|
|
Current U.S.
Class: |
709/206 |
Current CPC
Class: |
G06Q 10/107
20130101 |
Class at
Publication: |
709/206 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A method for managing a predetermined set of email messages on a
source email server from a remote email network, said method
comprising the steps of: (a) receiving an email message at the
source email server, wherein said email message has a destination
email address in a first field, a code in a second field and an
instruction in a third field, wherein said destination email
address corresponds to a subscriber account on the remote email
network; (b) checking a database to determine a permission for the
destination email address; and (c) performing the instruction on
the set of email messages if the permission is granted.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation of copending U.S. utility
application having Ser. No. 09/739,816, which was filed on Dec. 20,
2000, which is entirely incorporated herein by reference.
FIELD OF THE INVENTION
[0002] The present invention relates to the transmission of
electronic messages over computer networks, and more particularly,
to a method and apparatus for managing and manipulating a plurality
of electronic messages on the basis of pre-determined criteria.
BACKGROUND OF THE INVENTION
[0003] During the past decade, electronic mail messages ("email")
have become an indispensable tool for facilitating business and
personal communications. Through computer networking systems such
as local-area networks ("LAN"), wide-are networks ("WAN"), and the
world-wide web ("WWW"), network user can send and receive notes,
messages, letters, etc., to communicate with others who are in the
same office or perhaps in remote locations across the world.
[0004] For a variety of reasons, many email users typically
maintain email accounts with multiple email service providers. For
example, a user may have a business email account, a personal email
account with a paid service provider, and a personal email account
with a free email service provider. Moreover, users may have email
accounts for use with interactive paging systems or other handheld
electronic messaging devices (e.g., personal data advisor, wireless
telephone, etc.). Typically, each email service provider will
assign a unique email address to each subscriber of the service.
The email address generally corresponds to the user's account on an
email host managed by the service provider. As known in the art,
one or more email hosts may be used to process inbound email while
one or more different email hosts may be used to process outbound
email. Alternatively, the same hosts could be used for processing
both inbound and outbound email messages. In the present example,
although only a single email host is shown for each network, it is
to be understood that multiple email hosts may be used in actual
implementation of an email network.
[0005] FIG. 1 shows examples of common service providers typically
employed by email users for sending and receiving email For
example, the user may have one or more accounts with one or more
email service providers directly connected to Internet email
network 10, such as e.g., a service provided via email host 12.
Such accounts are generally accessible via any computer or network
in communication with Internet email network 10. Computers on
Internet email network 10, e.g., email host 12 or computer 14, may
be in communication with each other and with computers on the other
networks, such as Internet Service Provider ("ISP") network 20,
wireless network 30, interactive paging network 40, or private
network 50. Some email service providers offer purely
Internet-based email services. Such services are accessible to
subscribers already having connectivity to the Internet. For
example, a user on computer 14, already connected to Internet email
network 10, may subscribe to email services hosted on email host
12. The user in this case may be assigned an email address such as:
john@emailhost12.com. In addition to using computer 14, the user
may access his or her email via other computers, such as, e.g.,
computers 24 or 54 shown in FIG. 1. Typical examples of such
Internet-based email service providers include, e.g., Hotmail.com,
Yahoo.com, and the like.
[0006] As noted above, the user may have multiple email accounts
through multiple service providers. For example, in addition to the
account on email host 12, the user may have an email account on
email host 22 on ISP network 20. In the present example, the user
may be assigned an email address such as john@emailhost22.net. As
with the Internet-based email services, email services provided by
ISPs are generally accessible from any computer on the Internet.
For example, the user may access email via computer 24, connected
to ISP network 20, or via computers 14 or 54 on Internet email
network 10 and private network 50, respectively.
[0007] As shown in FIG. 1, the user may have more specialized email
accounts delivered via other networks. For example, the user may
send and receive email via wireless network 30 and email host 32.
Wireless devices, e.g., telephone 34 or personal digital assistant
("PDA") 36, may be used to send and receive email to or from other
wireless devices on wireless network 30 or other email systems
connected via Internet email network 10. The user may also have an
email account on interactive paging network 40 and associated email
host 42. The user in this case may use interactive pager 44 to send
and receive email to any other Internet email address. Finally, the
user may have an email account on private network 50 hosted on
email host 52. The email service provider in this case could be,
e.g., the user's employer and the email messaging system hosted on
email host 52 could be a proprietary email application server.
Moreover, email accounts hosted on email host 52 may only be
accessible using a computer directly connected to private network
50 and may require a proprietary client application running on
computer 54.
[0008] Users typically are assigned different email address for
each individual email account. For example the user may have email
addresses: jdoe@emailhost32.wireless.com, jdoe@emailhost42.paging
.net, and john.doe@emailhost52.work.com corresponding to wireless
network 30, interactive paging network 40 and private network 50,
respectively. As described more fully below, such specialized email
services typically are not accessible from any computer on the
Internet.
[0009] A problem for users having such multiple email accounts is
that there may be different hardware, software and communications
systems requirements for accessing the email stored on each
account. For example, some email service providers allow users to
access their email via any computer connected to the Internet using
a variety of suitable email client programs. Suitable client
programs may include web browser client applications, such as
applications available from Microsoft Corporation or Netscape
Corporation, or other applications using suitable email
communications protocols. Commonly used email communications
protocols include, e.g., Post Office Protocol ("POP" or "POP3") or
Internet Messaging Access Protocol ("IMAP" or "IMAP4"). Other email
service providers, may require proprietary software such as, e.g.,
Lotus Notes, or Groupwise. In addition to different software
requirements, there may be other barriers for managing and
accessing email on multiple accounts for using a single interface.
For example, private networks may allow access to email services
only via certain communications channels, such as, e.g., a direct
dial-up network connection to a private network comprising the
email host, or only from computers within a defined physical
perimeter. Also, an email service provider may only offer access to
email accounts via special hardware, such as a wireless telephone
or interactive pager.
[0010] A problem therefore exists for users having multiple email
accounts because access to each email account using a single device
may not be possible. One method used to get around this problem has
been to set up automatic forwarding procedures from each account to
a central account. Using this method, the user need only ensure
access is available to this central account to have access to all
of his or her email. This method has numerous drawbacks, e.g.,
there is little or no segregation of the user's email making it
more difficult to separate work accounts from personal accounts;
depending on the account used to receive all email, attachments may
not be readable; and in some cases, the user is identified as the
sender of the email making it more difficult to identify and
prioritize the email. Another drawback is that the user must have
access to the central account any time he or she wishes to review
email messages. However, users may not always know in advance where
they will be located and what type of email access will be
available.
SUMMARY OF THE INVENTION
[0011] The present invention comprises a system and method for
remotely managing email messages on a source server. The system
comprises a database of destination email addresses corresponding
to subscriber accounts authorized to remotely manage email
messages. To remotely manage email on the source server, the
subscriber (also referred to herein as the "user") sends management
instructions via email messages transmitted to the source server
from one of the subscriber's destination email addresses.
Accordingly, the instruction email messages have a valid
destination email address in the messaged sender-id field. The
instruction email message may have a special code in some
predetermined field, or, alternatively, the instruction email
message may be addressed to a special account on the subscriber's
source server. When the source server receives an instruction email
message (identified by the special code or because it was addressed
to a special account), the source server checks the database to
verify the destination email address as an authorized account. If
the destination address is valid, i.e., the address has been
registered, the source server source server interprets the
subscriber's instructions and performs the requested management
tasks on email in the user's account on the source server.
[0012] The instruction message may contain a command providing the
user's instructions to the source server. Alternatively, if the
message contains no command, the source server may perform a
default action on the user's email messages. The instruction
message may further include criteria for identifying the email
messages to be operated on by the source server. The criteria may
include Boolean operators and provide conditions or rules for
determining whether or not a message is to be included. The
criteria may also include strings of data and associated email
message fields which should be searched for matching email
messages. Accordingly, the user can specify, with some
particularity, which messages in his or her email account on the
source server will be managed. The email managed according to the
present invention may comprise email messages in the user's inbox,
the user's outbox or both mailboxes on the source server.
[0013] In a preferred embodiment of the present invention, a
registration module and database are provided for administering
users' destination email addresses. The database comprises a list
of destination email addresses associated with each user. The
database may further comprise device type associated with each
destination email address. This additional information may be used
to determine whether or not the device type is compatible with the
user's instructions. In this embodiment, if the device is not
compatible, the system may modify the user's instructions according
to the device type.
[0014] It is an object of the present invention to provide a system
and method for remotely managing email messages on an email server
using a remote email account.
[0015] It is another object of the present invention to enable
users to remotely manage email messages on an email server using a
remote email account with a standard email client interface.
[0016] It is another object of the present invention to allow an
email user to retrieve email from one email account to a remote
email account.
[0017] These and other objects of the present invention are
described in greater detail in the detailed description of the
invention, the appended drawings and the attached claims.
DESCRIPTION OF THE DRAWINGS
[0018] FIG. 1 is a schematic diagram of a network architecture in
which the present invention may be implemented.
[0019] FIG. 2 is a functional diagram showing data flow and
programming logic used in a preferred embodiment of the present
invention.
[0020] FIG. 3a is a flow chart of steps carried out in a preferred
embodiment of the present invention.
[0021] FIG. 3b is a flow chart of steps carried out in an
alternative embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0022] The present invention may be implemented in any network
email architecture, such as, e.g., the architecture shown in FIG.
1. In a preferred embodiment, only the email server application on
selected email hosts need be modified or supplemented with
programming logic and databases according to the present invention.
That is, only email server applications allowing remote email
management need the additional programming logic. The remote email
server applications and associated client application do not need
any changes to operate in accordance with the present invention. In
an alternative embodiment, the email client applications used by
subscribers to issue instruction email messages may be modified or
supplemented as described herein.
[0023] For purpose of explanation, assume a user (not shown in FIG.
1) has email accounts on each of the hosts and networks described
above. That is, assume the user's email addresses for the
respective networks are as shown in Table 1, below. Assume, further
for purposes of the present example, that the user wishes to manage
email on email hosts 12, 22 or 52 via remote email accounts
accessible via mobile telephone 34, PDA 36 or interactive pager 44.
In this case, the email server applications running on email hosts
12, 22 and 52 are referred to herein as "source server
applications" and the user's accounts on wireless network 30 and
interactive paging network 40 are referred to herein as
"destination addresses." TABLE-US-00001 TABLE 1 NETWORK EMAIL
ADDRESS Internet Email Network 10 John.Doe@emailhost12.com ISP
Network 20 john@emailhost22.net Wireless Network 30
jdoe@emailhost32.wireless.com Interactive Paging Network 40
jdoe@emailhost42.paging.net Private Network 50
John_Doe@emailhost52.work.com
[0024] In the preferred embodiment, the present invention is
implemented by adding programming logic to the source server
application. For example, the source server applications running on
email hosts 12, 22 and 52 would include programming logic for
interpreting instructions from authorized users and acting
accordingly. Email hosts 32 and 42 could also include the
programming logic for interpreters such instructions if the user
wishes to remotely manage email on accounts in those networks.
[0025] FIG. 2 shows a schematic diagram of a source application
server and the programming logic added in the preferred embodiment
of the present invention. As shown in FIG. 2, the programming logic
comprises a plurality of program modules. The modules may be
external applications called by email application server 200 as
shown in FIG. 2, or alternatively, one or more of the modules may
be integral to application server 200. The modules in the preferred
embodiment include registration module 210, instruction module 220
and action module 230. As shown in FIG. 2, registration module 210
and instructions module 220 each interfaces with a database.
Although databases 212 and 222 are shown as different databases,
they could comprise a single database storing the information
needed to carryout the present invention. Moreover, the information
may be integral to the modules or email server application 200, in
which case no separate database is required.
[0026] Registration module 210 uses database 212 to store user
registration information. Registration information may comprise a
list of valid destination addresses for each user and may further
include a password selected by the user for access control. User
registration information may be transmitted to registration module
210 using any suitable means. For example, the requests may be
provided via an interactive form submitted using a web browser
interface. Alternatively, the requests may be provided via email
from the user. The request could even be manually entered by a
technician upon oral or written request by the user. The
registration module may also provide any user interface features
desirable for allowing users to identify all destination addresses
that from which the user may manage his or her email according to
the present invention.
[0027] In the present example, because the user wished to remotely
manage accounts from wireless network 30 and paging network 40, the
user's email addresses on those networks must be registered in the
source server applications. That is, the user would register
destination addresses jdoe@emailhost32.wireless.com and
jdoe@emailhost42.paging.net via a registration module on email
hosts 12, 22 and 52. By registering a destination address on a
source server, the user authorizes the source server application to
accept email management instructions received from the destination
address. For example, if the user wishes to retrieve email from his
or her private network account to his or her interactive pager
account, the user must register the address
jdoe@emailhost42.paging.net on email host 52. To request retrieval
of the email, the user sends an email message from interactive
pager 44 to email host 52 as described below.
[0028] User management instructions are sent via email messages
from the destination address to the source server. In one
embodiment, the user's email message includes a special code in a
predetermined field to identify the email message as a request for
remote management by the user. In this case, when the source server
receives an incoming email messages it checks the predetermined
field for the special code. If the code is present in the
predetermined field, the email message is passed to instruction
module 220 for further processing. For example the special code may
be a particular character string, such as, e.g., "#" or "*MANAGE
EMAIL*" or some other string or symbol which flags an incoming
email message for special processing. The predetermined field could
be any of the fields comprising an email message. Preferably, the
predetermined field is either the subject field or the email
message body. In an alternative embodiment, the user addresses the
email to a special account on the source server. In this case, all
email addressed to the special account is passed on to instruction
module 220 for processing. In either case, instruction module 220
or email application server 200 consult with registration module
210 and database 212 to verify that the sender of the email message
is authorized to remotely manage an email account. If the sender is
authorized, i.e., if the email message was received from a
registered destination email address, instruction module 220 parses
the message to determine the appropriate instructions. If the
sender is not authorized, then no further action need be taken by
the system of the present invention. The system may optionally send
an error message in reply to the received email message to inform
the sender of the problem.
[0029] The user's instructions are inserted in the email in a
predefined format. For example, the instructions may be inserted
into the email subject field and may include a command and a
criteria. The command identifies the actual email management
instructions the user wishes to perform and the criteria identifies
the email message to be acted on. In a preferred embodiment, if no
criteria is provided, the command is performed on all of the user's
email on the source server. Also, in a preferred embodiment, the
command may be blank, which may indicate that some default command,
such as retrieve, should be executed.
[0030] In a preferred embodiment, the commands include management
operations such as send; delete; forward (to another account); send
without attachments, send only attachments; move (to a folder or
directory on the source server); print; and the like. Also, in the
preferred embodiment, multiple commands may be issued in a single
email message. For example, the user may instruct the source server
to send the user's email to the destination address, then delete
the email from the user's mailbox on the source server. The
criteria used to identify email messages may include a Boolean
operation, such as, e.g., "DATE>YESTERDAY" (all email received
since yesterday); "FROM=jane.doe@home.com" (all email received from
the address jane.doe@home.com), or "DATE=21 Jun. 2000 and SUBJ<
> `important document;`" (all email received on the date, Jun.
21, 2000 and containing the phrase "important document" in the
subject field). The criteria need not be Boolean-based, that is,
any suitable syntax may be used to allow the user to identify a
particular email message or class of email messages to be managed
according to the system and method of the present invention.
Moreover, the email messages to be managed could even include email
in the user's "outbox," i.e., the criteria could allow the user to
identify email messages sent by the user from the source server.
Instruction module may consult database 222 for valid Boolean
operators and fields which may be operated upon. Database 222 may
also comprise the user's email account (i.e., the user's inbox and
outbox).
[0031] After instruction module 220 determines the user's
management commands and identifies the email messages to be
operated on, action module 230 is invoked. As shown in FIG. 2,
either instruction module 220 or email server application 200 may
invoke action module 230. Action module 230 prepares the selected
email messages according to the user's instructions. For example,
action module 230 may instruction email application server 230 to
forward the selected email to the destination address. In a
preferred embodiment, action module 230 further formats the email
messages for easy identification at the destination address. For
example, action module 230 may modify the subject field of the
message to indicate the true sender's name. Such modification is
useful because the message sent to the destination address will
have a new sender, such as the user's account on the source server
or some other account on the source server. By modifying the
subject field, the user can identify the message's original sender.
Similarly, the subject field could be modified to include the
criteria provided by the user in the email instruction message.
Again, such modification would assist the user in identifying the
email once it is received at the destination address.
[0032] Registration database 212 may further comprise a list of
device types and associated device capabilities for each registered
destination email addresses. Such information can be used to
validate instructions sent by the user. For example, database 212
may include an annotation that wireless telephone 34 does not have
the capability to receive binary attachments. Accordingly, if the
user sends an instruction that would otherwise result in a binary
attachment being transmitted to wireless telephone 34, instruction
module 220 or action module 230 may consult database 212 to
determine whether or not the action should be taken.
[0033] In another alternative embodiment, registration database 212
may comprise a password or personal identification number ("PIN").
In this embodiment, the user is not limited to using only
registered destination email addresses for remotely managing email
on the source server. That is, the user may send an email
instruction from any email account, provided that the instruction
email includes the password or PIN. Preferably, the instruction
email is encrypted by the user to protect the password or PIN. If
the email is encrypted, the email server application includes the
key needed to decrypt the email for further processing.
[0034] The present invention may further comprise programming logic
added to an email client application. Such programming logic
includes a user-friendly interface for constructing email
instruction messages according to the present invention.
Accordingly, a user need not memorize or use a complex syntax for
identifying the email messages to be managed. Moreover, the user
need not know the command structure required by the instruction
module on the email application server-side.
[0035] The flow charts in FIGS. 3a and 3b show the steps
implemented in a embodiment of the present invention. In FIG. 3a,
the email server application accepts email messages directed to a
special account setup to receive email instructions according to
the preferred embodiment of the present invention. In contrast, the
flow chart in FIG. 3b shows email server application implemented
using the alternative embodiment of checking incoming email for the
special code in some predetermined field, such as the subject field
of the message.
[0036] In step 300, an email message is received by an email server
application (for example email server application 200 shown in FIG.
2) on an email host, such as email host 52 in private network 50.
In step 310, the system determines if the email message is
addressed to the special account for handling according to the
present invention. If the email is not addressed to the special
account, the message is processed according to normal email
channels and the system and method of the present invention ends
processing. If the email message is addressed to the special
account, step 320 is performed. In step 320, registration database
212 is checked to determine whether or not the sender of the email
is a registered destination email address. Step 320 may be
performed directly by email server application 200 or by
instruction module 220 or even registration module 210. As shown in
FIG. 3a, if the sender is registered, the system moves on to step
330. If the sender is not a registered destination email address,
the system may perform optional step 335 and check the email
message to see if a valid PIN or password is included. If a PIN or
password is included in the message it is checked against database
212 for validity. If the PIN or password is not valid, the system
exits. In an alternative embodiment, an additionally step may be
included such that an error message is sent to the sender of the
email. If the PIN or password is valid, the system moves on to step
330.
[0037] In step 330, instruction module 220 parses the email message
to determine the user's instructions for remotely managing email on
the source server. As described above, the instruction may comprise
a plurality of commands and a plurality of criteria for selecting
email messages to be managed. In step 330, instruction module
ensures that the instruction is valid and can be performed as
requested. If the instruction is not valid, the system may attempt
to fix the instruction in optional step 345. If the user's
instructions cannot be fixed, the system may move on to optional
step 347, where the user is sent a reply message. If optional step
345 is implemented in an embodiment of the present invention, the
fixed instruction preferably is non-invasive, that is, the system
will not destroy email messages on the source server without
express instructions from the user. As described above, a situation
where the system could fix the instruction may arise if database
212 also includes device type information associated with each
destination email address. In this case, if the user requests
attachments to be sent, but the device cannot receive such input,
the users' instruction may be modified to send only the main part
of the email but no attachments. Similarly, the user's instruction
may be modified to instead send an error message or other
informational message to the user.
[0038] If the user's instruction is valid or is fixed in step 345,
the system moves on to step 350 for further processing according to
the present invention. In step 350, the user's instructions are
processed by action module 230. As described above, actions taken
may include a number of email management tasks. For example, the
action may be to send selected email messages to the user followed
by deleting the email from the user's inbox.
[0039] The flow chart in FIG. 3b shows many of the same steps
described above. For simplicity, optional steps, such as steps 345
and 347, are omitted from FIG. 3b. However, these optional steps
and others may be included in this embodiment if desired. The
primary difference between the embodiment shown in FIG. 3b and that
shown in FIG. 3a, is how the system determines that an email
received by the email server application comprises a request for
remote management from a user. As shown in FIG. 3b, step 310
(determining that the email is sent to a special account) is
replaced by step 315. In step 315, a predetermined field of the
email message is checked for a special code. In a preferred
embodiment, the predetermined field is the subject field and the
special code comprises a character or string of characters not
commonly included in a subject field. The code may also comprise
the users instructions for remote management. The remaining steps
shown in FIG. 3b are the same as shown in FIG. 3a.
[0040] The foregoing disclose of embodiments of the present
invention has been presented for purposes of illustration and
description. It is not intended to be exhaustive or to limit the
invention to the precise forms disclosed. Many variations and
modification of the embodiments described herein will be obvious to
one of ordinary skill in the art in light of the above disclosure.
The scope of the invention is to be defined only by the claims
appended hereto, and by their equivalents.
* * * * *