REGISTER  |  SIGN IN
United States Patent Application20020120697
Kind CodeA1
Generous, Curtis ; et al.August 29, 2002
Multi-channel messaging system and method
Abstract
A system for delivery of a message to a subscriber over multiple communications channels includes means for accepting the message from a sender, means for determining a sequence of the communications channels for delivery of the message based on a subscriber profile, and means for delivery of the message over at least one of the communications channels until acknowledgement of message receipt by the subscriber.
Inventors:Generous; Curtis (Great Falls, VA), Dunbar; Richard  (Alexandria, VA), Rusnock; Jerry  (Gaithersburg, MD), Whalen; Matthew  (Arlington, VA), Shenton; Christopher  (Washington, DC)
Correspondence Name and Address:Suite 1200 1750 Tyson's Boulevard
GREENBERG TRAURIG, LLP
McLean
VA
22102
US
Series Code:930496
Filed:August 16, 2001
U.S. Current Class:709/206
U.S. Class at Publication:709/206
Intern'l Class:G06F 015/16
Claims

What is claimed is:
1. A system for delivery of a message to a subscriber over multiple communications channels comprising: means for accepting the message from a sender; means for determining a sequence of the communications channels for delivery of the message based on a subscriber profile; and means for delivery of the message over at least one of the communications channels until acknowledgement of message receipt by the subscriber.

2. The system of claim 1, wherein the message includes at least one of an email, an Instant Message, a video, a fax, a page and a voice message.

3. The system of claim 1, wherein the communications channels are tried sequentially until delivery of the message is acknowledged.

4. The system of claim 1, wherein the message is sent out simultaneously over all communications channels designated by the subscriber in the subscriber profile.

5. The system of claim 1, wherein the communications channels include at least one of Instant Messenger, cellular telephone, telephone land line, email, fax, pager and voice message.

6. The system of claim 1, wherein the acknowledgement includes positive acknowledgement.

7. The system of claim 1, wherein the acknowledgement includes negative acknowledgement.

8. The system of claim 1, wherein the message is converted to a form suitable to the communications channel being used.

9. The system of claim 1, wherein the message is converted from character-based to sound-based for delivery to a voice message.

10. The system of claim 1, wherein the message includes a tag.

11. The system of claim 10, wherein the tag includes message delivery expiration time.

12. The system of claim 1, further including means for monitoring functioning of networks, wherein communication channel selection for the delivery of the message is based on the monitoring.

13. The system of claim 1, further including means for monitoring functioning of email servers, wherein communication channel selection for the delivery of the message is based on the monitoring.

14. The system of claim 1, wherein the means for delivery monitors at least one of the following message delivery status indicators in order to select an optimal communication channel for the delivery of the message: Received for assembly, Assembled, Not Assembled, Reason Not Assembled, Sent via DA/Delivered, Sent via DA/Queued, Sent via DA/Rejected, and Sent to Assembled Message data store.

15. The system of claim 1, wherein the message is delivered based on at least one of subscriber geographical information, subscriber ZIP code, subscriber City, subscriber State, subscriber Country, and subscriber Phone number Area Code, subscriber Time zone data, and subscriber Latitude/Longitude data.

16. The system of claim 1, further including at last one of the following capabilities: Time Lapse, the message must be read within a certain time, and the message be read from a specific device.

17. A method of delivering of a message to a subscriber over multiple communications channels comprising the steps of: accepting the message from a sender; determining a sequence of the communications channels for delivery of the message based on a subscriber profile; and delivering the message over at least one of the communications channels until acknowledgement of message receipt by the subscriber.

18. The method of claim 17, wherein the message includes at least one of an email, an Instant Message, a video, a fax, a page and a voice message.

19. The method of claim 17, wherein the communications channels are tried sequentially until delivery of the message is acknowledged.

20. The method of claim 17, wherein the message is sent out simultaneously over all communications channels designated by the subscriber in the subscriber profile.

21. The method of claim 17 wherein the communications channels include at least one of Instant Messenger, cellular telephone, telephone land line, email, fax, pager and voice message.

22. The method of claim 17, wherein the acknowledgement includes positive acknowledgement.

23. The method of claim 17, wherein the acknowledgement includes negative acknowledgement.

24. The method of claim 17, wherein the message is converted to a form suitable to the communications channel being used.

25. The method of claim 17, wherein the message is converted from character-based to sound-based for delivery to a voice message.

26. The method of claim 17, wherein the message includes a tag.

27. The method of claim 26, wherein the tag includes message delivery expiration time.

28. The method of claim 17, further including the step of monitoring functioning of networks, wherein communication channel selection for the delivery of the message is based on the monitoring.

29. The method of claim 17, further including the step of monitoring functioning of message servers, wherein communication channel selection for the delivery of the message is based on the monitoring.

30. The method of claim 17, wherein the step of delivering the message monitors at least one of the following message delivery status indicators in order to select an optimal communication channel for the delivery of the message: Received for assembly, Assembled, Not Assembled, Reason Not Assembled, Sent via DA/Delivered, Sent via DA/Queued, Sent via DA/Rejected, and Sent to Assembled Message data store.

31. The method of claim 17, wherein the message is delivered based on at least one of subscriber geographical information, subscriber ZIP code, subscriber City, subscriber State, subscriber Country, and subscriber Phone number Area Code, subscriber Time zone data, and subscriber Latitude/Longitude data.

32. The method of claim 17, wherein the delivery step delivers the message subject to at least one of the following restrictions: Time Lapse, the message must be read within a certain time, and the message be read from a specific device.

33. A system for delivering an electronic message comprising: means for continuously monitoring functioning of communication channels for delivering the message to a subscriber; means for delivering the message to the subscriber based on a subscriber profile defining priority for the communication channels; and means for modifying the delivery sequence of the communication channels based on information from the means for continuously monitoring.

34. The system of claim 33, wherein the means for monitoring monitors functioning of networks.

35. The system of claim 33, wherein the means for monitoring monitors functioning of remote servers.

36. The system of claim 33, wherein the means for monitoring monitors availability of remote resources on a network.

37. The system of claim 33, wherein the means for monitoring monitors response times of remote resources on a network.

38. The system of claim 33, wherein the means for monitoring maintains statistics on response times of remote resources on a network.

39. The system of claim 33, wherein the means for monitoring number of failed connections to remote resources on a network.

40. The system of claim 33, wherein the means for monitoring monitors if a remote server is down.

41. A method of delivering an electronic message comprising the steps of: continuously monitoring functioning of communication channels for delivering the message to a subscriber; delivering the message to the subscriber based on a subscriber profile defining priority for the communication channels; and modifying the priority for the communication channels based on information from the means for continuously monitoring.

42. The method of claim 41, wherein the step of monitoring monitors functioning of networks.

43. The method of claim 41, wherein the step of monitoring monitors functioning of remote servers.

44. The method of claim 41, wherein the step of monitoring monitors availability of remote resources on a network.

45. The method of claim 41, wherein the step of monitoring monitors response times of remote resources on a network.

46. The method of claim 41, wherein the step of monitoring maintains statistics on response times of remote resources on a network.

47. The method of claim 41, further including the step of monitoring number of failed connections to remote resources on a network.

48. The method of claim 41, wherein the step of monitoring monitors if a remote server is down.

49. A system for delivery of a message to a subscriber comprising: means for accepting the message from a sender; means for adding an expiration time to the message for delivery of the message; and means for delivery of the message to the subscriber prior to the expiration time; means for receiving acknowledgement of message receipt by the subscriber.

50. The system of claim 49, wherein the message includes at least one of an email, an Instant Message, a video, a fax, a page and a voice message.

51. The system of claim 49, further including means for delivery of the message over multiple communications channels.

52. The system of claim 49, wherein the communications channels are tried sequentially until delivery of the message is acknowledged.

53. The system of claim 49, wherein the message is sent out simultaneously over all communications channels designated by the subscriber in a subscriber profile.

54. The system of claim 49, wherein the communications channels include at least one of Instant Messenger, cellular telephone, telephone land line, email, fax, pager and voice message.

55. The system of claim 49, wherein the acknowledgement includes at least one of a positive acknowledgement and a negative acknowledgement.

56. The system of claim 49, wherein the message is converted to a form suitable to the communications channel being used.

57. The system of claim 49, wherein the message is converted from character-based to sound-based for delivery to a voice message.

58. The system of claim 49, wherein the message includes a tag.

59. The system of claim 58, wherein the tag includes message delivery expiration time.

60. The system of claim 58, wherein the tag includes globally unique tracking key identifier.

61. The system of claim 58, wherein the tag includes globally unique message identifier.

62. The system of claim 58, wherein the tag includes versioning information.

63. The system of claim 58, wherein the tag includes a security checksum.

64. The system of claim 58, wherein the tag is dependent on a communication channel chosen for delivery of the message.

65. The system of claim 49, further including means for monitoring functioning of networks, wherein communication channel selection for the delivery of the message is based on the monitoring.

66. The system of claim 49, further including means for monitoring functioning of message servers, wherein communication channel selection for the delivery of the message is based on the monitoring.

67. The system of claim 49, wherein the means for delivery monitors at least one of the following message delivery status indicators in order to select an optimal communication channel for the delivery of the message: Received for assembly, Assembled, Not Assembled, Reason Not Assembled, Sent via DA/Delivered, Sent via DA/Queued, Sent via DA/Rejected, and Sent to Assembled Message data store.

68. The system of claim 49, wherein the message is delivered based on at least one of subscriber geographical information, subscriber ZIP code, subscriber City, subscriber State, subscriber Country, and subscriber Phone number Area Code, subscriber Time zone data, and subscriber Latitude/Longitude data.

69. The system of claim 49, further including at last one of the following capabilities: Time Lapse, the message must be read within a certain time, and the message be read from a specific device.

70. A method of delivering a message to a subscriber comprising the steps of: accepting the message from a sender; adding an expiration time to the message for delivery of the message; and delivering the message to the subscriber prior to the expiration time; and receiving acknowledgement of message receipt by the subscriber.

71. The method of claim 70, wherein the message includes at least one of an email, an Instant Message, a video, a fax, a page and a voice message.

72. The method of claim 70, further including the step of delivery of the message over multiple communications channels.

73. The method of claim 70, wherein, in the delivering step, the communications channels are tried sequentially until delivery of the message is acknowledged.

74. The method of claim 70, wherein the message is sent out simultaneously over all communications channels designated by the subscriber in a subscriber profile.

75. The method of claim 70, wherein the communications channels include at least one of Instant Messenger, cellular telephone, telephone land line, email, fax, pager and voice message.

76. The method of claim 70, wherein the acknowledgement includes at least one of a positive acknowledgement and a negative acknowledgement.

77. The method of claim 70, further including the step of converting the message to a form suitable to the communications channel.

78. The method of claim 70, further including the step of converting the message from character-based to sound-based for delivery to a voice message.

79. The method of claim 70, wherein the message includes a tag.

80. The method of claim 79, wherein the tag includes message delivery expiration time.

81. The system of claim 79, wherein the tag includes globally unique tracking key identifier.

82. The system of claim 79, wherein the tag includes globally unique message identifier.

83. The system of claim 79, wherein the tag includes versioning information.

84. The system of claim 79, wherein the tag includes a security checksum.

85. The method of claim 79, wherein the tag is dependent on a communication channel chosen for delivery of the message.

86. The method of claim 70, further including the step of monitoring functioning of networks, wherein communication channel selection for the delivery of the message is based on the monitoring.

87. The method of claim 70, further including the step of monitoring functioning of message servers, wherein communication channel selection for the delivery of the message is based on the monitoring.

88. The method of claim 70, wherein the delivery step monitors at least one of the following message delivery status indicators in order to select an optimal communication channel for the delivery of the message: Received for assembly, Assembled, Not Assembled, Reason Not Assembled, Sent via DA/Delivered, Sent via DA/Queued, Sent via DA/Rejected, and Sent to Assembled Message data store.

89. The method of claim 70, wherein the message is delivered based on at least one of subscriber geographical information, subscriber ZIP code, subscriber City, subscriber State, subscriber Country, and subscriber Phone number Area Code, subscriber Time zone data, and subscriber Latitude/Longitude data.

90. A system for delivery of a message to a subscriber over multiple communications channels comprising: means for accepting the message from a sender; means for adding a channel-dependent tracking ID to the message; means for determining a sequence of the communications channels for delivery of the message to the subscriber; and means for delivery of the message over at least one of the communications channels.

91. The system of claim 90, wherein the message includes at least one of an email, an Instant Message, a video, a fax, a page and a voice message.

92. The system of claim 90, wherein the communications channels are tried sequentially until delivery of the message is acknowledged.

93. The system of claim 90, wherein the message is sent out simultaneously over all communications channels designated by the subscriber in a subscriber profile.

94. The system of claim 90, wherein the communications channels include at least one of Instant Messenger, cellular telephone, telephone land line, email, fax, pager and voice message.

95. The system of claim 90, further including means for acknowledgement of message receipt by the subscriber.

96. The system of claim 90, wherein the tracking ID includes expiration time.

97. The system of claim 90, wherein the tracking ID includes globally unique tracking key identifier.

98. The system of claim 90, wherein the tracking ID includes globally unique message identifier.

99. The system of claim 90, wherein the tracking ID includes versioning information.
100. The system of claim 90, wherein the tracking ID includes a security checksum.
101. The system of claim 90, further including means for monitoring functioning of networks, wherein communication channel selection for the delivery of the message is based on the monitoring.
102. The system of claim 90, further including means for monitoring functioning of message servers, wherein communication channel selection for the delivery of the message is based on the monitoring.
103. The system of claim 90, wherein the tracking ID is encoded.
104. A method of delivering a message to a subscriber over multiple communications channels comprising the steps of: accepting the message from a sender; adding a channel-dependent tracking ID to the message; determining a sequence of the communications channels for delivery of the message to the subscriber; and delivering the message to the subscriber over at least one of the communications channels.
105. The method of claim 104, wherein the message includes at least one of an email, an Instant Message, a video, a fax, a page and a voice message.
106. The method of claim 104, wherein the delivery step tries the communications channels sequentially until delivery of the message is acknowledged.
107. The method of claim 104, wherein, in the delivery step, the message is sent out simultaneously over all communications channels designated by the subscriber in a subscriber profile.
108. The method of claim 104, wherein the communications channels include at least one of Instant Messenger, cellular telephone, telephone land line, email, fax, pager and voice message.
109. The method of claim 104, further including the step of acknowledging message receipt by the subscriber.
110. The method of claim 104, wherein the tracking ID includes expiration time.
111. The method of claim 104, further including the step monitoring functioning of networks, wherein communication channel selection in the delivery step is based on the monitoring.
112. The method of claim 104, further including the step of monitoring functioning of message servers, wherein communication channel selection in the delivery step is based on the monitoring.
113. The method of claim 104, wherein the tracking ID is encoded.
114. The system of claim 104, wherein the tracking ID includes globally unique tracking key identifier.
115. The system of claim 104, wherein the tracking ID includes globally unique message identifier.
116. The system of claim 104, wherein the tracking ID includes versioning information.
117. The system of claim 104, wherein the tracking ID includes a security checksum.
118. A system for managing message delivery over a network comprising: means for gathering notification events from remote resources using tags embedded in messages; means for correlating data about the notification events; and means for continuously sending the messages through a plurality of communication channels prioritized based on the correlating step, until acknowledgement of receipt of the messages by the subscriber.
119. A method of managing message delivery over a network comprising the steps of: gathering notification events from remote resources using tags embedded in messages; correlating data about the notification events; and continuously sending the messages through a plurality of communication channels prioritized based on the correlating step, until knowledgement of receipt of the messages by the subscriber.
120. A system for managing message delivery over a network comprising: means for determining locations of a sender and a subscriber; means for prioritizing a plurality of communication channels for optimal delivery of a message based on the locations of the sender and the subscriber; and means for delivering the messages through the plurality of communication channels, until acknowledgement of receipt of the message by the subscriber.
121. A method of managing message delivery over a network comprising the steps of: determining locations of a sender and a subscriber; prioritizing a plurality of communication channels for optimal delivery of a message based on the locations of the sender and the subscriber; and delivering the messages through the plurality of communication channels, until acknowledgement of receipt of the message by the subscriber.
122. A computer program product for managing message delivery over a network comprising: means for determining subscriber message retrieval pattern; means for delivery of a message to a subscriber on a remote resource based on the subscriber message retrieval pattern; and means for receiving acknowledgement of receipt of the message by the subscriber.
123. A method of managing message delivery over a network comprising the steps of: determining subscriber message retrieval pattern; delivering a message to a subscriber on a remote resource based on the subscriber message retrieval pattern; and receiving acknowledgement of receipt of the message by the subscriber.
124. A computer program product for delivery of a message to a subscriber over multiple communications channels comprising: a computer usable medium having computer readable program code means embodied in the computer usable medium for causing an application program to execute on a computer system, the computer readable program code means comprising: computer readable program code means for accepting the message from a sender; computer readable program code means for determining a sequence of the communications channels for delivery of the message based on a subscriber profile; and computer readable program code means for delivery of the message over at least one of the communications channels until acknowledgement of message receipt by the subscriber.
125. A computer program product for delivering an electronic message comprising: a computer usable medium having computer readable program code means embodied in the computer usable medium for causing an application program to execute on a computer system, the computer readable program code means comprising: computer readable program code means for continuously monitoring functioning of communication channels for delivering the message to a subscriber; computer readable program code means for delivering the message to the subscriber based on a subscriber profile defining priority for the communication channels; and computer readable program code means for modifying the priority for the communication channels based on information from the means for continuously monitoring.
126. A computer program product for delivery of a message to a subscriber comprising: a computer usable medium having computer readable program code means embodied in the computer usable medium for causing an application program to execute on a computer system, the computer readable program code means comprising: computer readable program code means for accepting the message from a sender; computer readable program code means for adding an expiration time to the message for delivery of the message; and computer readable program code means for delivery of the message to the subscriber prior to the expiration time; computer readable program code means for receiving acknowledgement of message receipt by the subscriber.
127. A computer program product for delivery of a message to a subscriber over multiple communications channels comprising: a computer usable medium having computer readable program code means embodied in the computer usable medium for causing an application program to execute on a computer system, the computer readable program code means comprising: computer readable program code means for accepting the message from a sender; computer readable program code means for adding a channel-dependent tracking ID to the message; computer readable program code means for determining a sequence of the communications channels for delivery of the message to the subscriber; and computer readable program code means for delivery of the message over at least one of the communications channels.
128. A computer program product for managing message delivery over a network comprising: a computer usable medium having computer readable program code means embodied in the computer usable medium for causing an application program to execute on a computer system, the computer readable program code means comprising: computer readable program code means for gathering notification events from remote resources using tags embedded in messages; computer readable program code means for correlating data about the notification events; and computer readable program code means for continuously sending the messages through a plurality of communication channels prioritized based on the correlating step, until acknowledgement of receipt of the messages by the subscriber.
129. A computer program product for managing message delivery over a network comprising: a computer usable medium having computer readable program code means embodied in the computer usable medium for causing an application program to execute on a computer system, the computer readable program code means comprising: computer readable program code means for determining locations of a sender and a subscriber; computer readable program code means for prioritizing a plurality of communication channels for optimal delivery of a message based on the locations of the sender and the subscriber; and computer readable program code means for delivering the messages through the plurality of communication channels, until acknowledgement of receipt of the message by the subscriber.
130. A computer program product for managing message delivery over a network comprising: a computer usable medium having computer readable program code means embodied in the computer usable medium for causing an application program to execute on a computer system, the computer readable program code means comprising: computer readable program code means for determining subscriber message retrieval pattern; computer readable program code means for delivery of a message to a subscriber on a remote resource based on the subscriber message retrieval pattern; and computer readable program code means for receiving acknowledgement of receipt of the message by the subscriber.
Description


[0001] This application claims priority to U.S. Provisional Application No. 60/224,507, filed on Aug. 14, 2000, and to U.S. patent application No. ______, entitled MULTI-CHANNEL MESSAGING SYSTEM AND METHOD, filed on Aug. 14, 2001, which are both incorporated by reference herein.

[0002] This application includes material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office files or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

[0003] 1. Filed of the Invention

[0004] This invention relates to delivery of electronic information to its intended recipient over a network, and more particularly, to delivery of information, such as a message, over multiple communication channels in a manner that increases the likelihood of receipt by the recipient.

[0005] 2. Discussion of the related art

[0006] Although a number of methods currently exist to deliver information, such as email, to a recipient, these methods suffer from a number of drawbacks. One of these drawbacks is a general difficulty in the sender knowing whether and when the intended recipient received the message, particularly when the information is time sensitive, and the recipient is capable of receiving the message on multiple communications channels, such as email, voice message, Instant Messenger, pager, etc.

[0007] Accordingly, there is a need for a system and method that substantially increases the likelihood of receipt of the message in the shortest possible time.

SUMMARY OF THE INVENTION

[0008] In a preferred embodiment, the invention provides a high-performance message distribution engine for delivering large volumes of customized messages via multiple delivery channels, tracking message queuing and delivery status, tracking message access by recipients, performing automatic alternate delivery of messages upon encountering errors, performing automatic alternate delivery of messages when recipient fails to read the message within a pre-configured amount of time, and providing immediate and summary reports to clients and administrators of the system.

[0009] Alternate "Delivery Agents" are provided for delivering messages to a recipient via alternate paths, such as e-mail, pager, voice, FAX, or instant message. A "Message Rollover" or "Message Roaming" function is provided for sending a message to a recipient using alternate e-mail addresses or message delivery agents if the primary delivery agent fails to deliver the message or the message is not acknowledged within a pre-determined amount of time.

[0010] The system of the invention encompasses a rules-based delivery engine, which provides for a per-recipient profile database, which allows for an automated selection of the optimal delivery channel, based on such factors as priority of message, time of day, type of information, past delivery history, type of client software used, etc . . . The system of invention includes a system architecture which is highly scalable, fault tolerant, and supports geographical diversity and a fully distributed architecture, capable of high volumes of traffic with respect to each of the above functions. The system of the invention can be used to distribute large volumes of messages, newsletters, alerts, electronic documents, and other multimedia information. Interfaces are provided for allowing third-party clients to use the system to send large volumes of messages and receive reports on the delivery status of their customizable messages. This and other auditing, tracking and reporting functionality allows the system in its preferred embodiment to be operated as a service bureau.

BRIEF DESCRIPTION OF THE ATTACHED DRAWINGS

[0011] The foregoing and other objects, features, and advantages of the invention will be apparent from the following more particular description of preferred embodiments as illustrated in the accompanying drawings, in which reference characters refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating principles of the invention.

[0012] FIG. 1 shows a diagram illustrating the message assembly and delivery processes of the invention in accordance with a preferred embodiment.

[0013] FIG. 2 shows a diagram illustrating an overview of the architecture of the system of the invention in accordance with a preferred embodiment.

[0014] FIG. 3 shows a diagram illustrating the reporting subsystem and related subsystems in accordance with a preferred embodiment of the invention.

[0015] FIG. 4 shows a diagram illustrating the reporting subsystem and its data store according to a preferred embodiment of the invention.

[0016] FIG. 5 shows a diagram illustrating the assembly engine and its related subsystems in accordance with a preferred embodiment of the invention.

[0017] FIG. 6 shows a diagram illustrating the tracking subsystem of the invention according to a preferred embodiment.

[0018] FIG. 7 shows a diagram illustrating the instant messenger subsystem of the invention according to a preferred embodiment.

[0019] FIG. 8 shows a diagram illustrating process distribution in the system of the invention according to a preferred embodiment.

[0020] FIG. 9 shows a diagram illustrating service management in the system of the invention according to a preferred embodiment.

[0021] FIG. 10 shows a diagram illustrating the database architecture of the system of the invention according to a preferred embodiment.

[0022] FIG. 11 shows a diagram illustrating the web server architecture of the system of the invention according to a preferred embodiment.

[0023] FIG. 12 shows a diagram illustrating the application server architecture of the system of the invention according to a preferred embodiment.

[0024] FIG. 13 shows a diagram illustrating the delivery agent architecture of the system of the invention according to a preferred embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] The system of the invention in its preferred embodiment provides operations which encompass a complete lifecycle of electronic communications, including `mailing` initiation, pre-processing and message assembly, scheduling, delivery, tracking and reporting. Certain broad features of the invention will be discussed firstly below.

[0026] Message Priority

[0027] The system of the invention provides for individual message priorities to be set, and for that information to be used to determine the delivery sequence of these messages. Multiple priority levels for messages may be supported in the system of the invention. These priorities may be, e.g., Bulk, Normal, Alert, Blast, and Priority -[1-5]. Higher priority messages will always take precedence over lower priority messages. The system of the invention uses the priority information of the message to determine the order in which a message should be processed relative to other jobs being performed Message Priority for delivery is discussed in detail in the E-mail Delivery Agent (EDA) Subsystem section below. The user/customer provides a priority for all messages in a submission and that priority will be assigned to each message.

[0028] Rollover or Message Roaming

[0029] The "Rollover" or "Message Roaming" feature of the invention provides the ability to send a message to a recipient using multiple alternate delivery channels or message delivery agents should the primary delivery agent fail to deliver the message or not be acknowledged within a specific time frame. Rollover will occur for a message if specified in client input for a recipient and if the message delivery fails for the primary or more preferred delivery agent. Message delivery failure may be determined, e.g., based upon feedback from remote message transfer agents (MTAs), discussed in further detail below. Multiple levels of rollover are preferably supported.

[0030] The message roaming feature of the invention provides for a much greater delivery completion success by providing the ability for multiple delivery channels to be tried, either in succession (Alert) or in parallel (Blast), until a success condition has been met. The trigger mechanism for the rollover feature to be activated include such conditions as:

[0031] Failure reported by a delivery agent (DA) when attempting to deliver a message. Failures are classified by either a hard-error (permanent) or soft-error (temporary). Different actions can be taken when encountering either hard or soft errors.

[0032] Inability of a delivery agent to contact the remote device after a pre-determined amount of time (time based rollover or TBR)

[0033] The ability to trigger an alternate delivery channel based on the user's profile and/or based on policy/rules (e.g. send information to a pager if a critical message is sent during non-business hours).

[0034] Unified Message Tracking

[0035] The system of the invention provides for the ability to gather real time statistics on the actions of delivery, reading, bouncing, forwarding, in-transit, queued, and replies. The status of each message is tracked so that clients may query for the status of messages and for summary reporting of submissions. The system should be able to trace message assembly, queuing, delivery and failures, to remote destinations, independently of the communication channel used.

[0036] The date and time the message was read should also be tracked. These data are recorded each time a message is read.

[0037] The recipient's software provides functionality for reading the message, time message was read, message size, network location, connectivity speed and any other attributes that can be gleaned about the user. Data extracted from a recipients' browser are collected by a Web Agent (WAG). The WAG sub-system is described in further detail below; WAG Subsystems requirements are set forth below and identify which information is to be tracked.

[0038] An Out of Band Subsystem receives and initiates tracking of bounced e-mail and autoreply messages.

[0039] Both Variable Envelope Return Path (VERP) and Delivery Status Notification (DSN) are preferably supported. Known ways to track messages should be supported. Their use may be configurable by a Systems Administrator where necessary. DSN "success" messages may be used but may not necessarily be "on" by default.

[0040] The use of delivery channel-specific VERPs are the preferred principle method used to track and identify errors relating to a message. All information necessary in processing and tracking requests must be made available by knowing the VERP.

[0041] Message Transfer Agents Probes/Health Probes

[0042] Independent software entities may be provided which periodically connect to, and sense the operational status of, remote message transfer agents (MTAs) throughout the top one thousand domains in use by the system. Connection times, MX server preferences, etc., can all be recorded and analyzed to provide a set of `best bet` MTA server addresses for each domain at any given time prior to the time when they are needed by the DAs. This set of MTA server addresses can be referenced instead of the more time-consuming DNS for 95+% of all outbound mail. Additional health-probes may be used to determine the operational status of other remote servers (e.g. AOL AIM servers) and used by the appropriate DA's.

[0043] Message Expiration Time

[0044] All messages within a single submission preferably have one and the same associated expiration time. The default expiration time for the system may be set at, e.g., three days from the time of scheduled delivery. Expiration date and time are specified in Universal Time Coordinated (UTC). Values for expiration time should be able to be configured at the system level, at the client level and at the submission level.

[0045] Messages that exceed the expiration time set for them are deleted from the message queue. Messages are not assembled if the anticipated assembly time exceeds the Expiration Time. Tracking information is submitted to the Delivery Scheduler for entry into the Tracking Database tables for each message deleted from the message queue or not assembled due to exceeding expiration time.

[0046] Custom Messaging

[0047] Clients/users of the system are provided with the ability to customize messages sent to their recipients on a per-user basis for content in the message by using variable substitution. Global defaults may be set for all messages in a submission. Per-recipient values will always supercede global values. Clients are able to customize message per Delivery Type on a per-user basis. There is preferably one, non-recursive level of substitution done per message. The customization data is provided in the client's submission. The following data elements may need to be accommodated in the submission:

[0048] Recipient's zip code

[0049] Recipient's city

[0050] Recipient's state

[0051] Recipient's area code

[0052] Recipient's name

[0053] Recipient's delivery time

[0054] Secure Encrypted Mail

[0055] The system of the invention includes functionality that provides for various security features to be associated with a message.

[0056] Messages sent by a user of the system may be encrypted, either by the user or by the system itself, and mechanisms for decrypting messages at the recipient end once the message is received.

[0057] Messages sent by the system may include `conditional` events that determine whether or not a message is able to be read by the recipient. The possible conditions may include, in part, such variables as:

[0058] Was the message received by a authenticated recipient, using the PKI infrastructure and digital certificates such as those commercially available by organizations like Verisign. The use of S/MIME is envisioned as the preferred mechanism for this purpose.

[0059] Is the message attempted to be read by an approved IP address?

[0060] Is the message attempted to be read within a preset time frame? Within specific time windows (e.g. business hours only)?

[0061] Is the message attempted to be read originating from a pre-approved software module (e.g. allow message to be read by a Eudora mail client but not by an AOL mail client).

[0062] Comparing the source of the mail read request to previous successful requests and deny if source if different.

[0063] Shreddable Mail

[0064] The system of the invention may include functionality which allows a sender to associate rules with a message to determine if it can be opened and read by the recipient. In this respect, the system allows the sender to determine that messages which do not meet the rules (e.g., they are not delivered or read before a certain date) are automatically deleted. Some of the rules that may be used include:

[0065] Time Lapse: message must be read within a certain time frame or it becomes unavailable (ala `shredded` metaphor)

[0066] Delete after read once (i.e. mission impossible metaphor: `this message will self destroy in 5 seconds`)

[0067] Who reads it: require that the message be read from a specific device (e.g. IP address). Password access can be enabled.

[0068] In one embodiment, messages containing only a URL are delivered to a recipient; the content is available only via click through to the Web Delivery Agents (discussed in further detail below) and may, therefore, be deleted under certain conditions or at certain times, e.g., when the message is read once or after a certain time has elapsed.

[0069] Recipient Data and Client List Management

[0070] Clients/users of the system are responsible for recipient list management and all messages submitted to recipients. The client provides subscribe/unsubscribe information in each message. That information preferably includes either a URL or an e-mail address that can be used by a recipient to subscribe/unsubscribe. A client is able to send messages to its full list of recipients, but is preferably excluded from sending messages to a subset of their recipient list. A client who wishes to send messages to subsets of their recipient list is thereby forced to separately register each submission.

[0071] Recipient data is persistent across all clients and submissions. A client may given the ability, through a directive in a submission, to request that the recipient list not be persistent. A client's recipient list data will be persistent across submissions. A client's recipient list data may point to global recipient data. There will be a "blacklist" of domains and recipients which are not to receive messages.

[0072] Message Delivery by Recipient's Geographic Location

[0073] Messages for recipients are preferably deliverable based on the client's input of geographical information included within the submission input. The Delivery Scheduler provides functionality to segregate messages based on the attributes listed below and sent to a specific Assembly Engine for assembly and delivery based on local time of the recipient.

[0074] Segregation attributes include, but are not limited to, the following:

[0075] ZIP code

[0076] City

[0077] State

[0078] Country

[0079] Phone number Area Code

[0080] Time zone data (e.g. EDT, PST)

[0081] Latitude/Longitude data

[0082] An example of this use would be a client who wants all messages delivered by 8:00 am local time for the recipient. Delivery of the messages could be split up as to deliver Easternmost time zone messages first and then follow with following time zones. Messages for other time zones might be transferred to a remote location for assembly and delivery.

[0083] Guaranteed Mail

[0084] In accordance with one feature of the invention, functionality is provided whereby operators of the system can guarantee that a message will be delivered to its recipient, except where the recipient's id no longer exists or is unreachable, etc. In this respect, the system may include functionality for embedding special data tags in electronic messages that trigger specific, detectable events to occur on the system's servers. These data triggers are used to record all activity associated with the `history` of a message, including whether or not a message has been received and acted upon by a recipient. This, combined with the Out Of Band (OOB) error handler, provides the ability to `guarantee` to a sender that a message was successfully received and read by a recipient.

[0085] Overall System Operation

[0086] FIG. 1 shows the message assembly and delivery processes of the invention in accordance with a preferred embodiment. At "Input", submission data is accepted in XML format. The XML Parser then parses the input data, stores the parsed data in the Submission Database, stores the unparsed XML input file in the Archive Database, and informs a Submission Router of the new submission. The XML Parser creates the submission ID for the new submission.

[0087] Submission Routers are provided for keeping track of which Delivery Scheduler is handling a particular submission. The Submission Router is responsible for deciding which Delivery Scheduler (discussed in detail further below) should handle a particular submission. This decision is stored in the database for future reference by other Submission Routers. The Submission Router should communicate with that Delivery Scheduler and inform it that it is responsible for that submission.

[0088] If a given Delivery Scheduler should become unavailable, the Submission Router should find another Delivery Scheduler to take over all of the submissions currently being handled by the failed Delivery Scheduler. The Submission Router should notify the new Delivery Scheduler that it is now tasked with handling the submission.

[0089] In order to meet the above obligation, it may be necessary for the Submission Routers to monitor the health of the various Delivery Schedulers. They should not only monitor whether they are up or down, but how busy they are.

[0090] If a process asks the Submission Router which Delivery Scheduler is responsible for a particular submission, the Submission Router checks it own cache to determine the correct answer. If the answer is not in the cache, the Submission Router gets the answer from the database.

[0091] The Delivery Schedulers are provided for keeping track of the status of each message for a particular submission. A Delivery Scheduler initiates assembly and delivery as needed. The Delivery Scheduler keeps track of the assembly status for each message of a particular submission that is scheduled for future delivery. The Delivery Scheduler keeps track of when submissions should run. A given submission is handled entirely by a particular Delivery Scheduler.

[0092] When the Delivery Scheduler is told that it is responsible for a submission, it spawns a new thread, retrieves all of the submission data from the database and builds it own internal data structures.

[0093] If any process in the system comes to the conclusion that a particular recipient should have their message sent via their second or third delivery option, that information is directly passed to the appropriate Delivery Scheduler. That process will ask the Submission Routers which Delivery Scheduler is handling that submission.

[0094] If any process determines that a particular recipient has received their message and no more messages should be sent, that information is directly passed to the appropriate Delivery Scheduler.

[0095] When the Delivery Scheduler talks to a particular Assembly Engine, it tells the Assembly Engine whether the data should be handed to a Delivery Agent immediately, or whether it should be stored in the Assembled Messages Data Store (for pre-assembled submissions).

[0096] The Delivery Scheduler submits a list of recipients (typically 1,000 at a time) that need to be assembled to any given Assembly Engine. The Assembly Engine then retrieves message templates, message style sheets, and all of the recipient information directly from the submission database.

[0097] Submissions that should not be delivered immediately are put into a timer queue. The messages are all assembled. The data structure holding the submission linked list is deleted. When the time comes to deliver the submission, the database is queried and the submission linked list is rebuilt. The delivery is then started.

[0098] With continuing reference to FIG. 1, an Assembly Engine takes the message template, the message style sheet and recipient information and combines them to create the message which is to be delivered. Any process that communicates with the Assembly Engine do tells the Assembly Engine to either store the assembled message in the Assembled Messages Data Store or to contact a particular type of Delivery Agent.

[0099] Any process that communicates with the Assembly Engine tells the Assembly Engine whether that particular message has been pre-assembled. If the message has been pre-assembled, the Assembly Engine merely reads the message from the Assembled Message Data Store. If the message has not been pre-assembled, then the Assembly Engine assembles the message.

[0100] Any process that communicates with the Assembly Engine tells the Assembly Engine the range of recipient IDs which are to be assembled.

[0101] An Assembled Messages Data Store is provided for storing pre-assembled messages. A hashing function should be used to determine where to store the assembled message. This should be a function of the recipient ID and the delivery option.

[0102] Delivery Agents are provided for receiving assembled message and delivery information and delivering the message. The messages are dropped into queues and delivered as soon as possible. If a delivery attempt fails fatally, that information is communicated to the appropriate Delivery Scheduler.

[0103] Web Delivery Agents are provided for delivering an assembled web message to a client. The Web Delivery Agent should directly notify the appropriate Delivery Scheduler that the recipient has asked for the web message.

[0104] A web tracking agent is provided for reporting the retrieval of tracking images embedded in messages. The Web Tracking Agent should directly notify the appropriate Delivery Scheduler that the recipient has asked for the web message.

[0105] An Out-Of-Bounds (OOB) handler is provided for handling out-of-bounds messages. When a message bounces, 3.sup.rd party ACK, ASCII email ACK, or a Delivery Status Notification (DSN) arrives, it is received by the OOB Handler. The OOB Handler notifies the Delivery Scheduler of the bounce so that the Delivery Scheduler can immediately initiate the assembly/delivery of the second or third delivery option.

[0106] Subsystems

[0107] Diagrams of the Subsystems of the invention in a preferred embodiment appear in FIGS. 2 through 7.

[0108] The system's engine in its preferred embodiment is comprised of the following subsystems:

[0109] Data Upload

[0110] Parse Validate and Load

[0111] Submission Router

[0112] Delivery Scheduler

[0113] Assembly Engine

[0114] Administrative Interface

[0115] Reporting (Internal & External)

[0116] Wag

[0117] EDA

[0118] IMDA

[0119] DAStats

[0120] MTA Probe (MTAP)

[0121] Logging

[0122] Tracking

[0123] Each of these subsystems will be described in detail further below.

[0124] Subsystem State Information

[0125] Every subsystem writes its state information to a database or to a file on an NFS-mounted file system. If the data are on an NFS, then MAILDIR format will be used. The data will be used by the Administrative Interface for displaying subsystem status. At a minimum, the following state information is required:

[0126] Subsystem name

[0127] Process ID of the parent process

[0128] State (up/down/starting/stopping)

[0129] Last update time

[0130] General metrics that will indicate load

[0131] The update interval is specified in a Configuration Database, discussed below. All state changes will require an update. The lack of any update within a period that is twice the length of the specified update interval will be interpreted as an indication that the particular subsystem is down.

[0132] All configuration information for all subsystems is preferably stored in a Configuration Database. All subsystems obtain their configuration information from this Configuration Database.

[0133] All daemons preferably follow general Unix conventions for responding to signals. These conventions include the following:

1
HUP (1): Read the configuration file and reinitialize TERM (15): Shutdown USR1 (16): Increment debug by one level USR2 (17): Halt debug STOP: Suspend CONT: Continue

[0134] All signals should be handled consistently across all subsystems. A consistent signal should be used to dump state information to a flat file.

[0135] Each subsystem writes its state information to a database or to a file on an NFS-mounted file system. If the data are on an NFS, then MAILDIR format may be used. The data is used by the Administrative Interface for displaying subsystem status. At a minimum, the following state information will be required:

[0136] Subsystem name

[0137] Process ID of the parent process

[0138] State (up/down/starting/stopping)

[0139] Last update time

[0140] General metrics that will indicate load

[0141] Uptime

[0142] The update interval is specified in the Configuration Database. All state changes generally require an update.

[0143] The system of the invention preferably includes functionality for processing and responding to automated response messages from recipients.

[0144] All blocking calls (reads/writes) should be wrapped with a SIGALARM to prevent deadlocks.

[0145] With continuing reference to FIGS. 2 through 7, each subsystem will be discussed in detail below.

[0146] Logging Subsystem

[0147] A logging subsystem is provided for logging system events and errors to log files. The logging Subsystem should rotate logs and remove old logs based on the configuration information as specified in the initialization function. Log rotation preferably occurs as part of re-initialization after the reception of a HUP signal. The logging Subsystem should be re-entrant, thread-safe and as non-blocking as possible.

[0148] If writing a log message or opening a log file fails for any system administrator recoverable problem, then block all logging calls from returning control to the application and send the error to standard error and the SNMP monitoring station with an Emergency message level.

[0149] A Logging library is preferably provided and can be linked with any application or subsystem of the system of the invention. The logging library should contain an initialization function which accepts information on the service name (what the calling service will be called in the logs) to write in the log file. The logging library contains functions to write messages to logs. Each function accepts a severity level, a debug level to determine if the log message should be written or ignored and a variable number of parameters with substitutions to define the message. The logging library preferably only logs full lines. It should be re-entrant, thread-safe and as non-blocking as possible. If writing a log message or opening a log file fails for any system administrator recoverable problem, then all logging calls are blocked from returning control to the application and the error is sent to standard error and the SNMP monitoring station with an Emergency message level.

[0150] The severity levels that the logging Subsystem should understand are the same as syslog--DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, and EMERGENCY.

[0151] The format of a log file line is preferably as follows:

[0152] YYYY/MM/DD HH:MM:SS hostname service[pid] severity: message filename:linenumber

[0153] The logging library preferably contains functions which accept a service name, message severity level, debug level, and log message. Based on the inputs, the log library will determine if the message should be written to a log file. If the message is written to a file, the library will construct the log message line and send an SNMP trap if appropriate for the message based on the severity. The log library will send messages to a message queue for being written to disk. A success or failure message will be sent to the calling application.

[0154] Logging Daemon

[0155] A Logging Daemon is provided for consolidating messages for all Ranger (eFoton) processes running on the system(s). The logging Subsystem preferably contains an initialization function which accepts information on directory in which to store logs, log filename, service name to write in the log file, retention length before removal of old log files, rotation frequency in minutes, and size at which to rotate files. Default values are: log rotation frequency are 60 minutes, size at which to rotate files is 10 MB, directory is "/var/log", filename is the same as service name. Service name is not optional.

[0156] The logging Subsystem preferably sends an SNMP trap to the monitoring station based on a configuration parameter. If not specified in the configuration database, messages of severity level "Warning" or higher will result in SNMP traps being delivered to the SNMP monitoring station. [i.e. TrapDebug=FALSE, TrapError=TRUE]. After being rotated, logs will be compressed using a compression utility.

[0157] The log daemon receives input from the configuration database and the log message queue. Optionally, the log daemon may receive messages via a TCP connection from other log daemons. The log daemon writes the log messages to the appropriate file or sends the messages to another log daemon via TCP for writing.

[0158] Tracking Subsystem

[0159] The invention includes a Tracking Subsystem for collecting and storing tracking data from the Ranger subsystems to allow tracking of messages from submission, through processing, to delivery to, and reading by, the recipient. The tracking subsystem preferably comprises the following elements:

[0160] Tracking Library

[0161] Tracking Daemon

[0162] Tracking Data Store

[0163] These elements are illustrated in FIG. 6, and are described below.

[0164] The tracking library is a library that can be linked with any application or subsystem of the invention. The tracking library is be re-entrant, thread-safe and as non-blocking as possible. If writing to the tracking data store fails for any reason, control is returned to the application, the error is recorded in the Subsystem State Table and the Logging Subsystem sends an SNMP trap at the EMERGENCY level to the Network Monitoring System.

[0165] The status of each message is tracked so that clients may query for the status of messages and for summary reporting of submissions. The system should be able to trace message assembly, queuing attempted delivery, delivery, message expiration and rollover. The date and time the message was read will be tracked if at all possible; advertisements, messages, and submission progress will also be tracked.

[0166] The recipient's software for reading the message, time message was read, message size, network location, connectivity speed and any other attributes that can be gleaned about the recipient. Data extracted from a recipients' browser should be collected by the Web Agent (WAG). The WAG sub-system is described in detail below.

[0167] The Out of Band Sub-system will update tracking of bounced messages and messages generated by auto-responders.

[0168] The following data will be stored in the tracking database. Data will be submitted to the Submission Router by the Delivery Agent.

[0169] MessageID

[0170] Success/hard failure

[0171] Reason for failure

[0172] MTA speed in bytes per second

[0173] Date & time recorded in UTC. The date should include a 4-digit year. Time will be recorded to the millisecond, and if possible, to the microsecond.

[0174] RecipientID

[0175] SubmissionID

[0176] The Tracking Subsystem updates the Message Table with the following on behalf of all DAs upon receipt of a delivery success/hard fail:

2
Status (delivered / failed / trying alternate DA) UpdateDt (record update date-timestamp DaType DA which delivered or last DA tried

[0177] The tracking library contains functions accepting tracking data to be sent to the tracking daemon. The data includes the following data elements (not inclusive) from the subsystems for storage in the tracking data store:

[0178] trackingID-tracking module generated

[0179] trackingdate

[0180] trackingTime

[0181] clientID

[0182] submissionID

[0183] messageID

[0184] recipientID

[0185] module-submission router, parse/validate, assembly, E-mailDA, IMDA, WAG, OOB

[0186] moduleStatus-status of module processing, possible valid values (not inclusive):

[0187] --MTA accepted

[0188] --MTA deferred

[0189] --MTA reject

[0190] --Ranger queued

[0191] --Deferred queue

[0192] --Roll over attempted

[0193] --IM expired

[0194] --Ad expired

[0195] --Delivery success

[0196] --Delivery failure

[0197] --Message read

[0198] --Received

[0199] --Received format check-ok

[0200] --Assembly scheduled

[0201] --Assembly started

[0202] --Assembly complete

[0203] --Delivery started

[0204] --Delivery complete

[0205] --Message delivered

[0206] --Message assembled

[0207] --Message delivery failed--retry

[0208] --Message delivery failed--rollover

[0209] --Message delivery failed--hard

[0210] --Message bounced

[0211] --Message deferred

[0212] --Message read

[0213] --Administratively deleted

[0214] --Error code

[0215] --MessageReadTime

[0216] --MessageReadDate

[0217] --MessageDeliveryCost

[0218] --DeliveryClass (E-mail, IM, Pager, WAG)

[0219] --E-mailAddress

[0220] --Domain

[0221] --Mua

[0222] --IspMTA

[0223] --Browser

[0224] --RecipientConnSpeed

[0225] --IspConnSpeed

[0226] --ImURL

[0227] --ImID

[0228] --SuccessDeliveryDate

[0229] --SuccessDeliveryTime

[0230] --Ad clicked

[0231] --moduleStatusValue

[0232] As set forth above, the tracking library contains functions that send messages to the tracking daemon. Success or failure indication is returned to the calling application. Data sent to the tracking daemon includes the Input data elements described above.

[0233] A tracking daemon is provided which accepts tracking messages from all Ranger processes running on the system(s). The Tracking Subsystem updates the Message Table with the following data on behalf of all Delivery Agents upon receipt of a delivery success/hard fail:

3
Status (delivered / failed / trying alternate DA) UpdateDt (record update date-timestamp DaType DA which delivered or last DA tried

[0234] The tracking daemon receives configuration information from the configuration database. The tracking daemon is also preferably able to receive messages from a TCP connection from remote systems of the invention. The tracking daemon further accepts data destined for the tracking data store from all subsystems.

[0235] The tracking daemon formats its received data into properly formatted SQL statements for inserting tracking data into the tracking data store. The tracking daemon queues tracking data in a tracking data cache to allow batch tracking data inserts into the tracking data store. The tracking daemon validates incoming data (range checks, format, etc.). Data checking is intended for internal error checking. Invalid data will be logged via the logging facility.

[0236] The tracking daemon reports errors via the Logging Subsystem and the SNMP monitoring station with an appropriate level message. In the case of data store failure or non-response, the tracking daemon queues tracking data in a tracking data cache, block all tracking calls from returning control to the application and send the error to standard error and the SNMP monitoring station with an Emergency message level. The tracking daemon reports erroneous data inputs via the Logging Subsystem.

[0237] The tracking daemon submits tracking data entries to the tracking data store. In the case of an error, the tracking daemon sends error messages to the Logging Subsystem and the SNMP monitoring station with an Emergency message level.

[0238] Data Upload Subsystem

[0239] A Data Upload Subsystem is provided for receiving and processing uploaded data from clients. The input process may be made available 24.times.7 and may run on more than one machine. Electronic submission may be made with HTTP/HTTPS, SMTP, or FTP, should be stored on an NFS-mounted partition and should be lock-free. MAILDIR format should be used. The submission of file decompression will create a single uncompressed file.

[0240] Upon successful reception of incoming data, a unique submission ID is assigned. Receipt of data is tracked. Each submission is preferably stored in a directory named for the client-employee who transmitted the submission. A unique filename is assigned to a new submission. The Data Upload Subsystem will obtain all required configuration information from the Configuration Database.

[0241] Data which is received by the Data Upload Subsystem includes desired delivery time for data, including time zone, the priority for the groups of e-mails (e.g., bulk, normal and expedited), the Job-ID (provided by the client) for each submission. Submissions without a unique job-id or with a duplicate job-id will be rejected, client information including a valid client authorization code and optional digital signature.

[0242] The content and formatting data in the input stream preferably consists of one of the following, in the following order of appearance:

[0243] An XML body with XSL formatting information, as in the following example:

[0244] <content>

[0245] <body>

[0246] <!--- Not used until future XSL compliant --->

[0247] <!--- release --->

[0248] </body>

[0249] </content>

[0250] An empty body with DA-specific templates containing body. There is preferably DA-specific body-format combination for every DA option specified, as in the example:

[0251] <content>

[0252] <template datype=www>

[0253] <title>Ed McMahon says<var: susbt-name=name>

[0254] is a winner</title>

[0255] </template>

[0256] <template datype=e-mail daopt=html>

[0257] <title>Ed McMahon says<var: susbt-name=name>

[0258] is a winner</title>

[0259] </template>

[0260] <template datype=pager>

[0261] <var: subst-name=name>is a winner.

[0262] </template>

[0263] <template datype=IM daopt=ICQ>

[0264] <var: subst-name=name>is a winner.

[0265] See<var: subst-name=URL>

[0266] </template>

[0267] </content>

[0268] The submission metadata preferably comprises the following information:

[0269] Expiration Date & Time

[0270] Delivery Goal Date & Time

[0271] Default Priority

[0272] Number of Recipients

[0273] Global substitution data conforms to the specification as supplied in the following example of recipient substitution data. Global variable values are used during content variable substitution in cases when recipient-specific substitution value is provided.

[0274] <dadata type=IM>

[0275] <attr name=URL val=RangerURL>

[0276] </dadata>

[0277] The recipient information preferably includes the following data elements and may contain multiple instances of the following information:

[0278] a) DA Type: Delivery Agent Type--this is preferably either e-mail, pager or Instant Message (M). The system of the invention may alternatively provide for delivery over a combination of multiple delivery paths, including but not limited to, e-mail, instant message, and web-based.

[0279] b) DA Option: The Delivery Agent Option is specific for the DA Type and may be contain the following options:

[0280] E-mail:ASCII, HTML, AOL, MIME

[0281] IM: AOL, Yahoo, ICQ, MSN

[0282] Pager, via e-mail gateway, or native SMS.

[0283] c) DA Preference: Delivery Agent Preference will be numeric representing the order to attempt delivery by that mechanism.

[0284] d) DA-Specific Address: Delivery Agent Specific Address should contain information on how to deliver the message for the DA Type specified. The information may be represented as follows and conform to a DTD representing this data specified by Ranger:

4
E-mail: RFC-822 compliant address Pager: RFC-822
compliant address or Phone Number, PIN, and Paging System Information or HTTP Postal: Postal Standard Address-Format Addresses Fax: Phone Number Voice: Phone Number

[0285] e) DA Preference: Only one DA Preference of any ranking is allowed per recipient.

[0286] f) Recipient Substitution Data: Data may be provided on a per-recipient basis for substitution into the message templates. Every substitution variable in the content must be defined by a substitution name value pair for each recipient or globally, or the recipient specific message will be rejected.

[0287] The following example illustrates the correct ordering of Recipient Information data elements.

[0288] <recipient id=xxxxxx>

[0289] <da-data>

[0290] <da rank=1>

[0291] <addr datype=e-mail daopt=html>

[0292] <address>nobody@nowhere.com

[0293] </address>

[0294] </addr>

[0295] </da>

[0296] <da rank=2>

[0297] <addr type=postal daopt=fedex-overnight>

[0298] <street1>xxxx</street1>

[0299] <street2>xxxx</street2>

[0300] <city>xxxx</city>

[0301] <state>xxxx</state>

[0302] . . . .

[0303] </addr>

[0304] </da>

[0305] <substdata>

[0306] <attr name=account val=12.34.5 />

[0307] <attr name=balance val=$1.23/>

[0308] </substdata>

[0309] </recipient>

[0310] MD5 checksums will be provided for the following sections:

[0311] Recipient

[0312] Content

[0313] Submission metadata

[0314] The Input Subsystem provides positive/negative feedback on acceptance of input.

[0315] The Data Upload Subsystem stores input data in MAILDIR format to a Network File System (NFS) for processing. The Data Upload Subsystem sends a message to the Parse, Validate & Load Subsystem that content has been received for delivery.

[0316] A Parse, Validate & Load Subsystem for taking the client input (a submission), parsing it, validating it, loading the data into a database, and notifying the Submission Router that it is ready for processing. The Parse, Validate & Load Subsystem accepts input from the Data Upload Subsystem. Data will is preferably contained in a single compressed file. The submission template table data may be stored as XML/XSL. An XSL style sheet is stored in the database as CLOBS. The data provided is preferably in one XML document. The following information should be supplied in the order delineated in the Input Requirements below for every unique submission to the Ranger system.

[0317] A client-unique, client-generated job-id and any optional attributes needed for submission data are included as metadata. Submissions without a unique job-id or with a duplicate job-id are rejected. The client information consists of a valid client authorization code and optional digital signature.

[0318] With respect to processing, the Parse, Validate & Load Subsystem is first notified by the Input Subsystem that a new submission has arrived for processing. The Parse, Validate & Load Subsystem then decompresses the received submission data file. The Parse, Validate & Load Subsystem then assigns a client-unique Submission ID to each validated submission. The Parse, Validate & Load Subsystem then opens the submission file and performs the following actions:

[0319] Read client id

[0320] Validate client id against the client tables

[0321] Validate that the submission was located in the proper directory for the submitter.

[0322] Validate that the job-id is unique.

[0323] Perform additional idempotency checks

[0324] Verify the component checksums are correct

[0325] Ensure that the XML submission components are well-formed and valid according to the DTD

[0326] Validation checks on recipient address fields for all delivery types. Rejected fields will be recorded in a failure table and processing will continue.

[0327] Failure of any of the above actions will result in the following:

[0328] Halt of processing

[0329] Logging of error(s)

[0330] Notification e-mail to the client of the problems with the submission

[0331] The customer's e-mail address is checked to ensure rfc822-compliant e-mail addresses.

[0332] The Parse, Validate & Load component updates submission database status column to reflect current status (valid & ready for load/rejected corrupt/rejected mal-formed, etc). In the case of successful validation, the client will be notified with the following information:

[0333] "Your submission has been received"

[0334] Message size

[0335] Customer ID

[0336] Job-ID (To be provided by the client)

[0337] Submission-ID

[0338] Checksum status

[0339] Accept/reject/statistical status

[0340] Scheduled assembly time

[0341] In the case of a failed validation the client is notified with the following information:

[0342] "Your submission has been received"

[0343] Message size

[0344] Customer #

[0345] Job-ID

[0346] Submission-ID

[0347] Checksum status

[0348] Accept/reject/statistical status

[0349] Error(s) found

[0350] The Parse, Validate & Load Subsystem inserts parsed submission data into the Submission Database, and then notifies the Submission Router of submission ready to be processed and scheduled for delivery. The Parse, Validate & Load Subsystem also stores the unparsed XML file in an Archive Database along with ClientID and SubmissionID data.

[0351] Submission Router

[0352] A Submission Router subsystem is preferably provided and is responsible for deciding which Delivery Scheduler will schedule processing for a particular submission. This decision is stored in a cache for future reference and in the submission database for future reference by other Submission Routers. The Submission Router communicates with the selected Delivery Scheduler and informs that Delivery Scheduler of it's responsibility for that submission. The Submission Router monitors the status (up, down and how busy) of the Delivery Scheduler to which it has assigned submissions. If a given Delivery Scheduler should become unavailable or otherwise fail, the Submission Router assigns another Delivery Scheduler to take over the process scheduling of the submission assigned to the failed Delivery Scheduler. Also in this case, the Submission Router will update it's cache and the submission database with the new Delivery Scheduler assignment information.

[0353] The Submission Router responds to requests from subsystems for information on which Delivery Scheduler has been assigned which submission. The Submission Router first checks it's own cache for the needed information. If the requested information is not found, the Submission Router queries the submission database for the needed information.

[0354] The Submission Router handles submitted data from the Out of Band subsystem relating incoming data to the appropriate submission and client information submitting this information to the tracking daemon for storage in the tracking database.

[0355] The Submission Router accepts data from a recipient's message handlers and/or domains indicating whether a message has been successfully received.

[0356] With respect to inputs, the Submission Router accepts submission-ready-for-processing information from the Parse and Validate Subsystem. The Submission Router accepts message status data and forward it to the Tracking Subsystem for all Delivery Agents. The Submission Router accepts status information from the Delivery Scheduler to which it has assigned submissions. The Submission Router accepts requests for status information from the Administrative Subsystem. The Submission Router accepts requests for Delivery Scheduler information from all Subsystems. The Submission Router accepts requested data from the Submission Database.

[0357] The Submission Router processes incoming data from the Out of Band and Web Tracking Agents subsystems. Received data is related to the appropriate message, submission and client and submitted to the Delivery Scheduler, which submits the data to the Tracking Subsystem for storage. The Submission Router requests, accepts, and processes data from the submission database as needed.

[0358] All code in the Submission Router preferably makes use of two Global Variables:

[0359] GlobalDebugLevel: This is used to determine the debug level at which the system is currently running. It enables libraries to use the same debug level without providing additional function calls.

[0360] GlobalShutdown: This is used by all threads to determine if it is shutdown time. This facilitates processing, since there is no good signaling mechanism between threads.

[0361] The Submission Router sends submission information to a selected Delivery Scheduler. The Submission Router also sends requests for data to the submission database.

[0362] The Submission Router accepts a failure message for each instance in a submission where a message cannot be delivered to the intended recipient, a/k/a, a "bounced" message. Sources for the failure message may be any of the Delivery Agent Subsystems or the Out of Band (OOB) Subsystem

[0363] The failure message for each bounced message may include the following elements:

5
a) DATESTAMP-UTC date & time in UTC format b) RecipientAddress address of intended recipient (address of failed delivery), could be e-mail, IM, pager, fax, etc. c) BounceError error condition causing bounce d) Action action taken in response to bounce, if any e) Reason why the action was taken ExtraComments Delivery Agent h) MessageID Ranger-assigned message ID i) SubmissionID Ranger-assigned submission ID j) RecipientID Ranger-assigned recipient ID k) SubsystemID identifier of subsystem originating entry (EDA, IMDA, OOB, etc.)

[0364] An example of such a failure message is the following:

[0365] 571 nosuchuser@nosuchdomain.com we do not relay

[0366] The Submission Router will provide requested status information to the Admin Subsystem.

[0367] Based on return information from a recipient's message server and/or domain, the Submission Router will inform the Delivery Scheduler of the success or failure of its delivery attempts.

[0368] Tracking data is sent to the Tracking Subsystem via the Delivery Scheduler.

[0369] Delivery Scheduler

[0370] Delivery Schedulers are provided for processing submissions received from a Submission Router. The Delivery Scheduler initiates assembly and delivery as required. The Delivery Scheduler keeps track of the assembly status for each message of a particular submission that is scheduled for future delivery. The Delivery Scheduler preferably processes submissions immediately upon receipt from a submission router. The Delivery Scheduler handles an assigned submission in its entirety.

[0371] When the Delivery Scheduler is notified by a submission router that it is responsible for a submission, it will spawn a new thread, retrieve the necessary submission data from the submission database, build it's own internal data structures and initiate communication with an Assembly Engine. The Delivery Scheduler will be notified by the Submission Router when a recipient has received their message and no more attempts at delivery should be made. The Delivery Scheduler is also notified by the Submission Router when delivery of a message to a recipient has failed. The Delivery Scheduler will then attempt delivery via another delivery method if one is available.

[0372] The Delivery Scheduler is able to retrieve desired alternative delivery means for the recipient. That is, the Delivery Scheduler retrieves the next Delivery Agent type from the list of prioritized, alternate addresses/delivery methods specified in the submitted data for this recipient.

[0373] The Delivery Scheduler maintains message status in a database. In this respect, should the Delivery Scheduler fail, another Delivery Scheduler process can pick up processing from where the original Delivery Scheduler stopped.

[0374] The Delivery Scheduler monitors the DA Stats cache to keep track of domains that are not currently accepting messages and not attempt assembly/delivery of messages for those domains.

[0375] When the Delivery Scheduler communicates with an Assembly Engine it will tell the Assembly Engine whether the assembled message is to be passed to a DA for delivery immediately or be stored in the Assembled Messages data-store for pre-assembled message delivery at a later time.

[0376] The Delivery Scheduler will track a submission in its database whether or not a message has been pre-assembled for future delivery.

[0377] The Delivery Scheduler submits a list (size is configurable) of recipients (i.e. 1000) for which messages will need to be assembled to a given Assembly Engine. Each such assembled list is designated as a chunk.

[0378] The Delivery Scheduler places submissions not scheduled for immediate delivery into a special timer queue. The messages in the submission are scheduled and pre-assembled. The data structure holding the submission linked list will then be deleted. When the time comes to deliver, the submission the database will be queried and the submission linked list will be rebuilt. The actual delivery of the messages will then be initiated.

[0379] The Delivery Scheduler may be provided with functionality to divide a submission chunk into geographic chunks based on best delivery location (remote sites running the system of the invention). This division may be based upon, e.g.:

[0380] Recipient's zip code

[0381] Recipient's city

[0382] Recipient's state

[0383] Recipient's area code

[0384] The Delivery Scheduler is the intermediary between other subsystems and the Tracking Subsystem. That is, other subsystems communicate with the Tracking Subsystem through the Delivery Scheduler.

[0385] The Delivery Scheduler will accept submission information from a Submission Router. Information received will include:

[0386] SubmissionID

[0387] Whether the submission will be scheduled for immediate delivery or for pre-assembly for later processing

[0388] The Delivery Scheduler also accepts message update information from a Submission Router. Information received may include:

[0389] Notification of message received by the recipient

[0390] Notification of failed message delivery to the recipient

[0391] As part of its configuration information, the Delivery Scheduler accepts the following data from the submission database:

[0392] host

[0393] ports

[0394] number of threads

[0395] chunk size

[0396] message cache flush timing

[0397] The Delivery Scheduler must accept a message from the Assembly Engine, which notifies the assembly scheduler that some messages were not assembled for a given batch. The communication is preferably synchronous, and does not return until the Assembly Engine has handled all the submitted messages and has returned a status (success/failure/queued).

[0398] The Delivery Scheduler also accepts input from the DA Stats Cache, and accepts data from Web Tracking Agents.

[0399] The Delivery Scheduler sets up and stores the status of each message in a submission. The data should be cached and periodically (timing will be configurable) dumped to a database.

[0400] Upon receipt of a submission to process, the Delivery Scheduler will spawn a new thread, retrieve all submission information from the submission database and build it's own internal data structures.

[0401] When the Delivery Scheduler receives notification from the Submission Router that a message has been received, the Delivery Scheduler updates its records and database entries accordingly.

[0402] When the Deliver Scheduler receives notification from the Submission Router that a message delivery attempt has failed the Delivery Scheduler will collect the information necessary to attempt delivery via another delivery method. This relates to the "Rollover" feature, discussed in further detail elsewhere herein.

[0403] The Delivery Scheduler maintains message status in a database allowing another Delivery Scheduler to pick up processing where the original Delivery Scheduler left off should it fail.

[0404] The Delivery Scheduler monitors the DA Stats cache to keep track of domains that are not currently accepting messages.

[0405] The Delivery Scheduler tracks whether or not a message has been pre-assembled for future delivery. This information is stored in a database for possible processing by another Delivery Scheduler.

[0406] The Delivery Scheduler places submissions not scheduled for immediate delivery into a special timer queue for future processing. Messages scheduled for future processing will be assigned to an assembly engine for pre-assembly.

[0407] The Delivery Scheduler responds (ACK/NAK) to Submission Router inputs.

[0408] The Delivery Scheduler requests submission data (based on received submissionID) from the Submission Database.

[0409] The Delivery Scheduler sends messages to a selected Assembly Engine for assembly. The information preferably includes:

[0410] A flag to tell the assembly engine whether or not to immediately attempt message delivery or to store the assemble message in the Assembled Message data store for future delivery.

[0411] A list of recipients and message information for those recipients for messages to be assembled. The size of the list will be configurable.

[0412] Data elements to be included in this information are:

[0413] SubmissionID

[0414] RecipientIDs

[0415] Delivery Methods

[0416] Delivery schedule (Immediate or Delayed to specified time)

[0417] Assembly Engine Subsystem

[0418] An Assembly Engine is provided for assembling messages as assigned by a Delivery Scheduler for either immediate delivery or for assembly for future delivery. The Assembly Engine uses a message template, message style sheet, and recipient information to assemble a customized message specifically for the assigned recipient.

[0419] The Delivery Scheduler detailing assignments to an Assembly Engine tells the Assembly Engine to either build the messages for immediate delivery or to store in the Assembled Message data store. If the messages are to be built for immediate delivery the assigning Delivery Scheduler will tell the Assembly Engine which DA to pass the assembled messages to.

[0420] The Delivery Scheduler detailing assignments to an Assembly Engine will tell the Assembly Engine if the messages assigned for processing have been pre-assembled. If the message has been pre-assembled the Assembly Engine will read the message from the Assembled Message data store. The Delivery Scheduler detailing assignments to an Assembly Engine will pass a list of messages for assembly. The Assembly Engine will retrieve the messages template, message style sheet and recipient information from the Submission Database.

[0421] The Assembly Engine is limited to variable substitution, not content creation from distinct categories. There is no limit on the number of substituted variables, or the size of the substituted variables. Variables may not be recursively substituted.

[0422] The Assembly Engine creates messages formatted for each recipient based on their DA preferences.

[0423] Should a decision be made by the Delivery Scheduler to rollover delivery to another delivery method for a particular message, the Assembly Engine will rebuild the message as appropriate for the new delivery method based on recipient preferences.

[0424] Rollover is the process in which a message is regenerated and scheduled for delivery utilizing an alternate DA, if one exists, when delivery utilizing a more-preferred DA has not succeeded. Reasons for unsuccessful delivery include:

[0425] Failure to deliver the message using the preferred DA

[0426] Expiration arrived on preferred DA

[0427] The DAs which are used for transmitting messages to a particular recipient can be analyzed on a recipient basis to determine which are statistically most successful. Once this is determined for a recipient, it future delivery agent choices can be influenced based on past performance.

[0428] The Assembly Engine may support the following delivery formats:

[0429] E-mail/ASCII

[0430] E-Mail/MIME alternate (text/plain; text/html)

[0431] E-mail/HTML

[0432] E-mail/AOL

[0433] E-mail/Pager (Pager/RFC822)

[0434] IM/AOL (TOC protocol)

[0435] IM/ICQ

[0436] IM/Yahoo

[0437] IM/MSN

[0438] The Assembly Engine is preferably configured not to delay submissions due to any behavior on the part of other submissions (e.g. very long assembly time, down domains, etc.).

[0439] The number of concurrent Assembly Engines is only limited by resource availability. When a resource limit has been reached, no more Assembly Engines will be started, and an SNMP trap will be generated.

[0440] The Assembly Engine merges the components of a message from global and recipient submission data into a message prepared and formatted for delivery using XSL. The assembly engine is preferably able to generate the multi-part mime and base-64 encoding of messages.

[0441] The Assembly Engine preferably delivers assembled messages to the DA via QMQP+ based on message priority if the message should be immediately delivered. If the primary DA host is unavailable or the message should be held for later delivery, then the message will be stored in the Assembled Message data store. If the message is not assembled due to it's domain mail server(s) being down the Assembly Engine will so notify the Delivery Scheduler.

[0442] After successful assembly, the status field for the message in the Submission Database is updated to "Assembled" in the message table of the database.

[0443] The Assembly Engine reports all message tracking information to the Delivery Scheduler. Tracking status will include, but not be limited to, the following categories:

[0444] Received for assembly

[0445] Assembled

[0446] Not Assembled

[0447] Reason Not Assembled

[0448] Sent via DA/Delivered

[0449] Sent via DA/Queued

[0450] Sent via DA/Rejected

[0451] Sent to Assembled Message data store

[0452] Messages assembled by the Assembly Engine contain subscribe/unsubscribe information provided by each Ranger client. This information may be used in a normal variable substitution. Subscribe/unsubscribe information should be present in every message delivered by the system of the invention.

[0453] The Assembly Engine is preferably able to convert XML to HTML, ASCII, AOL, or any other supported format as needed.

[0454] The Assembly Engine receives the following input from a Delivery Scheduler:

[0455] MessageID

[0456] SubmissionID

[0457] RecipientIDs

[0458] Delivery_Type Immediate/Pre-Assemble--Tells the Assembly Engine whether or not the messages assigned are to be passed immediately to a DA for delivery or to the Assembled Message data store.

[0459] PreAssembled True/False--Tells the Assembly Engine whether or not the messages assigned have already been assembled

[0460] The Assembly Engine receives pre-assembled messages from the Assembled Message data store; receives input from the Domain Stats Cache; and receives message assembly data from the Submission Database. The Assembly Engine also requests and receives blacklisted addresses from the Blacklist. The Assembly Engine will refrain from building messages for recipients whose addresses and/or domains appear in the Blacklist.

[0461] The Assembly Engine assembles customized messages using a message template, message style sheet and recipient information.

[0462] The Assembly Engine will include Time Zone Lookup functionality such that it can determine a recipient's Time Zone from standard US Postal Service Zip Code data.

[0463] The Assembly Engine sends assembled messages to the assigned (by the Delivery Scheduler) Delivery Agent for messages delivery. The Assembly Engine should supply the VERP and Expiration Date to the Delivery Agent.

[0464] The Assembly Engine further sends assembled messages to the Assembled Message data store as directed by the assigning Delivery Scheduler.

[0465] The Assembly Engine requests message assembly data from the Submission Database based on information received from the assigning Delivery Scheduler. Those data include, but are not limited to, the following:

[0466] Content

[0467] DA

[0468] Specific XSL Formatting Information

[0469] Global substitution data

[0470] Recipient preferences

[0471] Recipient substitution data

[0472] The Assembly Engine output to the Delivery Scheduler includes location or time zone information to enable the Delivery Scheduler to calculate the appropriate delivery time for a given recipient.

[0473] The Assembly Engine outputs to the Tracking Subsystem a list of blacklisted recipients for whom messages were not built.

[0474] Delivery Agent Subsystems

[0475] E-Mail Delivery Agent Subsystem

[0476] A collection of E-Mail Delivery Agent Substems (EDAs) are provided for delivering large volumes of e-mail messages (e.g., in excess of million e-mail messages) per hour. With an estimated size of 15
KB/message, the system requires approximately 42 Mbps outbound bandwidth.

[0477] The EDA will attempt immediate delivery and queue the message for further attempts if immediate delivery is not possible but no hard failure is encountered.

[0478] An EDA preferably comprises the following elements:

[0479] Mail Transport Agent

[0480] Local mail queue

[0481] Mechanism to access remote domain mailers' readiness status

[0482] Mechanism to update the tracking database via the Submission Router

[0483] The EDAs should be able to accommodate messages of varying priorities. This can be done on a per-EDA submission, or could be done by having the Delivery Scheduler/Assembly Engine send messages to machines, which are specific to various queue priorities.

[0484] EDAs receive messages via network connections from the Assembly Engine for immediate delivery, as well as for delivery of pre-assembled messages; the goal is to reduce disk transfer to speed delivery where possible. This may be done via QMQP+.

[0485] Each physical EDA machine will have one or more EDA processes with multiple delivery threads; the number of processes and threads is determined empirically to find the fastest combination; each process must listen on a unique socket number for incoming connections.

[0486] Each machine running an EDA process preferably has the Domain stats cache available in memory. Each EDA process will in turn have many EDA delivery threads, which will access that information from memory. This requires that each EDA machine have a separate thread running to fetch stats cache data from the database and load the memory resource; this process will use a "double buffering" approach to store data into a write-only portion while EDA processes access the read-only portion; a mutex is used to indicate which portion is readable and which is write-able.

[0487] Each EDA gets content information in its final format in order to reduce processing requirements on the EDA; this includes message headers (including VERP and Expiration), message body, variables substituted, and formatted as ASCII, HTML, or multi-part MIME as appropriate to the recipient's profile.

[0488] The DA uses Variable Envelope Return Paths (VERPs) to set a message-unique and recipient-unique envelope "From" field; this will be used by "OOB Handlers" to determine the actual recipient if mail bounces back from remote site. It will also be used by Web Agents for tracking.

[0489] For each hard-rejected message, the EDA will send a delivery failure message to the Submission Router and/or the Assembly Engine, so that it can direct the appropriate Delivery Scheduler to identify an alternative delivery means for the recipient, if an alternative delivery means has been specified in the submission.

[0490] An EDA receives messages from an assembly engine via QMQP+ protocol. Messages are preferably transmitted to EDAs via a Load Balancer to ensure the receiving EDA can accept the transmission. Once a message is received from an Assembly Engine its life should be tracked.

[0491] Each EDA will get the address in its normal "user@dom.ain" format. The EDA will attempt to resolve this domain to an available IP address by calling the Domain stats. If the domain is not in the DNS cache, the EDA will have to attempt domain name resolution to the best Mx or A record itself.

[0492] EDAs receive intelligence about the availability and speed of remote domain mail transport agents from the Domain Stats cache.

[0493] The EDA will attempt immediate delivery unless the "Domain Stats" entry for the target has marked it "Down" or "Administratively Down." The EDA will first attempt immediate delivery before committing to disk, to improve performance. It should not acknowledge the QMQP+ submission until it has completed one of the following operations:

[0494] A) Successfully delivered the message and updated tracking information through the Delivery Scheduler or the Submission Router

[0495] B) Updated tracking information through the Delivery Scheduler or the Submission Router after the receipt of a hard failure (Permanent rejection by a remote MTA)

[0496] C) Committed a message to SAN disk queue and updated tracking information after the receipt of a soft failure (Transient deferral)

[0497] Mail which cannot be delivered immediately, ("Domain Stats" has marked the target "Down/AdmDown") will be queued for later delivery attempts by the EDA.

[0498] The EDA uses "Domain Stats" information to decide whether to send mail immediately or queue, and how long it should wait for remote connection and greeting, number of simultaneous queues allowed, etc.

[0499] The EDA will delete a message from it's queue when the message's expiration time passes. Expiration date/time will be indicated by a message "X-" header set by the Assembly Engine. It will also send tracking data to the Submission Router.

[0500] The EDA preferably never generates a bounce message, which might slow down other subsystems. The EDA tracks the message, but the message content of the failed deliveries should not be included.

[0501] The EDA will time the delivery and calculate the speed of connection to the remote MTA (bytes/seconds); this should be added to the tracking database for the domain.

[0502] If an EDA cannot make a connection to a target, the EDA will attempt to re-deliver the message, based on Qmail's existing exponential backoff algorithm.

[0503] The E-mail Delivery Agent updates tracking information by responding to the Assembly Engine or by sending asynchronous updates to the Submission Router.

[0504] Tracking updates are preferably as specific as possible, so as to guide subsequent attempts; these are based on SMTP reply codes in RFC-821; status values include Success, or Soft/Hard errors. Soft/Hard status will be based on the SMTP reply code, either 4yz for Transient errors (Soft) or 5yz for Permanent errors (Hard). Example database table MessageStatusKey status symbols include: EDA_250_Success, EDA_421_ServiceNotAvailable, EDA_Hard_450_MailboxUnavailable, EDA_Hard_550_MailboxUnavailable, EDA_Hard_553_MailboxNameNotAllowed. An EDASoftUnknownReason and an EDAHardUnknownReason may be needed as new ways for mail to fail are discovered.

[0505] 421 <domain>Service not available, closing transmission channel

[0506] 450 Requested mail action not taken: mailbox unavailable [e.g. mailbox busy]

[0507] 451 Requested action aborted; local error in processing

[0508] 452 Requested action not taken; insufficient system storage

[0509] 455 temporarily unable to accommodate one or more parameters [RFC-1869]

[0510] 500 Syntax error, command unrecognized

[0511] 501 Syntax error in parameters or arguments

[0512] 502 Command not implemented

[0513] 503 Bad sequence of commands

[0514] 504 Command parameter not implemented

[0515] 550 Requested action not taken: mailbox unavailable

[0516] 551 User not local; please try <forward-path>

[0517] 552 Requested mail action aborted; exceeded storage allocation

[0518] 553 Requested action not taken: mailbox name not allowed [including no-relaying]

[0519] 554 Transaction failed

[0520] 555 does not recognize or cannot implement one or more of the parameters [RFC-1869]

[0521] The EDA may need to interpret SMTP transient (4xx) errors as hard failures if the transient error would significantly slow delivery.

[0522] The EDA tracks SMTP 5xx errors to capture their numeric code and server-specific text string.

[0523] The EDA will enable an Administrator of the system of the invention to start, pause, or stop a message queue at any time.

[0524] The EDA stores the mail queue on SAN disk so the queue may be made available to other EDAs in the event of EDA failure.

[0525] The EDA updates the tracking database via the Assembly Engine or the Delivery Scheduler with success, failure or attempted delivery information, the identity of the machine that took the action, speed of the connection, and timestamp.

[0526] The EDA preferably includes functionality to deliver messages to remote MTAs.

[0527] The EDA sends requests for domain information to the Domain Stats cache/database.

[0528] The EDA will generate a failure message for each instance in a submission where a message cannot be delivered to the intended recipient, a/k/a, a "rejected" message. The EDA will pass the VERP back to the Assembly Engine or to the Submission Router.

[0529] Instant Messenger Delivery Subsystem

[0530] An Instant Messenger (IM) delivery subsystem is provided for delivering IM messages to recipients via AOL's Instant Messenger Service. The messages should be delivered quickly, and the IM delivery subsystem should allow for an early decision as to whether or not to roll delivery of the message over to another delivery method.

[0531] AOL Instant Messenger (AIM) and ICQ may both be supported. AIM uses the OSCAR protocol. ICQ uses the ICQ protocol.

[0532] FIG. 7 shows the modules that comprise the IM Subsystem.

[0533] IM Delivery Agents

[0534] IM Delivery Agents are provided for contacting IM servers/recipients and delivering IM messages. For each undelivered message, the IMDA will send a delivery failure message to the Delivery Scheduler, so that the Delivery Scheduler may identify an alternative delivery means for the recipient, if an alternative delivery means has been specified in the submission. The IMDAs will support 5 thousand messages per hour, collectively.

[0535] The IMDA accepts input from an assembly engine. The IMDA then sends the message to the recipient via an IM server. Input elements may include any or all of the following:

[0536] VERP--message ID

[0537] ImID--Screenname of the recipient

[0538] ImMessage--URL/text

[0539] TTL--time to live for the message

[0540] CRC--circular redundancy check for the message

[0541] ImType

[0542] ClientID

[0543] SubmissionID

[0544] RecipientID

[0545] The IMDA will accept IM server login account information from the IM server login pool database based on InUse status (multiple logins from a single account are not allowed so if the InUse status is "TRUE" the next login account for that ImType will be needed).

[0546] Login--login id for imType

[0547] Password--password for login

[0548] InUse--yes/no

[0549] The IMDA accepts module status requests and start/stop requests from the Admin module.

[0550] The IMDA accepts input from the IM Stats database. The Delivery Scheduler periodically requests IM server(s) status and associated connectivity speed to aid in determining what IM messages can/cannot be delivered (allows for early rollover decision) and what server to use.

[0551] When delivering messages to an IM server, an IMDA will request login information based on ImType from the IM Server Login Pool database and login into the assigned IM server in preparation for delivering IM messages. If the InUse status is "IN USE" the IMDA will request another login for ImType.

[0552] The IMDA reports module status when requested. Status information includes, e.g., the following data:

[0553] Up/down

[0554] Messages scheduled

[0555] Threads running

[0556] Servers connected to

[0557] An IMDA reports to a IM Server Login Pool Database when use of account information is complete.

[0558] The IMDA reports delivery-to-server success/failure to the Submission Router or the Assembly Engine.

[0559] The IMDA updates InUse based on input from an IM delivery agent when the delivery agent is finished using the account.

[0560] The IMDA requests IM server(s) status and connectivity speeds for ImType from the IM Stats data store.

[0561] If a message's time to live has expired, it will not attempt delivery of the message and will report the message as not delivered due to delivery time expiration.

[0562] The IMDA reports module status when requested, including:

[0563] Up/down

[0564] Messages scheduled

[0565] If a message is undeliverable, the IMDA reports delivery failure to the Submission Router.

[0566] The IMDA sends login and password information to an IM server.

[0567] The IMDA will send message(s) to recipient. Such messages include, e.g., the following data:

[0568] ImID

[0569] ImMessage

[0570] The IMDA sends message tracking data to the Submission Router or the Assembly Engine. Such data includes, e.g.:

[0571] VERP

[0572] IMID

[0573] IM type

[0574] Date-time-group if available

[0575] Speed of user's connectivity

[0576] TTL

[0577] URL/message

[0578] Delivered/not delivered

[0579] Delivery class

[0580] The IMDA sends account-no-longer-needed status to the IM Server Login Pool database; sends module status to Admin Subsystem; updates the IM Server Login Pool database when IM login account information is released; sends "In Use" data to the IM Server Login Pool database; and sends ACK/NAK or data to Admin Subsystem in response to requests as appropriate.

[0581] The IMDA generates a failure message for each instance in a submission where a message cannot be delivered to the intended recipient, a/k/a, a "rejected" message. This can be done using the same synchronous mechanism used by the Electronic Mail delivery Agent (EDA).

[0582] The failu