Title of Invention

METHOD FOR MERGING AND SPLITTING OF ONGOING SESSIONS IN SESSION BASED APPLICATIONS

Abstract

The present invention is related to communication systems over mobile or the Internet. More specifically, the invention is related to the group communication systems like POC or IMS on the Internet or mobile systems. The POC or IMS use SIP technology to accomplish communication between users. The current invention provides a method to facilitate the management of user sessions. A user can initiate merge operation for two distinct groups. The user has to just select the groups to be merged. Then, a merge initiator signal is sent to a controlling function. The controlling function then sends invites to other users in the group. All the interested users are then merged together. Similarly, the user can initiate division of a group. In this case, a division initiator signal is sent to the controlling function. The controlling function invites the concerned users regarding the division. The interested users are divided into two groups.

Full Text

FIELD OF THE INVENTION This invention in general relates to the field of session based applications like POC and SIMPLE IM. This invention relates to group communication applications like POC and IM, where multiple group sessions are possible. This invention relates to SIP technology protocol. More specifically this invention relates to system and method for merging and splitting of sessions in session based applications like IMS applications simple IM and POC. BACKGROUND OF THE INVENTION IMS based application like POC and SIMPLE IM uses SIP session control procedure for establishing group communication sessions. There can be multiple group sessions simultaneously running for a particular user. There is a need for merging the two separate group sessions into one session for some use cases. Currently SIP does not support the merging of two or more group sessions. There are various use cases where splitting of group into two sessions is required. SIP also does not support this procedure. This invention proposes the SIP extensions to support this feature for merging the two or more sessions and splitting two sessions into two or more groups. SUMMARY OF THE INVENTION IMS based application like POC and SIMPLE IM uses SIP session control procedure of creation of a session. There can be one to one session or group sessions. SIP procedure allows initiating one to one session and group sessions. Group session could be Pre-arranged sessions or Ad-Hoc sessions. User can have simultaneous sessions. It is beneficial in some cases to allow user to merge a session or split a session in two or more groups. Consider User A is having two sessions. One group session is poc_groups, which is discussing on PoC related topics. Second session is im_group, which is discussing on SIMPLE IM related topics. In some situation where PoC group discussing on important issue which is common to SIMPLE IM group as well, in this case user wants to merge two groups into one group. User can initiate a merge request and server should be able to merge these two sessions into one session. Similarly, there is possibility of splitting of sessions into two or more groups in case of hierarchical group scenarios or in Ad-Hoc fashion. This will allow user to split one session into two sessions. Currently, a SIP procedure does not allow mechanism to merge the on-going sessions or split sessions into two sessions. Currently for merging of sessions, User needs to tear down the current on-going sessions and then create a new session for merged group. This required lots of signaling from the User side. The present invention proposes a method which allows user to send only one request for merging of sessions. The proposed method simplifies the merging of sessions with single request. Similarly for splitting of sessions, User need to send the terminate signal for current ongoing signal and then send the separate invite for the each split sessions. This requires lot of signaling from the client device which can waste lot of wireless resources. The present invention provides the system and methods which allow user to send single request for splitting of the session into two or more sessions. The present invention extends the SIP procedure and allow user to send the request for merging and for splitting of sessions. The present invention further provides two methods for the merging and two methods for splitting of the sessions. Accordingly the invention explains a method to facilitate merging and splitting of user sessions wherein merging operation comprising the steps of: a user selecting groups to be merged; sending a merge initiator signal to a controlling function; sending invites to other users in the group by the controlling function; and merging the interested users together, Splitting operation comprising the steps of: sending a splitting initiator signal to the controlling function; the controlling function inviting the concerned users regarding the split; and splitting the interested users. The present invention aims to provide the system and methods for enabling the users to initiate the merging and splitting of sessions. This invention initially discuss merging of session which provides two methods first method uses INVITE method and second method uses REFER method. These methods extend the INVITE and REFER methods for initiating the merging request. Similarly, invention extends the INVITE and REFER methods for initiating splitting request. 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 DRAWINGS Figure 1 illustrates System architecture for INVITE based method for merging of sessions Figure 2 illustrates Basic Flow diagrams Figure 3 illustrates Terminating side Flow diagram: On demand session case Figure 4 illustrates Terminating side Flow diagram: Pre-establish session case Figure 5 illustrates Sending BYE to user who rejects the REINVITE Figure 6 illustrates Schema format for Merged invite Body Figure 7 illustrates System architecture for REFER based merging of merging of sessions Figure 8 illustrates Logical flows for REFER based method for merging of sessions Figure 9 illustrates INVITE method for splitting of sessions Figure 10 illustrates Flow diagram for session split with INVITE request Figure 11 illustrates REFER method for splitting of sessions Figure 12 illustrates Flow diagram for session splitting using REFER method Figure 13 illustrates Schema format for splitting of sessions Figure 14 illustrates including new user into a merged session Figure 15 illustrates excluding user from a merged session DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 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 and drawings are 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. As discuss in the previous section basic use cases and motivation for merging and splitting of session, this section explains the detail solution for splitting and merging of session. Firstly, it discusses about merging of session then followed by splitting of sessions. Merging of sessions: This part of invention deals with merging of sessions. In this invention, two methods are proposed. First method uses INVITE method and other method uses REFER method. These methods are discussed next. In this proposal assumption is that session ids are know to user who initiate the merging request. INVITE method for merging of sessions This method uses INVITE method for sending of merging request. As shown in the Figure 1, Client A is initiator of merging request. There are two ongoing sessions, Session L1 (User B, User C, User D, and User A) and Session L2 (User G, User F, User E, and User A). Controlling function is common to both sessions, According to this method user sends INVITE request with session type URI parameter and merging indicator, e.g., set as "Ad-hoc+SessionMerge". Note a new tag is proposed to identify this request as merging request. Client A wants to merge two sessions L1, and L2. For this Client send INVITE request and add the +SessionMerge tag in session URI parameter in Request URI header field e.g. Request-URI:sip:PoCConferenceFactoryURI;session="Ad-Hoc+SessionMerge". Client A also adds the session information into the body of the session merge INVITE request. Client A adds session ids of sessions to be merged. Request URI of this INVITE request will be set to conference factory URI. Controlling function receives the Merge INVITE request. Controlling function also extract the body to identify the sessions to be merged. Controlling function sends the RE-INVITE with new session parameters to all users of session L1 and session L2. Controlling function also add tag +SessionMerge in the session URI parameter. Controlling function also adds information about the other session information, so that user can decide on to join the session or not. Controlling function also can send the group advertisement before sending the RE-INVITE so that user knows merging of session is going to happen. Upon receiving of RE- INVITE from the controlling function, user sends the 2000K response. All users are aware of the session merge situation by group advertisement and information in a RE-INVITE request. Controlling function also create the merged conference package for general notification about the merged session. This is a general proposed method using INVITE. Figure 2 explains the procedure in detail. In this scenario, there are two sessions, one session is L1 session, and other session is L2 session. Flows according to proposed solutions are follows: 1. Client A wants to initiate the merge request, Sends a INVITE request a. Including SessionMerge parameter in session URI parameter in Request-URI header, b. Request-URI header field contains conference factory URI c. INVITE Body will include session ids of sessions to be merged d. INVITE body can also have optional information for including and excluding of users into merged sessions is Client A is authorized to do so. 2. Controlling function receives this invite request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URI header a. Controlling function creates new session parameter and new session ids for merged sessions b. Extract body of invite to identify the sessions to be merged 3. Optionally, Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one 4. Controlling function then sends the RE-INVITE to all users a. +SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b. Merged session id and session parameters c. REPLACES header will have the session information about session, to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session 5. Client B device sends the 200 OK response to merged request 6. Controlling function forwards a 200 OK response to Client A device. 7. Create a merged conference package and Controlling function sends the notification about the merged session information. This ways Merge INVITE request will be used by the client device to initiate the merge request. Figure 3 explains the flow diagram case for terminating side in case of On- demand session: 1. Controlling function sends the RE-INVITE to Participating function with all details about merging of session 2. Participating server forwards the request to Client device 3. Client device send the 2000K response to participating function 4. Participating function forwards the request to controlling function Figure 4 explains Terminating side Flow diagram: Pre-establish session case: 1. Controlling function sends the RE-INVITE to Participating function with ail details about merging of session 2. Participating server send MBCP DISCONNECT message in RTCP protocol with reason of DISCONNECT as merging of session 3. Client device sends MBCP Talk Burst Acknowledgement response to DISCONNECT message 4. Participating server send MBCP CONNECT message in RTCP protocol with information about the new session parameters 5. Client device sends MBCP Talk Burst Acknowledgement response to CONNECT message 6. Participating function then send the 2000K response to controlling function This way INVITE based method is used for merging of the two sessions. When any user reject the REINVITE then controlling server send the BYE to him to tear down the session. This scenario is shown in the figure 5. Figure 6 shows, schema structure should be included in the Merged INVITE request. Schema has root element called SessionMerge. SessionMerge element has one element called Session. This element is used to include session ids of sessions to be merged. This element has two attributes one is SessionID and other is NoofUser. SessionID is used to specify the ID of sessions. NoofUser is option attribute and generally it is added by controlling function to give information about other sessions to users of session. Session has child element called UserName, which is used by controlling function to indicate the users in the session. Session Merge also has two optional elements for excluding and including any users from the merged session. REFER method for merging of sessions This method uses REFER method for sending of merging request. As shown in the Figure 7. This method actually adds other sessions to one session to create a merged session. Client A is initiator of merging request. There are two ongoing session, Session L1 (User B, User C, User D, and User A) and Session L2 (User G, User F, User E, and User A). Controlling function is common to both sessions. According to this method user sends REFER request with session URI parameter set as "Ad-hoc+SessionMerge". Client A wants to merge two sessions L1, and L2. For this Client send REFER request and add the +SessionMerge tag in session URI parameter in Request URI header field e.g. Request- URI:sip:[email protected];session="Ad-Hoc+SessionMerge".. Client A also adds the session information into the body of the session merge INVITE request. Client A adds session ids of sessions to be merged. Request URI of this INVITE request will be set to L1 session id. Controlling function receives the Merge REFER request. Controlling function also extract the body to identify the sessions to be merged. Controlling function sends the RE-INVITE with new session parameters to all users of session L2. Controlling function also add tag +SessionMerge in the session URI parameter. Controlling function also adds information about the other session, so that user can decide on to join the session or not. Controlling function also can send group advertisement before sending the RE-INVITE so that user knows merging of session is going to happen. Upon receiving of RE-INVITE from the controlling function, user sends the 200 OK response. All users are aware of the session merge situation by group advertisement and information in a RE-INVITE request. Controlling function also create the merged conference package for general notification about the merged session. This is a general proposed method using REFER. Figure 8 explains the procedure in detail. In this scenario, there are two sessions, one session is L1 session, and other session is L2 session. Flows according to proposed solutions are follows: 1. Client A wants to initiate the merge request, Sends a REFER request a. +SessionMerge parameter in session URI parameter in Request- URI header. b. Request-URl header field contains L1 session Id c. REFER-TO field contains reference to REFER body d. REFER Body will include session ids of sessions to be merged e. REFER body can also have optional information for including and excluding of users into merged sessions is Client A is authorized to do so. 2. Controlling function receives this REFER request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URl header. a. Send 202 Accepted response to Client A b. Extract body of REFER to identify the sessions to be merged to current session 3. Optionally, Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one 4. Controlling function then sends the RE-INVITE to all users of L2 session a. +SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b. Merged session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not 5. Client B device sends the 200 OK response to merged request 6. Controlling function send the NOTIFY to Client A to indicate the status related to REFER request 7. Client A sends a 200 OK response 8. Create a merged conference package and Controlling function sends the notification about the merged session information This way Merge REFER request will be used by the client device to initiate the merge request. The schema defined in previous section is valid for this method as well. The procedures at terminating side will remain same as given in the previous section. Splitting of sessions: This part of the invention deals with splitting of sessions. In this invention, two methods are proposed. First method uses INVITE method and other method uses RFER method. These methods are discussed next. In this proposal assumption is that hierarchical group definition is stored in controlling function or in controlling function XDMS. This proposal also considers the situation for ad-hoc group splitting case, where user split the session in ad-hoc fashion. INVITE Method for splitting of sessions This method uses INVITE method for sending of splitting request. As shown in the Figure 9, Client A is initiator of splitting request. There is one ongoing session, Session L1 (User B, User C, User D, User A, User G, User F, and User E). According to this method user sends INVITE request with session URI parameter set as "Ad-hoc+SessionSplit". Note a new tag is proposed to identify this request as splitting request. Client A wants to split current session. For this Client send INVITE request and add the +SessionSplit tag in session URI parameter in Request URI header field e.g. Request- URI:sip:[email protected];session="Ad-Hoc+SessionMerge".. Client A also adds the group information into the body of the session split INVITE request. Client A adds group URIs which identifies the groups into which session needs to be split. In case of Ad-hoc split client A also adds user names in each group so that two group sessions are created in Ad-Hoc fashion. Request URI of this INVITE request will be set to session id of current session. Controlling function receives the split INVITE request. Controlling function also extract the body to identify the groups into which session needs to be split. Controlling function sends the RE-INVITE with new session parameters to all users. Controlling function also add tag +SessionSplit in the session URI parameter. Controlling function also adds information about group, so that user can decide on to join the session or not. Controlling function also can send the group advertisement before sending the RE-INVITE so that user knows splitting of session is going to happen. Upon receiving of RE-INVITE from the controlling function, user sends the 2000K response. All users are aware of the session split situation by group advertisement and information in a RE-INVITE request. Controlling function also create the conference package for each group; general notification about the session. This is a general proposed method using INVITE. Figure 10 explains the procedure in detail. in this scenario, there is one session and client A wants to split the session into two sessions with G1 and G2. Flows according to proposed solutions are follows: 1. Client A wants to initiate the split request, Sends a INVITE request a. +SessionSplit parameter in session URI parameter in Request-URI header. b. Request-URI header field contains session id of current session c. INVITE Body will include groups URIs and also can have user names in each group for Ad-hoc splitting d. INVITE body can also have optional information for including and excluding of users into each group sessions if Client A is authorized to do so. 2. Controlling function receives this invite request and identifies it as a split request by seeing the +SessionSplit tag in Request-URI header. a. Controlling function creates new session parameter and new session ids for other sessions b. Extract body of invite to identify the groups 3. Optionally, Controlling function sends the group advertisement to each user of sessions to indicate the splitting of session in to two 4. Controlling function then sends the RE-INVITE to all users a. +SessionSplit tag to identify it as splitting invite, so that client can retrieve session parameter from RE-INVITE request b. split session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session 5. Client B device sends the 200 OK response to split request 6. Controlling function forwards a 200 OK response to Client A device. 7. Create a conference package and Controlling function sends the notification about each session information This way split INVITE request will be used by the client device to initiate the split request. REFER Method for splitting of sessions This method uses REFER method for sending of splitting request. As shown in the Figure 11, Client A is initiator of splitting request. There is one ongoing session, Session L1 (User B, User C, User D, User A, User G, User F, and User E). According to this method user sends REFER request with session URI parameter set as "Ad-hoc+SessionSplit". Note a new tag is proposed to identify this request as splitting request Client A wants to split current session. For this Client send REFER request and add the ++SessionSplit tag in session URI parameter in Request URI header field e.g. Request- URI:sip:[email protected];session="Ad-Hoc+SessionMerge". Client A also adds the group information into the body of the session split REFER request. Client A adds group URIs which identifies the groups into which session needs to be split In case of Ad-hoc split client A also adds user names in each group so that two group sessions are created in Ad-Hoc fashion. Request URI of this REFER request will be set to session id of current session. REFER-TO is set to reference to body of REFER request. Controlling function receives the split REFER request. Controlling function also extract the body to identify the groups into which session it needs to split. Controlling function sends the RE-INVITE with new session parameters to all users. Controlling function also add tag +SessionSplit in the session URI parameter. Controlling function also adds information about group, so that user can decide on to join the session or not. Controlling function also can send the group advertisement before sending the RE-INVITE so that user knows splitting of session is going to happen. Upon receiving of RE-INVITE from the controlling function, user sends the 2000K response. AH users are aware of the session split situation by group advertisement and information in a RE-INVITE request. Controlling function also create the conference package for each group; general notification about the session. This is a general proposed method using REFER. Figure 12 explains the Flow diagram for sessions splitting using REFER method. In this scenario, there is one session and client A wants to split the session into two sessions with G1 and G2. Flows according to proposed solutions are follows, 1. Client A wants to initiate the split request, Sends a REFER request a. +SessionSplit parameter in session URI parameter in Request-URl header. b. Request-URl header field contains current session Id c. REFER-TO field contains reference to REFER body d. REFER Body will include Group ids of sessions e. REFER body can also have optional information for including and excluding of users into Split sessions if Client A is authorized to do so. 2. Controlling function receives this REFER request and identify it as a Split request by seeing the +SessionSplit tag in Request-URl header a. Send 202 Accepted response to Client A b. Extract body of REFER to identify the sessions to be split from current session 3. Controlling function sends the group advertisement to each user of sessions to indicate the Split of session in to two 4. Controlling function then sends the RE-INVITE to all users of G1 session a. +SessionSplit tag to identify it as Splitting invite, so that client can retrieve session parameter from RE-INVITE request b. Split session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the session or not 5. Client B device sends the 200 OK response to Split request 6. Controlling function send the NOTIFY to Client A to indicate the status related to REFER request 7. Client A sends a 200 OK response 8. Create a Split conference package and Controlling function for each session, and sends the notification about the Split session information This way split REFER request will be used by the client device to initiate the split request. Schema for Splitting of sessions Figure 13 shows, schema structure should be included in the Split INVITE request. Schema has root element called SessionSplit. SessionSplit element has one element called Group. This element is used to include group ids. This element has two attributes one is Group_URL and other is N oof User. Group_URL is used to specify the URL of group. NoofUser is option attribute and generally, it is added by controlling function to give information about other sessions to users of session. Group has child element called UserName, which is used by controlling function to indicate the users in the session. In case of Ad-hoc session split client will include the user names. Session Split also has two optional elements for excluding and including any users from the Split sessions. Excluding and including users from sessions: This section gives example for case where user can exclude or include the any member from the merged session or split sessions. Including user while merging the session In this example its shows, how user can use the INCLUDE element so that he can invite new user into a merged session. Figure 14 shows flow diagram for merging scenario, in this example user A wants to add new user M into merged session. The flows are as follows, 1. Client A wants to initiate the merge request, Sends a INVITE request a. Including SessionMerge parameter in session URI parameter in Request-URl header. b. Request-URl header field contains conference factory URI c. INVITE Body will include session ids of sessions to be merged d. INVITE body will have Include element with value set to User M address. 2. Controlling function receives this invite request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URl header a. Controlling function creates new session parameter and new session ids for merged sessions b. Extract body of invite to identify the sessions to be merged 3. Optionally, Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one 4. Controlling function then sends the RE-INVITE to all users a. +SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b. Merged session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session 5. Controlling function also send the INVITE to User M for inviting the user into a merged session a. Merged session id and session parameters b. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session 6. Client M device sends the 200 OK response to INVITE request. After this session will commence normally, so this way Include element is used for including new user into a merged session. Excluding user while merging the session In this example its shows, how user can use the EXCLUDE element so that he can exclude any user from a merged session. Figure 14 shows flow diagram for merging scenario, in this example user A wants to exclude user C from a merged session. The flows are as follows, 1. Client A wants to initiate the merge request with excluding user C, Sends a INVITE request a. Including SessionMerge parameter in session URI parameter in Request-URl header. b. Request-URl header field contains conference factory URI c. INVITE Body will include session ids of sessions to be merged d. INVITE body will have Exclude element with value set to User C address. 2. Controlling function receives this invite request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URl header s a. Controlling function creates new session parameter and new session ids for merged sessions b. Extract body of invite to identify the sessions to be merged 3. Optionally, Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one 4. Controlling function then sends the RE-INVITE to all users a. +SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b. Merged session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session 5. Controlling function also send the BYE to User C for excluding him from merged session. After this session will commence normally, so this way Exclude element is used for excluding any user from a merged session. Ndte this inclusion and exclusion is also applicable while splitting a session as well. It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device. Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, 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 XDMS - XML Document Management Server POC - Push to talk Over Cellular We Claim, 1. A method to facilitate merging and splitting of user sessions wherein merging operation comprising the steps of: a user selecting groups to be merged; sending a merge initiator signal to a controlling function; sending invites to other users in the group by the controlling function; and merging the interested users together, Splitting operation comprising the steps of: sending a splitting initiator signal to the controlling function; the controlling function inviting the concerned users regarding the split; and splitting the interested users. 2. A method as claimed in claim 1 wherein an INVITE method for merging of sessions comprising the steps of: sending a INVITE request by a first client who wants to initiate the merge request; controlling function receiving the invite request and identifying it as a Merge request; controlling function optionally sending a group advertisement to each user of sessions to indicate the merging of session in to one; controlling function then sending the RE-INVITE to all users; ' a second client sending response to merge request; controlling function forwarding a response to the first client; and Creating a merged conference package and the controlling function sending the notification about the merged session information. 3. The method as claimed in claim 1 wherein a REFER method for merging of sessions comprising the steps of: a first client who wants to initiate the merge request, sending a REFER request i controlling function receiving the REFER request and identify it as a Merge request; controlling function optionally sending the group advertisement to each user of sessions to indicate the merging of session in to one; controlling function sending the RE-INVITE to all users of the session; a second client sending a response to merge request; controlling function sending the NOTIFY to the first client to indicate the status related to REFER request; first client sending a response; and creating a merged conference package and the controlling function sending the notification about the merged session information. 4: The method as claimed in claim 1 wherein a INVITE method for splitting of sessions comprising the steps of: a first client wanting to initiate the split request, sending a INVITE request; controlling function receiving the invite request and identifying it as a split request; Controlling function creating new session parameter and new session ids for other sessions; controlling function optionally sending the group advertisement to each user of sessions to indicate the splitting of session in to two; controlling function sending the RE-INVITE to all users, a second client device sending a response to split request; controlling function forwarding response to first Client; and creating a conference package and the Controlling function sending the notification about each session information . 5. The method as claimed in claim 1 wherein a REFER Method for splitting of sessions comprising the steps of: a first Client wanting to initiate the split request, Sending a REFER request; controlling function receiving the REFER request and identifying it as a Split request; controlling function sending the group advertisement to each user of sessions to indicate the split of session in to two; controlling function sending the RE-INVITE to all users of the session; a second client sending response to split request; controlling function sending the NOTIFY to first client to indicate the status related to REFER request; first client sending a response ; and creating a split conference package and controlling function for each session, and sending the notification about the Split session information . 6. A method to facilitate merging and splitting of user sessions substantially described particularly with reference to the accompanying drawings.

Documents:

2475-CHE-2006 AMENDED PAGES OF SPECIFICATION 11-07-2013.pdf

2475-CHE-2006 AMENDED CLAIMS 11-07-2013.pdf

2475-CHE-2006 AMENDED PAGES OF SPECIFICATION 17-02-2014.pdf

2475-CHE-2006 CORRESPONDENCE OTHERS 21-10-2013.pdf

2475-CHE-2006 CORRESPONDENCE OTHERS 12-07-2013.pdf

2475-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 11-07-2013.pdf

2475-CHE-2006 FORM-1 11-07-2013.pdf

2475-CHE-2006 FORM-1 12-07-2013.pdf

2475-CHE-2006 FORM-13 11-07-2013.pdf

2475-CHE-2006 FORM-3 11-07-2013.pdf

2475-CHE-2006 OTHER PATENT DOCUMENT 11-07-2013.pdf

2475-CHE-2006 OTHER PATENT DOCUMENT 1 11-07-2013.pdf

2475-CHE-2006 POWER OF ATTORNEY 11-07-2013.pdf

2475-CHE-2006 POWER OF ATTORNEY.pdf

2475-CHE-2006 AMENDED CLAIMS 21-11-2013.pdf

2475-CHE-2006 AMENDED PAGES OF SPECIFICATION 21-11-2013.pdf

2475-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 17-02-2014.pdf

2475-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 21-11-2013.pdf

2475-CHE-2006 FORM-1 17-02-2014.pdf

2475-CHE-2006 FORM-13 12-12-2013.pdf

2475-CHE-2006 POWER OF ATTORNEY 12-07-2013.pdf

2475-CHE-2006 POWER OF ATTORNEY 17-02-2014.pdf

2475-CHE-2006 ABSTRACT.pdf

2475-CHE-2006 CLAIMS.pdf

2475-CHE-2006 DESCRIPTION (COMPLETE).pdf

2475-CHE-2006 DRAWINGS.pdf

2475-CHE-2006 FORM 18.pdf

2475-CHE-2006 FORM-13 16-12-2013.pdf

2475-che-2006-correspondnece-others.pdf

2475-che-2006-description(provisional).pdf

2475-che-2006-drawings.pdf

2475-che-2006-form 1.pdf

2475-che-2006-form 26.pdf