Browse Prior Art Database

Proactively Updating Recipient's Status to Feed an Out-of-office Aware Email System Disclosure Number: IPCOM000197288D
Publication Date: 2010-Jul-01

Publishing Venue

The 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.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 11% of the total text.

Page 1 of 28

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


Server 1

Server 2

User 2

User 1

User 3


[This page contains 8 pictures or other non-text objects]

Page 2 of 28

Vacation System

Vacation Planner

Out of Office Provider

Recipient's Mail Server

Server Engine

Subscription Manager

 Status Records

 Common Subsciption DB

FC List

New Records of today (server)

Sender's Mail Server

Status Manager

Sender's client utility

Out Of

Office Reader

Client Engine

Counter FC List


Records of today

Recipient Refresher



Page 3 of 28


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

Client Side:

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: Recipient e-mail address:

Subscription request's message format:

New Records of today] if sender's client...