Title of Invention	SYSTEM AND METHOD FOR LABEL KEY MESSAGES
Abstract	The present invention relates to the field of telecommunication networks. More specifically, the invention is related to SIP (Session Initiation Protocol) based messaging applications. The invention describes a method for allowing users to label the key messages of the conversation. These labels which identify the key messages are stored in the history metadata of the conversation file The user may search the conversations stored on the server to identify the labeled messages and download only those key messages. The method can also be used by the user to delete the irrelevant portion of the conversation with only the labeled portion left intact.

Title of Invention

SYSTEM AND METHOD FOR LABEL KEY MESSAGES

Abstract

The present invention relates to the field of telecommunication networks. More specifically, the invention is related to SIP (Session Initiation Protocol) based messaging applications. The invention describes a method for allowing users to label the key messages of the conversation. These labels which identify the key messages are stored in the history metadata of the conversation file The user may search the conversations stored on the server to identify the labeled messages and download only those key messages. The method can also be used by the user to delete the irrelevant portion of the conversation with only the labeled portion left intact.

Full Text	FIELD OF THE INVENTION The present invention, in general, relates to various SIP (Session Initiation Protocol) based applications such as Instant Messaging, Push to talk over Cellular, and any other future applications like Converged IP Messaging (CPM). More particularly, the present invention relates to those applications where a User is allowed to store/retrieve or manipulate messages stored on a network. More particularly, the present invention relates to a method to label key messages of a conversation so that they can be selectively retrieved/deleted later. DESCRIPTION OF RELATED ART The present invention proposes a mechanism to label key messages in a conversation history that are stored in the Server in the context of SIP (Session Initiation Protocol) based messaging applications such as IM, PoC, CPM etc. At present, various messaging applications allow a user to store a copy of the conversation on the network. Storage on the Server is usually enabled by a User configured service setting to always store conversations or a User initiated request to store a particular conversation. The User can also stop recording at any time when the recording is in-progress. The User is then allowed to retrieve and manage (e.g. get descriptive information about conversations, delete conversations etc) the stored conversation. Usually, in order to retrieve a stored conversation. User first gets the descriptive information, i.e. metadata about the stored conversation, which could contain for example from, to, time-stamp (element representing the creation time of the message), etc as described in OMA developed SIMPLE IM XDM 1.0 specification. Descriptive information about the stored conversation helps the User to identify the right conversation to be retrieved or referred to. Once identified the conversation, the User can then retrieve it entirely on his device. Existing art for conversation history: 1. Start recording by default setting: Server provides placeholder for User's default setting whether turning on conversation recording. User can change the value of this setting via various methods, for e.g., SIP PUBLISH method or XCAP method. When the User has requested for default setting - which stands for recording of all conversation - all messages coming to the User are recorded by the Server until the User cancels the default recording request/setting or on some Server error condition like when the User has reached his/her server storage limit for conversation recording, etc. The methods are described in OMA developed SIMPLE IM 1.0 specifications. 2. Start recording by on-demand User directive: User need not record all the conversations by default. Instead the on-demand User directive allows User to request the recording, on-demand, during the conversation. User can issue such request via various methods during the conversation (e.g., SIP INVITE/REFER methods). These methods are described in OMA developed SIMPLE IM 1.0 specifications. 3. Stop recording by on-demand User directive: A User can stop recording of the conversation anytime he/she wants, but the recording done till that point will be stored in the Server. User can issue such requests via e.g., SIP BYE method. Upon the termination of recording, the Sever would generate the metadata related about the conversation stored on the Server. The concerned methods are described in OMA developed SIMPLE IM 1.0 specifications. 4. Stop recording at the end of conversation: If there is no on-demand User directive to stop recording during the conversation, the recording of conversation will be automatically stopped at the end of conversation. Upon the termination of recording, the Sever would generate the metadata related about the conversation stored on the Server. The related methods are described in OMA developed SIMPLE IM 1.0 specifications. 5. Stop recording when the system limit reached: If there is no on-demand User directive to stop recording during the conversation and User's storage box becomes full on the Server, then Server may stop recording after issuing a notification or warning to the user stating that the storage box on the Server is full. Also, upon the termination of recording, the Sever would generate the metadata related about the conversation stored on the Server. The concerned methods are described in detail in the OMA developed SIMPLE IM 1.0 specifications. Server action followinp the request to store conversation: Each time the Server receives a SIP message or a media session to be stored, the Server will, 1. In case of pager mode messages, it stores the complete messages including all the header fields and bodies of the SIP request. 2. in the case of media session, it stores: a. all relevant headers of the SIP session establishment and termination. b. complete contents of the media session including headers. 3. Assigns a unique conversation history reference for each stored message, e.g., in the form of unique message id. 4. Stores the conversation history in the user's account on the Server. 6. Generates the metadata associated with the stored conversation and stores. The more such details are d^scribed in OMA developed SIMPLE IM 1.0 specifications. An example of such metadata structure is shown as below: Metadata of the conversation history which may be stored on the server will contain descriptive information regarding the conversation. OMA developed SIMPLE IM XDM 1.0 specification describes the metadata in detail. Metadata generally consists of elements like (size of the saved content), (the date at which the history expires), (representing the subject header in original message), (start time of the saved history), (end time of the saved history), (user provided name for the recorded conference) etc., along with element with attribute "history-reference" (the complete path and unique identifier of the actual history content). LIMITATIONS Currently, OMA developed enablers do not support content based search over the stored conversations. User has to make a guess on the stored conversation in order to retrieve any interested part of the conversation. Also User may have to retrieve the entire stored conversation though User may be interested only in part of the stored conversation. In other words, the User experiences high latency while retrieving stored conversation as the entire conversation has to be retrieved. Also, the overall User experience with this kind of approach is poor. ■ That is, with the present technology, it is not possible to do content search over the stored conversation. ■ Even if content search is supported in future o Content search done in order to retrieve a particular information from storage is complex and costly o Content search and retrieve is slower. o User has to retrieve entire stored conversation even if User is interested in part of the stored conversation. o It amounts to poor user experience. In the state of the art literature, the patent titled 'System and method for queuing and book marking telephony conversations' (US Patent Office Publication No. US20040203621A1) describes a system and method for querying and book marking telephony conversations. According to the invention, the users issue commands to insert bookmarks into the audio recording, the textual recording, or both, either during the live conference or during later playback. A user can issue these commands by voice or by sending data (for example, text) through the user's device. The commands may also be issued by software running on the user's device. The user can also add, modify, and delete bookmarks and can provide a descriptive title for bookmarks. Further, as per the invention, bookmarks can be used to indicate important words or phrases, to mark changes in the subject of the conversation, etc. Bookmarks can be used by users to assist in the retrieval of information as well as by information processing software used to retrieve portions of stored conversations. Another patent, titled 'System and method for message storage assurance in a geographically distributed voice messaging system' (patent no. US20060002522A1) talks about a voice messaging system that comprises of a common message store, a local data store located remotely from the common message store, and a media server. The media server is operable to receive a call directed to a number serviced by the media server, prompt the user for a voice message, direct the voice message to the local data store for temporary storage, notify the common message store that the voice message is present in the local data store, respond to a request to transfer the voice message to the common message store, and direct the local data store to erase the message upon receipt of a communication from the common message store that the voice message was successfully saved. From the foregoing, it becomes obvious that even though the prior art literature does talks about the concept of attaching a bookmark/name/label to a key position in a recorded text/audio file, the use of metadata to identify conversations, and a method for temporarily storing an audio file before processing and sending a data file to be stored at common message storage, none explicitly mention any process or method for the retrieval of the key portion or of deletion of other parts of the recorded message. Also, the prior art falls silent in the areas of selectively labeling a 'message' or having labels as identifiable elements of metadata. The present invention tries to overcome the existing shortcomings in the prior art by proposing a system and method for labeling key messages of a stored conversation so that they can be selectively retrieved for reference/reading later. It also lets the user delete the irrelevant portions of the conversation, leaving only the labeled portion intact. SUMMARY OF THE INVENTION It is therefore the primary object of the present invention to let the user label key messages of a stored conversation so that they can be selectively retrieved for reference/reading later. It is another object of the invention to let a user delete the irrelevant portions of the stored conversation, leaving only the labeled portion intact. It is a further object of the invention to eliminate the need for extensive content search in stored history in order to retrieve information. It is yet another object of the invention to propose a cost effective method to label key messages of a stored conversation. It is a further object of the invention to provide a faster mechanism for content search and retrieval. It is also object of the invention to let users delete selected parts of the stored conversation. Accordingly, the present invention proposes a method to label key messages of an ongoing conversation by the user so that they can be selectively retrieved for reference/reading later or deleted from the server, the method comprising, • Requesting the creation of labels for key messages anytime by the user while the conversation recording is on (label marking); • Performing label abstraction by the application server at the end of storing conversation to identify the labeled messages; • Initiating a request to retrieve the stored history from the application server by the user; and • Returning the requested part of the stored history by the server. These and other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS Figure 1 illustrates the retrieval of the message with specific label from the stored history. BRIEF DESCRIPTION OF THE INVENTION The preferred embodiments of the present Invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description is not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However, in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. The present invention has the following highlights: a. It describes a mechanism to label key messages in a conversation history that are stored in the Server in the context of SIP based messaging applications like IM, PoC, CPM. In other words, this invention proposes a procedure for label marking. b. Procedure for label abstraction, c. Procedure for the retrieval of the labeled contents. a. Procedure for label marking A User can request to create label for key messages anytime while the conversation recording is on. Labels may span across a single message or a set of sequential messages or media. Label: "Start/End/none"; "label_name" Where Label header - existence says whether to start or end labeling messages If Label value is Start then the request is for labeling start of key message If Label value is End then the request is to end labeling of key message label_name parameter - Is for the name of the label User would want to have (labels could be one of the pre-defined ones) Method-1 and Method-2 explained below are applicable to the scenarios where the User and the Conferencing Server belong to the same network. The methods are also applicable to the Conferencing where MSRP is media session established. For the cases where User and Conferencing Server belong to different network is explained as Method-3 and Method-4. These methods are also applicable to scenarios where the User and the Conferencing Server belongs to the same network. Method-3 and Method-4 is independent of the type of media conferencing; i.e., whether it is MSRP, RTP etc. Methods explained below is applicable to conferencing where RTP media session is established. Method-1: Request via new MSRP header The present invention proposes a new 'Label' MSRP [IETF draft draft-ietf-simple-message-sessions] header in the format explained below, to the methods carrying the messages/media in the conversation. Since the target of the messages in the conversation are the end users, the 'Label' header field, which is intended only to the Server, is removed by the Server before relaying the message to the next entity. Create label request procedure can be demonstrated with MSRP [IETF draft draft-ietf-simple-message-sessions] message as an example below: 1. Example for request to begin label MSRP d93kswow SEND To-Path: msrp://friends.example.com:8888/9di4ea;tcp From-Path: msrp://charlie.example.com:7777/iau39;tcp Message-ID: 12339sdqwer Byte-Range: 1-106/106 Label: Start; alice_address Content-Type: text/html Alice can you give me your address please foobar d93kswow$ 2. Example for request to end label MSRP d94kswow SEND To-Path: msrp://friends.example.com:8888/9di4ea;tcp From-Path: msrp://charlie.example.com:7777/iau39;tcp Message-ID: 12339sdqwer Byte-Range: 1-106/106 Label: End; alice_address Content-Type: text/html Alice, thank you for your address foobar d93kswow$ Method-2: Request via new MSRP method Alternately, this invention proposes a new message request "STORE" when a User requests to create label. The request will be directed to the Server with details including label-start or label-end, label-name and the message ID. Unlike in Method-1, the target for new request is not end users and hence terminated at the Server. An example of the LABEL request with MSRP [IETF draft draft-ietf-simple-message-sessions] is as given below: 1. Example for request to begin label MSRP dkei38sd STORE To-Path: msrp://server.example.com:7777/iau39;tcp From-Path: msrp.V/chariie.example.com:8888/9di4ea;tcp Message-ID: 12339sdqwer Label: Start; aliceaddress dkei38sd$ 2. Example for request to end label MSRP dkei38sd STORE To-Path: msrp://server.example.com:7777/iau39;tcp From-Path: msrp://charlie.example.com:8888/9di4ea;tcp Message-ID: 12339sdqwer Label: end; alice_address dkei38sd$ "Label" header field's definitions remain the same as explained in the common section above. Upon receiving such a request, the Server stores Label information as a part of metadata along with corresponding message-IDs. Method-3 and Method-4: The User requested recording of the conversation and the Sever recording the conversation has a dialog created between them at the time the User requested recording of conversation. The same dialog can be used to send "Label" request to the Server that is recording the conversation. Thus Server knows to which conversation the Label has to be marked with. The request to "Label" can be for 'start' or 'end' as explained in the above chapters and the request contains the 'label name'. Label: "Start/End/none"; "label_name" Method-3 and Method-4 are independent of type of media conferencing i.e., whether it is MSRP, RTP etc. Method-3: Request via MESSAGE method In this invention, as an alternate method, the "Label: "Start/End /none"; "labelname" information can be carried in the SIP MESSAGE method header or in the body. Both begin label and end label requests are sent within the same dialog that exists between the User requesting for recording and the Server that is recording. The below example gives insight on how to request for Label marking. 1. Example for request to begin label in SIP MESSAGE header MESSAGE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP charlie.domain.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:[email protected];tag=49583 To: sip:[email protected] Call-ID: [email protected] CSeq: 1 MESSAGE Label: Start; alice_address Content-Type: text/plain Content-Length: 0 Similarly there can be request to end label in the SIP MESSAGE header. 2. Example for request to begin label in SIP MESSAGE body MESSAGE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP charlie.domain.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:[email protected];tag=49583 To: sip:[email protected] Call-ID: [email protected] CSeq: 1 MESSAGE Content-Type: application/vnd.example.label+xml Content-Length: x Similarly there can be request to end label in the SIP MESSAGE body. Method-4: Request via UPDATE method In this method, the "Label: "Start/End /none"; "label_name" information can be carried in the SIP UPDATE method header. Both begin label and end label requests are sent within the same dialog that exists between the User requesting for recording and the Server that is recording. The example below gives more insight on how to request for Label marking. 1. Example for request to begin label UPDATE sips:[email protected]/TCP SIP/2.0 Via: SIP/2.0/TLS charlie.example.com ;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob From: Alice ;tag=1928 Call-ID: [email protected] CSeq: 10197 UPDATE Contact: Label: start; alice_address Similarly, there can be several methods to mark start and end of labeling depending on the media type in the recording session. This invention does not restrict the invention to just MSRP and RTP media types, and similar such methods are applicable to other media types as well. Method-5: Request via RTCP message 0 12 3 01234567890123456 7 89012345678901 \|V=2\|P\| subtype \| PT=APP=204 i length \| + -+- + - + - + - + -+- + - + - + - + - + - + - + - +-4-1—+- + - + - + - + -+ - + - + - + - + - + - + - + - + - + - + 1 SSRC I 4._.)._ + _ + _ + _ + _+_4._-(-_ + _ + _ + _. + _ + _ + _-\|-_-\|-_ + _-)-_+_ + _ + _ + _ + _4-_ + _^__l-_-\|._.4-_ + _ + _ + I name (ASCII) I + _+_ + _ + _ + _ + _.(._4_ + _ + _-I-_-(-_4_f-- + _-,^4_-\|--f _ + _-!-_ f_ + _.\|-_-\|-_-)-_^_ + _ + _ + _4-_-^_ + i application-dependent data I Table 1: RTCP App message structure Subtype: This is used to Identify the App message P: The padding bit P SHALL be set to 0. Length: The length field in the RTCP header is the length of the packet in 32-bit words, not counting the first 32-bit word in which the length field resides. Name: The 4-byte ASCII string in the RTCP header SHALL be unique with respect to other APP packets that the application might receive. Application-dependent data: Application specific information. Table 1 show a basic RTCP APP message, which can be utilized for setting a Label for ongoing media transfer. RTP is used for continuous media transfer, so message identification has to be done using the timestamp attribute parameter as mentioned in Chapter b) below. This method extends RTCP APP message and proposes new APP message for setting the Label. Table 2 shows structure of the new Label APP message. 0 12 3 0123456 7 89012 3456789012345678901 +- + - + - + -+- + - + - + -f- + ~ + ~-f- + - + - + - + - + - + - + -+- + - + - + - + - + - + - + - + - + - + - + - + - + \|V=2\|P\|1 11111 PT=APP=2 04 I length \| +-+-+-+-+-+-+-4-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 SSRC of Client requesting Labeling Media Burst \| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-)-_+-+-+-+-+-+-+ I name=Application specific Name \| - I Time-stamp \| Time-stamp \| \| I = 103 I -length = 8 \| : : Time stamp value I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-4-+-+-+-+-+-+ ■ I Label - 111 I Option \| Length \| Label \| I I - Start/Stop I I : : Label ... I + - + - + - + - + - + - + - + - + - + - + - + --I-- + - + -+- + - + - + - + - + - + -+- + - + - + -+ - + - + - + - + - + - + Table 2: Structure for Label APP message Subtype: 11111, this will identify App message as Label App message. This is just an example but any value another than 11111 can be assigned to identify this as a Label App message SSRC: This is a SSRC value of Client who is requesting for the Labeling. Name: Any application specific name e.g. For PoC application we can have value as PoCI Time stamp: This field is used to indicate the time attribute. As described earlier, this attribute is used to identify the media time stamp parameter. First field value 103 is indicating the Time Stamp attribute. The Length value is utilized for the length of time stamp value. The actual time stamp value will be mentioned in the message. Label: This new field is used to set a Label for particular part of continuous media. First attribute value "111" will identify this as Label field. Option attribute: This attribute is used to tell Application Server to start labeling or to stop labeling. Length: This will indicate the total length of the Label field including label name. Label: This attribute will have the actual name of the label to be given to the part of continuous media When User wants to label some part of continuous media, Client sends a Label App message to Application Server. In the Label App message. Client will set "Option" attribute of Label field' to "Start" and mention the Label name to be given to that part of media. Client shall set the length field. When User wants to stop labeling. Client shall send the same Label App message with "Option" value set to "Stop". When Application Server receives a Label request message, Application Sen/er extracts the timestamp value, retrieve the Label name and then store the extracted information in the Meta data. Following the "Label" request received by the Server as explained in the above listed various Methods, the Server needs to act based on the type of media session. a.) If the media session is for MSRP Each time the Server receives the request to mark label 'start' or 'end', the Server notes the MSRP Message-ID with those labels. This information is used in creating the label abstraction metadata at the time of closing the recording session. (See the next section 'Procedure for label abstraction' for label abstraction metadata). The MSRP Message-ID that is corresponding to the time when the request to begin Label is received is stored in 'start-id' in the Label metadata. Similarly, the MSRP Message-ID that is corresponding to the time when the request to end Label is received is stored in 'end-id' in the Label metadata. b.) If the media session is for RTP Each time the Server receives the request to mark label, the Server notes the relative timestamp from the start point of start of recording itself. This information is used in creating the label abstraction metadata at the time of closing the recording session. (See the next section 'Procedure for label abstraction' for label abstraction metadata). The relative timestamp that is corresponding to the time when the request to begin Label is received is stored in 'start-time' in the Label metadata. Similarly, the relative timestamp that is corresponding to the time when the request to end Label is received is stored in 'end-time' in the Label metadata. b. Procedure for label abstraction: Once the User has made requests to mark labels to the messages that are being stored in the server, there needs a label abstraction method to identify those labeled messages. The label abstraction should contain the label name as requested by the User, and the start and end Message-IDs/Relative timestamp of the messages/media that are associated with the label. Message-IDs are always unique in a stored conversation for an MSRP Session and like wise the relative timestamp can be used in case of RTP Session. The Label Abstraction can be express in XML format. Such XML expressed Label Abstraction can be explained with an example as below but not restricted to exact syntax and is extendable based on the application suitability. A new element is defined representing that the saved history contains labels. element consists of one or more child elements representing name of the label provided by the User. In case of MSRP Media session, element: 1. Consists of attribute "start-id": representing start of the label. The value is taken from the "message-id" header field of the message at the time of receiving create label request. 2. May consist of attribute "end-id": representing end of the label. The value is taken from the "message-id" header field of the message at the time of receiving end label request. In case of RTP Media session, element: A) Consists of attribute "start-time": representing start of the label. The value is the relative timestamp created at the time of receiving begin label request to the time when the session begins. B) May consist of attribute "end-id": representing end of the label. The value is the relative timestamp created at the time of receiving end label request to the time when the session begins. Metadata of the conversation history which may be stored on the server will contain descriptive information regarding the conversation. Metadata as described in OMA developed SIMPLE IM XDM 1.0 specifications, generally consists of elements like (size of the saved content), (the date at which the history expires), (representing the subject header in original message), (start time of the saved history), (end time of the saved history), (user provided name for the recorded conference) etc., along with element with attribute "history-reference" (the complete path and unique identifier of the actual history content). The above described Label Abstraction can be placed as part of such conversation metadata. As a way of expressing Label Abstraction, this invention proposes to extend the existing metadata with the new element for "Label" as defined above. With this approach, element can be an immediate child element to element or at any other appropriate place of the element. The following is about how the Label Abstraction as above explained can be delivered to User: Label information is available to User as part of the metadata of the stored history. After the end of storing conversation, User can get the metadata of the stored conversation in many ways. One way is to retrieve those metadata by using XCAP GET or SIP SUBSCRIBE etc. The other way is to get notified of such metadata by Push mechanism such as WAP Push or SIP Push etc. Below example considers User client using XCAP GET method to retrieve the metadata of the stored message conversation. GET http;//xcap.example.com /services/org.openmobilealliance.history-list/users/sip:[email protected]/conv_history HTTP/1.1 Content-Length: 0 After the Server has performed the necessary authorization checks on the request originator, it sends an HTTP "200 OK" response including the metadata of the stored history with label information in the body. HTTP/1.1 200 OK Etag:"etu15" Content-Type: application/vnd.oma.history+xml 25 2006-08-16T15:05:00.0Z"friends" end-id=12359sdqwef> 2006-08-14T15:05:00.OZ 2006-08-14T15:15:00.OZ friends Charlie Joe Alice c. Procedure for the retrieval of the labeled contents: User may initiate a request to retrieve stored history with a SIP request like SIP INVITE or SIP REFER. The SIP request includes a list of message identities in the form of "URI-list" containing a list of message id's representing each stored history item i.e., the list of history reference(s). According to the definition in metadata explained above, history reference is the value of the "history-reference" attribute that identifies the stored history that the user wants to retrieve. With this type of SIP request User is able to retrieve entire stored history of a conference. If a User wishes to retrieve part of the stored history of a conference that has labels, the label name that represents the part that User is interested in need to be delivered along with the above-mentioned conversation history retrieval request. As a possible way, this invention proposes new attribute "label-name" which can be included along with the URI-list in the SIP request for conference history retrieval. The "label-name" attribute is containing the name of the label represented in element according to the definition in metadata explained above. This label name identifies the part of stored history that the user wants to retrieve. On receiving the SIP message requesting to retrieve part of the stored history, the Server needs to check if the "label-name" represented by the new attribute in the URI-list is a valid entry or not. In order to do that, the Server will first retrieve the history metadata including that contains the values in element. The Server then checks if the values that are contained in "start-id" and "end-id" are valid by searching for those ids in the corresponding content, if the Server does not find values in the content of the stored history, then the User is responded with appropriate SIP error response containing the warning header like "Not valid Label" etc else it is understood that the Server has found valid entry. If Server identifies that the value contained in new attribute is a valid entry, then the User is returned with the part of the stored history representing the value that are contained in element and not the entire stored history represented by "history-reference" attribute. User may initiate a request to delete stored history with a SIP request like SIP INVITE or SIP REFER as described in OMA developed SIMPLE IM 1.0 specifications. According to the definition in metadata explained above, history reference is the value in "history-reference" attribute that identifies the stored history that the user wants to delete. With this type of SIP request User is able to delete entire stored history of a conference. If a User wishes to delete portion of the stored history of a conference that is not labeled, this invention proposes new attribute "label-name" which can be included along with the URI-list. If Server identifies that the value contained in new attribute is a valid entry, then the Server retains portion of the stored history that is identified by the "label-name" and deletes the rest of the stored history. In another case the User may request to delete only the portion of stored history which is marked by the "label-name". It is assumed that users Alice, Joe and Charlie are in a conference. Refer Figure-1. 1. All users in the conference exchange series of messages. 2-3. Charlie decides to create label to a set of messages while exchanging messages during the conference. So Charlie initiates a request to Server for creating label indicating the start of label. Charlie receives acknowledge from the server. 4. Users in the conference continue exchanging messages and Server notes the message-ids of these messages for labeling.. 5-6. Charlie decides to stop labeling messages. So Charlie initiates a request to Server indicating to stop labeling. Charlie receives acknowledge from the server. 7. User continues to exchanges series of messages. Once the session is terminated, Server creates metadata for the history to be stored including the labels in the metadata. 8. The user Charlie wants to obtain the document describing the metadata about his stored conversations. GET http://xcap.example.com /services/org.openmobilealliance.history-list/users/sip:[email protected]/conv_history HTTP/1.1 Content-Length: 0 9. After the Server has performed the necessary authorization checks on the request originator, the Server sends an HTTP "200 OK" response including the requested document in the body. HTTP/1.1 200 OK Etag:"etu15" Content-Type: application/vnd.oma.history+xml 25 2006-08-16T15:05:00.OZ"friends" 2006-08-14T15:05:OO.OZ2006-08-14T15:15:00.0Z friends Gharlie Joe Alice 10-12. Let us assume that Charlie wants to retrieve only the messages that are under the label name "aliceaddress" Charlie then creates a SIP INVITE request INVITE sip:[email protected] SIP/2.0 From: To: Content-Type: multiparty/mixed; boundary = 'Boundary' Boundary Content-Type : application/Sdp Boundary Content-Type: application/resource-list+xml contain list of labels, in this example there will be only one entry i.e. the label name 'alice_address'. This INVITE request is routed to the Server according to SiP procedures. 13-14. The Server extracts the messages corresponding to label name "alice_address" and sends the stored messages to Charlie. 15-16. The Server sends SIP BYE and the corresponding 200 OK from the client to end the session ADVANTAGES ■ The invention overcomes the need for content search over huge content like stored history ■ Content search in order to retrieve a particular information from storage is easier with this invention and will be less expensive ■ Content search and retrieve is slower where as this invention will make it faster ■ Only part of the stored content that is necessary for the end user can be retrieved ■ Good user experience Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawing, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart there from. GLOSSARY OF TERMS AND DEFINITIONS THEREOF OMA - Open Mobile Alliance SIP - Session Initiation Protocol IM - Instant Messaging PoC - Push to Talk Over Cellular XML - Extended Markup Language XDM - XML Document Management XCAP - XML Configuration Access Protocol SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions CPM - Converged IP Messaging IETF - The Internet Engineering Task Force RFC - Request For Comments We Claim 1. A method to label key messages of an ongoing conversation by the user so that they can be selectively retrieved for reference/reading later or deleted from the server the method comprising, • Requesting the creation of labels for key messages anytime by the user while the conversation recording is on (label marking); • Performing label abstraction by the application server at the end of storing conversation to identify the labeled messages; • Initiating a request to retrieve the stored history from the application server by the user; and • Returning the requested part of the stored history by the server. 2. The method as claimed in claim 1, wherein the labels may span across a single message or a set of sequential messages or media. 3. The method as claimed in claim 1, wherein the user and the conferencing server may be in the same network or different networks. 4. The method as claimed in claim 1, wherein, in conferences where MSRP is media session enabled, the label requests are sent through MSRP header/method. 5. The method as claimed in claim 1, wherein the request for label is sent as part of the dialog created between the User requested recording of the conversation and the Sever recording the conversation at the time of the User requested recording of the conversation. 6. The method as claimed in claim 5, wherein it is independent of the type of media conferencing. 7. The method as claimed in claim 1, wherein separate requests are sent to the server to 'start' and 'end' labeling of a conversation. 8. The method as claimed in claim 1, wherein a Label APP message is used for setting the label in case of continuous media transfer. 9. The method as claimed in claim 8, wherein the Label APP message is the extension of RTCP APP message. 10.The method as claimed in claim 8, wherein the server acts on the label requests based on the type of media session. 11. The method as claimed in claim 1, wherein the label abstraction is expressed as an extension of the Metadata of the conversation history stored in the server. 12. The method as claimed in claim 1, wherein the label abstraction contains the label name as requested by the User, and the start and end Message-IDs/Relative timestamp of the messages/media that are associated with the label. 13. The method as claimed in claim 1, wherein the metadata of the stored history is retrieved using XCAP GET or SIP SUBSCRIBE methods, or through Push mechanism such as WAP Push or SIP Push etc. 14. The method as claimed in claim 1, wherein the retrieval of the stored data is achieved through a SIP request (SIP INVITE/SIP REFER). 15.The method as claimed in claim 14, wherein the SIP request contains a list of message identities in the form of "URI-list", which includes a list of message id's representing each stored history item. 16. The method as claimed in claim 14, wherein the retrieval of a part of the stored data is achieved by specifying an additional attribute - 'label name' J - in the SIP request. 17.The method as claimed in claim 16, wherein the server sends the requested content to the user only if the label name' is a valid entry. 18.The method as claimed in claim 16, wherein a user can opt to delete selected parts of the conversation history identified by the 'label name' attribute. 19. A method to label key messages of an ongoing conversation by the user so that they can be selectively retrieved for reference/reading later or deleted from the server, substantially as herein described with respect to the accompanying drawings.

Full Text

FIELD OF THE INVENTION
The present invention, in general, relates to various SIP (Session Initiation Protocol) based applications such as Instant Messaging, Push to talk over Cellular, and any other future applications like Converged IP Messaging (CPM). More particularly, the present invention relates to those applications where a User is allowed to store/retrieve or manipulate messages stored on a network. More particularly, the present invention relates to a method to label key messages of a conversation so that they can be selectively retrieved/deleted later.
DESCRIPTION OF RELATED ART
The present invention proposes a mechanism to label key messages in a conversation history that are stored in the Server in the context of SIP (Session Initiation Protocol) based messaging applications such as IM, PoC, CPM etc.
At present, various messaging applications allow a user to store a copy of the conversation on the network. Storage on the Server is usually enabled by a User configured service setting to always store conversations or a User initiated request to store a particular conversation. The User can also stop recording at any time when the recording is in-progress. The User is then allowed to retrieve and manage (e.g. get descriptive information about conversations, delete conversations etc) the stored conversation. Usually, in order to retrieve a stored conversation. User first gets the descriptive information, i.e. metadata about the stored conversation, which could contain for example from, to, time-stamp (element representing the creation time of the message), etc as described in OMA developed SIMPLE IM XDM 1.0 specification. Descriptive information about the stored conversation helps the User to identify the right conversation to be retrieved or referred to. Once identified the conversation, the User can then retrieve it entirely on his device.

Existing art for conversation history:
1. Start recording by default setting:
Server provides placeholder for User's default setting whether turning on conversation recording. User can change the value of this setting via various methods, for e.g., SIP PUBLISH method or XCAP method. When the User has requested for default setting - which stands for recording of all conversation - all messages coming to the User are recorded by the Server until the User cancels the default recording request/setting or on some Server error condition like when the User has reached his/her server storage limit for conversation recording, etc. The methods are described in OMA developed SIMPLE IM 1.0 specifications.
2. Start recording by on-demand User directive:
User need not record all the conversations by default. Instead the on-demand User directive allows User to request the recording, on-demand, during the conversation. User can issue such request via various methods during the conversation (e.g., SIP INVITE/REFER methods). These methods are described in OMA developed SIMPLE IM 1.0 specifications.
3. Stop recording by on-demand User directive:
A User can stop recording of the conversation anytime he/she wants, but the recording done till that point will be stored in the Server. User can issue such requests via e.g., SIP BYE method. Upon the termination of recording, the Sever would generate the metadata related about the conversation stored on the Server. The concerned methods are described in OMA developed SIMPLE IM 1.0 specifications.

4. Stop recording at the end of conversation:
If there is no on-demand User directive to stop recording during the conversation, the recording of conversation will be automatically stopped at the end of conversation. Upon the termination of recording, the Sever would generate the metadata related about the conversation stored on the Server. The related methods are described in OMA developed SIMPLE IM 1.0 specifications.
5. Stop recording when the system limit reached:
If there is no on-demand User directive to stop recording during the conversation and User's storage box becomes full on the Server, then Server may stop recording after issuing a notification or warning to the user stating that the storage box on the Server is full. Also, upon the termination of recording, the Sever would generate the metadata related about the conversation stored on the Server. The concerned methods are described in detail in the OMA developed SIMPLE IM 1.0 specifications.
Server action followinp the request to store conversation:
Each time the Server receives a SIP message or a media session to be stored, the Server will,
1. In case of pager mode messages, it stores the complete messages including all the header fields and bodies of the SIP request.
2. in the case of media session, it stores:
a. all relevant headers of the SIP session establishment and
termination.
b. complete contents of the media session including headers.
3. Assigns a unique conversation history reference for each stored message, e.g., in the form of unique message id.
4. Stores the conversation history in the user's account on the Server.

6. Generates the metadata associated with the stored conversation and stores.
The more such details are d^scribed in OMA developed SIMPLE IM 1.0 specifications.
An example of such metadata structure is shown as below:
Metadata of the conversation history which may be stored on the server will contain descriptive information regarding the conversation. OMA developed SIMPLE IM XDM 1.0 specification describes the metadata in detail. Metadata generally consists of elements like (size of the saved content), (the date at which the history expires), (representing the subject header in original message), (start time of the saved history), (end time of the saved history), (user provided name for the recorded conference) etc., along with element with attribute "history-reference" (the complete path and unique identifier of the actual history content).
LIMITATIONS
Currently, OMA developed enablers do not support content based search over the stored conversations. User has to make a guess on the stored conversation in order to retrieve any interested part of the conversation. Also User may have to retrieve the entire stored conversation though User may be interested only in part of the stored conversation. In other words, the User experiences high latency while retrieving stored conversation as the entire conversation has to be retrieved. Also, the overall User experience with this kind of approach is poor.
■ That is, with the present technology, it is not possible to do content search over the stored conversation.
■ Even if content search is supported in future

o Content search done in order to retrieve a particular information from storage is complex and costly
o Content search and retrieve is slower.
o User has to retrieve entire stored conversation even if User is interested in part of the stored conversation.
o It amounts to poor user experience.
In the state of the art literature, the patent titled 'System and method for queuing and book marking telephony conversations' (US Patent Office Publication No. US20040203621A1) describes a system and method for querying and book marking telephony conversations. According to the invention, the users issue commands to insert bookmarks into the audio recording, the textual recording, or both, either during the live conference or during later playback. A user can issue these commands by voice or by sending data (for example, text) through the user's device. The commands may also be issued by software running on the user's device. The user can also add, modify, and delete bookmarks and can provide a descriptive title for bookmarks. Further, as per the invention, bookmarks can be used to indicate important words or phrases, to mark changes in the subject of the conversation, etc. Bookmarks can be used by users to assist in the retrieval of information as well as by information processing software used to retrieve portions of stored conversations.
Another patent, titled 'System and method for message storage assurance in a geographically distributed voice messaging system' (patent no. US20060002522A1) talks about a voice messaging system that comprises of a common message store, a local data store located remotely from the common message store, and a media server. The media server is operable to receive a call directed to a number serviced by the media server, prompt the user for a voice message, direct the voice message to the local data store for temporary storage, notify the common message store that the voice message is present in the local data store, respond to a request to transfer the voice message to the common message store, and direct the local data store to erase the message

upon receipt of a communication from the common message store that the voice message was successfully saved.
From the foregoing, it becomes obvious that even though the prior art literature does talks about the concept of attaching a bookmark/name/label to a key position in a recorded text/audio file, the use of metadata to identify conversations, and a method for temporarily storing an audio file before processing and sending a data file to be stored at common message storage, none explicitly mention any process or method for the retrieval of the key portion or of deletion of other parts of the recorded message. Also, the prior art falls silent in the areas of selectively labeling a 'message' or having labels as identifiable elements of metadata.
The present invention tries to overcome the existing shortcomings in the prior art by proposing a system and method for labeling key messages of a stored conversation so that they can be selectively retrieved for reference/reading later. It also lets the user delete the irrelevant portions of the conversation, leaving only the labeled portion intact.
SUMMARY OF THE INVENTION
It is therefore the primary object of the present invention to let the user label key messages of a stored conversation so that they can be selectively retrieved for reference/reading later.
It is another object of the invention to let a user delete the irrelevant portions of the stored conversation, leaving only the labeled portion intact.
It is a further object of the invention to eliminate the need for extensive content search in stored history in order to retrieve information.
It is yet another object of the invention to propose a cost effective method to label key messages of a stored conversation.

It is a further object of the invention to provide a faster mechanism for content search and retrieval.
It is also object of the invention to let users delete selected parts of the stored conversation.
Accordingly, the present invention proposes a method to label key messages of an ongoing conversation by the user so that they can be selectively retrieved for reference/reading later or deleted from the server, the method comprising,
• Requesting the creation of labels for key messages anytime by the user while the conversation recording is on (label marking);
• Performing label abstraction by the application server at the end of storing conversation to identify the labeled messages;
• Initiating a request to retrieve the stored history from the application server by the user; and
• Returning the requested part of the stored history by the server.
These and other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 illustrates the retrieval of the message with specific label from the stored history.
BRIEF DESCRIPTION OF THE INVENTION
The preferred embodiments of the present Invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which

may be embodied in various forms. The following description is not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However, in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail.
The present invention has the following highlights:
a. It describes a mechanism to label key messages in a conversation
history that are stored in the Server in the context of SIP based
messaging applications like IM, PoC, CPM. In other words, this
invention proposes a procedure for label marking.
b. Procedure for label abstraction,
c. Procedure for the retrieval of the labeled contents.
a. Procedure for label marking
A User can request to create label for key messages anytime while the conversation recording is on. Labels may span across a single message or a set of sequential messages or media.
Label: "Start/End/none"; "label_name" Where
Label header - existence says whether to start or end labeling
messages If Label value is Start then the request is for labeling start of key message
If Label value is End then the request is to end labeling of key message
label_name parameter - Is for the name of the label User would want to have (labels could be one of the pre-defined ones)

Method-1 and Method-2 explained below are applicable to the scenarios where the User and the Conferencing Server belong to the same network. The methods are also applicable to the Conferencing where MSRP is media session established.
For the cases where User and Conferencing Server belong to different network is explained as Method-3 and Method-4. These methods are also applicable to scenarios where the User and the Conferencing Server belongs to the same network. Method-3 and Method-4 is independent of the type of media conferencing; i.e., whether it is MSRP, RTP etc.
Methods explained below is applicable to conferencing where RTP media session is established.
Method-1: Request via new MSRP header
The present invention proposes a new 'Label' MSRP [IETF draft draft-ietf-simple-message-sessions] header in the format explained below, to the methods carrying the messages/media in the conversation. Since the target of the messages in the conversation are the end users, the 'Label' header field, which is intended only to the Server, is removed by the Server before relaying the message to the next entity.
Create label request procedure can be demonstrated with MSRP [IETF draft draft-ietf-simple-message-sessions] message as an example below:
1. Example for request to begin label MSRP d93kswow SEND
To-Path: msrp://friends.example.com:8888/9di4ea;tcp From-Path: msrp://charlie.example.com:7777/iau39;tcp Message-ID: 12339sdqwer Byte-Range: 1-106/106 Label: Start; alice_address Content-Type: text/html

Alice can you give me your address please
foobar

d93kswow$
2. Example for request to end label
MSRP d94kswow SEND
To-Path: msrp://friends.example.com:8888/9di4ea;tcp
From-Path: msrp://charlie.example.com:7777/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-106/106
Label: End; alice_address
Content-Type: text/html

Alice, thank you for your address
foobar

d93kswow$
Method-2: Request via new MSRP method
Alternately, this invention proposes a new message request "STORE" when a User requests to create label. The request will be directed to the Server with details including label-start or label-end, label-name and the message ID. Unlike in Method-1, the target for new request is not end users and hence terminated at the Server.

An example of the LABEL request with MSRP [IETF draft draft-ietf-simple-message-sessions] is as given below:
1. Example for request to begin label
MSRP dkei38sd STORE
To-Path: msrp://server.example.com:7777/iau39;tcp
From-Path: msrp.V/chariie.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer
Label: Start; aliceaddress
dkei38sd$
2. Example for request to end label
MSRP dkei38sd STORE
To-Path: msrp://server.example.com:7777/iau39;tcp
From-Path: msrp://charlie.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer
Label: end; alice_address dkei38sd$
"Label" header field's definitions remain the same as explained in the common section above.
Upon receiving such a request, the Server stores Label information as a part of
metadata along with corresponding message-IDs.
Method-3 and Method-4:
The User requested recording of the conversation and the Sever recording the conversation has a dialog created between them at the time the User requested recording of conversation. The same dialog can be used to send "Label" request to the Server that is recording the conversation. Thus Server knows to which conversation the Label has to be marked with. The request to "Label" can be for

'start' or 'end' as explained in the above chapters and the request contains the 'label name'.
Label: "Start/End/none"; "label_name"
Method-3 and Method-4 are independent of type of media conferencing i.e., whether it is MSRP, RTP etc.
Method-3: Request via MESSAGE method
In this invention, as an alternate method, the "Label: "Start/End /none"; "labelname" information can be carried in the SIP MESSAGE method header or in the body. Both begin label and end label requests are sent within the same dialog that exists between the User requesting for recording and the Server that is recording. The below example gives insight on how to request for Label marking.
1. Example for request to begin label in SIP MESSAGE header
MESSAGE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP charlie.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:[email protected];tag=49583
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 1 MESSAGE
Label: Start; alice_address
Content-Type: text/plain
Content-Length: 0
Similarly there can be request to end label in the SIP MESSAGE header.
2. Example for request to begin label in SIP MESSAGE body
MESSAGE sip:[email protected] SIP/2.0

Via: SIP/2.0/TCP charlie.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:[email protected];tag=49583
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 1 MESSAGE
Content-Type: application/vnd.example.label+xml
Content-Length: x

Similarly there can be request to end label in the SIP MESSAGE body. Method-4: Request via UPDATE method
In this method, the "Label: "Start/End /none"; "label_name" information can be carried in the SIP UPDATE method header. Both begin label and end label requests are sent within the same dialog that exists between the User requesting for recording and the Server that is recording. The example below gives more insight on how to request for Label marking.
1. Example for request to begin label UPDATE sips:[email protected]/TCP SIP/2.0 Via: SIP/2.0/TLS charlie.example.com ;branch=z9hG4bK776asdhds Max-Forwards: 70
To: Bob From: Alice ;tag=1928 Call-ID: [email protected] CSeq: 10197 UPDATE

Contact: Label: start; alice_address
Similarly, there can be several methods to mark start and end of labeling depending on the media type in the recording session. This invention does not restrict the invention to just MSRP and RTP media types, and similar such methods are applicable to other media types as well.
Method-5: Request via RTCP message
0 12 3
01234567890123456 7 89012345678901
|V=2|P| subtype | PT=APP=204 i length |
+ -+- + - + - + - + -+- + - + - + - + - + - + - + - +-4-1—+- + - + - + - + -+ - + - + - + - + - + - + - + - + - + - +
1 SSRC I
4._.)._ + _ + _ + _ + _+_4._-(-_ + _ + _ + _. + _ + _ + _-|-_-|-_ + _-)-_+_ + _ + _ + _ + _4-_ + _^__l-_-|._.4-_ + _ + _ +
I name (ASCII) I
+ _+_ + _ + _ + _ + _.(._4_ + _ + _-I-_-(-_4_f-- + _-,^4_-|--f _ + _-!-_ f_ + _.|-_-|-_-)-_^_ + _ + _ + _4-_-^_ +
i application-dependent data I
Table 1: RTCP App message structure
Subtype: This is used to Identify the App message
P: The padding bit P SHALL be set to 0.
Length: The length field in the RTCP header is the length of the packet
in 32-bit words, not counting the first 32-bit word in which the length
field resides.
Name: The 4-byte ASCII string in the RTCP header SHALL be unique
with respect to other APP packets that the application might receive.
Application-dependent data: Application specific information.
Table 1 show a basic RTCP APP message, which can be utilized for setting a Label for ongoing media transfer. RTP is used for continuous media transfer, so message identification has to be done using the timestamp attribute parameter as mentioned in Chapter b) below. This method extends RTCP APP message

and proposes new APP message for setting the Label. Table 2 shows structure of the new Label APP message.
0 12 3
0123456 7 89012 3456789012345678901
+- + - + - + -+- + - + - + -f- + ~ + ~-f- + - + - + - + - + - + - + -+- + - + - + - + - + - + - + - + - + - + - + - + - +
|V=2|P|1 11111 PT=APP=2 04 I length |
+-+-+-+-+-+-+-4-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 SSRC of Client requesting Labeling Media Burst |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-)-_+-+-+-+-+-+-+
I name=Application specific Name |
- I Time-stamp | Time-stamp | |
I = 103 I -length = 8 | :
: Time stamp value I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-4-+-+-+-+-+-+
■ I Label - 111 I Option | Length | Label |
I I - Start/Stop I I :
: Label ... I
+ - + - + - + - + - + - + - + - + - + - + - + --I-- + - + -+- + - + - + - + - + - + -+- + - + - + -+ - + - + - + - + - + - +
Table 2: Structure for Label APP message
Subtype: 11111, this will identify App message as Label App message. This is just an example but any value another than 11111 can be assigned to identify this as a Label App message
SSRC: This is a SSRC value of Client who is requesting for the Labeling.
Name: Any application specific name e.g. For PoC application we can have value as PoCI
Time stamp:
This field is used to indicate the time attribute. As described earlier, this attribute is used to identify the media time stamp parameter. First field value 103 is indicating the Time Stamp attribute. The Length value is utilized for the length of time stamp value. The actual time stamp value will be mentioned in the message.

Label: This new field is used to set a Label for particular part of continuous media. First attribute value "111" will identify this as Label field.
Option attribute: This attribute is used to tell Application Server to start labeling or to stop labeling.
Length: This will indicate the total length of the Label field including label name.
Label: This attribute will have the actual name of the label to be given to the part of continuous media
When User wants to label some part of continuous media, Client sends a Label App message to Application Server. In the Label App message. Client will set "Option" attribute of Label field' to "Start" and mention the Label name to be given to that part of media. Client shall set the length field.
When User wants to stop labeling. Client shall send the same Label App message with "Option" value set to "Stop".
When Application Server receives a Label request message, Application Sen/er extracts the timestamp value, retrieve the Label name and then store the extracted information in the Meta data.
Following the "Label" request received by the Server as explained in the above listed various Methods, the Server needs to act based on the type of media session.
a.) If the media session is for MSRP
Each time the Server receives the request to mark label 'start' or 'end', the Server notes the MSRP Message-ID with those labels. This information is used in creating the label abstraction metadata at the time of closing the recording

session. (See the next section 'Procedure for label abstraction' for label abstraction metadata). The MSRP Message-ID that is corresponding to the time when the request to begin Label is received is stored in 'start-id' in the Label metadata. Similarly, the MSRP Message-ID that is corresponding to the time when the request to end Label is received is stored in 'end-id' in the Label metadata.
b.) If the media session is for RTP
Each time the Server receives the request to mark label, the Server notes the relative timestamp from the start point of start of recording itself. This information is used in creating the label abstraction metadata at the time of closing the recording session. (See the next section 'Procedure for label abstraction' for label abstraction metadata). The relative timestamp that is corresponding to the time when the request to begin Label is received is stored in 'start-time' in the Label metadata. Similarly, the relative timestamp that is corresponding to the time when the request to end Label is received is stored in 'end-time' in the Label metadata.
b. Procedure for label abstraction:
Once the User has made requests to mark labels to the messages that are being stored in the server, there needs a label abstraction method to identify those labeled messages. The label abstraction should contain the label name as requested by the User, and the start and end Message-IDs/Relative timestamp of the messages/media that are associated with the label. Message-IDs are always unique in a stored conversation for an MSRP Session and like wise the relative timestamp can be used in case of RTP Session.
The Label Abstraction can be express in XML format. Such XML expressed Label Abstraction can be explained with an example as below but not restricted to exact syntax and is extendable based on the application suitability.
A new element is defined representing that the saved history

contains labels. element consists of one or more child elements representing name of the label provided by the User.
In case of MSRP Media session, element:
1. Consists of attribute "start-id": representing start of the label. The value is taken from the "message-id" header field of the message at the time of receiving create label request.
2. May consist of attribute "end-id": representing end of the label. The value is taken from the "message-id" header field of the message at the time of receiving end label request.
In case of RTP Media session, element:
A) Consists of attribute "start-time": representing start of the label. The value is the relative timestamp created at the time of receiving begin label request to the time when the session begins.
B) May consist of attribute "end-id": representing end of the label. The value is the relative timestamp created at the time of receiving end label request to the time when the session begins.
Metadata of the conversation history which may be stored on the server will contain descriptive information regarding the conversation. Metadata as described in OMA developed SIMPLE IM XDM 1.0 specifications, generally consists of elements like (size of the saved content), (the date at which the history expires), (representing the subject header in original message), (start time of the saved history), (end time of the saved history), (user provided name for the recorded conference) etc., along with element with attribute "history-reference" (the complete path and unique identifier of the actual history content). The above described Label Abstraction can be placed as part of such conversation metadata. As a way of expressing Label Abstraction, this invention proposes to extend the existing metadata with the new element for "Label" as defined above.

With this approach, element can be an immediate child element to element or at any other appropriate place of the element.
The following is about how the Label Abstraction as above explained can be delivered to User:
Label information is available to User as part of the metadata of the stored history. After the end of storing conversation, User can get the metadata of the stored conversation in many ways. One way is to retrieve those metadata by using XCAP GET or SIP SUBSCRIBE etc. The other way is to get notified of such metadata by Push mechanism such as WAP Push or SIP Push etc.
Below example considers User client using XCAP GET method to retrieve the metadata of the stored message conversation.
GET http;//xcap.example.com
/services/org.openmobilealliance.history-list/users/sip:[email protected]/conv_history HTTP/1.1
Content-Length: 0
After the Server has performed the necessary authorization checks on the request originator, it sends an HTTP "200 OK" response including the metadata of the stored history with label information in the body.
HTTP/1.1 200 OK Etag:"etu15"
Content-Type: application/vnd.oma.history+xml

25
2006-08-16T15:05:00.0Z"friends"

end-id=12359sdqwef>

2006-08-14T15:05:00.OZ

2006-08-14T15:15:00.OZ

friends

Charlie

Joe

Alice

c. Procedure for the retrieval of the labeled contents:
User may initiate a request to retrieve stored history with a SIP request like SIP INVITE or SIP REFER. The SIP request includes a list of message identities in the form of "URI-list" containing a list of message id's representing each stored history item i.e., the list of history reference(s). According to the definition in metadata explained above, history reference is the value of the "history-reference" attribute that identifies the stored history that the user wants to retrieve. With this type of SIP request User is able to retrieve entire stored history of a conference.
If a User wishes to retrieve part of the stored history of a conference that has labels, the label name that represents the part that User is interested in need to be delivered along with the above-mentioned conversation history retrieval request. As a possible way, this invention proposes new attribute "label-name" which can be included along with the URI-list in the SIP request for conference

history retrieval. The "label-name" attribute is containing the name of the label represented in element according to the definition in metadata explained above. This label name identifies the part of stored history that the user wants to retrieve.

On receiving the SIP message requesting to retrieve part of the stored history, the Server needs to check if the "label-name" represented by the new attribute in the URI-list is a valid entry or not. In order to do that, the Server will first retrieve the history metadata including that contains the values in element. The Server then checks if the values that are contained in "start-id" and "end-id" are valid by searching for those ids in the corresponding content, if the Server does not find values in the content of the stored history, then the User is responded with appropriate SIP error response containing the warning header like "Not valid Label" etc else it is understood that the Server has found valid entry.
If Server identifies that the value contained in new attribute is a valid entry, then the User is returned with the part of the stored history representing the value that are contained in element and not the entire stored history represented by "history-reference" attribute.
User may initiate a request to delete stored history with a SIP request like SIP INVITE or SIP REFER as described in OMA developed SIMPLE IM 1.0 specifications. According to the definition in metadata explained above, history reference is the value in "history-reference" attribute that identifies the stored history that the user wants to delete. With this type of SIP request User is able to

delete entire stored history of a conference.
If a User wishes to delete portion of the stored history of a conference that is not labeled, this invention proposes new attribute "label-name" which can be included along with the URI-list.
If Server identifies that the value contained in new attribute is a valid entry, then the Server retains portion of the stored history that is identified by the "label-name" and deletes the rest of the stored history.
In another case the User may request to delete only the portion of stored history which is marked by the "label-name".
It is assumed that users Alice, Joe and Charlie are in a conference. Refer Figure-1.
1. All users in the conference exchange series of messages.
2-3. Charlie decides to create label to a set of messages while exchanging messages during the conference. So Charlie initiates a request to Server for creating label indicating the start of label. Charlie receives acknowledge from the server.
4. Users in the conference continue exchanging messages and Server notes the message-ids of these messages for labeling..
5-6. Charlie decides to stop labeling messages. So Charlie initiates a request to Server indicating to stop labeling. Charlie receives acknowledge from the server.
7. User continues to exchanges series of messages. Once the session is terminated, Server creates metadata for the history to be stored including the labels in the metadata.

8. The user Charlie wants to obtain the document describing the metadata about his stored conversations.
GET http://xcap.example.com
/services/org.openmobilealliance.history-list/users/sip:[email protected]/conv_history HTTP/1.1
Content-Length: 0
9. After the Server has performed the necessary authorization checks on the request originator, the Server sends an HTTP "200 OK" response including the requested document in the body.
HTTP/1.1 200 OK Etag:"etu15"
Content-Type: application/vnd.oma.history+xml

25
2006-08-16T15:05:00.OZ"friends"

2006-08-14T15:05:OO.OZ

2006-08-14T15:15:00.0Z

friends

Gharlie

Joe

Alice

10-12. Let us assume that Charlie wants to retrieve only the messages that are under the label name "aliceaddress"
Charlie then creates a SIP INVITE request
INVITE sip:[email protected] SIP/2.0
From:
To:
Content-Type: multiparty/mixed; boundary = 'Boundary'
Boundary
Content-Type : application/Sdp
Boundary
Content-Type: application/resource-list+xml

contain list of labels, in this example there will be only one entry i.e. the label name 'alice_address'.
This INVITE request is routed to the Server according to SiP procedures.
13-14. The Server extracts the messages corresponding to label name "alice_address" and sends the stored messages to Charlie.

15-16. The Server sends SIP BYE and the corresponding 200 OK from the client to end the session
ADVANTAGES
■ The invention overcomes the need for content search over huge content like stored history
■ Content search in order to retrieve a particular information from storage is easier with this invention and will be less expensive
■ Content search and retrieve is slower where as this invention will make it faster
■ Only part of the stored content that is necessary for the end user can be retrieved
■ Good user experience
Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawing, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart there from.

GLOSSARY OF TERMS AND DEFINITIONS THEREOF
OMA - Open Mobile Alliance SIP - Session Initiation Protocol IM - Instant Messaging PoC - Push to Talk Over Cellular XML - Extended Markup Language XDM - XML Document Management XCAP - XML Configuration Access Protocol SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions
CPM - Converged IP Messaging
IETF - The Internet Engineering Task Force
RFC - Request For Comments

We Claim
1. A method to label key messages of an ongoing conversation by the user
so that they can be selectively retrieved for reference/reading later or
deleted from the server the method comprising,
• Requesting the creation of labels for key messages anytime by the user while the conversation recording is on (label marking);
• Performing label abstraction by the application server at the end of storing conversation to identify the labeled messages;
• Initiating a request to retrieve the stored history from the application server by the user; and
• Returning the requested part of the stored history by the server.

2. The method as claimed in claim 1, wherein the labels may span across a single message or a set of sequential messages or media.
3. The method as claimed in claim 1, wherein the user and the conferencing server may be in the same network or different networks.
4. The method as claimed in claim 1, wherein, in conferences where MSRP is media session enabled, the label requests are sent through MSRP header/method.
5. The method as claimed in claim 1, wherein the request for label is sent as part of the dialog created between the User requested recording of the conversation and the Sever recording the conversation at the time of the User requested recording of the conversation.
6. The method as claimed in claim 5, wherein it is independent of the type of media conferencing.
7. The method as claimed in claim 1, wherein separate requests are sent to

the server to 'start' and 'end' labeling of a conversation.
8. The method as claimed in claim 1, wherein a Label APP message is used for setting the label in case of continuous media transfer.
9. The method as claimed in claim 8, wherein the Label APP message is the extension of RTCP APP message.
10.The method as claimed in claim 8, wherein the server acts on the label requests based on the type of media session.
11. The method as claimed in claim 1, wherein the label abstraction is expressed as an extension of the Metadata of the conversation history stored in the server.
12. The method as claimed in claim 1, wherein the label abstraction contains the label name as requested by the User, and the start and end Message-IDs/Relative timestamp of the messages/media that are associated with the label.
13. The method as claimed in claim 1, wherein the metadata of the stored history is retrieved using XCAP GET or SIP SUBSCRIBE methods, or through Push mechanism such as WAP Push or SIP Push etc.
14. The method as claimed in claim 1, wherein the retrieval of the stored data is achieved through a SIP request (SIP INVITE/SIP REFER).
15.The method as claimed in claim 14, wherein the SIP request contains a list of message identities in the form of "URI-list", which includes a list of message id's representing each stored history item.
16. The method as claimed in claim 14, wherein the retrieval of a part of the stored data is achieved by specifying an additional attribute - 'label name'

J - in the SIP request.
17.The method as claimed in claim 16, wherein the server sends the requested content to the user only if the label name' is a valid entry.
18.The method as claimed in claim 16, wherein a user can opt to delete selected parts of the conversation history identified by the 'label name' attribute.
19. A method to label key messages of an ongoing conversation by the user so that they can be selectively retrieved for reference/reading later or deleted from the server, substantially as herein described with respect to the accompanying drawings.

Documents:

1374-CHE-2007 AMENDED CLAIMS 28-03-2014.pdf

1374-CHE-2007 AMENDED PAGES OF SPECIFICATION 03-11-2014.pdf

1374-CHE-2007 AMENDED PAGES OF SPECIFICATION 28-03-2014.pdf

1374-CHE-2007 FORM-1 03-11-2014.pdf

1374-CHE-2007 FORM-1 28-03-2014.pdf

1374-CHE-2007 FORM-13 12-12-2013.pdf

1374-CHE-2007 POWER OF ATTORNEY 03-11-2014.pdf

1374-CHE-2007 EXAMINATION REPORT REPLY RECEIVED 03-11-2014.pdf

1374-CHE-2007 EXAMINATION REPORT REPLY RECEIVED 28-03-2014.pdf

1374-CHE-2007 OTHER PATENT DOCUMENT 28-03-2014.pdf

1374-CHE-2007 POWER OF ATTORNEY 28-03-2014.pdf

1374-che-2007 abstract.pdf

1374-che-2007 claims.pdf

1374-che-2007 description(complete).pdf

1374-che-2007 drawings.pdf

1374-CHE-2007 FORM-13 17-12-2013.pdf

1374-che-2007-correspondnece-others.pdf

1374-che-2007-description(provisional).pdf

1374-che-2007-form 1.pdf

« Previous Patent

Next Patent »

Patent Number

263896

Indian Patent Application Number

1374/CHE/2007

PG Journal Number

48/2014

Publication Date

28-Nov-2014

Grant Date

26-Nov-2014

Date of Filing

27-Jun-2007

Name of Patentee

SAMSUNG R&D INSTITUTE INDIA-BANGALORE PRIVATE LIMITED

Applicant Address

#2870 ORION BUILDING BAGMANE CONSTELLATION BUSINESS PARK OUTER RING ROAD DODDANEKUNDI CIRCLE MARATHAHALLI POST BANGALORE 560037

Inventors:

#	Inventor's Name	Inventor's Address
1	PATIL MAYURESH MADHUKAR	SAMSUNG INDIA SOFTWARE OPERTIONS PVT LTD BAGMANE LAKEVIEW ,BLOCK 'B',NO.66/1,BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA ,BANGALORE-560093, KARNATAKA ,INDIA
2	PATTAN BASAVARAJ JAYAWANT	SAMSUNG INDIA SOFTWARE OPERTIONS PVT LTD BAGMANE LAKEVIEW ,BLOCK 'B',NO.66/1,BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA ,BANGALORE-560093, KARNATAKA ,INDIA
3	JAE KWON OH	SAMSUNG INDIA SOFTWARE OPERTIONS PVT LTD BAGMANE LAKEVIEW ,BLOCK 'B',NO.66/1,BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA ,BANGALORE-560093, KARNATAKA ,INDIA

PCT International Classification Number

H04L12/16

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1			NA