Retrieval of offline instant messages

[0001] The invention relates to instant messages based on SIP (Session Initiation Protocol) / SIMPLE (SIP for Real-time Messaging and Presence

Leveraging Extensions). The invention particularly relates to the problem that arises when the mail server stores instant messages on the network for further delivery to the end user (presumably when the user connects to the network at a later time).

[0002] It is assumed that user A sends one or more instant messages to user B. The technology used to deliver these messages can be based on the SIP MESSAGE method or MSRP (Message Session Relay Protocol). instant). It is also assumed that user B is not registered on his SIP server, and that the mail application server stores actual text messages for later delivery to user B.

[0003] When User B registers to his SIP network, the SIP User Customer subscribes to the Message Summary and Wait Indicator package and receives notifications of messages waiting to be downloaded. It is assumed that the mail server stores huge amounts of instant messages, so user B receives a notification that summarizes these stored instant messages.

[0004] Myers et al .: "RFC 1939: Post Office Protocol Version 3" Network Working Group Request for Comments, XX, XX, May 1996 (1996-05), pages 1-20, XP002197697, relates to the mail node protocol version 3 (POP3, Post Office Protocol Version 3), which allows the workstation to dynamically access mail on the server, i.e. it allows the workstation to retrieve mail that the server stores for it. Chapter 10 gives an example of a POP3 session in which a summary of messages stored on the server is made available to the client and the client retrieves messages by indicating to the server the number of the message that is included in the summary.

[0005] US 2003/0165231 A1 discloses a network telephony system that enables unified messaging services. Generally, the system includes at least one user client functionally coupled to the data network and a notification server functionally coupled to the data network. User clients are telephone endpoints, such as autonomous telephone devices or personal computers with appropriate telephone software. A message server is provided which is operably coupled to the data network and corresponds to the signaling server. System

- 2 also includes a media server that is functionally coupled to the network and includes computer data storage media for storing message files. The media server responds to the message server and, when a message condition occurs, is directly accessible to the calling party to store the message file for subsequent retrieval by the called party.

SUMMARY OF THE INVENTION [0006] The invention should allow improved offline instant message retrieval.

[0007] This is achieved by means of an end device according to claim 1, a method according to claim 10, a network device according to claim 4, a method according to claim 13, a network device according to claim 19 and a method according to claim

21.

[0008] Fig. 1 is a schematic block diagram showing the configuration of an end device and a network device according to the invention.

[0009] The end device 10 includes a receiving block 11, a selection block 12, a retaining block 13 and a sending block 14. The receiving block 11 receives a summary of messages stored on the mail server such as network device 20 and waiting to be received by the user, each message being associated with a unique identifier. Select block 12 selects, based on the message summary, at least one of the messages to be downloaded by the mail server. The block 13 determines the qualifying identifier for retrieving at least one message based on the unique identifier associated with at least one message, thereby obtaining at least one qualifying identifier for retrieval. The sending block 14 sends a download request with at least one download qualifying identifier by the mail server.

[0010] The unique identifier may be the message identifier provided by the mail server or the Uniform Resource Identifier (URI).

[0011] A network device 20 such as a mail server stores messages waiting to be downloaded by a user, and includes a receiving block 21 and a sending block 22. The receiving block 21 receives a download request with at least one identifier for retrieving at least one of the stored messages, and the sending block 22 sends at least one message towards the terminal device (e.g. terminal 10) of the user initiating the download request.

[0012] The sending block 22 may send at least one message in the Message Session Relay Protocol (MSRP) message SEND message.

[0013] According to a first embodiment, the network device 20 may also include a delivery block 23 that provides a message identifier for each of the stored messages, where the sending block 22 sends to the user

- a summary of the stored messages, e.g. to end device 10, with each message associated with a predefined message identifier.

[0014] Delivery block 23 may use the Call-ID header field contained in the request to initiate each session from stored messages as a message identifier or generate a unique Uniform Resource Identifier (URI), whereby the URI can be redirected to a network device where the message identifier is part of the URI.

[0015] Delivery block 23 may use the MSRP Request Message header field for each of the stored messages as the message identifier.

[0016] According to a second embodiment, the network device 20 may include a conference server and virtual endpoints such as the virtual clients of the SIP User corresponding to the stored messages. The conference server can receive downloaded requests from the user containing a list of identifiers pointing to selected from stored messages, whereby the download request establishing the first session of delivery of selected messages establishes second sessions for each of the selected messages identified on the list with virtual endpoints corresponding to the selected messages, and receives the selected messages during the second sessions and forwards the selected messages to the user in the first session.

[0017] It should be noted that the configuration shown in Fig. 1 serves to illustrate the invention, and the terminal devices and network devices may comprise further blocks performing subsequent functions (such as storing a block in the network device 20 for storing messages) that are not essential for understanding of the invention and description, which is omitted here.

[0018] Fig. 2 is a flowchart showing a method of retrieving messages from the mail server from the end device 10. In step S31, a summary of messages stored on the mail server and waiting to be downloaded by the user is received on the terminal device, each message is associated with a unique identifier. At step S32, at least one of the messages to be received from the mail server is selected based on the summary of the messages received at step S31. In step S33, the qualifying identifier for retrieving at least one message is determined based on the unique identifier associated with at least one message to, thereby receiving at least one qualifying identifier for download, and in step S34 the request for download with the qualifying identifier for download is sent to mail server.

[0019] Fig. 3 is a flowchart showing a method for retrieving messages from a mail server from the network device 20. In step S41, a download request with at least one identifier for downloading at least one stored message is received, and in step S42 at least one message is sent to the user's terminal device initiating the download request.

[0020] According to a second embodiment, the download request from the user, comprising a list of identifiers indicative of selected from stored messages, is received by the network device 20, the download request establishing the first session for delivery of the selected messages. Second sessions are established for each of the selected messages identified in the list, and the selected messages are received in the second session, the selected messages are forwarded to the user in the second session. The invention can be implemented as a product in the form of a computer program.

[0021] The mail server may be implemented as an mail server application or an instant mail server.

[0022] According to a first embodiment of the invention, the user receives a message summary notification that contains the unique message identity addressed to each of the stored messages. For each of the messages that the user wants to download, the SIP user's client creates a SIP session of messages intended for the identity of the message, e.g. after making some transformations. The server, when receiving an INVITE request, is able to uniquely determine the actual message that the user wants to receive.

[0023] This solution enables the user to select the stored instant messages that should be retrieved. The advantage is enormous in mobile situations where bandwidth is limited and especially in cases where the number and size of stored instant messages matters. Thus, the user can select messages selected as urgent or received from a specific user, and then read the other messages later.

[0024] According to a second embodiment of the invention, a mechanism is provided in which the user, after selecting the instant messages that he wants to download from the mail server, creates a single session (SIP INVITE) addressed to the selected messages by applying the URI-list concept. This embodiment models the mail server as consisting of a conference server and a series of virtual SIP user clients, each representing a stored instant message.

[0025] According to this embodiment, a mechanism is provided for selecting and retrieving messages already stored on the mail server in an optimal manner that can be used in a mobile environment. According to this solution, the user can download an unlimited selected number of stored messages during a single run of the protocol.

[0026] This solution allows the user to minimize the signals and actions for downloading selected messages by applying a single session towards the mail server. Provisional patent application "Method and apparatus for instant messaging" from Garcia et al. filed at the US Patent and Trademark Office September 30, 2005, the content of which is incorporated herein by reference and the first embodiment, allow the mass retrieval of stored instant messages

- 5 or selected messages one after the other (which means that each message required a separate SIP session).

[0027] Thus, the second embodiment of the invention increases user satisfaction due to lower delays during session establishment and optimizes resource operation on low bandwidth channels, such as an air interface.

In the drawings:

[0028] Fig. 1 is a schematic block diagram illustrating the configuration of an end device and a network device according to the invention.

[0029] Fig. 2 is a flow chart showing the collection method according to the invention.

[0030] Fig. 3 is a flow chart showing the collection method according to the invention.

[0031] Fig. 4 is a signal diagram according to the first embodiment of the invention.

[0032] Fig. 5 is a block diagram illustrating a mail server according to a second embodiment of the invention.

[0033] Fig. 6 is a diagram of signals according to a second embodiment of the invention.

Description of the Embodiment of the Invention [0034] Assuming that the instant messages were stored in the user's mailbox, when the user's telephone is switched on, he sends a subscription to the message summary event package, and receives a notification with a pending message; according to RFC3842 "Event Package Message Summary and Pending Message Indication for Session Initiation Protocol (SIP)." The content of RFC 3842 is incorporated herein by reference. The mechanism also applies to VOICE MAIL, FAX etc. The notification element (SIP user client acting on behalf of the user's message system) sends a summary of messages stored in the NOTIFY content (NOTIFICATION), e.g. "there are 4 old messages and 3 new waiting messages".

[0035] Alternatively, after counting the messages, message headers such as To (To), From (From), Date (Date), Subject and Message ID may be attached to each message.

[0036] After notification to the User / UE (User Device

Equipment), it can send INVITE to the server containing the type of media to download (for notification of the News group in the OMA (Open Mobile

Alliance), INVITE must contain a description of the MSRP SDP (Session Description Protocol, but may also contain other types of media).

[0037] In addition, the user may use the mechanism as described in the provisional patent application "Method and Apparatus for Instant Messaging" to retrieve all stored instant messages from the mail server, including information with metadata (e.g., sender, delivery time, etc. ). To this end, a SIP mechanism is provided for retrieving instant messages that were previously stored on the application server that acted as the message storage application server. This can be achieved by retaining the relevant SIP message headers by encapsulating them as a message / sip, for example, as specified in Paragraph

27.5 RFC 3261, or as a message / sipfrag, as specified in RFC 3420, and then sending it as the content of the MSRP SEND request. The contents of RFC 3261 and 3420 are hereby incorporated by reference. In addition, the storage application server may then add a header to the MSRP SEND message and to the encapsulated SIP message containing the time and date the message was received. In particular, a date / time header is inserted into each stored SIP and MRSP message. Innovative semantics can be used to encapsulate stored instant messages, and message / sip and message / sipfrag are used in MRSP, outside the original context. Thus, a method is provided for providing encapsulated SIP messages containing header information as the content of an MSRP message.

[0038] Due to the above mechanism, a method and device is provided by means of which a user can contact his mail server and download existing instant messages that are already stored on the server of the application storing messages. Instant messages can be stored on the application storage server using SIP MESSAGE requests (as in IETF RFC 3428) or MSRP messages (e.g., MSRP SEND requests) that are part of a SIP session. The content of RFC 3428 is hereby incorporated by reference. Metadata and / or header information may allow the user to determine the source of the message, the time at which the message came out, etc.

[0039] After establishing the SIP session with the MSRP media, all stored messages will be forwarded from the server to the user / UE. Each stored message will be sent in a separate MSRP SEND request (before the MSRP SEND request is split into chunks), and each will be identified by its original MessageID. In this way, the user downloads all messages at once, but is still able to classify all messages using Message-ID.

[0040] One of the shortcomings of some solutions is that the original identification of the sender (user information) is lost because the MSRP headers have no connection with the SIP URI that stores the message. Thus, the association of senders with their individual messages already available in the inboxes of the application's messages such as e-mail, instant messages, MMS etc. will be lost. This also applies to SIP MESSAGE requests in that they can be sent, but the recipient will not be able to identify the sender because it is placed on the server of the application that stores messages.

[0041] A mechanism is proposed by which the user, when he or she wants to download his stored instant message, establishes MSRP sessions with his message-storing application server. The AS storage message encapsulates every downloaded session or stand-alone MESSAGE in the MSRP SEND request. Thus, each MSRP SEND request represents a SIP or MESSAGE session that contains content (one or more MSRP SEND requests or a different type for messages).

Still, by the above mechanisms, user B cannot download a selected message (e.g., sent by a given user, during a specified period of time, with a specific subject or with a given priority). Specifically, there is no mechanism in which user B can indicate to the mail server which message the user would like to download.

First Embodiment [0043] Fig. 4 is a signal diagram showing messages exchanged between users and an application server (AS) storing messages according to the first embodiment. As shown in Fig. 4, Alice sends an instant message to Charlie using a SIP MESSAGE request (flow 1). This MESSAGE request contains text, named Text # 1 here. Assuming Charlie is offline, the message is received and stored on the application server (AS) that stores the message.

[0044] Another user, Bob, creates a SIP session by sending an INVITE request (flow 3) to Charlie. The INVITE request contains a session description that includes the MSRP descriptor for sending session based instant messages. Because Charlie is offline, the storing AS intercepts the INVITE request and establishes the session. Then, Charlie stores two messages in Charlie's account using MSRP SEND requests (flow 5 and 7, containing Text # 2 and Text # 3, respectively). That is, actual messages are sent with MSRP SEND requests. Message # 9 is a SIP BYE request that ends the instant message session.

[0045] Later, Charlie connects to the network and subscribes to message summary notifications by sending a SIP SIGN UP request (message # 11) towards his mail server, i.e. the AS storing the message.

[0046] Notifications are included in the NOTIFY request (message # 13). These notifications, which the user retrieves from subscribing to the event package, message summary and message waiting indicator contain, amongst other elements, a unique identifier for each message in the Message-ID header format. The mail server selects a Message-ID for each message. During typical mapping, the Message-ID in the notification may contain the same value as the Call-ID header field in SIP MESSAGE or SIP INVITE requests (which started the MSRP session) or the Message-ID in the notification may contain the same value as the Message-ID header field in the MSRP SEND request. After Charlie selects the message to download, he creates an INVITE request (message # 15) addressed to the specific message to download.

[0047] There are two alternative and similar implementations of the examples of the first embodiment:

Implementation example A:

[0048] The mail server copies the Call-ID header field contained in the SIP to the MessageID header of the message summary or copies the Message-ID header of the MSRP SEND request to the Message-ID header of the message summary. Thus, each stored SIP

MESSAGE, a full MSRP session (which was initiated by SIP INVITE) or a single MSRP SEND request is uniquely identified by Message-ID. Now, when the user selects a specific message to retrieve from the message summary, the stored message is assigned a unique SIP URI, which is built on the Message-ID header in the message summary.

[0049] This allows messages to be downloaded one after the other as if they were being stored with a MESSAGE SIP request. If the messages were stored with the set of MSRP SEND requests (in the INVITE-BYE session), this solution allows you to download either all MSRP messages that were part of the session identified by the Call-ID SIP INVITE or each individual MSRP SEND stored request.

[0050] The following is an example of a notification about the summary of messages that user B receives. The notification indicates that two new text messages are waiting to be downloaded.

NOTIFY sip:<a href="mailto:charlie@pc.example.com">charlie@pc.example.com</a> SIP / 2.0 To: <sip: charlie@example.com>; tag = 78923 From: <sip: mailserver.example.com>; tag = 4442 Date: Mon, 10 Jul 2000 04:28:53 GMT Contact: <sip : mailserver.example.com>

Call-ID: adsf0923jsdjw

CSeq: 31 NOTIFY

Event: summary-messages

Registration-status: active

Content Type: application / simple-summary-news Length-Content: 503

Messages-Waiting: yes

Message-Account: sip:<a href="mailto:charlie@mailserver.example.com">charlie@mailserver.example.com</a>

Text-Message: 2/0 (1/0)

To: <<a href="mailto:charlie@example.com">charlie@example.com</a>>

From: <<a href="mailto:alice@example.org">alice@example.org</a>>

Subject: are we driving together tomorrow?

Date: Sun, 09 Jul 2000 21:23:01 -0700

Priority: normal

- 9 Message-ID: <a href="mailto:32098d@alicepc.example.org">32098d@alicepc.example.org</a>

To: <<a href="mailto:charlie@example.com">charlie@example.com</a>>

From: <<a href="mailto:bob@example.com">bob@example.com</a>>

Subject: HELP! Sick at home, make a presentation for me please Date: Sun, 09 Jul 2000 21:25:12 -0700 Priority: urgent

Message-ID: d0982dkjs@bobmobile.example. com [0051] It is assumed that Charlie only wants to download the second message that was sent by<a href="mailto:bob@example.com">bob@example.com</a> and is identified by the Message-ID header value of <a href="mailto:d0982dkjs@bobmobile.example.com">d0982dkjs@bobmobile.example.com</a>. Charlie then creates a SIP INVITE request addressed to the SIP URI (whose general format is "sip: username @ hostname") made as follows:

- the output value of the selected Message-ID as the username in the URI

- The hostname of the mail server (this is usually configured earlier in the SIP User Client).

[0052] That is, a user (e.g., Charlie) maps the unique identifier of the stored instant message to a qualifying identifier for downloading.

[0053] Continuing our example, Charlie creates a SIP INVITE request (e.g., message # 15 in Fig. 4) whose URI-Request is:

sip: d0982dkjs 40bobmobile.example%. <a href="mailto:com@mailserver.example.com">com@mailserver.example.com</a> [0054] "% 40" is an encoded symbol corresponding to the "@" sign (this is standard practice in SIP).

[0055] For example, the user (i.e., Charlie) will send the following INVITE (only relevant headers are printed) to the voicemail server (AS storing messages) in message # 15.

INVITE sip: d0982dkjs%<a href="mailto:40bobmobile.example.com@mailserver.example.com">40bobmobile.example.com@mailserver.example.com</a> SIP / 2.0 From: <sip:<a href="mailto:charlie@example.com">charlie@example.com</a>>

To: <sip: d0982dkjs% 40bobmobile.example. com@mailserver.exampl e.com>

[0056] This INVITE request is redirected to the mail server (AS storing messages) according to the usual SIP procedures. The mail server retrieves the "username", retrieves it to obtain the original message ID, retrieves this message and sends it to Charlie. To this end, the mechanism described in the provisional patent application "Method and Apparatus for Instant Messaging" can be used.

[0057] For example, the storing AS takes the stored # 3 SIP INVITE message in Fig. 4, stored # 5 and # 7 MSRP SEND requests and stored # 9 SIP BYE message and encapsulates them in the MSRP SEND request (not shown) also

- 10 message type set to message / sip (Paragraph 27.5 RFC 3261) or message / sipfrag (RFC 3420).

Example of implementation B:

[0058] The implementation is essentially the same as A. The only difference is that the mail server fills the Message-ID header not the value of the Call-ID SIP MESSAGE or INVITE header that stored the instant message, but a unique URI that points to the mail server and identifies the message.

[0059] For example, below is the same NOTIFY request as indicated in embodiment A, but modified to implement example B:

NOTIFY sip:<a href="mailto:charlie@pc.example.com">charlie@pc.example.com</a> SIP / 2.0 To: <sip: charlie@example.com>; tag = 78923 From: <sip: mailserver.example.com>; tag = 4442 Date: Mon, 10 Jul 2000 04:28:53 GMT Contact: <sip : mailserver.example.com>

Call-ID: adsf0923jsdjw

CSeq: 31 NOTIFY

Event: summary-messages

Registration-status: active

Content Type: application / simple-summary-news Length-Content: 503

Messages-Waiting: yes

Message-Account: sip:<a href="mailto:charlie@mailserver.example.com">charlie@mailserver.example.com</a>

Text-Message: 2/0 (1/0)

To: <<a href="mailto:charlie@example.com">charlie@example.com</a>>

From: <<a href="mailto:alice@example.org">alice@example.org</a>>

Subject: are we driving together tomorrow?

Date: Sun, 09 Jul 2000 21:23:01 -0700

Priority: normal

Message-ID: <a href="mailto:120932@mailserver.example.com">120932@mailserver.example.com</a>

To: <<a href="mailto:charlie@example.com">charlie@example.com</a>>

From: <<a href="mailto:bob@example.com">bob@example.com</a>>

Subject: HELP! Ill at home, make a presentation for me please

Date: Sun, 09 Jul 2000 21:25:12 -0700

Priority: urgent

Message-ID: <a href="mailto:120933@mailserver.example.com">120933@mailserver.example.com</a> [0060] So, if Charlie wants to download the same second message provided by

Bob will create an INVITE request addressed to the Message-ID value assigned by

- 11 mail server for this message, which uniquely identifies the message on the server. In this alternative, there is no need to translate the received Message-ID into something else, before creating the SIP MESSAGE URI Request, i.e., the Message-ID value of the message to be downloaded is copied to the SIP Request-URI.

INVITE sip:<a href="mailto:120933@mailserver.example.com">120933@mailserver.example.com</a> SIP / 2.0 From: <sip:<a href="mailto:charlie@example.com">charlie@example.com</a>>

To: <sip:<a href="mailto:120933@mailserver.example.com">120933@mailserver.example.com</a>>

Second Embodiment [0061] As in the above, it is assumed that the user has been offline for some time and other users have stored one or more instant messages in the AS storing messages, usually using a SIP connection (session initiation protocol, RFC 3261) and MSRP (Message Session Relay Protocol, Internet-Draft draftietfsimple- message-sessions-12.txt) as protocols. When the user is online (connected to the network), the user can download all stored instant messages, e.g. by using the mechanisms described in the temporary patent application "Method and Apparatus for Instant Messaging". Still, this mechanism works for ALL stored instant messages.

[0062] The first embodiment described above allows the user to select either one and only one instant message to download (if the message was delivered with a SIP MESSAGE request), one and only one instant message session (if it were stored using SIP INVITE and several SEND requests MSRP) or one and only one MSRP SEND message. The mechanism is problematic if the user wants to download more than one instant message or more than one instant message session or more than one (but not all) MSRP SEND message belonging to the same session, because for each download action the user must establish a separate SIP session ( i.e. the user must send a separate SIP INVITE request) to the mail server.

[0063] This clearly presents problems, especially in a mobile environment. On the one hand, this creates delays between consecutive downloaded messages in connection with an additional 1.5 activities (INVITE-200-ACK) for the flow of signals. In addition, each of these INVITE requests can contain a large number of headers, so the number of bytes transferred between the user's client and the mail server is not negligible. [0064] According to a second embodiment of the invention, it is assumed that:

- Instant messages addressed to a specific user can be stored on the mail server

- There is a mechanism in place by which the user is informed about the summary of instant messages awaiting download. The mechanism contains a unique identifier for each message on the mail server. An example of such a mechanism is described in RFC 3842 "Event Package Summary

- 12 Messages and Pending Message Indication for Session Initiation Protocol (SIP) ".

- There is a mechanism that allows the user to map the unique identifiers of stored instant messages to the qualifying identifier for download. An example of such a mechanism is described in the first embodiment.

- There is a mechanism by which the user can set up a session to download one or more instant messages. An example of such a mechanism is described in the provisional patent application "Method and Apparatus for

Instant Messaging. "

[0065] According to a second embodiment, the AS storing the messages or the mail server is modeled as a virtual unit comprising:

- URI-list explorer server for SIP INVITE transactions, also known as a conference server according to "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", draft-ietf-sipping-uri-list-conferencing-03. txt, the content of which is incorporated herein by reference.

- One or more virtual SIP User Clients, also contained on the mail server. Each of these virtual SIP User Clients represents a resource that in the case of the invention is an effectively stored instant message or instant messaging session. A characteristic feature is that each instant message or instant messaging session is identified by a unique uniform resource identifier (URI).

[0066] Fig. 5 schematically illustrates a mail server host model (instant messaging server) integrating a conference server and a series of virtual SIP User Clients, each representing a stored instant message.

[0067] Fig. 6 is a signal diagram showing the messages exchanged between the user and the instant messaging server according to the second embodiment.

[0068] After modeling the mail server as indicated, when a user wants to download a set of stored instant messages by establishing a single SIP session, the user's client sends a single SIP INVITE request (message # 1) which contains two message contents: Session Description Protocol (RFC 2327) to establish an instant message session and URI-list (as indicated in draft-ietf-sippinguri- listconferencing-03.txt). SDP indicates readiness to establish at least an MSRP-based message stream (draft-ietf-simple-message-sessions-12.txt). The URI-list contains one or more URIs, each of which uniquely identifies stored instant messages on the server that the user wants to download.

- 13 The mail server responds with a 200 OK reply (message # 2) which contains an SDP indicating an MSRP based message media stream.

[0069] Upon receiving such an INVITE request, the conference server that is part of the mail server sends an INVITE request to each of the virtual SIP User Clients that identify the stored message. The conference server sends an INVITE request that contains an SDP to each of the URIs indicated on the INVITE incoming URI list. In other words, the mail server's conference server sends an INVITE request to each of the URIs that are on the INVITE URI list (# 1). These are INVITE # 4, # 5 and # 6 requests in Fig. 6. Each contains SDP content that indicates readiness to establish at least one message stream of media based on MSRP.

[0070] This creates a virtual, centralized conference between the end user and each of the virtual clients of the SIP User that identifies the message. Then, each of these SIP User virtual clients sends a stored instant message to the conference server, which in turn forwards it to the end user. In other words, virtual SIP User Customers respond with 200 OK messages containing their own SDP (messages # 7, # 8, and # 9 in Fig. 6), and then send stored messages (or instant messaging sessions), e.g. by using procedures indicated in the provisional patent application "Method and Apparatus for Instant Messaging" (this corresponds to the other messages from # 13 to # 24 in Fig. 6).

[0071] In particular, any virtual SIP user may take stored MESSAGE, retain relevant SIP MESSAGE request headers (e.g., From, To, Call-ID, P-Asserted-Identity, etc.), encapsulate it or as a message / sip (Paragraph 27.5 RFC 3261) or message / sipfrag (RFC 3420) and send it as the content of the MSRP SEND request (messages # 13, # 17, # 21 in Fig. 6).

[0072] Similarly, each of the virtual SIP user clients may take a second stored SIP INVITE message, corresponding to stored MSRP SEND requests and corresponding corresponding SIP BYE message, and encapsulate them in another MSRP SEND request (messages # 13, # 17, # 21), with the message type set to message / sip or message / sipfrag. Similarly, any SIP user virtual client can take the stored MSRP SEND request, encapsulate it as message / msrp and send it as the content of the MSRP SEND request (# 13, # 17, # 21).

[0073] The invention includes all possible combinations and permutations. For example, an MSRP SEND # 13 request can encapsulate a stored MSRP SEND request, while an MSRP SEND # 15 request can encapsulate a SIP MESSAGE request, or an MSRP SEND # 17 request can encapsulate a SIP INVITE request that contains all MSRP SEND requests sent as part of a session and SIP BYE request.

[0074] After the virtual SIP UA delivers its stored instant message to the server, it sends a BYE request (message # 25, # 2 7 and # 29 in Fig. 6) to the conference server to terminate the session. After disconnecting the last virtual SIP

- 14 UA, the conference server sends a BYE request (message # 31) to the user to terminate the session.

[0075] Finally, the end user downloaded a set of stored instant messages in one signal session.

[0076] It should be noted that the server in question is composed of a conference server and a series of virtual SIP User Clients, each representing a stored instant message. A monolithic implementation of the mail server is being considered, which is spread out for better understanding. Still, this does not impose implementation restrictions, and by implementing you can decide to separate the mail server components into different hosts. In this case, the term "mail server" used refers to the set of these hosts.

[0077] It should also be noted that in the case of a monolithic implementation of the mail server, the interfaces defined between the conference server and each of the virtual clients of the SIP User become internal choices or a specific API but do not necessarily have to be implemented using SIP.

[0078] It should be emphasized that embodiments of the invention also apply to the offline push message delivery mechanism. In push delivery systems, the application storage server knows when the offline user returns online, i.e. either through SIP SUBSCRIBE / NOTIFY and / or any other mechanism.

[0079] It should be understood that the above description only represents the invention and should not be construed as limiting the invention. Various modifications and uses may occur to those skilled in the art without departing from the scope of the invention as set out in the appended claims.

Prepared and verified

Anna Stenzel Patent Attorney