AN OVERBROAD PATENT ON DYNAMIC EMAIL NOTIFICATION - This application from Microsoft seeks to patent the idea of... email which changes appearance dynamically based on an external event! 10 minutes of your time can help narrow US patent applications before they become patents. Follow @askpatents on twitter to help.

QUESTION - Have you seen anything that was published before Dec 15, 2011 that discusses:

  1. A external system which sends EVENT SIGNALS to an email server; and
  2. an email server which modifies the appearance of email messages based on the external EVENT SIGNALS;

If so, please submit evidence of prior art as an answer to this question.. We welcome multiple answers from the same individual.

EXTRA CREDIT - A reference to anything that meets all of the criteria to the question above AND ALSO involves event signals such as: CHANGING MEMBERSHIP IN A GROUP, and dynamic updates such as CREATING CALENDAR EVENT .


Summary: [Translated from Legalese into English] A method of modifying the appearance of email or creating or deleting a calendar event based on an external event.

  • Publication Number: US 20130159426 A1
  • Application Number: 13/327,240
  • Assignee: Microsoft Corp.
  • Prior Art Date: Seeking prior Art predating Dec 15, 2011
  • Open for Challenge at USPTO: Open through Dec 20, 2013

Claim 1 requires each and every step below:

A method of controlling an electronic message system, the method comprising:

  1. Receiving at a messaging service in the electronic message system, an event signal relating to an event external to the messaging service, the event signal being received from an external system which is separate from the messaging service; and

  2. identifying one or more electronic messages within the electronic message system based on the event signal received and triggering a dynamic update to the identified electronic messages in response to receipt of the event signal.

In English this means:

A method for providing an external signal to an email service:

  1. Receiving an event signal (e.g. community response to a particular message, the location of one or more users, or a change in membership of a group.); and

  2. Triggering a dynamic update (e.g. displaying in a different manner or the message being delivered or deleted, a calendar event being created or destroyed) in response to the event signal

Good prior art would be evidence of a system that did each and every one of these steps prior to the Dec, 2011.

You're probably aware of ten pieces of art that meet this criteria already... separately, the applicant is claiming event signals such as: CHANGING MEMBERSHIP IN A GROUP, and dynamic updates such as CREATING/DELETING CALENDAR EVENT

"Method of controlling an electronic message system from Microsoft

What is good prior art? Please see our FAQ.

Want to help? Please vote or comment on submissions below. We welcome you to post your own request for prior art on other questionable US Patent Applications.

  • 1
    Can the event signal from the external system be in the form of an email, or does it have to use some other communication protocol (e.g. REST, etc)? From the above, I'm unclear.
    – JoeG
    Aug 6, 2013 at 14:43

5 Answers 5


The IMAP4 protocol is described by RFC1730, published December 1994. IMAP4 is commonly used to access e-mail inboxes today, having mostly replaced the much simpler POP3 in that role. However, IMAP4 is more than just a message retrieval protocol - it is essentially a document storage and filing facility.

Most pertinently, the following quoted section seems to cover the functionality described in the patent:

5.2. Mailbox Size and Message Status Updates

At any time, a server can send data that the client did not request. Sometimes, such behavior is required. For example, agents other than the server may add messages to the mailbox (e.g. new mail delivery), change the flags of message in the mailbox (e.g. simultaneous access to the same mailbox by multiple agents), or even remove messages from the mailbox. A server MUST send mailbox size updates automatically if a mailbox size change is observed during the processing of a command. A server SHOULD send message flag updates automatically, without requiring the client to request such updates explicitly. Special rules exist for server notification of a client about the removal of messages to prevent synchronization errors; see the description of the EXPUNGE response for more details.

Regardless of what implementation decisions a client may take on remembering data from the server, a client implementation MUST record mailbox size updates. It MUST NOT assume that any command after initial mailbox selection will return the size of the mailbox.

This is relevant because message flags are (and have for a long time been) commonly interpreted by e-mail clients as a prompt to display a message in a different colour, for example to highlight it as urgent. The specification also strongly hints at the likelihood of the flag update being performed by "agents" besides the IMAP4 server; this would not normally be a function of a Mail Delivery Agent, so that could only be an agent outside the messaging system.


Anyone who set up a cron job to have sendmail send a message has done number 1, and if the message is changed by just about anything it satisfies #2 also. Below is a forum post with instructions on how to set up the cron job from 2008.



Lotus Notes has external event trigger services with full access to mail.


  • 1
    The events that trigger the agents, as described on that IBM page, are all internal to the Lotus Domino messaging server. They do not qualify as prior art for a signal originating on an external system. It is theoretically possible to use Domino's externally-accessible interfaces (e.g., HTTP) to trigger an agent or web service that updates a previously-delivered email, however I know of know examples of this. (There are plenty examples in the other direction, where Domino server reaches out to an external system and then updates emails, but that's not what's described in the patent.) Jul 26, 2013 at 1:06

Here's a post from 2009, detailing the action of receiving a message and making a change to a calendar:



Moving messages between Outlook folders based on external events generated by the UPS shipper program was described on 31st March 2007 by anonymous contributor "Tech43" to the Thunderbird planning wiki:

For example, message sorting into folders based on business rules, and triggered by external events, like shipping system updates. This external approach also seems to limit the impact that individual application changes have to system operation.

Example of what I do now: Outlook launches an external Windows app (order manager) with every new message (via Rules Wizard). The external order manager app uses msoutl9.olb type library imported as components into Borland C++. This app opens the inbox and reads the new messages, looking for order confirmations sent from a website. The order confirmations are XML attachments and are processed into a MySQL database. The emails are sorted into folders based on order number, for easy retrieval later if needed. The UPS shipper program exports data into the same MySQL database. The order manager program scans the shipping tables for tracking numbers as orders come in, or when an operator tells it to update. Once the orders are in shipment status the order manager generates email messages in the outlook drafts folder and then sends them. This has the added benefit of archiving both inbound and outbound emails for each order within the outlook folders.

In other words, the purpose of this invention (a Windows app which communicated with Outlook via Outlook COM components) was to generate emails to customers telling them their order had dispatched, once UPS had assigned a tracking number to the shipment. The invention took two inputs:

a) Email order confirmations from the website which customers order through.

b) Tracking numbers from the UPS shipper program (presumably UPS WorldShip).

So input b) was an external event sent to the Outlook email client from the UPS shipper program [covering claim 1.1 of the patent]. The event was mediated through the MySQL tables which were accessed by both the UPS shipper program and the invention. The event caused the dispatch of a "Your order has shipped" email to the customer, which was then archived in the same folder as the incoming order confirmation email. [covering claim 1.2 of the patent].

This invention therefore appears to invalidate both claims of the patent.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .