Title of Invention

METHOD OF REVOKING A FLOOR FORM A TERMINATING USER USING A POC SERVER

Abstract

This invention provides the system and method by which PoC user can send request for revoking the floor from particular malicious user. In case of dispatcher session dispatcher can use this method for revoking the floor from one fleet member and giving the floor to more important user. This allows dispatcher to decide the priorities based on the situation rather than the predefined manner. This invention also proposes the mechanism for blocking the particular media from the particular user. This can also avoid receiving malicious media from the unwanted users.

Full Text

FIELD OF THE INVENTION The present invention is related to session-based applications like POC and SIMPLE IM. Particularly the present invention is related to group communication applications like POC and IM. This invention is related to the IMS applications where communication style is half duplex. More particularly, the present invention relates to a system and method for blocking and revoking floor from the user and also for blocking media from a user. DESCRIPTION OF RELATED ART IMS based application like POC and SIMPLE IM uses SIP session control procedure of creation of a session. We can have a 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. PoC application is half duplex in nature so that it requires floor control mechanism. PoC application uses media burst control protocol (MBCP) using the RTCP app message. PoC user can request for floor anytime and there request will be queued based on PoC server policy and Priority of floor request. Each user has priority assigned for floor request so that higher priority user will get floor first There are three kinds of priority levels are possible Pre-emptive, High and Normal Priority. Pre-emptive user can take floor from normal and high priority user. PoC server queue the floor request based on these priority levels. Currently, PoC specification doesn't allow revoking the floor from any user unless he is a Pre-emptive priority user. There is possible that any user use the floor maliciously. Other PoC user cannot take away the floor from him unless he is Pre¬emptive user. This is very much the case in Chat group and Ad-hoc groups. In case of chat and ad-hoc group session priority of users are same. In such situation there is possibility of using the floor maliciously. There are cases where some user sending the malicious content like virus and once they are spread to the floor other other users can suffer. In PoC we can have the dispatcher session in which one PoC user will act as a dispatcher and other user will act as a fleet members. Fleet member can send the media to dispatcher but not to other fleet members. In case of dispatcher session also dispatcher to revoke the floor he has to send the floor request. But current state of art doesn't support revoking the floor from user without getting the floor. US 7079857 B2 teaches a method and apparatus for arbitrating between a first communication device having floor control in a group communication network and a second communication device competing for floor control provides receiving a floor-control request from the second communication device, comparing respective priority levels of the first communication device and the second communication device, and granting floor control to the second communication device if the second communication device has a higher or equal priority level. In one embodiment, the controller receives the request for floor control from a push- r Ik {PTT) device. The arbitration is disclosed as being performed by assigning priority levels to devices and then comparing priority levels to decide floor control based on an algorithm. The feature of blocking media reception from one user is not explicitly mentioned in the patent. Further, it is not explicit whether the priority message is a new MBCP message or uses an existing MBCP message. US 20030154249 A1 teaches a method and apparatus for removing a member from an active call in a group communication network provides for receiving a member list from a user and sending a request to a server to remove the member list from the active group call. The method and apparatus further provides for announcing each member in the member list that they are being removed from the group call, receiving acknowledgement from each member in the member list, and sending a response to the request, indicating that the member list has been removed. The group communication is defined in the embodiments to include a Push to Talk (PTT) type of communication. The method by which users are removed from a group is by sending a message to the regional dispatcher (RD). The RD removes the users requested and may optionally indicate their removal status. The feature of blocking media reception from one user is not explicitly mentioned in the application. Further, it is not explicit whether the message sent to the RD is a new MBCP message or an existing MBCP message The present invention provides a system and method by which PoC user can send request for revoking the floor from particular malicious user. In case of dispatcher session dispatcher can use this method for revoking a floor from one t member and giving the floor to more important user. This allows dispatcher to decide the priorities based on the situation rather than the predefined manner. The present invention also proposes a mechanism for blocking the particular media from the particular user. This can also avoid receiving malicious media from the unwanted users. SUMMARY OF INVENTION The invention relates to the field of Push to Talk over Cellular (PoC). More specifically, the invention proposes a system and two methods for blocking and revoking floor rights from a user and blocking media from a user. The invention further allows any PoC user to remove another user from a group chat. This is accomplished by using RTCP app messages to send revoke messages- The invention proposes two methods for sending revoke messages. The first rflethod involves a new MBCP message to be sent to a PoC server, which then revokes the floor rights of the user based on the priority of the user requesting the revoke. The second method utilizes a floor request message, which extends the MBCP message to include new time-stamp information. The timestamp value if set to 0 (zero) will cause the server to revoke the floor rights of the user. Further, the invention allows users to block another user from sending media over a PoC session. This is accomplished by generating a new MBCP message which includes the SSRC of the user whose media is to be blocked, the user is retained jr^the group however he/she is not allowed to transmit any media. Further, in an embodiment of the invention a message to un-block the user can also be sent. Accordingly the invention explains a method of revoking a floor from a terminating user comprising the steps of: sending an MBCP message to a PoC server by an originating user; revoking the floor from the terminating user based on the local policy ; where if the originating user has a highest priority than the terminating user, the PoC server will directly revoke a floor. According the invention explains a system for revoking a floor from a terminating user comprising: a PoC server receiving an MBCP message send by an originating user; means for revoking the floor from the terminating user based on the local policy; where if the originating user has a highest priority than the terminating user, the PoC server will directly revoke a floor. Accordingly the invention explains a method of revoking floor from a terminating user comprising the steps of: sending an existing MBCP message by an originating user to PoC server; and revoking the floor of the terminating user based on the local policy. Accordingly the invention explains a system for revoking floor from a terminating user comprising: a PoC server receiving an existing MBCP message send by an originating user; and means for revoking the floor of the terminating user based on the local policy. Accordingly the invention also explains a method of blocking media from particular users comprising: using MBCP message for sending the blocking request; and the PoC user including the SSRC of user whose media needs to be blocked. According the invention explains a system for blocking media from particular users comprising: a MBCP message for sending the blocking request; and a PoC user including the SSRC of user whose media needs to be blocked. The 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 FIGURES Figure Idepicts a system Basic flows for revoking the floor Figure 2 depicts the floor revoke message Figure 3 depicts an example flows for Scenario a Figure 4 depicts an example flows for Scenario b Figure 5 depicts the flow diagram for revoke request with floor request message Figure 6 depicts the floor Request message with revoke extensions Figure 7 depicts the blocking particular media from some user message format Figure 8 depicts the basic flow diagram for blocking request Figure 9 depicts an example flow for blocking media from user DETAILED DESCRIPTION OF THE INVENTION The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. However, it will apparent to a person ordinarily skilled in the art that the disclosed embodiments are merely exemplary, which may be embodied in various forms. The following description and drawings are not to be construed as limiting. 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 may not be described in order maintain clarity. The terms used to describe various embodiments are exemplary. It should be understood that these are provided to merely aid the understanding of the description, and that their use and definitions in no way limit the scope of the invention As discussed in the previous section, basic use of the method showcases and provides motivation for revoking the floor from a particular user and blocking the media from a particular user. This section explains detailed methods for above features. First part of this section deals with revoking the floor from a user and second part of this invention deals with blocking the media from a particular user. IWs part of invention deals with blocking and revoking a user from the floor. Note here that the floor will be taken from terminating user and floor will be given to the next queued user. If queuing is not supported or no one is in a queue then floor will become idle. This part of invention proposes two methods one using the new RTCP app message (MBCP message) and other using existing RTCP app message. First Part: Revoking the floor from a user First Method: Floor revoke message using new message format This part of invention proposes a new MBCP message revoke message. This message structure is shown in the figure 2. Whenever the originating Poc user wants to revoke a floor from a other user he sends this message to the PoC server. Based on the local policy PoC server will revoke a floor from terminating user. Whenever requester is having highest priority than a PoC user having the floor, the PoC server will directly revoke a floor. In a case of dispatcher session, dispatcher will send this request and then PoC server will revoke the floor from current fleet user and give the floor to other fleet user. Figure 1 shows a basic system flow for revoking the floor Step 1.Client B wants to initiate the revoke request and sends a REVOKE request to User C which has the below mentioned purposes (a) and (b) a. User name C from his/her floor is to be revoked b. Reason code and additional information for mentioning the proper reason of revoke has to be sent along with the request Step 2.Controlling function receives this revoke request and sends the MBCP acknowledgement message which contains c. Status information of revoke request d. Reason code having "User-Revoked /Not authorized /User-not- Revoked" type of messages Step 3.Controlling function sends the Revoke message to user C e. This also contains the reason code mostly copied from the user revoke message, and if the user revoke message does not have reason code, then the PoC server will add the reason code and also add the SSRC information of user who requested for the revoke of floor. Step 4.User C releases the floor and then sends the MBCP acknowledgement The POC server in this situation behaves in such a way that whenever it receives a revoke message from any user, it extracts the SSRC of PoC Client from whom floor has to revoke from revoke message. PoC server also verifies the permission for revoking the floor depending on the priority of requesting user. If priority of requesting user is high then the PoC Server will revoke a floor from user so that the PoC Server will send a revoke message to user. If revoke message sent by requesting user contains reason code and additional information, then the PoC Server will copy these fields into revoke message and send it to the user. if the revoke message sent by requesting user does not contains reason code and additional information then the PoC Server will include the reason code with Floor-Revoked-Req and in additional information will have SSRC of requesting user. This may depend on the PoC server local policy. Whenever PoC Server receives the revoke request from any user, PoC Server will evaluate the verify the permission of that user based on the priority of that user. Based on this PoC Server will send the response to requesting user with status of the revoke request. PoC server sends the MBCP media burst acknowledge message to user. In media burst acknowledge message PoC Server give reason code as User-Revoked if user is revoked from floor, or No-Permission if requesting user is not authorized to do so. If particular conference doesn't support this feature then PoC Server can include "Not-allowed" code. After the user is revoked from the floor, the PoC Server will give the floor to next queued person or if no one has requested for queue then floor will becomes idle. In Case of dispatcher session, whenever the dispatcher sends the revoked message, the PoC Server will revoke floor from fleet member and give the floor to next fleet member whoever is there in a queue. This way PoC Server will handle the revoke request sent by any user. Figure 2 shows the format of the floor revoke message. In this message the client r includes a user identity from which floor needs to be revoked. The user can block a floor from a particular user in a queue. This revoke message also has the reason code and additional information. Figure 3 shows a flow example for blocking a user from the floor. Users A,B>C and D are involved in a conference. User D is having the floor and user D is sending the malicious information. So user A decides to revoke the floor from that user. PoC Session is going on between Users A,B,C and D. User D has requested the floor and started sending the malicious media and using the floor maliciously. The following are the basic flows, Step 1 PoC User D sends the malicious media to group Steps 2,3,4. PoC Server forwards this media to all members of the group Step 5 User B the sends Revoke message to user D with the following information in the MBCP Revoke message. i) SSRC of Client to be revoked ii) Additional information indicating the presence of sending of Malicious media PoC Server checks for the authorization of that user for revoking. Step 6 If the PoC Server authorizes User B for this request .then the PoC Server revokes the User D from floor be sending the revoke message to user D Step 7 PoC Server also sends the MBCP Media burst Acknowledged message with status of the Revoked message as given below i) The Reason Code as sent is "USER D-REVOKED" In this way the invention helps user to revoke any user. The additional information in the revoke message help to inform the user about reason for revoke. Figure 4 shows another example of revoking an user from the floor Users A,B.C and D are having a dispatch session. User B is the dispatcher of dispatcher session. Currently fleet member D is having a floor. User B decides to revoke the floor from current fleet member D because he wants to clarify some important issue related to the discussion and wants to give the floor to next fleet User. The current situation is as follows The PoC Dispatch Session is going on between the User A, User B, User C and User D. User B is a Dispatcher of this dispatcher session. Currently User D has the floor. The following are the basic flows Step 1. PoC User D sends the media to dispatcher Step 2. PoC Server forwards this media to dispatcher of session Step3. User B Sends Revoke message to user D which contains the informations (I and ii) in the MBCP Revoke message, i) SSRC of Client to be revoked ii) Additional information containing the 'urgent need information' from the next fleet member PoC Server checks for the authorization of that user for revoking. Step 4. If PoC Server authorizes User B for this request then, then the PoC Server revokes User D from floor by sending the revoke message to user D Step 5. The PoC Server also sends the MBCP (Media burst Acknowledge message) with status of the Revoked message in the following format i) Reason Code will be in the form of "USER-REVOKED" This way basic invention helps the user to revoke any user. The additional information in the revoke message help to inform the user about the reason for the revoke. Second Method: Using existing floor request message This part of invention proposes to use the existing MBCP message with additions to support for revoke message. This message structure is shown in the figure 6. Whenever the PoC user wants to revoke a floor from a user, he sends this message to PoC server. Based on the local policy ,the user is revoked. The Media Burst request timestamp option indicates when the original MBCP (Media Burst Request message) was sent. So this time attribute is basically a time value indicating when the client generated the request. If the jser wants to raise the revoke request rather than floor request, then the client includes this new field value and also includes the additional information so that PoC Server can differentiate these two requests. Whenever the requester is having the highest priority than the PoC user having floor, then the PoC server directly revokes the floor. If PoC user has the same priority then the PoC server will revoke a floor based on the number of requests. In case of dispatcher session, dispatcher will send this request and then PoC server will revoke the floor from current user and give the floor to other user. Basic signaling with respect to figure 5 flows is as follows, Step 1 Client B wants to initiate the revoke request and Sends a Floor request message containing a. Additional field (Revoke request) b. Reason code and additional information for mentioning the proper reason of revoke Step 2.Controlling function receives this revoke request and sends the MBCP acknowledgement message containing c. Status information of revoke request d. Reason code in the format "User Revoked / No-perm ission/Not- allowed" Step 3.Controlling function then sends the Revoke message to user C This also has the reason code mostly copied from the 'user revoke message', and if the 'user revoke message' does not have reason code, then the PoC server will add the reason code and also add the SSRC information of user, who requested for the revoke of floor. Step 4.User C then releases the floor and then sends the MBCP acknowledgement The POC server in this situation behaves in such a way that whenever it receives a floor request message from any user with additional field indicating it as revoke request, then it identifies this request as floor revoke message. The PoC server also verifies the permission for revoking the floor depending on the priority of a requesting user. If priority of requesting user is high, the PoC server will revoke a floor from user by sending a a revoke message to user. The PoC Server will include the reason code with 'Floor-Revoked-Req' and the additional information will have the SSRC of requesting user. This may be depending on the PoC server local policy. Whenever PoC Server receives the revoke request from any user, the PoC Server verifies for the permission of that user based on the priority. Based on this PoC Server will send the response to requesting user with status of the revoke request. The PoC server the sends the MBCP (media burst acknowledge message) to user. In the media burst acknowledge message, the PoC Server gives reason code as 'User-Revoked' if the user is revoked from floor, or 'No-Permission' if the requesting user is not authorized to do so. If particular conference doesn't support this feature, then the PoC Server can include 'Not-allowed' code also. After the user is revoked from the floor, the PoC Server will give the floor 'to next queued person, or if no one has requested for queue then the floor becomes idle. In case of dispatcher session, whenever the dispatcher sends the revoked message, the PoC Server will revoke fleet member from the floor and give the floor to next fleet member whoever is there in the queue. This way PoC Server handles the revoke request sent by the any user. Figure 6 shows floor request message with the red part showing extension to it for revoking a message. The PoC user will use this new Field value for indicating it as a revoke message. When a user wants to send a revoke message then he will include the field value as mentioned below in this data packet. "Field = 120(Decimal) Revoke message" If this field value is not present, then this will be interpreted as normal floor request message. An "Additional information" field is also used to give addition information if required (as previously discussed) Second Part: Blocking some media from particular users This part invention deals with blocking the media from a user. This can be useful in a case where a user may be sending the malicious media e.g. virus etc. So here, the one user can block media from the user who is sending malicious media. This invention provides the mechanism to achieve this. This invention proposes new MBCP message for sending the blocking request. Figure 7 shows message format for the blocking request. Here in this request message, the PoC user will include the SSRC of user whose media needs to be blocked. This request also supports the need to block the particular media from user e.g. blocking images from this user. These media characteristics can be included in the media field. The length field is used for indicating the use of values included in a media. There can be multiple media parameters in a single request. To unblock the blocked media the same request can be sent. This request is works like a toggle button. This way by using this request, we can block the media form a particular user. Figure 8 shows, basic flow diagram for blocking the certain media from a particular user. The steps are as follows, Step 1.Client B wants to initiate the Blocking request and Sends a Media blocking request message containing information about a. The SSRC of user whose media needs to be blocked b. What Media parameter needs to blocked Step 2.The Controlling function receives this Blocking request and sends the MBCP acknowledgement message containing c. Status information of Blocked request d. Reason code having the message" Media-Blocked " The server in this situation behaves in such a way that When ever it receives a blocking request message from any user, it verifies the permission for blocking the media depending on the local policy or if it performs the same act even if the PoC Server does not support this feature. If PoC Server supports this feature, then it will set the corresponding filter for that user. The PoC Server filters media from user who is mentioned in blocking request. Whenever the originating user sends a blocking request with different media parameters other than the ones previously sent, then the PoC Server will add this media parameter into the filter and block this media type as well as. If originating PoC user sends blocking request with same parameter as the previous requests then the PoC Server identifies this as unblocking request and removes the filtering. Any user can use this feature. So this is not specific for any user. This way-originating user can handle the blocking request from any user. This filter will be valid till the conference exists. After the conference is ends, then these filter rules are not valid. Figure 9 shows a typical example for blocking media from floor In this situation Users A,B,C and D are having conference. User D is having the floor and is sending the malicious information. So user A has decided to block media from that user. The current situation will now be discussed as below PoC Session is going on between the User A, User B, User C and User D. User D has requested the floor and started sending the malicious media and using the floor maliciously. The following are the basic flows (Steps), which are followed in this case based on the present invention Step 1. PoC User D sends the malicious media to group Steps 2,3,4. PoC Server forwards this media to all members of the group Step 5. User B Sends Block media message to the PoC Server with the following information in the MBCP Block message. i) SSRC of Client from which media to be blocked ii) The concerned Media type whereby and where after the video PoC Server checks for the authorization of that user for revoking. Step 6. If the PoC Server authorizes User B for this request then, PoC Server send the acknowledge by sending MBCP talk burst acknowledgement containing the below mentioned code i) The Reason code will be "Media-Blocked " Steps 7,8,9. PoC User D sends media to the group but PoC Server sends this media to User A, and User C only and not to User B as per blocking the request made previously by User B In this way the present invention helps the user to block certain media from any user. While the embodiments of the present invention have been illustrated and described, it wilf be clear that the present invention and its advantages are not limited to these embodiments only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art without departing from the spirit and scope of the present invention as described in the claims. ADVANTAGES Present invention relates to a system and method for revoking a floor from particular users and also for blocking user from getting floor. The present invention provides the ability to block a user from a PoC chat based on the request of another user in the chat. Here the Blocking action is being performed based on priority levels of users and the Message requesting the blocking of another user being an MBCP message is an added advantage. The present invention is also a system and method for blocking media from the particular user thereby providing the ability to block a specific and particular type of media. Although the present invention has been fully described in connection with 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 SIP-Session Initiation Protocol ,WE CLAIM; 1. A method of revoking a floor from a terminating user comprising the steps of: sending an MBCP message to a PoC server by an originating user; revoking the floor from the terminating user based on the local policy ; where if the originating user has a highest priority than the terminating user, the PoC server will directly revoke a floor. 2. A method as claimed in claim 1 wherein a reason code and additional information for mentioning the reason for revocation is sent along with the MBCP message. 3. A method as claimed in clam 1 further comprising a controlling function receiving a revoke request and sending an MBCP acknowledgement message which contains the status information of the revoke request and the reason code having the type of messages. 4. A method as claimed in clam 1 further comprising the controlling function sending the revoke message to the terminating user which contains the reason code, and if the revoke message does not have reason code, then the PoC server add the reason code and the SSRC information of the originating user. & A method as claimed in clam 1 further comprising the step of releasing the floor and sending the MBCP acknowledgement by the terminating user. 6. A method of revoking floor from a terminating user comprising the steps of: sending an existing MBCP message by an originating user to PoC server; and revoking the floor of the terminating user based on the local policy. 7. The method according to claim 6 further comprises a Media Burst request timestamp option indicating when a Media Burst Request message is sent. 8. The method as claimed in claim 6 wherein the originating user is adapted to raise a revoke request or a floor request. 9. The method as claimed in claim 6 wherein if the originating user has a higher priority than the terminating user, then the PoC server directly revokes the floor. 10. The method as claimed in claim 6 wherein if the originating and the terminating users has the same priority then the PoC server revoke a floor based on the number of requests. 11. The method according to claim 6 further comprises a dispatcher session, where a dispatcher sends the request and the PoC server revoking the floor from a current user and giving the floor to another user. 12. A method of blocking media from particular users comprising: using MBCP message for sending the blocking request; and the PoC user including the SSRC of user whose media needs to be blocked. 13. The method as claimed in claim 12 wherein the said method is adapted to unblock the blocked media by using same request. 14. A system for revoking a floor from a terminating user comprising: a PoC server receiving an MBCP message send by an originating user; means for revoking the floor from the terminating user based on the local policy; where if the originating user has a highest priority than the terminating user, the PoC server will directly revoke a floor. 15. A system for revoking floor from a terminating user comprising: a PoC server receiving an existing MBCP message send by an originating user; and means for revoking the floor of the terminating user based on the local policy. 16.A system for blocking media from particular users comprising: a MBCP message for sending the blocking request; and a PoC user including the SSRC of user whose media needs to be blocked. 17. A method of revoking a floor from a terminating user substantially described particularly with reference to the accompanying drawings. 18. A system for revoking a floor from a terminating user substantially described particularly with reference to the accompanying drawings.

Documents:

0673-che-2007 abstrcat duplicate.pdf

0673-che-2007 abstrcat.pdf

0673-che-2007 claims duplicate.pdf

0673-che-2007 claims.pdf

0673-che-2007 description (complete) duplicate.pdf

0673-che-2007 description (complete).pdf

0673-che-2007 drawings duplicate.pdf

0673-che-2007-correspondnece-others.pdf

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

0673-che-2007-drawings.pdf

0673-che-2007-form 1.pdf

0673-che-2007-form 26.pdf

673-CHE-2007 AMENDED PAGES OF SPECIFICATION 13-09-2013.pdf

673-CHE-2007 AMENDED CLAIMS 13-09-2013.pdf

673-CHE-2007 EXAMINATION REPORT REPLY RECEIVED 13-09-2013.pdf

673-CHE-2007 FORM-1 13-09-2013.pdf

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

673-CHE-2007 FORM-13 13-09-2013.pdf

673-CHE-2007 FORM-5 13-09-2013.pdf

673-CHE-2007 OTHER PATENT DOCUMENT 13-09-2013.pdf

673-CHE-2007 POWER OF ATTORNEY 13-09-2013.pdf

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