Title of Invention	METHOD AND SYSTEM FOR POLITE FLOOR RELEASE REQUEST FOR POC SESSION
Abstract	A method and system for requesting a floor in a push-to-talk over Cellular (PoC) session is disclosed. The method includes sending a floor release request by an originating PoC client by using a Media Burst Control Protocol (MBCP) to a target PoC client holding the floor. The method also includes receiving a floor grant message from a PoC server based on sending the floor release request. The originating PoC client includes a processor configured to generate the floor release request. The originating PoC client also includes a transmitter configured to send the floor release request using a Media Burst Control Protocol (MBCP) to a target PoC client holding the floor via a PoC server. In addition, the originating PoC client includes a receiver configured to receive a floor grant message based from the second communication device based on the floor release request sent to the second communication device.

Title of Invention

METHOD AND SYSTEM FOR POLITE FLOOR RELEASE REQUEST FOR POC SESSION

Abstract

A method and system for requesting a floor in a push-to-talk over Cellular (PoC) session is disclosed. The method includes sending a floor release request by an originating PoC client by using a Media Burst Control Protocol (MBCP) to a target PoC client holding the floor. The method also includes receiving a floor grant message from a PoC server based on sending the floor release request. The originating PoC client includes a processor configured to generate the floor release request. The originating PoC client also includes a transmitter configured to send the floor release request using a Media Burst Control Protocol (MBCP) to a target PoC client holding the floor via a PoC server. In addition, the originating PoC client includes a receiver configured to receive a floor grant message based from the second communication device based on the floor release request sent to the second communication device.

Full Text	WE CLAIM: 1. A method for requesting a floor in a Push-to-Talk over Cellular (PoC) session, the method comprising: sending a floor release request by an originating PoC client using a Media Burst Control Protocol (MBCP) to a target PoC client holding the floor; and receiving a floor grant message from a PoC server based on sending the floor release request. 2. The method of claim, wherein the floor release request is sent from the originating PoC client to the target PoC client via a PoC server. 3. The method of claim 1 further comprising receiving a floor release response from the target PoC client. 4. The method of claim 3, wherein the floor release response is received via a PoC server. 5. The method of claim 1 further comprising sending a sending a floor message to PoC clients associated with the PoC session. 6. The method of claim 1 further comprising sending a floor release message by the target PoC client to the PoC server. 7. An originating Push-to-Talk over Cellular (PoC) client comprising: a processor configured to generate a floor release request; a transmitter configured to send the floor release request using a Media Burst Control Protocol (MBCP) to a target PoC client holding the floor via a PoC server; and a receiver configured to receive a floor grant message based from the second communication device based on the floor release request sent to the second communication device. 8. The originating PoC further comprising a push-to-talk button configured to initiate a process of sending the floor release request. 9. A method for requesting a floor in a Push-to-talk over Cellular (PoC) session as substantially described and explained with reference to the drawings. 10. An originating Push-to-Talk over Cellular (PoC) client as substantially described and explained with reference to the drawings. FIELD OF THE INVENTION Th$ present invention relates to managing a floor jn a communication session. More specifically, the present invention relates to a method and system for requesting a floor in a Push-to-Talk over Cellular session. BACKGROUND OF THE INVENTION Push-to-Talk over Cellular (PoC) session uses a floor to manage session between PoC clients associated with the PoC session. A user of a PoC client having the floor is authorized to talk or speak. A PoC server managing the PoC session may revoke the floor from the PoC client having the floor. The PoC server may revoke the floor, if the PoC client holds the floor for a time that is greater than a maximum time that the PoC client is authorized to hold the floor. Alternatively, a user of the PoC client having the floor can release the floor for the other users in the PoC session, when the user associated with a PoC client having the floor does not have anything to talk or when a user in the PoC session requests the user of the PoC client having the floor to release the floor. A user in the PoC session can request the PoC client having the floor to release the floor by sending a message. For example, the user requesting for the floor can use a Short Messaging Service (SMS) message or an Instant Message (IM) to send a request for the floor to the POC client having the floor. However, an application used for sending an SMS or an IM is different from an application used for the PoC session. As a result, a request for releasing the floor may not be rendered to the PoC client immediately or the request may be ignored by the user of the PoC client having the floor as the user need to switch between the applications for used for SMS (or IM) and the application used for PoC session. In light of the above discussion, there is a need for a method and system for sending a floor release request that can rendered to the user of the PoC client having the floor. Further, the method and system should also use an application that is used to manage the PoC session. SUMMARY OF THE INVENTION In an embodiment, a method for requesting a floor in a Push-to-Talk over Cellular (PoC) session is disclosed. The method includes sending a floor release request by an originating PoC client by using a Media Burst Control Protocol (MBCP) to a target PoC client holding the floor. The method also includes receiving a floor grant message from a PoC server based on sending the floor release request. In an embodiment, the floor release request is sent from the originating PoC client to the target PoC client via a PoC server. In another embodiment, an originating PoC client is disclosed. The originating PoC client includes a processor configured to generate the floor release request. The originating PoC client also includes a transmitter configured to send the floor release request using a Media Burst Control Protocol (MBCP) to a target PoC client holding the floor via a PoC server. In addition, the originating ♦ » PoC client includes a receiver configured to receive a floor grant message based from the second communication device based on the floor release request sent to the second communication device. In an embodiment, the originating PoC client also includes a push-to-talk button configured to initiate a process of sending a floor release request. 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 FIGURES FIG. 1 illustrates a communication network, in accordance with one embodiment of the present invention. FIG. 2 illustrates an originating PoC client, in accordance with one embodiment of the present invention. FIG. 3 illustrates a target PoC client, in accordance with one embodiment of the present invention. FIG. 4 illustrates a floor release request, in accordance with one embodiment of the present invention. FIG. 5 illustrates a floor release response, in accordance with one embodiment of the present invention. FIG. 6 illustrates a floor release message, in accordance with one embodiment of the present invention. FIG. 7 illustrates a flow chart depicting a method for requesting a floor in a Push-to-talk over Cellular (PoC) session, in accordance with one embodiment of the present invention. FIG. 8 illustrates a message flow diagram for requesting a floor in a Push- to-talk over Cellular (PoC) session, in accordance with one embodiment of the present invention. DETAILED DESCRIPTION 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. FIG. 1 illustrates a communication network 100, in accordance with one embodiment of the present invention. The communication network 100 can include one or more PoC servers and a plurality of PoC clients. An example of the communication network 100 includes, but is not limited to, a cellular communication network. For the purpose of this description, the communication network 100 is shown to include a PoC server 102, a PoC client 104, a PoC client 106, a PoC client 108, and a PoC client 110. In some embodiments, the PoC client 104 may be referred to as an originating PoC client. In some embodiments, the PoC client 106 may be referred to as target PoC client. Examples of PoC clients include, but are not limited to, mobile phones and personal digital assistants, laptop computers, personal computers. This embodiment will be explained with the help of the PoC server 102, the PoC client 104, the PoC client 106 and the PoC client 108. However, it will be apparent to a person ordinarily skilled in the art that the present embodiment can be explained and/or implemented by using any other PoC server and PoC clients in the communication network 100. The PoC server 102 facilitates a PoC session. The PoC client in the PoC session can communicate with each other by using a Media Burst Control Protocol (MBCP). A PoC client in the PoC session can send a floor release request to a PoC client having the floor through the PoC Server. A user of a PoC client having the floor is authorized to talk or speak. For example, the originating PoC client 104 (PoC client that wants a floor) can send a floor release request the target PoC client 106 (having the floor). The PoC server 102 can facilitate • r transfer of the floor from the target PoC 106 to the originating PoC 104. Functionalities of the originating PoC client 104 that enables the originating PoC client 104 to send a floor release request to the target PoC client 106 is explained with help of FIG. 2. FIG. 2 illustrates the originating PoC client 104, in accordance with an embodiment of the present invention. The PoC originating client 104 includes a Push-to-Talk (PTT) button 202, a processor 204, a transmitter 206, and a receiver 208. The PTT button 202 is configured to initiate a floor release request. For example, the PTT button 202 can be configured to send a floor release request to the target PoC client 106 on a double push. The processor 204 is configured to generate a floor release request, based initiation of the floor release request. The floor release request of this embodiment also includes a unique identifier of the originating PoC client 104. A format for floor release request is explained with help of FIG. 4. After the floor release request is generated by the processor 204, the transmitter 206 sends the floor release request to the target PoC client 106 via the PoC server 102. The PoC server 102 sends a floor grant message to the originating PoC client 104, based on receiving a floor release message form the target PoC client 106. A format of the floor release message is explained with help of FIG. 6. The receiver 208 is configured to receive the floor grant from the PoC server 102. Thereafter, the originating PoC client 104 is authorized to talk or speak in the PoC session. • t FIG. 3 illustrates the target PoC client 106, in accordance with an embodiment of the present invention. The target PoC client 106 is shown to display names of users in the PoC communication session. For example, the target PoC client 106 is shown to display 'Joe', 'Laura', 'Rick' and 'Linda'. 'Rick' is associated with the originating PoC client 104. In addition to the names of users in the PoC session, the target PoC client 106 displays a message 'Rick is requesting you to release the floor'. The message is transmitted to the target PoC client 106 by using MBCP. As a result, the message is instantly displayed on the target PoC client 106. Thereafter, a user of the target PoC client 106 can decide to release the floor or ignore the message. FIG. 4 illustrates a floor release request, in accordance with one embodiment of the present invention. The floor release request of this embodiment includes a unique identity of the originating PoC client 104, in addition to the standard parameters/fields in the floor release request. The unique identity of the originating PoC client 104 enables the PoC server 102 to send the floor grant (based on floor release message or floor release response message received from the target PoC client 106) to the originating PoC client 104. In addition, the unique identity of the originating PoC client 104 enables the PoC server 102 to send a floor release response (based on a floor release response received from the target PoC client 106). The floor release request is * » explained in detail in Open Mobile Alliance (OMA) PoC specifications. FIG. 5 illustrates a floor release response, in accordance with one embodiment of the present invention. The floor release response of this embodiment includes a unique identity of the originating PoC client 104, in addition to the standard parameters/fields in the floor release response. The unique identity of the originating PoC client 104 enables the PoC server 102 to send the floor release response (based on floor release response received from the target PoC client 106) to the originating PoC client 104. Further, the PoC server 102 replaces the synchronization source (SSRC) field with its SSRC. This enables the originating PoC client 104 to correlate to the exact POC session. The floor release response also includes a reason code. The reason code is a variable field and can take different values based on the action taken by use of the target PoC client 106. Examples of these values include, but are not limited to, 'Success, the PoC Client was reached', 'Rejected', 'Operation Not Permitted', 'Time Out', and 'Floor is Idle'. 'Success, the PoC Client was reached' indicates that the target PoC client has received the floor release request; however it does not mean that the user of the target PoC client has actually released the floor. The floor release from the user of the target PoC client may take time. 'Rejected' indicates that the target PoC client rejected the request. For example, the target PoC client may not accept floor release request messages. • * 'Rejected' does not necessarily mean that the user of the target PoC client manually rejected the floor release request. 'Operation Not Permitted' indicates that the PoC server determined that the floor release request cannot be sent to the target PoC Client, due to some reason, for example, the user of the target PoC client blocked floor release requests. 'Time Out' indicates that PoC server did not get any response from the target PoC client in a stipulated time. For Time Out', the originating PoC client starts a 'timer', when it sends the floor release request. The originating PoC client can retransmit the floor release request, when the timer times out (based on the policies defined at the originating PoC client). 'Floor is Idle' indicates that the floor is idle to be taken. The floor release request is explained in detail in OMA PoC specifications. FIG. 6 illustrates format for sending a floor release message, in accordance with one embodiment of the present invention. The floor release message of this embodiment includes a unique identity of the originating PoC client 104, in addition to the standard parameters/fields in the floor release message. The unique identity of the originating PoC client 104 enables the PoC server 102 to send the floor grant (based on floor release message received from the target PoC client 106) to the originating PoC client 104. The floor release message is explained in detail in OMA PoC specifications. FIG. 7 illustrates a flow chart depicting a method for requesting a floor in a . Push-to-talk over Cellular (PoC) session, in accQrdance with one embodiment of the present invention. The method is explained with help of FIG. 1, FIG. 2 and FIG. 4. However, it will be apparent to a person ordinarily skilled in the art that the present embodiment can be explained/ practiced with help of any suitable communication network and/ or originating PoC client. Further, the method can use more number of steps as depicted in FIG. 7. The method for requesting a floor in a Push-to-talk over Cellular (PoC) session is initiated at step 702. At step 704, a floor release request is sent by the originating PoC client 104 to the target PoC client 106. The originating PoC client can send the floor release request by using the floor release request explained in FIG. 4. Further, the originating client 104 sends the floor release request by using the MBCP. At step 706, the originating PoC client 104 receives a floor grant message from the PoC server 102. The PoC server 102 sends the floor grant message to originating PoC client, based on the floor release message received from the target PoC client 106. Thereafter, the method for requesting a floor in a Push-to-talk over Cellular (PoC) session terminates at step 708. The method for requesting a floor in a Push-to-talk over Cellular (PoC) session is explained in detail with help of a call flow diagram of FIG. 8. FIG. 8 illustrates a message flow diagram for requesting a floor in a Push- to-talk over Cellular (PoC) session, in accordance with one embodiment of the • ♦ present invention. FIG. 8 is shown to include the PoC server 102, the originating PoC client 104, the target PoC client 106 and the PoC client 108. The PoC client 108 is any PoC client (other than the originating PoC client and target PoC client) that is associated with the PoC session along with the originating PoC client 104 and the target PoC client 106. Although, the call flow diagram is explained with help of the originating PoC client 104, the target PoC client 106 and the client 108 associated with the PoC session, however it will apparent to a person ordinarily skilled in the art the present embodiment can be explained/ practiced with help of a PoC session with an originating PoC client, a target PoC client, and any number of PoC clients. In an embedment, the PoC session is already established. To initiate the process of requesting the floor, the originating PoC client 104 sends a floor release request 802 to the PoC server 102. The originating PoC client 104 sends the floor release request, as the user of the originating PoC client 104 wants talk or speak. The originating PoC client adds its unique identifier in the floor release request. This identifier enables the PoC server and the target PoC client to identify a PoC client requesting for the floor (for example, the originating PoC client 104). Further, the originating PoC client 104 uses the MBCP message to send the floor release request. As a result, a message related to the floor release request can be immediately displayed on the display of the target PoC client 106 (as shown in FIG. 3). On receiving the floor release request, the PoC server 102 looks-up for the target PoC client 106 in, for example, a look-up table based on SSRC of the PoC client. The PoC server 102 then forwards the floor release request 802 as a floor release request 804 to the target PoC client 106. The target PoC client 106 sends a floor release response 806 (as shown in FIG. 5) as an acknowledgement to the floor release request 804 to the PoC server 102. The target PoC client 106 'Success' as a text in the response and uses reason code as 'Success, the PoC Client was reached'. Thereafter, the floor release response 806 is forwarded as a floor release response 808 to the target PoC client 106. A pop-up message can be displayed on the target PoC 106 (as shown in FIG. 3), based on the floor release request 804 received by the target PoC client 106. The user of the target PoC client 106 can then decide to either release the floor for the originating PoC client or ignore the message. As the user of the target PoC client 106 has an option to ignore the floor release request, the floor release request 802 (804) of this embodiment can also be called as a 'polite floor release request'. The target PoC client 106 sends a floor release message 810 to the PoC server 102, if the user of the target PoC client 106 decides to release the floor. In an embodiment, the target PoC client 106 can release the floor, based on preferences of the user of the target PoC client 106. For example, the user of the target PoC client 106 has something to talk, when the target PoC client 106 received the floor release request. In this example, the user of the * , target PoC client 106 can release the floor when the user finishes talking. The user of the target PoC client 106 can release the floor by pressing the PTT button available the target PoC client in a particular fashion (for example, pressing the PTT button twice). The PoC server grants the floor 812 to the originating PoC client, based on receiving the floor release message from the target PoC client 106. Thereafter, the PoC server 102 sends a floor taken message 814 and floor taken message 816 to the target PoC client 106 and the PoC client 108. The floor taken message is sent to inform the target PoC client 106 and PoC client 108 that the floor is successfully taken by the originating PoC client 104. On receiving the floor, the user of the originating PoC client can talk in the PoC session. The target PoC client adds 'Rejected' in the response code field of the floor release response 806. 'Rejected' in the response code field indicates that user have rejected the floor release request or the target PoC client does not accept such messages. In an embodiment, the PoC server can break a tie between to originating PoC clients for granting floor, when more than one originating clients request for the floor. The PoC server 102 can break this tie based on the policies defined at the PoC server 102. For example, the PoC server 102 can use 'first in first out' policy to break a tie between originating clients requesting for floor. In an embodiment, the PoC server 102 can block all the floor release requests by • * applying a local policy that blocks the floor release requests. This prevents the PoC server 102 from getting flooded with the floor release requests. Various embodiments as described above provide following advantages. The present invention provides a method and system for politely requesting a floor from a user of a target PoC client. The user of target PoC client can release the floor or ignore the floor release request. Further, the present invention gives the user of the target PoC client flexibility to schedule the floor release. For example, the user of the target PoC client may release the floor when the user has finished talking. The present invention can work with pre-established and on- demand PoC session without any change in state of PoC clients or a PoC server. In addition, the PoC server can block all (polite) floor release requests so that the PoC server is not flooded with these requests. While the embodiments of the present invention have been illustrated and described, it will 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.

Full Text

WE CLAIM:
1. A method for requesting a floor in a Push-to-Talk over Cellular (PoC) session, the method comprising:
sending a floor release request by an originating PoC client using a Media Burst Control Protocol (MBCP) to a target PoC client holding the floor; and
receiving a floor grant message from a PoC server based on sending the floor release request.
2. The method of claim, wherein the floor release request is sent from the originating PoC client to the target PoC client via a PoC server.
3. The method of claim 1 further comprising receiving a floor release response from the target PoC client.
4. The method of claim 3, wherein the floor release response is received via a PoC server.
5. The method of claim 1 further comprising sending a sending a floor message to PoC clients associated with the PoC session.
6. The method of claim 1 further comprising sending a floor release message by the target PoC client to the PoC server.
7. An originating Push-to-Talk over Cellular (PoC) client comprising:
a processor configured to generate a floor release request;
a transmitter configured to send the floor release request using a Media Burst Control Protocol (MBCP) to a target PoC client holding the floor via a PoC server; and
a receiver configured to receive a floor grant message based from the second communication device based on the floor release request sent to the second communication device.
8. The originating PoC further comprising a push-to-talk button configured to initiate a process of sending the floor release request.
9. A method for requesting a floor in a Push-to-talk over Cellular (PoC) session as substantially described and explained with reference to the drawings.
10. An originating Push-to-Talk over Cellular (PoC) client as substantially described and explained with reference to the drawings.

FIELD OF THE INVENTION
Th$ present invention relates to managing a floor jn a communication session. More specifically, the present invention relates to a method and system for requesting a floor in a Push-to-Talk over Cellular session.
BACKGROUND OF THE INVENTION
Push-to-Talk over Cellular (PoC) session uses a floor to manage session between PoC clients associated with the PoC session. A user of a PoC client having the floor is authorized to talk or speak. A PoC server managing the PoC session may revoke the floor from the PoC client having the floor. The PoC server may revoke the floor, if the PoC client holds the floor for a time that is greater than a maximum time that the PoC client is authorized to hold the floor. Alternatively, a user of the PoC client having the floor can release the floor for the other users in the PoC session, when the user associated with a PoC client having the floor does not have anything to talk or when a user in the PoC session requests the user of the PoC client having the floor to release the floor.
A user in the PoC session can request the PoC client having the floor to release the floor by sending a message. For example, the user requesting for the floor can use a Short Messaging Service (SMS) message or an Instant Message (IM) to send a request for the floor to the POC client having the floor. However, an application used for sending an SMS or an IM is different from an application used for the PoC session. As a result, a request for releasing the floor may not be rendered to the PoC client immediately or the request may be ignored by the user of the PoC client having the floor as the user need to switch between the applications for used for SMS (or IM) and the application used for PoC session.
In light of the above discussion, there is a need for a method and system for sending a floor release request that can rendered to the user of the PoC client having the floor. Further, the method and system should also use an application that is used to manage the PoC session.
SUMMARY OF THE INVENTION
In an embodiment, a method for requesting a floor in a Push-to-Talk over Cellular (PoC) session is disclosed. The method includes sending a floor release request by an originating PoC client by using a Media Burst Control Protocol (MBCP) to a target PoC client holding the floor. The method also includes receiving a floor grant message from a PoC server based on sending the floor release request. In an embodiment, the floor release request is sent from the originating PoC client to the target PoC client via a PoC server.
In another embodiment, an originating PoC client is disclosed. The originating PoC client includes a processor configured to generate the floor release request. The originating PoC client also includes a transmitter configured to send the floor release request using a Media Burst Control Protocol (MBCP) to
a target PoC client holding the floor via a PoC server. In addition, the originating
♦ »
PoC client includes a receiver configured to receive a floor grant message based from the second communication device based on the floor release request sent to the second communication device. In an embodiment, the originating PoC client also includes a push-to-talk button configured to initiate a process of sending a floor release request.
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 FIGURES
FIG. 1 illustrates a communication network, in accordance with one embodiment of the present invention.
FIG. 2 illustrates an originating PoC client, in accordance with one embodiment of the present invention.
FIG. 3 illustrates a target PoC client, in accordance with one embodiment of the present invention.
FIG. 4 illustrates a floor release request, in accordance with one embodiment of the present invention.
FIG. 5 illustrates a floor release response, in accordance with one embodiment of the present invention.
FIG. 6 illustrates a floor release message, in accordance with one embodiment of the present invention.
FIG. 7 illustrates a flow chart depicting a method for requesting a floor in a Push-to-talk over Cellular (PoC) session, in accordance with one embodiment of the present invention.
FIG. 8 illustrates a message flow diagram for requesting a floor in a Push- to-talk over Cellular (PoC) session, in accordance with one embodiment of the present invention.
DETAILED DESCRIPTION
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.
FIG. 1 illustrates a communication network 100, in accordance with one embodiment of the present invention. The communication network 100 can include one or more PoC servers and a plurality of PoC clients. An example of the communication network 100 includes, but is not limited to, a cellular communication network. For the purpose of this description, the communication network 100 is shown to include a PoC server 102, a PoC client 104, a PoC client 106, a PoC client 108, and a PoC client 110. In some embodiments, the PoC client 104 may be referred to as an originating PoC client. In some embodiments, the PoC client 106 may be referred to as target PoC client. Examples of PoC clients include, but are not limited to, mobile phones and personal digital assistants, laptop computers, personal computers. This embodiment will be explained with the help of the PoC server 102, the PoC client 104, the PoC client 106 and the PoC client 108. However, it will be apparent to a person ordinarily skilled in the art that the present embodiment can be explained and/or implemented by using any other PoC server and PoC clients in the communication network 100.
The PoC server 102 facilitates a PoC session. The PoC client in the PoC session can communicate with each other by using a Media Burst Control Protocol (MBCP). A PoC client in the PoC session can send a floor release request to a PoC client having the floor through the PoC Server. A user of a PoC client having the floor is authorized to talk or speak. For example, the originating
PoC client 104 (PoC client that wants a floor) can send a floor release request the target PoC client 106 (having the floor). The PoC server 102 can facilitate
• r
transfer of the floor from the target PoC 106 to the originating PoC 104. Functionalities of the originating PoC client 104 that enables the originating PoC client 104 to send a floor release request to the target PoC client 106 is explained with help of FIG. 2.
FIG. 2 illustrates the originating PoC client 104, in accordance with an embodiment of the present invention. The PoC originating client 104 includes a Push-to-Talk (PTT) button 202, a processor 204, a transmitter 206, and a receiver 208. The PTT button 202 is configured to initiate a floor release request. For example, the PTT button 202 can be configured to send a floor release request to the target PoC client 106 on a double push. The processor 204 is configured to generate a floor release request, based initiation of the floor release request. The floor release request of this embodiment also includes a unique identifier of the originating PoC client 104. A format for floor release request is explained with help of FIG. 4. After the floor release request is generated by the processor 204, the transmitter 206 sends the floor release request to the target PoC client 106 via the PoC server 102. The PoC server 102 sends a floor grant message to the originating PoC client 104, based on receiving a floor release message form the target PoC client 106. A format of the floor release message is explained with help of FIG. 6. The receiver 208 is
configured to receive the floor grant from the PoC server 102. Thereafter, the
originating PoC client 104 is authorized to talk or speak in the PoC session. • t
FIG. 3 illustrates the target PoC client 106, in accordance with an embodiment of the present invention. The target PoC client 106 is shown to display names of users in the PoC communication session. For example, the target PoC client 106 is shown to display 'Joe', 'Laura', 'Rick' and 'Linda'. 'Rick' is associated with the originating PoC client 104. In addition to the names of users in the PoC session, the target PoC client 106 displays a message 'Rick is requesting you to release the floor'. The message is transmitted to the target PoC client 106 by using MBCP. As a result, the message is instantly displayed on the target PoC client 106. Thereafter, a user of the target PoC client 106 can decide to release the floor or ignore the message.
FIG. 4 illustrates a floor release request, in accordance with one embodiment of the present invention. The floor release request of this embodiment includes a unique identity of the originating PoC client 104, in addition to the standard parameters/fields in the floor release request. The unique identity of the originating PoC client 104 enables the PoC server 102 to send the floor grant (based on floor release message or floor release response message received from the target PoC client 106) to the originating PoC client 104. In addition, the unique identity of the originating PoC client 104 enables the
PoC server 102 to send a floor release response (based on a floor release
response received from the target PoC client 106). The floor release request is
* »
explained in detail in Open Mobile Alliance (OMA) PoC specifications.
FIG. 5 illustrates a floor release response, in accordance with one embodiment of the present invention. The floor release response of this embodiment includes a unique identity of the originating PoC client 104, in addition to the standard parameters/fields in the floor release response. The unique identity of the originating PoC client 104 enables the PoC server 102 to send the floor release response (based on floor release response received from the target PoC client 106) to the originating PoC client 104. Further, the PoC server 102 replaces the synchronization source (SSRC) field with its SSRC. This enables the originating PoC client 104 to correlate to the exact POC session.
The floor release response also includes a reason code. The reason code is a variable field and can take different values based on the action taken by use of the target PoC client 106. Examples of these values include, but are not limited to, 'Success, the PoC Client was reached', 'Rejected', 'Operation Not Permitted', 'Time Out', and 'Floor is Idle'. 'Success, the PoC Client was reached' indicates that the target PoC client has received the floor release request; however it does not mean that the user of the target PoC client has actually released the floor. The floor release from the user of the target PoC client may
take time. 'Rejected' indicates that the target PoC client rejected the request. For
example, the target PoC client may not accept floor release request messages. • *
'Rejected' does not necessarily mean that the user of the target PoC client manually rejected the floor release request. 'Operation Not Permitted' indicates that the PoC server determined that the floor release request cannot be sent to the target PoC Client, due to some reason, for example, the user of the target PoC client blocked floor release requests. 'Time Out' indicates that PoC server did not get any response from the target PoC client in a stipulated time. For Time Out', the originating PoC client starts a 'timer', when it sends the floor release request. The originating PoC client can retransmit the floor release request, when the timer times out (based on the policies defined at the originating PoC client). 'Floor is Idle' indicates that the floor is idle to be taken. The floor release request is explained in detail in OMA PoC specifications.
FIG. 6 illustrates format for sending a floor release message, in accordance with one embodiment of the present invention. The floor release message of this embodiment includes a unique identity of the originating PoC client 104, in addition to the standard parameters/fields in the floor release message. The unique identity of the originating PoC client 104 enables the PoC server 102 to send the floor grant (based on floor release message received from the target PoC client 106) to the originating PoC client 104. The floor release message is explained in detail in OMA PoC specifications.
FIG. 7 illustrates a flow chart depicting a method for requesting a floor in a . Push-to-talk over Cellular (PoC) session, in accQrdance with one embodiment of the present invention. The method is explained with help of FIG. 1, FIG. 2 and FIG. 4. However, it will be apparent to a person ordinarily skilled in the art that the present embodiment can be explained/ practiced with help of any suitable communication network and/ or originating PoC client. Further, the method can use more number of steps as depicted in FIG. 7.
The method for requesting a floor in a Push-to-talk over Cellular (PoC) session is initiated at step 702. At step 704, a floor release request is sent by the originating PoC client 104 to the target PoC client 106. The originating PoC client can send the floor release request by using the floor release request explained in FIG. 4. Further, the originating client 104 sends the floor release request by using the MBCP. At step 706, the originating PoC client 104 receives a floor grant message from the PoC server 102. The PoC server 102 sends the floor grant message to originating PoC client, based on the floor release message received from the target PoC client 106. Thereafter, the method for requesting a floor in a Push-to-talk over Cellular (PoC) session terminates at step 708. The method for requesting a floor in a Push-to-talk over Cellular (PoC) session is explained in detail with help of a call flow diagram of FIG. 8.
FIG. 8 illustrates a message flow diagram for requesting a floor in a Push-
to-talk over Cellular (PoC) session, in accordance with one embodiment of the
• ♦
present invention. FIG. 8 is shown to include the PoC server 102, the originating PoC client 104, the target PoC client 106 and the PoC client 108. The PoC client 108 is any PoC client (other than the originating PoC client and target PoC client) that is associated with the PoC session along with the originating PoC client 104 and the target PoC client 106. Although, the call flow diagram is explained with help of the originating PoC client 104, the target PoC client 106 and the client 108 associated with the PoC session, however it will apparent to a person ordinarily skilled in the art the present embodiment can be explained/ practiced with help of a PoC session with an originating PoC client, a target PoC client, and any number of PoC clients. In an embedment, the PoC session is already established.
To initiate the process of requesting the floor, the originating PoC client 104 sends a floor release request 802 to the PoC server 102. The originating PoC client 104 sends the floor release request, as the user of the originating PoC client 104 wants talk or speak. The originating PoC client adds its unique identifier in the floor release request. This identifier enables the PoC server and the target PoC client to identify a PoC client requesting for the floor (for example, the originating PoC client 104). Further, the originating PoC client 104 uses the MBCP message to send the floor release request. As a result, a message related
to the floor release request can be immediately displayed on the display of the target PoC client 106 (as shown in FIG. 3).
On receiving the floor release request, the PoC server 102 looks-up for the target PoC client 106 in, for example, a look-up table based on SSRC of the PoC client. The PoC server 102 then forwards the floor release request 802 as a floor release request 804 to the target PoC client 106. The target PoC client 106 sends a floor release response 806 (as shown in FIG. 5) as an acknowledgement to the floor release request 804 to the PoC server 102. The target PoC client 106 'Success' as a text in the response and uses reason code as 'Success, the PoC Client was reached'. Thereafter, the floor release response 806 is forwarded as a floor release response 808 to the target PoC client 106.
A pop-up message can be displayed on the target PoC 106 (as shown in FIG. 3), based on the floor release request 804 received by the target PoC client 106. The user of the target PoC client 106 can then decide to either release the floor for the originating PoC client or ignore the message. As the user of the target PoC client 106 has an option to ignore the floor release request, the floor release request 802 (804) of this embodiment can also be called as a 'polite floor release request'. The target PoC client 106 sends a floor release message 810 to the PoC server 102, if the user of the target PoC client 106 decides to release the floor. In an embodiment, the target PoC client 106 can release the floor, based on preferences of the user of the target PoC client 106. For example, the
user of the target PoC client 106 has something to talk, when the target PoC
client 106 received the floor release request. In this example, the user of the * ,
target PoC client 106 can release the floor when the user finishes talking. The user of the target PoC client 106 can release the floor by pressing the PTT button available the target PoC client in a particular fashion (for example, pressing the PTT button twice).
The PoC server grants the floor 812 to the originating PoC client, based on receiving the floor release message from the target PoC client 106. Thereafter, the PoC server 102 sends a floor taken message 814 and floor taken message 816 to the target PoC client 106 and the PoC client 108. The floor taken message is sent to inform the target PoC client 106 and PoC client 108 that the floor is successfully taken by the originating PoC client 104. On receiving the floor, the user of the originating PoC client can talk in the PoC session.
The target PoC client adds 'Rejected' in the response code field of the floor release response 806. 'Rejected' in the response code field indicates that user have rejected the floor release request or the target PoC client does not accept such messages.
In an embodiment, the PoC server can break a tie between to originating PoC clients for granting floor, when more than one originating clients request for the floor. The PoC server 102 can break this tie based on the policies defined at the PoC server 102. For example, the PoC server 102 can use 'first in first out'
policy to break a tie between originating clients requesting for floor. In an
embodiment, the PoC server 102 can block all the floor release requests by
• *
applying a local policy that blocks the floor release requests. This prevents the PoC server 102 from getting flooded with the floor release requests.
Various embodiments as described above provide following advantages. The present invention provides a method and system for politely requesting a floor from a user of a target PoC client. The user of target PoC client can release the floor or ignore the floor release request. Further, the present invention gives the user of the target PoC client flexibility to schedule the floor release. For example, the user of the target PoC client may release the floor when the user has finished talking. The present invention can work with pre-established and on- demand PoC session without any change in state of PoC clients or a PoC server. In addition, the PoC server can block all (polite) floor release requests so that the PoC server is not flooded with these requests.
While the embodiments of the present invention have been illustrated and described, it will 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.

Documents:

http://ipindiaonline.gov.in/patentsearch/GrantedSearch/viewdoc.aspx?id=p4WpIJ3HZzvcCXs1Lqhm4w==&loc=egcICQiyoj82NGgGrC5ChA==

« Previous Patent

Next Patent »

Patent Number

269641

Indian Patent Application Number

528/CHE/2007

PG Journal Number

45/2015

Publication Date

06-Nov-2015

Grant Date

29-Oct-2015

Date of Filing

14-Mar-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	SIMITH NAMBIAR	EMPLOYED AT SAMSUNG INDIA SOFTWARE OPERAATIONS PVT LTD BAGMANE LAKEVIEW BLOCK 'B' NO 66/1 BAGMANE TECH PARK C V RAMAN NAGAR BYRASANDRA BANGALORE 560093 KARNATAKA
2	SUNGJIN PARK	EMPLOYED AT SAMSUNG ELECTRONICS CO LTD GLOBAL STANDARD & RESEARCH LAB TELECOMMUNICATION NETWORK 416 MEATON-3DONG YEONGTONG-GU SUWON KOREA 442 600
3	JHIYE LEE	EMPLOYED AT SAMSUNG ELECTRONICS CO LTD GLOBAL STANDARD & RESEARCH LAB TELECOMMUNICATION NETWORK 416 MEATON-3DONG YEONGTONG-GU SUWON KOREA 442 600

PCT International Classification Number

H04B7/24

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1			NA