Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
STORING DISPOSITION NOTIFICATIONS IN A MESSAGE STORE
Document Type and Number:
WIPO Patent Application WO/2016/185252
Kind Code:
A1
Abstract:
Storing an IMDN message in a CMS that comprises a non-volatile file system and a cache may include identifying a difference between an IMDN message and a base record, the base record being stored in the cache of the CMS. Storing the IMDN message may further include storing a variance record in the cache of the CMS, the variance record comprising the difference between the IMDN message and the base record, and a reference to the base record. Storing the IMDN message may include discarding the IMDN message, and in response to receiving a request for the IMDN message, reconstructing the IMDN message from the base and variance records stored in the cache without reading from the non-volatile file system. Responding to the request for the IMDN message may include responding with the reconstructed IMDN message.

Inventors:
KELL DAVE (CA)
CARSLAKE DICKON (CA)
TSUI KWAN-KI (CA)
Application Number:
PCT/IB2015/053719
Publication Date:
November 24, 2016
Filing Date:
May 20, 2015
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
ERICSSON TELEFON AB L M (PUBL) (SE)
International Classes:
G06F3/06; G06F12/08; H04L12/58
Domestic Patent References:
WO2012109145A22012-08-16
Other References:
JON BUTLER ET AL: "A Proposal for Shared Dictionary Compression over HTTP", 8 September 2008 (2008-09-08), pages 1 - 18, XP055026339, Retrieved from the Internet [retrieved on 20120507]
None
Attorney, Agent or Firm:
DUFORT, Julie (Patent Department8400 Decarie Boulevar, Town Mount Royal Quebec H4P 2N2, CA)
Download PDF:
Claims:
CLAIMS

What is claimed is:

1. A method for storing an Instant Message Disposition Notification, IMDN, message in a Common Message Store, CMS, that comprises a non-volatile file system and a cache, the method comprising:

identifying a difference between an IMDN message and a base record, the base record being stored in the cache of the CMS;

storing a variance record in the cache of the CMS, the variance record comprising: the difference between the IMDN message and the base record;

a reference to the base record;

discarding the IMDN message;

in response to receiving a request for the IMDN message:

reconstructing the IMDN message from the base and variance records stored in the cache of the CMS without reading from the non-volatile file system of the CMS;

responding to the request for the IMDN message with the reconstructed IMDN message.

2. The method of claim 1 , wherein the base record is a preconfigured incomplete IMDN message.

3. The method of claim 1 , further comprising receiving the IMDN message subsequent to: receiving a previous IMDN message;

storing the base record in the cache of the CMS, the base record comprising the

previous IMDN message.

4. The method of claim 1 , further comprising storing the base and variance records in an Internet Message Access Protocol (IMAP) message store within the cache of the CMS.

5. The method of claim 1 , further comprising loading the base record into the cache of the CMS from the non-volatile file system of the CMS prior to identifying the difference between the IMDN message and the base record.

6. The method of claim 1 :

wherein the IMDN message comprises an IMDN header and an IMDN payload;

further comprising compressing the IMDN header and the IMDN payload of the IMDN message using different respective compression schemes to generate the variance record. 7. The method of claim 6:

wherein the base record comprises a cached payload;

wherein using different respective compression schemes to generate the variance

record comprises applying a delta compression scheme to the IMDN payload based on the cached payload.

8. The method of claim 6:

wherein the base record comprises a cached header that comprises at least one name- value pair;

wherein the IMDN header comprises at least one name-value pair;

wherein using different respective compression schemes to generate the variance

record comprises applying a first compression scheme to the IMDN header, the first compression scheme comprising:

deleting each name-value pair from the IMDN header that is also found in the cached header;

for each name-value pair of the cached header for which there is not a name- value pair in the IMDN header having the same name, inserting the name-value pair of the cached header into the IMDN header with an empty value field.

9. The method of claim 8, wherein the first compression scheme further comprises applying dictionary compression to the IMDN header subsequent to the deleting and inserting of name- value pairs.

10. The method of claim 1 , wherein storing the variance record in the cache of the CMS is in response to determining that a size of the variance record is smaller than a threshold.

11. The method of claim 1 , further comprising:

receiving the IMDN message before receiving a subsequent IMDN message;

generating a compressed copy of the subsequent IMDN message;

selectively storing the subsequent IMDN message based on a size of the compressed copy relative to a threshold, the selectively storing comprising: in response to the size of the compressed copy being smaller than the

threshold, storing the compressed copy in the cache of the CMS; in response to the size of the compressed copy being bigger than the

threshold, storing the subsequent IMDN message in the non-volatile file system of the CMS without storing the subsequent IMDN message in the cache.

12. The method of claim 1 , further comprising:

receiving the IMDN message subsequent to receiving a previous IMDN message

relating to a disposition of a non-IMDN message stored in the CMS;

storing the base record in the cache of the CMS, wherein the base record comprises the previous IMDN message;

retaining the base record in the cache after the non-IMDN message is deleted from the CMS.

13. The method of claim 1 ,

wherein the request for the IMDN message comprises a particular IMAP Unique

Identifier (UID) that corresponds to the variance record in the cache of the CMS;

wherein the reconstructing comprises:

retrieving the variance record from the cache of the CMS using the particular IMAP UID;

retrieving the base record from the cache of the CMS using the reference comprised in the variance record.

14. The method of claim 1 , further comprising writing the base record and the variance record stored in the cache of the CMS to the non-volatile file system of the CMS.

15. The method of claim 1 , further comprising selecting the base record from a plurality of potential base records stored in the cache of the CMS.

16. The method of claim 1 :

wherein the base and variance record each comprise a header that comprises at least one name-value pair;

wherein reconstructing the IMDN message from the base and variance records

comprises including, in the reconstructed IMDN message:

each name-value pair in the header of the base record having a name not found in the header of the variance record;

each name-value pair in the header of the variance record having a name not found in the header of the base record;

each name-value pair in the header of the variance record having a non-empty value and a name found in the header of the base record; wherein each name-value pair in the header of the base record having a name found in the header of the variance record that corresponds to an empty value is excluded from the reconstructed IMDN message.

17. The method of claim 1 :

wherein the variance record comprises a variance record header and a variance record payload;

wherein reconstructing the IMDN message from the base and variance records

comprises decompressing the variance record header and the variance record payload using different respective decompression schemes.

18. A network server for storing an Instant Message Disposition Notification, IMDN, message in a Common Message Store, CMS, that comprises a non-volatile file system and a cache, the network server configured to:

identify a difference between an IMDN message and a base record, the base record being stored in the cache of the CMS;

store a variance record in the cache of the CMS, the variance record comprising:

the difference between the IMDN message and the base record;

a reference to the base record;

discard the IMDN message;

in response to receiving a request for the IMDN message:

reconstruct the IMDN message from the base and variance records stored in the cache of the CMS without reading from the non-volatile file system of the CMS;

respond to the request for the IMDN message with the reconstructed IMDN message.

19. The network server of claim 18, configured to perform the method according to any of claims 2 through 17.

20. A computer program, comprising instructions that, when executed on at least one processor, cause the at least one processor to carry out the method according to any of claims 1 through 17.

21. A carrier containing the computer program of claim 20, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

Description:
STORING DISPOSITION NOTIFICATIONS IN A MESSAGE STORE

TECHNICAL FIELD

The present application generally relates to storing Instant Message Disposition Notification (IMDN) messages, and specifically relates to storing an IMDN message in a Common Message Store (CMS) that comprises a non-volatile file system and a cache.

BACKGROUND

An Instant Message Disposition Notification (IMDN) message is a mechanism by which a user may be informed as to the status of a particular message. In other words, an IMDN message may be used to inform a user as to the disposition of a particular message. Examples include notifying a user as to whether a particular message has been delivered, is processing, or has been displayed. IMDN messages may be used to inform a user as to the disposition of a wide variety of non-IMDN messages, including for example instant messages and email messages. Although users may benefit from the disposition information that IMDN messages may provide, IMDN messages may increase overhead within the network in order to store and signal such messages. In particular, a Common Message Store (CMS) may be, according to existing techniques, at least somewhat burdened by the storage and signaling required to support IMDN messages.

SUMMARY

The present application generally relates to IMDN messages, and specifically relates to storing an IMDN message in a CMS that comprises a non-volatile file system and a cache. The methods and apparatus as described herein may be used to store an IMDN message as a variance record that comprises a difference between the IMDN message and a base record in the cache, such that the IMDN message may be later reconstructed from the base and cache records without reading from the non-volatile file system.

Exemplary embodiments comprise a method for storing an IMDN message in a CMS that comprises a non-volatile file system and a cache. The method comprises identifying a difference between an IMDN message and a base record, the base record being stored in the cache of the CMS. The method further comprises storing a variance record in the cache of the CMS, the variance record comprising the difference between the IMDN message and the base record, and a reference to the base record. The method further comprises discarding the IMDN message, and in response to receiving a request for the IMDN message, reconstructing the IMDN message from the base and variance records stored in the cache of the CMS without reading from the non-volatile file system of the CMS. The method further comprises, in response to receiving a request for the IMDN message, responding to the request for the IMDN message with the reconstructed IMDN message. In some embodiments, the base record is a preconfigured incomplete I DN message.

In some embodiments, the method further comprises receiving the IMDN message subsequent to receiving a previous IMDN message, and subsequent to storing the base record in the cache of the CMS, the base record comprising the previous IMDN message.

In some embodiments, the method further comprises storing the base and variance records in an Internet Message Access Protocol (IMAP) message store within the cache of the CMS.

In some embodiments, the method further comprises loading the base record into the cache of the CMS from the non-volatile file system of the CMS prior to identifying the difference between the IMDN message and the base record.

In some embodiments, the IMDN message comprises an IMDN header and an IMDN payload, and the method further comprises compressing the IMDN header and the IMDN payload of the IMDN message using different respective compression schemes to generate the variance record. In an embodiment, the base record comprises a cached payload, and using different respective compression schemes to generate the variance record comprises applying a delta compression scheme to the IMDN payload based on the cached payload. In an embodiment, the base record comprises a cached header that comprises at least one name- value pair, and the IMDN header comprises at least one name-value pair. Using different respective compression schemes to generate the variance record comprises applying a first compression scheme to the IMDN header. The first compression scheme comprises deleting each name-value pair from the IMDN header that is also found in the cached header, and for each name-value pair of the cached header for which there is not a name-value pair in the IMDN header having the same name, inserting the name-value pair of the cached header into the IMDN header with an empty value field. In one embodiment, the first compression scheme further comprises applying dictionary compression to the IMDN header subsequent to the deleting and inserting of name-value pairs.

In some embodiments, storing the variance record in the cache of the CMS is in response to determining that a size of the variance record is smaller than a threshold.

In some embodiments, the method further comprises receiving the IMDN message before receiving a subsequent IMDN message, generating a compressed copy of the subsequent IMDN message, and selectively storing the subsequent IMDN message based on a size of the compressed copy relative to a threshold. The selectively storing comprises, in response to the size of the compressed copy being smaller than the threshold, storing the compressed copy in the cache of the CMS, and in response to the size of the compressed copy being bigger than the threshold, storing the subsequent IMDN message in the non-volatile file system of the CMS without storing the subsequent IMDN message in the cache.

In some embodiments, the method further comprises receiving the IMDN message subsequent to receiving a previous IMDN message relating to a disposition of a non-IMDN message stored in the CMS, storing the base record in the cache of the CMS, wherein the base record comprises the previous IMDN message, and retaining the base record in the cache after the non-IMDN message is deleted from the CMS.

In some embodiments, the request for the IMDN message comprises a particular IMAP Unique Identifier (UID) that corresponds to the variance record in the cache of the CMS, and the reconstructing comprises retrieving the variance record from the cache of the CMS using the particular IMAP UID, and retrieving the base record from the cache of the CMS using the reference comprised in the variance record.

In some embodiments, the method further comprises writing the base record and the variance record stored in the cache of the CMS to the non-volatile file system of the CMS.

In some embodiments, the method further comprises selecting the base record from a plurality of potential base records stored in the cache of the CMS.

In some embodiments, the base and variance record each comprise a header that comprises at least one name-value pair. Reconstructing the IMDN message from the base and variance records comprises including, in the reconstructed IMDN message, each name-value pair in the header of the base record having a name not found in the header of the variance record. Reconstructing the IMDN message from the base and variance records comprises further including, in the reconstructed IMDN message, each name-value pair in the header of the variance record having a name not found in the header of the base record. Reconstructing the IMDN message from the base and variance records comprises further including, in the reconstructed IMDN message, each name-value pair in the header of the variance record having a non-empty value and a name found in the header of the base record. Each name- value pair in the header of the base record having a name found in the header of the variance record that corresponds to an empty value is excluded from the reconstructed IMDN message.

In some embodiments, the variance record comprises a variance record header and a variance record payload, and reconstructing the IMDN message from the base and variance records comprises decompressing the variance record header and the variance record payload using different respective decompression schemes.

Other embodiments of the disclosure comprise a network server for storing an IMDN message in a CMS that comprises a non-volatile file system and a cache. The network server is configured to identify a difference between an IMDN message and a base record, the base record being stored in the cache of the CMS. The network server is further configured to store a variance record in the cache of the CMS, the variance record comprising the difference between the IMDN message and the base record, and a reference to the base record. The network server is further configured to discard the IMDN message, and in response to receiving a request for the IMDN message, reconstruct the IMDN message from the base and variance records stored in the cache of the CMS without reading from the non-volatile file system of the CMS. The network server is further configured to, in response to receiving the request for the IMDN message, respond to the request for the I DN message with the reconstructed IMDN message.

In some embodiments, the base record is a preconfigured incomplete IMDN message.

In some embodiments, the network server is further configured to receive the IMDN message subsequent to receiving a previous IMDN message, and subsequent to storing the base record in the cache of the CMS, the base record comprising the previous IMDN message.

In some embodiments, the network server is further configured to store the base and variance records in an Internet Message Access Protocol (IMAP) message store within the cache of the CMS.

In some embodiments, the network server is further configured to load the base record into the cache of the CMS from the non-volatile file system of the CMS prior to identifying the difference between the IMDN message and the base record.

In some embodiments, the IMDN message comprises an IMDN header and an IMDN payload, and the network server is further configured to compress the IMDN header and the IMDN payload of the IMDN message using different respective compression schemes to generate the variance record. In an embodiment, the base record comprises a cached payload, and, to use different respective compression schemes to generate the variance record, the network server is further configured to apply a delta compression scheme to the IMDN payload based on the cached payload. In an embodiment, the base record comprises a cached header that comprises at least one name-value pair, and the IMDN header comprises at least one name-value pair. To use different respective compression schemes to generate the variance record, the network server is further configured to apply a first compression scheme to the IMDN header. The first compression scheme comprises deleting each name-value pair from the IMDN header that is also found in the cached header, and for each name-value pair of the cached header for which there is not a name-value pair in the IMDN header having the same name, inserting the name-value pair of the cached header into the IMDN header with an empty value field. In one embodiment, the first compression scheme further comprises applying dictionary compression to the IMDN header subsequent to the deleting and inserting of name- value pairs.

In some embodiments, the network server is configured to store the variance record in the cache of the CMS in response to determining that a size of the variance record is smaller than a threshold.

In some embodiments, the network server is further configured receive the IMDN message before receiving a subsequent IMDN message, generate a compressed copy of the subsequent IMDN message, and selectively store the subsequent IMDN message based on a size of the compressed copy relative to a threshold. To selectively store, the network server is configured to, in response to the size of the compressed copy being smaller than the threshold, store the compressed copy in the cache of the CMS, and in response to the size of the compressed copy being bigger than the threshold, store the subsequent IMDN message in the non-volatile file system of the CMS without storing the subsequent IMDN message in the cache.

In some embodiments, the network server is further configured to receive the IMDN message subsequent to receiving a previous IMDN message relating to a disposition of a non- IMDN message stored in the CMS, store the base record in the cache of the CMS, wherein the base record comprises the previous IMDN message, and retain the base record in the cache after the non-IMDN message is deleted from the CMS.

In some embodiments, the request for the IMDN message comprises a particular IMAP Unique Identifier (UID) that corresponds to the variance record in the cache of the CMS, and to reconstruct, the network server is configured to retrieve the variance record from the cache of the CMS using the particular IMAP UID, and retrieve the base record from the cache of the CMS using the reference comprised in the variance record.

In some embodiments, the network server is configured to write the base record and the variance record stored in the cache of the CMS to the non-volatile file system of the CMS.

In some embodiments, the network server is further configured to select the base record from a plurality of potential base records stored in the cache of the CMS.

In some embodiments, the base and variance record each comprise a header that comprises at least one name-value pair. To reconstruct the IMDN message from the base and variance records, the network server is configured to include, in the reconstructed IMDN message, each name-value pair in the header of the base record having a name not found in the header of the variance record. The network server is further configured to include in the reconstructed IMDN message each name-value pair in the header of the variance record having a name not found in the header of the base record. The network server is further configured to include in the reconstructed IMDN message each name-value pair in the header of the variance record having a non-empty value and a name found in the header of the base record. Each name-value pair in the header of the base record having a name found in the header of the variance record that corresponds to an empty value is excluded from the reconstructed IMDN message.

In some embodiments, the variance record comprises a variance record header and a variance record payload, and to reconstruct the IMDN message from the base and variance records, the network server is configured to decompress the variance record header and the variance record payload using different respective decompression schemes.

Other embodiments comprise a computer program, comprising instructions that, when executed on at least one processor in a network server, cause the at least one processor to identify a difference between an IMDN message and a base record, the base record being stored in the cache of the CMS. The instructions further cause the processor to store a variance record in the cache of the CMS, the variance record comprising the difference between the IMDN message and the base record, and a reference to the base record. The instructions further cause the processor to discard the IMDN message, and in response to receiving a request for the IMDN message, reconstruct the IMDN message from the base and variance records stored in the cache of the CMS without reading from the non-volatile file system of the CMS. The instructions further cause the processor to, in response to receiving a request for the IMDN message, respond to the request for the IMDN message with the reconstructed IMDN message.

Other embodiments comprise a carrier containing the computer program described above, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

Of course, the present invention is not limited to the above features and advantages. Indeed, those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram of a system that includes a network with user nodes and a network server attached, according to one or more embodiments.

Figure 2 is a block diagram of an example network server according to one or more embodiments.

Figures 3A-3B are call flow diagrams for storing and retrieving messages using a network server, according to one or more embodiments.

Figure 4A is a block diagram illustrating compression of an IMDN message for storage into a CMS, according to one or more embodiments.

Figure 4B is a block diagram illustrating reconstruction of an IMDN message without reading from a non-volatile file system, according to one or more embodiments.

Figure 5 is a logic flow diagram for storing an IMDN message in a CMS that comprises a non-volatile file system and a cache, according to one or more embodiments.

Figure 6 is a more detailed logic flow diagram for storing an IMDN message in a CMS that comprises a non-volatile file system and a cache, according to one or more embodiments.

Figure 7 is a block diagram of exemplary hardware for storing an IMDN message in a CMS that comprises a non-volatile file system and a cache, according to one or more embodiments.

Figure 8 is a block diagram of exemplary processing circuitry for storing an IMDN message in a CMS that comprises a non-volatile file system and a cache, according to one or more embodiments.

Figure 9 is a block diagram of exemplary software for storing an IMDN message in a CMS that comprises a non-volatile file system and a cache, according to one or more embodiments. DETAILED DESCRIPTION

Figure 1 illustrates a system 100 comprising network nodes attached to a network according to one or more embodiments. The system 100 comprises a network server 110 and two user nodes 120a-b, each of which are attached to a network 130. The network 130 may, for example, support Internet Protocol (IP)-based packet switched communications through which the user nodes 120a-b are able to exchange messages with each other, and with network server 110. The user nodes 120a-b may be any network-enabled physical computing device that provides an interface to a user. Examples of a user node 120 may include a personal computer, laptop computer, tablet, personal data assistant (PDA), mobile phone, smart television, media player, and the like. Thus, network 130 may support the user nodes 120a-b in exchanging messages such as emails, instant messages, and chat messages, to name a few.

The network server 110 may be any network-enabled physical computing device that supports the exchange of messages between user nodes 120a-b. For example, to support the exchange of messages between user nodes 120a-b, network server 110 may store messages sent from network node 120a to network node 120b, until such time as network node 120b is available or otherwise ready to retrieve such messages. Network server 110 may additionally or alternatively store messages sent between user nodes 120a-b for purposes of providing cloud- based long-term storage, or for data backup/retention purposes. Thus, examples of the network server 110 may facilitate the exchange of messages between user nodes 120a-b by retaining messages for either short or long periods of time. Particular examples of the network server 110 include, but are not limited to, an email server, a chat server, and an instant messaging server.

Figure 2 illustrates an example of a network server 110 according to one or more embodiments. The network server 110 comprises an Internet Message Access Protocol (IMAP) server 240 and or a Session Initiation Protocol (SIP) server 250, each of which is in

communication with a Common Message Store (CMS) 210. The CMS 210 comprises a cache 220 and a non-volatile file system 230. IMAP is a protocol that may be used for email retrieval and storage. Thus, the example network server 110 of Figure 2 may use the IMAP server 240 to support the exchange of email messages between user nodes 120a-b by storing email messages in a CMS 210 that operates as an IMAP message store. Similarly, SIP is a protocol that may be used for sending instant messages and managing messaging sessions between endpoints. Thus, the example network server 110 of Figure 2 may use the SIP server 250 to support the exchange of instant messages between user nodes 120a-b by storing instant messages in the CMS 210. As previously discussed, the network server 110 may, according to embodiments, be any network-enabled physical computing device that supports the exchange of messages between user nodes 120a-b. Accordingly, network server 110 may support additional, fewer, or different message servers than the IMAP server 240 and SIP server 250 depicted in Figure 2, in support of other types of messages. Further, the CMS 210 may be used to store other signaling messages, control messages, and/or messaging messages, including, e.g., IMDN messages.

The non-volatile file system 230 may provide long-term, reliable, persistent storage for messages stored in the CMS 210, whereas the cache 220 may provide high-performance access to a subset of the information in the CMS 210 that is most commonly accessed. One or more records stored in the cache 220 may be periodically or systematically backed-up to the non-volatile file system 230 to help prevent data loss in case of a failure (e.g., a power outage, an operating system crash). One or more records stored in the non-volatile file system 230 may be loaded into the cache 220 in response to requests for those record(s) while they are not present in the cache 220 (e.g., a cache miss). One or more records stored in the non-volatile file system 230 may also be loaded into the cache 220 in response to a prediction that those record(s) may soon be requested. One or more records stored in the non-volatile file system 230 may also be loaded into the cache 220 when the network server 110 powers on, boots up, and/or experiences any other event. Examples of a non-volatile file system 230 may include one or more hard drives and or one or more solid state drives. Examples of a cache 220 may include one or more solid state memory devices and or one or more Random Access Memory circuits. As compared to the non-volatile file system 230, examples of the cache 220 may generally be characterized as smaller in capacity and higher in read and or write performance, according to one or more embodiments.

One or more IMDN messages may be used to learn and/or report the status of a particular message that is stored at, or has passed through, network server 110. For example, an IMDN message may be used to inform user node 120a when an email sent by the user node 120a is delivered to, or displayed by, user node 120b. An example of IMDN messages being used to report the disposition of a non-IMDN message is depicted in Figures 3A-B.

According to the example beginning in Figure 3A, user node 120a sends a non-IMDN message to network server 110, which may be handled at the network server 110 by message server 260 (step 302). The non-IMDN message may be addressed to user node 120b (or a user thereof) and may contain a header, message envelope, or flag in which a request for message disposition notifications may be indicated. Message server 260 may be able to detect the request for message disposition notifications, and may thereafter provide user node 120a with information pertaining to the status of the non-IMDN message.

Message server 260 may proceed to store the non-IMDN message in the CMS 210. As previously discussed, the CMS may comprise a cache 220 and a non-volatile file system 230. The cache 220 is frequently limited in the amount of data that may be stored therein. Thus, in order for a record to be stored in the cache 220, it may be required that the size of the record be smaller than a threshold. Additionally or alternatively, the cache 220 may be purposed for storing metadata about received non-IMDN messages that enable those non-IMDN messages to be readily accessed and retrieved from the non-volatile file system 230. In the example of Figure 3A, to store the non-I DN message in the CMS 210, the message server 260 stores metadata concerning the non-IMDN message in the cache 220 (step 304), and stores the non-IMDN message itself in the non-volatile file system 230 (step 306). As part of storing a message in the CMS 210, the message server 260 may assign an identifier to the non-IMDN message. This identifier may, for example, facilitate later retrieval of the corresponding message. For example, the message server 260 may assign an IMAP unique identifier (UID) to the non-IMDN message as part of storing the non-IMDN message in the CMS 210.

The user nodes 120a-b may check for messages received by the message server 260. This check may, for example, be performed occasionally, periodically, in response to one or more events, and/or in response to user input. For example, the user node 120b may poll the network server 110 every 5 minutes for new email messages, or may check for messages upon reestablishing connectivity to the network 130. According to one particular example, the user node 120b may send an IMAP search command to the message server 260 to ask for messages that have arrived according to particular criteria. In the example of Figure 3A, user node 120b checks the message server 260 for messages (step 308) after the message server 260 receives and stores the non-IMDN message.

The message server 260 may then access metadata stored in the cache 220 to determine whether one or more messages relevant to the message check are stored in the non-volatile file system 230 (step 310). The cache 220 may then return one or more identifiers corresponding to one or more messages relevant to user node 120b (step 312). The message server 260 may then return the one or more message identifiers to the user node 120b (step 314). User node 120b may then request the non-IMDN message from the message server 260 (step 316). This request may, for example, be an IMAP fetch command in which the UID of the non-IMDN message (previously retrieved from the message server 260) is specified. The message server 260 may then access the non-volatile file system 230 (step 318) and retrieve the non-IMDN message (step 320), which the message server 260 may then return to the user node 120b (step 322).

As previously discussed, the non-IMDN message may contain a header, message envelope, or flag in which a request for message disposition notifications may be indicated. Thus, upon receiving the non-IMDN message, the user node 120b may learn that user node 120a has requested message disposition notifications for the non-IMDN message. Accordingly, user node 120b may send an IMDN message to the message server 260 indicating that the non-IMDN message has been delivered (i.e., the user node 120b may send a "delivered" IMDN message to the message server 260) (step 324). As discussed above, messages received by the message server 260 may be stored in the cache 220 of the CMS 210, although the cache 220 may require a message stored therein to be smaller than a threshold. Accordingly, message server 260 may compress the "delivered" IMDN message (step 326) and compactly store the compressed "delivered" IMDN message in the cache 220 (step 328). Alternatively, the message server 260 may omit compressing the "delivered" I DN message, and store the "delivered" IMDN message as received, should sufficient cache space be available. In either case, the "delivered" IMDN message may be assigned an identifier as previously discussed.

Also as previously discussed, user node 120a may check message server 260 for messages. According to the example shown in Figure 3A, user node 120a performs such a check (step 330) after the "delivered" IMDN message has been received and stored by the message server 260. Consequently, the message server 260 may access metadata stored in the cache 220 to determine whether one or more messages relevant to user node 120a is stored in the CMS (step 332). The cache 220 may then return one or more such message identifiers to the message server 260 (step 334), and the message server 260 may return those message identifiers to the user node 120a (step 336). Among these identifiers may be an identifier corresponding to the "delivered" IMDN message. User node 120a may request the "delivered" IMDN message from the message server 260, for example, using the corresponding identifier (step 338). For example, the user node 120a may send an IMAP fetch command along with a UID of the "delivered" IMDN message to the message server 260. In response to receiving the request for the "delivered" IMDN message, the message server 260 may access the cache 220 (step 340) to retrieve the "delivered" IMDN message therefrom (step 342), decompress "delivered IMDN message (if compressed) (step 344) and return the "delivered" IMDN message to the user node 120a (step 346), all without accessing the non-volatile file system 230.

With reference now to Figure 3B, user node 120b may at some point after having received the non-IMDN message, display the non-IMDN message to a user (step 348).

Accordingly, user node 120b may send an IMDN message to notify the message server 260 that the non-IMDN message has been displayed (i.e., the user node 120b may send a

"displayed" IMDN message to the message server 260) (step 350). As previously discussed, a message received by the message server 260 may be compressed in order to store the message in the cache 220. Accordingly, the message server 260 may compress the

"displayed" IMDN message. To compress the "displayed" IMDN message, the message server 260 may take advantage of the "displayed" IMDN message's similarity to the previously received "delivered" IMDN message. For example, the message server 260 may access the cache 220 (step 352) to retrieve the "delivered" IMDN message therefrom (step 354), and identify a difference between the "displayed" IMDN message and the "delivered" IMDN message (step 356). Thus, the "delivered" IMDN message may act as a base record for comparison with the "displayed" IMDN message. The message server 260 may then store the difference between the "displayed" IMDN message and the "delivered" IMDN message in a variance record in the cache 220 (step 358). This variance record may contain the

aforementioned difference from the base record (i.e., the difference between the "displayed" and "delivered" IMDN messages, according to the example in Figures 3A-B) and a reference to the base record (e.g., a UID of the "delivered" I DN message). Having stored the variance record including the above-discussed difference in the cache 220, the message server 260 may freely discard the "displayed" IMDN message (step 360) since, as will be further discussed below, the message server 260 may reconstruct the "displayed" IMDN message as needed from information stored in the cache 220.

User node 120a may again check the message server 260 for messages (step 362), and the message server 260 will again access the cache 220 (step 364) to retrieve one or more message identifiers (step 366) and return the one or more message identifiers to the user node 120a (step 368). An identifier that corresponds to the variance record in the cache 220 may, for example, be among these message identifiers returned to the user node 120a. The user node 120a may then send a request to the message server 260 for the "displayed" IMDN message using the identifier corresponding to the variance record.

In response to receiving the request for the "displayed" IMDN message (step 370), the message server 260 may access the cache 220 (step 372) and retrieve the variance record (step 374). As discussed above, the variance record comprises a reference to a corresponding base record. Accordingly, the message server 260 may use the reference in order to access the cache (step 376) and retrieve the "delivered" IMDN message (step 378), which was earlier used as the base record. The message server 260 may then reconstruct the "displayed" IMDN message from the base and variance records (step 380) and respond to the request for the "displayed" IMDN message (step 382) without reading from the non-volatile file system.

According to one or more embodiments, this may result in a scheme that avoids relatively long non-volatile file system 230 read times in order to retrieve relatively small, and highly- predictable, IMDN messages.

Although the example of Figure 3B used an earlier-received IMDN message as a base record for identifying differences and for reconstruction, other kinds of data stored in the cache 220 may be suitable for use as the base record according to one or more embodiments. For example, one or more incomplete IMDN messages may be preconfigured (e.g., as a template) and stored in the cache 220 such that they may be used as the above-discussed base record. Further, the base record may, for example, be a record that was loaded into the cache 220 from the non-volatile file system 230 of the CMS 210 prior to identifying the difference between the "displayed" IMDN message and the base record (e.g., upon initial boot of the message server 260).

According to one or more embodiments, an IMDN message is compressed before being stored in the cache 220 of the CMS 210. Such compression of an IMDN message may involve the use of one or more compression schemes. An example of a network server 110 compressing an IMDN message for storage in a cache 220 is illustrated in Figure 4A. The example of Figure 4A illustrates that the network server 110 has an IMDN message 410, a message server 260, a cache 220, and a non-volatile file system 230. The IMDN message 410 may comprise an I DN header 420 and an I DN payload 430. The IMDN message 410 may be compressed, for example, by a message server 260 of the network server 110 using different respective compression schemes 440a-b to generate a variance record 450 that may later be used to reconstruct the IMDN message 410. Compressions schemes 440a-b that may be applied to either the IMDN header 420 or the IMDN payload 430 include, but are not limited to, one or more of null compression, run-length compression, keyword encoding, dictionary encoding, adaptive Huffman encoding, and Lempel-Ziv-Welch encoding, to name a few. As will be explained in further detail below, one or more of the compression schemes 440a-b applied may involve multiple compression techniques applied in parallel, or in sequence, and may involve either standard or proprietary approaches. Further, one or more of the compression schemes 440a-b may use one or more records already stored in the cache 220. For example, as shown in Figure 4A, compression scheme 440a makes use of base record 460 in the cache 220 to compress the IMDN header 420. In particular, a compression scheme 440 may make use of the cached header 470a or cached payload 480a of the base record 460 to produce the variance record 450. Further, compressing the IMDN message 410 using different respective compression schemes 440a-b may produce a variance record 450 that also has a header 470b and payload 480b. According to one or more embodiments, one or more writes to the cache 220 (e.g., writes performed in order to store the variance record 450) may be written back to the non-volatile file system 230, e.g., for data backup purposes. More generally, one or more embodiments may include writing the base record 460 and/or the variance record 450 to the non-volatile file system 230.

In one embodiment, the message server 260 compresses the IMDN message 410, at least in part, by applying a delta compression scheme 440b to the IMDN payload 430. The message server 260 may base the delta compression scheme 440b on the cached payload 480a of base record 460 stored in the cache 220. For example, the delta compression scheme 440b may eliminate data duplication between the IMDN payload 430 and the cached payload 480a of the base record 460 by, for example, identifying a difference between the IMDN message between the two payloads. A delta compression scheme 440b thus applied may produce a payload 480b of the variance record 450 that is smaller in size than the IMDN payload 430, and that may subsequently be stored in cache 220. Thus, the delta compression scheme 440b may be applied in order to generate the variance record 450.

In one embodiment, the IMDN header comprises at least one name-value pair, and the message server 260 compresses the IMDN message 410, at least in part, according to a compression scheme 440a that comprises inserting and or deleting one or more name-value pairs to/from the IMDN header 420. The message server 260 may base the insertion and or deletion of one or more name-value pairs on one or more name-value pairs in the cached header 470a of the base record 460. For example, the compression scheme 440a applied to the IMDN header 420 may comprise deleting each name-value pair from the IMDN header 420 that is also found in the cached header 470a of the base record 460. The compression scheme 440a applied to the I DN header 420 may additionally or alternatively comprise, for each name value pair of the cached header 470a for which there is not a name-value pair in the IMDN header 420 having the same name, inserting the name-value pair of the cached header 470a into the IMDN header 420 with an empty value field. Thus, the name-value pair approach to compression may be applied in order to produce a header 470b of the variance record 450 that is smaller in size than the IMDN header 420, for example, by identifying a difference between the IMDN message between one or more name-value pairs in the two payloads and deleting more information from the IMDN header 420 than is inserted. Accordingly, the name-value approach described above may be applied to generate the variance record 450.

As one example of a compression scheme 440a that may perform both the inserting and deleting of name-value pairs described above, an IMDN header 420 with name-value pairs {A-1 , B-2, C-3}, compressed based on a cached header 470a with name-value pairs {A-1 , B-4, D-5}, may produce a header 470b of the variance record 450 that comprises name-value pairs {B-2, C-3, D- }. In this example, A-1 is deleted from the IMDN header 420 because it is also found in the cached header 470a. Further, D- (i.e., D, with an empty corresponding value) is inserted into the IMDN header 420 because the cached header 470b comprises the name-value pair D5, and there is not a name-value pair in the IMDN header 420 having the same name (i.e., D). Since no inserting or deleting rule exists in this example, name-value pairs B2 and C3 in the IMDN header 420 are left unchanged. Additional, fewer, or different rules for handling name- value pairs between headers may also be employed, according to embodiments. For example, a rule for handling name-value pairs in compression scheme 440a may include modifying certain name-value pairs of the IMDN header 420 to produce the header 470b of the variance record 450.

Further, as previously discussed, a compression scheme 440a-b may comprise multiple compression techniques applied in parallel or in sequence. Thus, according to embodiments, compression scheme 440a may further comprise applying dictionary compression to the IMDN header 420 subsequent to the deleting and/or inserting of name-value pairs. For example, the compression scheme 440a may determine whether the size of the IMDN header 420 would be reduced by such dictionary compression (e.g., by prospectively applying the dictionary compression to the IMDN header 420), and may include or exclude dictionary compression in the generation of the variance record 450 accordingly.

As previously discussed, storing the variance record 450 in the cache 220 may be in response to determining that a size of the variance record 450 is smaller than a threshold. Notwithstanding, one or more embodiments may not be able to store every IMDN message 410 that the network server 110 receives. Accordingly, one or more embodiments may include generating a compressed copy of an IMDN message 410 (e.g., as described above), and selectively storing the IMDN message 410 based on a size of the compressed copy relative to the threshold. For example, this selectively storing may comprise, in response to the size of the compressed copy being smaller than the threshold, storing the compressed copy in the cache 220 of the CMS 210, and in response to the size of the compressed copy being bigger than the threshold, storing the IMDN message 410 in the non-volatile file system 230 of the CMS 210 without storing the IMDN message 410 in the cache 220. Accordingly, one or more embodiments may involve storing one or more IMDN messages 410 in the cache 220, and storing one or more other IMDN messages, received previously or subsequently, in the nonvolatile file system 230 (but not the cache 220).

According to embodiments, the storing of a base record 460 and variance record 450 in the cache 220 may enable reconstruction of the corresponding IMDN message 410 without the need to access the non-volatile file system 230. The base record 460 and or the variance record 450 may correspond to a respective IMDN message for reporting the disposition of a non-IMDN message that, at some point, was received by the network server 110 and stored in the CMS 210. Notwithstanding, a non-IMDN message may, at some point, be deleted from the CMS 210. There are many reasons why a non-IMDN message may be deleted. For example, the user device 120b may delete a non-IMDN message from the network server 110 once the non-IMDN message has been delivered. Additionally or alternatively, the network server 110 may purge old and/or unused messages from the CMS 210. Notwithstanding, according to embodiments, a base record 460, stored in the cache 220, that comprises an IMDN message may be retained by the network server 110 after the corresponding non-IMDN message is deleted from the CMS 210. For example, the network server 110 may retain the base record 460 to facilitate the compression of subsequently received IMDN messages, as well as to ensure that variance records referencing the base record can be used to reconstruct the corresponding IMDN messages. According to embodiments, the network server 110 may accumulate a plurality of base records 460 in the cache 220 by any of the mechanisms described above. Thus, the base record 460 used, for example, as a basis for compressing the IMDN header 420 according to compression scheme 440a may be selected from a plurality of potential base records (e.g., a plurality of base records that are retained by the network server 110 for purposes of participating in a compression scheme 440, regardless of whether they correspond to non-IMDN messages in the CMS 210).

To enable later reconstruction, the variance record 450 may be stored in the cache 220 along with a reference 495 to the base record 460 used during compression. This reference may be an IMAP UID, a cache address, a memory pointer, or an array index, for example. Once the variance record 450 is stored in cache 220, the IMDN message 410 may be discarded. In response to receiving a request for the IMDN message 410, the network server may reconstruct the IMDN message 410 from the base record 460 and the variance record 450 stored in the cache 220 without reading from the non-volatile file system 230. Figure 4B illustrates an example of reconstructing the I DN message 410 without reading from the non-volatile file system 230. In the example of Figure 4B, reconstructing the IMDN message 410 comprises the message server 260 retrieving both the variance record 450 and the base record 460 from the cache 220. To retrieve the variance record 450, the message server 260 may use a particular record identifier received in the request for the IMDN message 410. This record identifier may, for example, be a particular IMAP UID that corresponds to the variance record 450. To retrieve the base record 460, the message server 260 may use the reference 495 comprised in the variance record 450. Having retrieved the base record 460 and the variance record 450, the message server 260 may reconstruct the IMDN message from the base record 460 and variance record 450 by decompressing the variance record header 470b and variance record payload 480b using different respective decompression schemes 490a-b.

These decompression schemes 490a-b may, for example, be a decompression scheme 490a-b appropriate for decompressing data compressed by the corresponding compression schemes 440a-b discussed above with respect to Figure 4A. As one example, the

reconstructing comprises including in the reconstructed IMDN message 485 one or more name- value pairs found in the headers 470a-b of the base record 460 and variance record 450. For example, consider the above-discussed example in which the IMDN header 420 had name- value pairs {A-1 , B-2, C-3}, the cached header 470a of the base record 460 had name-value pairs {A-1 , B-4, D-5}, and variance record 450 with a header 470b was produced that comprised name-value pairs {B-2, C-3, D- }. To reconstruct the IMDN message 410, the reconstructing may comprise including in the reconstructed IMDN message 485 each name-value pair in the header 470a of the base record 460 having a name not found in the header 470b of the variance record 450. In such an example, name-value pair A-1 is in the base record 460 header 470a, but not in the variance record 450 header 470b. Thus, according to this example, the name-value pair A-1 would be included in the reconstructed IMDN message 485. To reconstruct the IMDN message 410, the reconstructing may further comprise including in the reconstructed IMDN message 485 each name-value pair in the header 470b of the variance record 450 having a name not found in the header 470a of the base record 460. According to this example, name-value pair C-3 is in the variance record 450 header 470b, but not in the base record 460 header 470a. Thus, according to this example, the name-value pair C-3 would be included in the reconstructed IMDN message 485. To reconstruct the IMDN message 410, the reconstructing may further comprise including in the reconstructed IMDN message 485 each name-value pair in the header 470b of the variance record 450 having a non-empty value and a name found in the header 470a of the base record 460. According to this example, name-value pair B-2 is in the variance record 450 header 470b and has a non-empty value and a name found in the header 470a of the base record 460. Thus, according to this example, the name- value pair B-2 would be included in the reconstructed IMDN message 485. Further, although the name-value pair D- is in the variance record 450 header 470b and has a name found in the header 470a of the base record 460, D- has an empty value, and is excluded from the reconstructed IMDN message 485, according to this example.

In view of the above modifications and variations, Figure 5 generally illustrates an example method 500 for storing an IMDN message 410 in a CMS 210 that comprises a nonvolatile file system 230 and a cache 220. The method 500 comprises identifying a difference between an IMDN message 410 and a base record 460, the base record 460 being stored in the cache 220 of the CMS 210. The method 500 further comprises storing a variance record 450 in the cache 220 of the CMS 210, the variance record 450 comprising the difference between the IMDN message 410 and the base record 460. The variance record further comprises a reference 495 to the base record 460. The method 500 further comprises discarding the IMDN message 410, and in response to receiving a request for the IMDN message 410,

reconstructing the IMDN message 410 from the base and variance records 460, 450 stored in the cache 220 of the CMS 210 without reading from the non-volatile file system 230 of the CMS 210, and responding to the request for the IMDN message 410 with the reconstructed IMDN message 485.

Figure 6 illustrates a more detailed example method 600 for storing an IMDN message 410 in a CMS 210 that comprises a non-volatile file system 230 and a cache 220. According to the method 600, a network server 110 receives a non-IMDN message (block 605) and stores the non-IMDN message in the CMS 210 (block 610). The network server 110 then receives an IMDN message (block 615) and stores the IMDN message as a base record 460 (block 620). The network server 110 then receives a subsequent IMDN message 410 (block 625) and identifies a difference between the subsequent IMDN message 410 and the base record 460 (block 630). The network server 110 then compresses the header 470b of the subsequent IMDN message 410 according to a first compression scheme 440a (block 635). The network server 110 then compresses the payload 480b of the subsequent IMDN message 410 according to a different compression scheme 440b (block 640). The network server 110 then checks whether the size of the compressed IMDN message 410 is less than a threshold (block 645).

If the size of the compressed IMDN message 410 is not less than the threshold, the network server 110 stores the subsequent IMDN message 410 in the non-volatile file system 230 (block 685) and in response to receiving a request for the subsequent IMDN message 410 (block 690), the network server 110 responds to the request with the subsequent IMDN message 410 stored in non-volatile file storage 230 (block 695). The network server 110 then returns to receiving a yet subsequent IMDN message 410 (block 625), and continuing according to the method 600.

If the size of the compressed IMDN message 410 is less than the threshold, the network server 110 stores the compressed IMDN message 410 as a variance record 450 (block 650), and discards the subsequent IMDN message 410 (block 655). In response to receiving a request for the subsequent IMDN message 410 (block 660), the network server 110 reconstructs the subsequent IMDN message 410 using the base record 460 and the variance record 470 without accessing the non-volatile file system 230 (block 665). The network server 110 then responds to the request for the subsequent IMDN message 410 with the reconstructed IMDN message 485 without reading from the non-volatile file system 230 (block 670). The network server 110 then deletes the non-IMDN message (block 675). Notwithstanding, the network server 110 retains the base record 460 in the cache 220, and returns to receiving a yet subsequent IMDN message 410 (block 625) and continuing according to the method 600.

Figure 7 illustrates example hardware of the network server 110, according to one or more embodiments. The network server 110 comprises processing circuitry 820 that is communicatively coupled to memory circuitry 810 and interface circuitry 880, e.g., via one or more buses. The processing circuitry 820 may comprise one or more microprocessors, microcontrollers, hardware circuits, discrete logic circuits, hardware registers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or a combination thereof. For example, the processing circuitry may be programmable hardware capable of executing machine instructions stored as a machine- readable computer program 850 in the memory circuitry 810. The memory circuitry 810 of the various embodiments may comprise any non-transitory machine-readable media known in the art or that may be developed, including but not limited to magnetic media (e.g., floppy disc, hard disc drive, etc.), optical media (e.g., CD-ROM, DVD-ROM, etc.), solid state media (e.g., SRAM, DRAM, DDRAM, ROM, PROM, EPROM, Flash memory, solid state disc, etc.), or the like, or any combination thereof. In particular, the memory circuitry 810 may comprise cache circuitry 860 and non-volatile file system circuitry 870 that utilize distinct non-transitory memory architectures and are configured to operate together as a CMS 210.

The interface circuitry 880 may comprise output circuitry 830 and input circuitry 840. The output circuitry 830 may be configured to output signals for display to a user, or to send communication signals over network 130 (e.g., IMDN and non-IMDN messages). For example, the output circuitry 830 may be comprised within one or more of a graphics adapter, a graphical processing unit, a display port, a Liquid Crystal display, a Light Emitting Diode display, and a transmitter. When the output circuitry 830 is comprised within a transmitter, the output circuitry 830 may, for example, be configured to send IMDN and non-IMDN messages, or store data in a remote cache 220 and non-volatile file system 230 (not illustrated in Figure 7). The input circuitry 840 may be configured to accept input from a user of the network server 110, or receive communication signals from user nodes 120. For example, the input circuitry 840 may be comprised within one or more of a pointing device (such as a mouse, stylus, touchpad, trackball, pointing stick, joystick), a touchscreen, a microphone for speech input, an optical sensor for optical recognition of gestures, a keyboard, and a receiver. When the input circuitry 840 is comprised within a receiver, the input circuitry 840 may be configured to receive IMDN and non- IMDN messages, accept input from a user at a remote location, and/or receive data from a remote cache 220 and non-volatile file system 230 (not illustrated in Figure 8).

The processing circuitry 820 is configured to identify a difference between an IMDN message 410 and a base record 460, the base record 460 being stored in the cache circuitry 860 of the CMS 210. The processing circuitry 820 is further configured to store a variance record 450 in the cache circuitry 860 of the CMS 210, the variance record 450 comprising the difference between the IMDN message 410 and the base record 460 and a reference 495 to the base record 460. The processing circuitry 820 is further configured to discard the IMDN message 410, and in response to receiving a request for the IMDN message 410, reconstruct the IMDN message 410 from the base and variance records 460, 450 stored in the cache circuitry 860 of the CMS 210 without reading from the non-volatile file system circuitry 870 of the CMS 210. The processing circuitry 820 is further configured to, in response to receiving the request for the IMDN message 410, respond to the request for the IMDN message 410 with the reconstructed IMDN message 485. According to one or more embodiments, the configuration of the processing circuitry 820 is a result of executing a machine-readable computer program 850 stored in the memory circuitry 810.

Figure 8 illustrates example processing circuitry 820 comprising a plurality of physical units. In particular, the processing circuitry 820 comprises an identifying unit 705, a storing unit 710, a discarding unit 715, a reconstructing unit 720, and a responding unit 725. The identifying unit 705 is configured to identify a difference between an IMDN message 410 and a base record 460, the base record 460 being stored in the cache circuitry 860 of the CMS 210. The storing unit 710 is configured to store a variance record 450 in the cache circuitry 860 of the CMS 210, the variance record 450 comprising the difference between the IMDN message 410 and the base record 460 and a reference 495 to the base record 460. The discarding unit 715 is configured to discard the IMDN message 410. In response to receiving a request for the IMDN message 410, the reconstructing unit 720 is configured to reconstruct the IMDN message 410 from the base and variance records 460, 450 stored in the cache circuitry 860 of the CMS 210 without reading from the non-volatile file system circuitry 870 of the CMS 210. In response to receiving the request for the IMDN message 410, the responding unit 725 is configured to respond to the request for the IMDN message 410 with the reconstructed IMDN message 485.

Figure 9 illustrates an example control application 850 comprising a plurality of software modules. In particular, the control application 850 comprises an identifying module 755, a storing module 760, a discarding module 765, a reconstructing module 770, and a responding module 775. The identifying module 755 is configured to identify a difference between an IMDN message 410 and a base record 460, the base record 460 being stored in the cache 220 of the CMS 210. The storing module 760 is configured to store a variance record 450 in the cache 220 of the CMS 210, the variance record 450 comprising the difference between the IMDN message 410 and the base record 460 and a reference 495 to the base record 460. The discarding module 765 is configured to discard the I DN message 410. In response to receiving a request for the IMDN message 410, the reconstructing module 770 is configured to reconstruct the IMDN message 410 from the base and variance records 460, 450 stored in the cache 220 of the CMS 210 without reading from the non-volatile file system 230 of the CMS 210. In response to receiving the request for the IMDN message 410, the responding module 775 is configured to respond to the request for the IMDN message 410 with the reconstructed IMDN message 485.

The present invention may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the invention. The present embodiments are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.