Proactively Updating Recipient's Status to Feed an Out-of-office Aware Email System
Publication Date: 2010-Jul-01
The IP.com Prior Art Database
The present invention facilitates an “out-of-office”-aware e-mail system that gives the sender the opportunity to reduce redundancy and improve efficiency while the sender sends e-mail. 1). We use Subscribe-Publish mechanism to inform the sender’s e-mail client of the “out-of-office” information for the ‘subscribed’ frequent contact person and also any modifications to the “out-of-office” information for that away person. A. We can define the rules as to how we create the subscription. For example, if the sender queries the recipient’s status for more than 3 times in 1 month, then the sender initiates one subscription to recipient’s mail server no matter the recipient is out-of-office or not. This rule is considered for the frequent contact persons. B. Another rule could be used when the sender firstly gets one recipient’s out-of-office message. Then the sender is subscribed to that recipient’s mail server during that recipient’s out-of-office period. This is considered as a common subscription. C. Recipient’s mail server will maintain subscribed records for those out-of-office messages in synchronous with sender’s mail client D. Once recipient’s e-mail server received any updates from the recipient’s Out-of-office information provider, it will publish the updates to the sender’s email client. 2). We use trust mechanism to inform the sender’s e-mail client of the “out-of-office” information for all subscribed and frequent contact persons. Sender will check and trust out-of-office message list and frequent contact person list in local, and will not send status query to recipient’s mail server any more within the subscription period. As more than 95% recipients are not out-of-office, and 80% emails are sent to 20% most frequent contact recipients (according to Vilfredo Pareto’s 80-20 Rule), this trust mechanism will save much cross-network query overhead. 3). We use the integrated Out-of-office Provider to capture the recipient's “out-of-office” status from various out-of-office sources, e.g. the vacation system, so that we can avoid the situation that the recipient forgot to enable his out of office facility. We can also integrate with enterprise personnel information system e.g. Blue Page, to get person’s backup information. When a recipient submits vacation request, he needs to input backup information, vacation duration and when he will be available to check e-mail during vacation, etc. Once capturing the out-of-office information, Out-of-office Provider will automatically push the vacation information to recipient’s mail server and recipient’s mail server will store out-of-office message in local. 4). We will provide the option for the sender to check the status of backup person in circulatory. 5). We will prompt the sender of the complete “out-of-office” information of the recipient. Such that sender will know the accurate time period when the recipient is available to handle e-mail during his/her vacation and when he/she will be back.
Proactively Updating Recipient '
's Status to Feed an Out
s Status to Feed an Out -
--office Aware Email System
office Aware Email System
This disclosure presents a method and system for building an "out-of-office"-aware e-mail system. The overall system architecture and workflow are shown in below Figures respectively.
1. System architecture
The whole architecture of the system
of Office Provider
Out of Office Provider
Recipient's Mail Server
Common Subsciption DB
New Records of today (server)
Sender's Mail Server
Sender's client utility
Counter FC List
Records of today
Counter FC List
Records of today
Referring to above system architecture figure, "out-of-office"-aware e-mail system includes four major components and four repositories in e-mail system client side, two components and 3 repositories in e-mail system server side and one components in vacation system side.They are:
User1 --- sender
User2 --- recipient
User3 --- backup of User2
Out Of Office Reader: It is responsible for capturing User1 inputted User2's email address in mail address field, informing Client Engine to check User2's status and prompting User1 if he wants to send email to User2's backup (User3) if User2's status is out-of-office.
Client Engine: It is core in the client side of whole system. It is responsible for runtime process and housekeeping job. For runtime process, it is responsible for recording all recipients' real-time out-of-office messages in the repository "New Records of today", recording the time and count of sending mail/query to each recipient in the repository "Query Counter" and searching recipient's out-of-office records & status from local repositories "New Records of today", "Calendar" and "FC List" or from remote e-mail server by invoking "Status Manager". For housekeeping job, it is responsible for synchronizing local "FC list" with remote email-server side and capturing subscribed out-of-office messages and storing to local repository "New Records of today".
Status Manager: It lies on top of sender's email server. It is responsible for sending status checking request/subscription request to recipient's e-mail server and receiving out-of-office status change and subscribed records from recipient's e-mail server. Meanwhile, it will store out-of-office records and subscribed records received from recipient's e-mail server into sender's server siderepository [
Status Checking request's message format:
Sender e-mail address: User1@cn.ibm.com Recipient e-mail address: User2@cn.ibm.com
Subscription request's message format:
New Records of today] if sender's client...