Communication system, method for operating a communication system, server unit, method for operating a server unit, communication service client unit and method for operating a communication service client unit

Communication system, method of operating communication system, server unit, method of operating server unit, communication service client unit, and method of operating communication service client unit

Communication system, method for operating a communication system, server unit, method for operating a server unit, communication service client unit and method for operating a communication service client unit

The invention relates to a communication system, a method of operating a communication system, a server unit, a method of operating a server unit, a communication service client unit, and a method of operating a communication service client unit.

The Push-to-Talk (PoC) communication service enables users of a mobile radio participating terminal to simultaneously transmit audio data to one or more receivers.

In this regard, there is a special push-to-talk button used on the mobile radio participating terminal, which enables the user to start inputting voice data when the participating terminal is operated.

When actually inputting the audio data, it usually uses a mobile radio communication network dissemination method to transmit it to the required receiver. This process is called "streaming"

When using the half-duplex method during sound input and transmission, only the sender who inputs and transmits the sound data can transmit the sound data to the receiver, but the receiver cannot send the sound data to the transmission at the same time By. In particular, the receiver cannot interrupt the actions of the sender.

Specifically, the use of push-to-talk communication is the same as the citizen-band (CB) radio method in the traditional user view, but it extends to the transmitter that can transmit audio data to receivers everywhere, and it can use at least one mobile Achieved by proper switching technology of radio communication network.

If a push-to-talk user wishes to send a voice message to the same recipients with which he or she is usually related, push-to-talk enables the user to define a personal, fixed cluster of users. By way of example, a push-to-talk user can define a cluster labeled "friends", which includes related members and their respective addresses, such as a phone number format or a call initiation protocol (SIP) Formal call initiation protocol-Uniform Resource Addresser (SIP-URL).

The cluster can then specify its own cluster address in the form of the call initiation protocol-uniform resource locator, and when the push-to-talk communication is used for the push-to-talk call, a user specifies the cluster address At the beginning, the push-to-talk server computer addresses all users in the cluster and invites all users to join the push-to-talk call.

The first condition for a member of the cluster to be invited is that the member has been registered in the mobile radio communication network that uses the push-to-talk function, that is to say, is "online".

In a push-to-talk call, the related push-to-talk users, whether they actively become the sender or passively become the receiver, are referred to as participants in the push-to-talk call hereinafter.

The cluster management as described in [1] and [2] can simply handle the cluster in the push-to-talk event. Alternatively, clusters can also be used in the events of other communication services. By way of example, a user can use an appropriate cluster to send multimedia message service (MMS) messages to all members of his family.

In the case of push-to-talk, for example, a user can use an appropriate cluster to start a push-to-talk call with all members of his community. For this purpose, the push-to-talk communication network that provides the push-to-talk communication network will include a cluster management server (GM server), in which the user can use and create and manage a cluster. The user is called the administrator of the cluster.

Consistent with the prior art, the main elements of a cluster specification are as follows:-Cluster Discriminator: This is used to provide the cluster with the same identification. By way of example, the form is sip: myfriends@myname.t-mobile.de-cluster-specific attributes: these attributes specify more precise properties of the cluster. It is:-Cluster Information: Information in simple text form (for example: "This is my family").

-Cluster visibility: This specifies which users can discover the cluster (for example, using a search function on the cluster management server). By way of example, the cluster visibility specifically indicates that only the administrator of the cluster can discover the cluster.

-Cluster duration: This specifies how long the cluster is and/or when the cluster is valid. By way of example, the cluster duration can specify a user's "football field friends" cluster to be valid only between 2 pm and 6 pm on Saturday.

-Service specification information: This is the specification information of which cluster events can be used in the communication service. By the example, in the push-to-talk event, there is a difference between "pre-arranged cluster" and "chat cluster". Therefore, if the cluster will be used in a push-to-talk event, the service specification information can be used to indicate which type of cluster is included.

-Cluster members: For such a cluster, this is a list of users belonging to the cluster, that is, cluster members. Each cluster member itself can also become a cluster. In particular, it can be clearly specified by means of identification (ID, for example, a consistent resource addresser for the call initiation agreement). In addition, subsequent attributes can also be specified in each cluster member:-Member rights: This specifies the rights of the cluster member.

-Anonymity: This specifies whether the cluster element can be anonymous during the communication in the cluster.

-Service specification information: This is the specification information of the communication service. For example, in the case of push-to-talk, the function of the push-to-talk call regulator can be used to distribute the service specification information to a cluster member.

Users with relevant rights, such as a cluster administrator, can implement subsequent cluster management operations for the cluster in accordance with the previous technology:-Cluster operations:-Obtain the cluster list-Create a new cluster-Delete the cluster-Modify Cluster properties-operations of members in the cluster:-get member list-add new members to the cluster-delete members in the cluster-modify member properties

In the push-to-talk event, a user uses a cluster in a subsequent manner. For example, refer to the description in Figure 1.

Figure 1 shows a message flow 100 according to the prior art.

In step 106, the user of the first push-to-talk client unit 101 is used as the user who creates a cluster (push-to-talk cluster) and sends a first message 120 to one of the cluster management server computers 104 A second push-to-talk client unit 102 (or related user) and a third push-to-talk client unit 103 (or related user). By way of example, the push-to-talk cluster has an identification (ID) sip: myfriends@abc.de, and the user uses a second message 121 to announce this message. In step 107, the cluster management server The computer 104 transmits the second message 121 to the first push-to-talk client unit 101.

In step 108, the user selects the push-to-talk cluster. In step 109, the user and the push-to-talk cluster start a push-to-talk conversation. For this purpose, the user uses the first push-to-talk client unit 101 to send a third message 122 to the push-to-talk server computer 105. In step 110, the push-to-talk server computer 105 confirms whether the identification (sip: myfriends@abc.de) specified in the third message 122 specifically specifies the push-to-talk cluster. The push-to-talk server computer 105 then sends a fourth message 123 to the cluster management server computer 104 in step 111 to determine and confirm which cluster members are part of the push-to-talk cluster. The cluster management server computer 104 then uses a fifth message 124 in step 112 to send a list of all cluster members in the push-to-talk cluster to the push-to-talk server computer 105. In this example, the cluster includes the second push-to-talk client unit 102 and the third push-to-talk client unit 103.

By sending a sixth message 125 to the second push-to-talk client unit 102 in step 113 and a seventh message 126 to the third push-to-talk client unit 103, the push-to-talk server The computer 105 invites all members in the push-to-talk cluster to join the push-to-talk call that has been set. In this example, once the first cluster member accepts the invitation of the second push-to-talk client unit 102 with an eighth message 127 in step 114, a ninth message 128 is sent to the click in step 116 That is, the initiator of the call is sent to the first push-to-talk client unit 101 to notify that the push-to-talk call has now started, and can transmit voice packets in the push-to-talk call event.

Consistent with the prior art, when a cluster is defined, for example, when a cluster is established in a cluster management server, the members of the cluster must be listed. In particular, the specification of which members the cluster contains is very static. In the case where a cluster includes all members of a user family becoming cluster members, this is not a serious disadvantage because the members of a user family do not change often.

In the case of a taxi operation, for example, it wants to establish a user cluster that sets the currently idle cluster members as their related taxis (or related drivers). Once a taxi becomes idle or enters the service, The cluster management operation implemented on the cluster management server is very inconvenient to "add new members to the cluster" or "delete members from the cluster".

In addition to considering the complexity of taxi operations and the low user-friendliness it creates, when sending messages to the cluster management server, it also causes problems such as the air interface of the mobile radio communication system used for communication. A very large number of communications services.

In addition, it is not necessarily available to the user (for example, in their radio mobile participating terminals) to determine who will then become a member of a cluster. The user may need a large amount of length to establish this information News.

In the case of taxi operation, the taxi operator (for example, or its mobile radio participating terminal) needs to be aware that a taxi becomes idle or enters service at any time, so the taxi operator always has the current information level. The fixed transmission of notification messages is also on the air interface of the mobile radio communication system used for communication, resulting in a very large number of messaging services.

The operation of cluster management using HyperFile Transfer Protocol (HTTP) is described in [2]. The commands used by the Hyperfile Transfer Protocol are described in [3].

[4] describes SIP INVITE, [5] describes SIP SUBSCRIBE, and [6] describes SIP MESSAGE. These are all methods based on the call initiation agreement.

[7] Describes a method of exchanging e-mails, in which a user can register with a server, and can indicate criteria to specify that he has sent e-mails to other users who should be sent, and can indicate a The path used to determine whether the e-mail is sent to him by other users.

Document [8] discloses a network-based system and a method for dynamically managing user clusters. Periodic dynamic user data will be compared with the cluster membership criteria to determine the user cluster.

Document [9] discloses a communication system in which a communication terminal selects a participant in the communication call from a list of possible participants in the communication call according to a geographic distance criterion.

[10] A communication system is disclosed, in which a participant in a communication call is selected from a cluster of possible participants of the communication call according to the geographical locations where the possible participants are respectively located.

The present invention is based on the problem of providing cluster utilization opportunities in the communication service event, and it does not have the aforementioned shortcomings.

This problem is solved by using a communication system, a method of operating a communication system, a server unit, a method of operating a server unit, a communication service client unit, and a method of operating a communication service client unit, which have the characteristics of an independent patent application.

The present invention provides a communication system, which has a communication service client unit, an additional communication service client unit, a communication service server unit, and a server unit, wherein the communication service client unit is used to generate one or more messages, including At least one criterion that can be met or not met by the additional communication service client unit, and includes the request for supplying the communication service, and the specification that the additional communication service client unit meets the criterion and becomes a participant in the provision of the communication service. The server unit is used to generate the list of additional communication service client units that meet the criteria and transmit it to the communication service server unit; and the communication service server unit is used to use the communication service client unit and meet the criteria Become the participants additional communication service client unit and provide the communication service.

The present invention also provides a communication system, which has a communication service client unit, an additional communication service client unit, a communication service server unit, and a server unit, wherein the communication service client unit is used to generate one or more messages, It includes at least one criterion that can be met or not met by the additional communication service client unit, and includes a request to supply the communication service, and the additional communication service client unit that meets the criteria and becomes a participant in the provision of the communication service. Specification. The server unit is used to transmit an information item representing the at least one criterion to the communication service server unit; and the communication service server unit is used to utilize the communication service client unit and an additional communication service that meets the criteria to become a participant The client unit provides the communication service.

The present invention also provides a method of operating a communication system, a server unit, a method of operating a server unit, a communication service client unit, and a method of operating a communication service client unit based on the above-mentioned communication.

Specifically, when a user uses its communication service client unit to request communication services, it is based on dynamically establishing an additional user cluster (or additional communication service client unit), and uses the communication service client unit to specify a criterion. The cluster member and the user participate in the provided communication service, for example, a push-to-talk (PoC) communication.

The user therefore does not statically specify a server unit cluster such as a cluster management server. It can only be manually modified when sending a message to the server unit, such as sending a message specifying that a particular user must be added to the cluster , Instead of specifying a criterion on which the server unit is based and dynamically confirming the cluster (at the beginning of the provision of the communication service).

By way of example, a user in a taxi control center can specify a criterion required to make all currently idle taxis part of the push-to-talk cluster. The server unit dynamically establishes the push-to-talk cluster, for example, by querying existing servers, which includes information about whether each taxi is currently idle. In this way, the user can always accurately send a voice message to the currently idle taxi, without always manually updating the push-to-talk cluster, and it does not need to obtain information about which taxis are currently idle. , These all require a lot of complexity in sending letters.

In this method, the present invention improves user friendliness and significantly reduces the complexity of sending messages.

In the above example, for example, the additional communication service client unit is a form of mobile radio participation terminal belonging to the taxi driver.

For example, the present invention makes the first communication service client unit and the additional communication service client unit become a mobile radio participating terminal according to the global mobile communication system (UMTS) standard or the global mobile communication system (GMS) standard form.

However, the present invention can not only be applied to communication services provided by means of mobile radio communication networks, but also can be applied to communication services provided by means of wired networks, such as a public switched telephone network (PSTN). ). In both cases, the communication service can be provided by the Internet. For example, the communication service is an Internet-based conference communication service, and the communication service client unit corresponds to a kind of Conference communication terminal. The present invention is also applicable to a large number of cluster characteristic communication services.

Specifically, the additional communication service client unit can not only be specified as a participant in the communication service in the form of a list, but can also participate in an "outlined" way, for example, filtering potential participants according to criteria And therefore use a specifiable criterion (or plural specifiable criteria) for dynamic definition.

The present invention can therefore use clusters dynamically defined by criteria in the event of a communication service.

The exemplary embodiments described below have advantages for existing and in some cases standardized communication networks. In order to implement the exemplary embodiment, it does not need to add any new network components to the existing communication network; the existing network components have extended functions. The exemplary embodiment can therefore be implemented in a simple and inexpensive way.

In one embodiment, the user can specify the maximum number of additional communication service client units that can participate in the communication service. Specifically, the user therefore has the ability to control the dynamically established cluster size.

If the additional communication service client unit cluster that meets the criteria is already provided in the communication service, that is, it changes during the communication service period, then by way of example, the service provided at the beginning of the service does not meet the criteria, but An additional communication service client unit that now meets the criteria can also become a participant, for example, it can be invited to join the provided communication service (such as a conference). Conversely, one of the additional communication service client units that no longer meets the criteria can be excluded from the provided communication service, for example from a meeting. In practice, the server unit can periodically check the criteria.

The server unit and the communication service server unit can be provided by the same server computer.

In one embodiment, in response to the second message, the communication service server unit sends a message to the communication service client unit to inform which communication service client unit of the additional communication service client unit currently meets the criterion. The communication service client unit can then confirm whether the additional communication service client unit that currently meets the criteria and becomes a participant can actually provide the communication service.

Specifically, the present invention extends the cluster management operations provided in accordance with the prior art. In addition, it also explicitly extends the request sent by the communication service client unit to the communication service server unit. For example, it extends the communication service that can be provided by the communication service using a dynamically defined cluster as a cluster member of the participant. Specification.

The server unit can be in the form of a cluster management server unit. By way of example, it can also extend the prior art and be provided by a cluster management (GM) server computer, or be provided by any other server computer. supply.

The preferred embodiments of the present invention can be established in the scope of related patent applications. Other minor modifications of the present invention described in conjunction with the communication system can also be appropriately modified, and the method of operating the communication system, the server unit, the method of operating the server, the communication service client unit, and the method of operating the communication service client unit Application.

The information item representing the at least one criterion may be the at least one criterion itself.

In addition, the communication service client unit can be used to send one or more messages with the at least one criterion to the server unit.

Consistent with a fine adjustment of the present invention, the server unit is used to store the at least one criterion.

In addition, the server unit can be used as a cluster management server unit.

By way of example, the request is located in the first message from the one or more messages and is transmitted from the communication service client unit to the communication service server unit.

In one embodiment, the criterion is located in the second message from the one or more messages and transmitted from the communication service client unit to the server unit.

In one embodiment, the criterion is located in the first message from the one or more messages (for example, and delivered from the communication service client unit to the server unit).

In one embodiment, the server unit generates a list of the additional communication service client units by transmitting a third message to at least one information server unit, and the third message includes a check for the additional communication service Whether the client unit meets the information request required by the standard.

In another embodiment, the communication service server unit generates a list of the additional communication service client units by transmitting a third message to at least one information server unit, and the third message includes a method for checking the Whether the additional communication service client unit meets the information request required by the standard.

Specifically, the server unit or the communication service server unit requires an information server unit with criterion information to obtain the information for checking that the list is generated according to the criterion.

By way of example, the information server unit is a presence server unit or a location server unit. According to this, for example, the information related to the criteria is location information or presence information.

If the server unit or the communication service server unit periodically checks the criteria (so it is always possible to check which additional communication service client units currently meet the criteria), for example, it can subscribe to a location server or exist Server, so it is always informed about the state change of the additional communication service client unit.

In one embodiment, the one or more messages also include another list of some of the additional communication service client units, and one of the additional communication service client units only appears on the other list and meets the criterion. In order to become a participant in the provision of communication services.

Therefore, the additional communication service client unit can be used to filter the participants in the communication service based on the criteria and define a list of potential cluster members.

By way of example, the communication service is a communication service based on Call Initiation Protocol (SIP).

Using communication identification, by using dynamic clusters (or sub-clusters), different cluster combinations (or sub-cluster combinations) can be implemented during the call of the call initiation protocol. In particular, for example, "whispering" and "sidebars" can be implemented. By way of example, users participating in the cluster communication can send voice data to a dynamically defined sub-cluster, and this voice data can only be received by members of the sub-cluster.

In one embodiment, at least one criterion in one or more messages is specifically specified based on Extensible Markup Language (XML).

By way of example, the communication service is a push-to-talk communication service, a communication service for sending instant messages, a multimedia message (MMS) communication service, or a conference communication service.

As mentioned above, the server unit checks the validity of the list of additional communication service client units that meet the criteria in the process of providing communication services (for example, in a periodic manner), and updates the list if appropriate, And transmit the update list to the communication service server unit.

As mentioned above, the communication service server unit is used to change the participants in the communication service according to the update list.

Consistent with another minor adjustment of the present invention, the communication service server unit checks whether the additional communication service client unit still meets the criteria in the process of providing communication services (for example, in a periodic manner), and if appropriate, changes Participants in this communication service.

In one embodiment, the communication service is provided as another communication service part of the server unit that provides the communication service.

Specifically, the dynamic establishment of sub-clusters of a cluster is used in the event of communication services provided by the cluster. By way of example, the push-to-talk communication is used in the event of a push-to-talk call, where the participant of the push-to-talk communication (or the client unit it uses) meets the criterion.

Figure 2 shows a message flow diagram 200 according to an exemplary embodiment of the invention.

The message flow 200 occurs between a cluster management client unit 201, a service section (ServiceX) client unit 202, a service section server unit 203, and a cluster management server unit 204. In this case, you can use the service section that represents any communication service in its event cluster.

Accordingly, for example, the service segment is a push-to-talk communication service, a communication service for sending instant messages, a multimedia short message communication service, or a conference communication service. The service section client unit 202 and the service section server unit 203 are configured according to the configuration settings of the communication service. The following will further explain a structure that uses push-to-talk.

In step 205, the cluster management client unit 201 establishes a (push-to-talk) cluster on the cluster management server unit 204. For this purpose, the cluster management client unit 201 sends a group_creation_request message 216 to the cluster management server unit 204. The group_creation_request message 216 includes:-a list of potential cluster members of the cluster and/or a first list of criteria;-(optional) the maximum number of cluster members in the cluster;-(optional) has been sent The automatic update flag specification;-(optional) specify the value of other parameters of the service section.

The cluster management server unit 204 then establishes an appropriate cluster, and in step 206 sends a response message 217 to the cluster management client unit 201, the message 217 including a unique identification for the establishment of the cluster.

In step 207, the service section client unit 202 sends a request message 218 to request the service section to be provided to the service section server unit 203. The request message 218 includes:-identification of the cluster and/or a second list of criteria;-(optionally) another list of potential cluster members; if the group_creation_request message 216 has specified the list of potential cluster members , The other potential cluster member list can be an expansion of the potential cluster member list;-(optional) the maximum number of cluster members in the cluster;-(optional) automatic updates that have been sent Flag specification;-(optional) request identification for requesting communication services; if the service segment is a push-to-talk communication service, it is called id_proposal push-to-talk communication identification;-(select (Sexual) specifies the values of other parameters of the service segment.

In step 208, the service zone server unit 203 determines that it cannot determine the cluster, in other words, it cannot confirm the current cluster membership. It therefore sends a request message 219 to the cluster management server unit 204 to request the cluster management server unit 204 to determine the cluster. The request message 219 contains:-for the identification of the cluster;-(optional) the second list of the criteria;-(optional) a list of the potential cluster members (it should be understood later that the potential cluster members The list means that it may be expanded by the other potential cluster member list, or when the group_creation_request message 216 does not specify the potential cluster member list, it may be the other potential cluster member list itself);-(Select (Sexually) the specification of the maximum number of cluster members in the cluster;-(optionally) specify the value of other parameters of the service section.

If the automatic update flag has been sent, the service section server unit 203 uses the request message 219 to request the cluster management server unit 204 to notify the cluster component change for a longer period of time. In this case, the service segment server unit 203 is notified by the cluster management server unit 204 whether the composition of the cluster has changed, for example, when a potential cluster member no longer meets the criteria or no longer meets the criteria in the average time. The criteria specified in the first list of the guidelines or the second list of the guidelines. In particular, when the automatic update flag has been transmitted, the cluster management server unit 204 periodically checks whether the potential cluster member currently meets the criteria.

This subscription, in other words, a request action for cluster component change notification, can also be implemented by the service segment server unit 203 at a later time.

In step 210, the cluster management server unit 204 determines all (available) users in the potential cluster member list, which ones meet (available) the criteria in the first list of criteria, and which ones meet the criteria in the first list of criteria. (Available) The criteria in the second list of the criteria. These users form the current list of cluster members. The method used by the cluster management server unit 204 to determine the current cluster members (in other words, the members on the current cluster member list) and the criteria specified in the method in the first list of the criteria or the method in the second list of the criteria related. This will be further explained later.

In step 211, the cluster management server unit 204 sends another response message 220 to the service segment server unit 203, and the response message 220 includes the current cluster member list.

Steps 212 and 213 are performed selectively. In step 212, the service section server unit 203 transmits an information message 221 to the service section client unit 202, which is used to notify the service section client unit 202 of the current cluster member list. By way of example, the information message 221 may also include some current cluster members or a complete list of the current cluster members.

In step 213, the service section client unit 202 sends a confirmation message 222 to the service section server unit 203, which is used to confirm that the request for the service section is generated in step 207. Alternatively, the service section client unit 202 may cancel the request for the service section in step 213, and this sequence will terminate accordingly.

In step 214, if the request for the service segment generated in step 207 is not cancelled in step 213, the service segment server unit 203 will use the current cluster member list for the service segment Request. According to the communication service form of the service section, it will be completed by the service section server unit 203 performing appropriate actions, for example, inviting the cluster member to join a cluster communication.

In step 215, the service section server unit 203 confirms the request for the service section generated in step 207 by sending a request confirmation message 223 to the service section client unit 202. The request confirmation message 223 contains:-(optional) a list of current cluster members;-a response identification; if the service section is a push-to-talk communication service, it is called PK_id for push-to-talk communication Identification;-(optional) specify the value of other parameters of the service section.

If the service section server unit 203 has requested the cluster management server unit 204 to notify the cluster composition change, in the event that the current cluster member list changes, the service section server unit 203 will be notified about the change. List of current cluster members. The service section server unit 203 therefore always knows the current component of the current cluster member list. According to the communication service form of the service section, the change of the current cluster member list (and the related notification of the server unit 203 of the service section) has specific related actions. For example, inviting people who have just joined the current cluster member list Cluster members participate in a cluster communication.

In another embodiment, steps 205 to 211 are performed as described above. However, step 212 must be performed, and the information message 221 includes the current cluster member list and a temporary cluster identification. In step 213, the service section client unit 202 does not send the confirmation message 222 to the service section server unit 203, but sends a new request for the service section to the service section server unit 203 , Which indicates the temporary cluster identification. The rest of the sequence from step 214 is the same as the above steps.

In one embodiment, the cluster management server unit 204 is not a form of separate functional block units, but the service section server unit 203 performs the above-mentioned functions for the cluster management server unit 204. In particular, in steps 219 and 220, there is no interaction between the cluster management server unit 204 and the service section server unit 203, or there is no longer a transmission to the service section server unit 203 as a Notification of a cluster component change notification section.

Figure 3 shows a communication system 300 according to an exemplary embodiment of the invention.

A separate push-to-talk participant server computer (that is, a push-to-talk server computer participant function block) 305 is connected to a first push-to-talk client unit 301 and a second push-to-talk client unit 301 in a manner of a respective interface 304 The push-to-talk client unit 302 is combined with the third push-to-talk client unit 303. The push-to-talk participant server computer 305 is also combined with the push-to-talk control server computer (the push-to-talk server computer control function block) 306.

The push-to-talk control server computer 306 is combined with a location server computer 307, a cluster management server 308, and a presence server computer 309. The cluster management server 308 is similarly combined with the location server computer 307 and the presence server computer 309.

The location server computer 307 provides location information. By way of example, the cluster management server 308 can query the location server computer 307 about the location of the second push-to-talk client unit 302.

The presence server computer 309 provides presence information. By way of example, the cluster management server 308 can ask the presence server computer 309 whether the second push-to-talk client unit 302 is currently available and whether it is closed, for example, or a communication link cannot be established condition.

By way of example, the interface 304 uses the radio access network (RAN), core network (CN) and Internet protocol multimedia sub Provided by system (IMS).

Alternatively, the interface 304 can be provided in a manner such as a public switched telephone network (PSTN) communication network.

The push-to-talk client units 301, 302, and 303 are respectively integrated into a mobile radio communication terminal, which is established according to the respective interface 304, and is based on the global mobile communication system standard, the global mobile communication system standard, Integrate the Packet Radio Service Technology (GPRS) standard or other mobile radio communication standards for communication.

Figure 4 shows a message flow diagram 400 according to an exemplary embodiment of the invention.

The message flow shown is a push-to-talk client unit 401, push-to-talk control server computer 402, cluster management server computer 403, location server computer 404, storage server computer 405, and additional clicks In other words, the client unit 406 is configured and set with reference to Figure 3. The second push-to-talk client unit 302 and the third push-to-talk client unit 303 correspond to the additional push-to-talk client Unit 406.

In the exemplary embodiment described below, it is assumed that the user of the push-to-talk client unit 401 wants to start a push-to-talk call with the following objects-all of their friends;-the object currently in the same town as the object (here In the example, it is the first criterion, criterion_1);-an object that is not currently working (in this example, it is the second criterion, criterion_2).

For this purpose, the user of the push-to-talk client unit 401 establishes a push-to-talk cluster in the cluster management server computer 403 by sending a group_generation_request message 423 in step 407. In order to define the push-to-talk cluster, the user transmits the list (member_list) in the group_generation_request message 423, which contains twenty different users (the users friends-that is, potential cluster members) and the According to the first criterion (criteria_1) defined in the group_generation_request message 423, these friends must be in Hamburg while the push-to-talk cluster is used.

The group_generation_request message can be transmitted using an instruction obtained by a Hyper File Transfer Protocol (HTTP), such as the form shown in Table 1.

<tables><img file="twi403148b_d0001.tif" he="680" id="i0001" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1807" /></tables><tables><img file="twi403148b_d0002.tif" he="1274" id="i0002" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1824" /></tables>

The instruction to get the hyperfile transfer protocol connection is described in [3] (the cluster management operation using the hyperfile transfer protocol is described in [2]).

In Table 1 and subsequent tables, in accordance with the exemplary embodiment, the entities provided for traditional messages will be indicated in bold.

In step 408, the cluster management server computer 403 responds to the push-to-talk client unit 401 by sending a group_generation_response message 424, which contains the unique cluster identification for the push-to-talk cluster, in this case , The recognition is sip: myfriends@abc.de.

In step 409, the user of the push-to-talk client unit 401 selects the push-to-talk cluster and specifies the second criterion (criteria_2) (both the first criterion and the second criterion may include plural criteria) to use The push-to-talk client unit 401 starts a push-to-talk conversation with potential cluster members that meet the first criterion and the second criterion in the push-to-talk cluster. The first criterion and the second criterion dynamically describe the push-to-talk cluster, so as time passes, the potential cluster members that meet the first criterion and the second criterion may change, in other words, it is displayed in the group_generation_request The user list contained in the message 423 may change.

The user of the push-to-talk client unit 401 wishes to be able to take into account the current components of the push-to-talk cluster during the initial push-to-talk call. The push-to-talk cluster is established by potential cluster members meeting the first criterion and the second criterion at any time. In particular, during the push-to-talk call, potential cluster members who are not currently participating in the push-to-talk call meet the first criterion and the second criterion (compared to the previous non-compliance situation). ), you need to be invited to the push-to-talk call. To achieve this, the user of the push-to-talk client unit 401 sets the automatic update flag (sutimatic_update_flag).

In step 410, the user initiates the push-to-talk call by sending an INVITE message 425 to the push-to-talk control server computer 402. The INVITE message 425 is set according to a SIP INVITE. SIP INVITE is described in [4]. The INVITE message 425 includes the specifications of the second criterion (criteria_2) and the automatic update flag specifications that have been set. For example, this is done using a catalog format, which has a definition that is new to the prior art. For example, the INVITE message 425 is in the form in Table 2.

<tables><img file="twi403148b_d0003.tif" he="331" id="i0003" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1789" /></tables><tables><img file="twi403148b_d0004.tif" he="1285" id="i0004" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1827" /></tables>

In step 411, the push-to-talk control server computer 402 has received the INVITE message 425 and determined that it cannot determine the push-to-talk cluster. In other words, it cannot determine which clusters the current push-to-talk cluster is. Produced by members.

Accordingly, the push-to-talk control server computer 402 transmits a first SUBSCRIBE message 426 in step 412 to request the cluster management server computer 403 to determine the current (existing) cluster member, in other words, to determine the current instant In other words, the cluster is produced by which cluster members. In order for the cluster management server computer 403 to determine the current cluster membership, the first SUBSCRIBE message 426 includes the second criterion. In this exemplary embodiment, the first SUBSCRIBE message 426 is set according to SIP SUBSCRIBE, for example, as shown in Table 3 (SIP SUBSCRIBE is described in [5]).

<tables><img file="twi403148b_d0005.tif" he="1645" id="i0005" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1836" /></tables>

As mentioned, this second criterion must be a cluster member that is not currently working.

Because the cluster management server computer 403 needs the current location (location status) of the potential cluster member (or the push-to-talk client unit used by the potential cluster member) to confirm the current cluster member, the cluster The management server computer 403 sends a second SUBSCRIBE message 427 to the location server computer 404 in step 413 (according to SIP SUBSCRIBE) to subscribe to the location server computer 404 and obtain information about the respective potential cluster members Information about the location status.

In addition, the cluster management server computer 403 needs information about whether the potential cluster member is currently working to confirm the current cluster member. This information will exist in the presence information item (presence state) managed by the presence server computer 405 for this cluster member for each potential cluster member. Accordingly, the cluster management server computer 403 sends a third SUBSCRIBE message 428 to the presence server computer 405 in step 414. The second SUBSCRIBE message 427 and the third SUBSCRIBE message 428 are transmitted for each potential cluster member. For the first cluster member with the identification sip: freund01@web.de, as shown in the example in FIG. 4, the identification exists in the first SUBSCRIBE message 427 and the second SUBSCRIBE message 428.

As mentioned, the first criterion is its friend, in other words, the potential group member must be located in the town of Hamburg. Alternatively, the first criterion may also be a location criterion related to the location of the user (or the push-to-talk client unit 401). By way of example, the first criterion can be that the user or the push-to-talk client unit 401 is located within a radius of 5 kilometers and belongs to the potential cluster member of the cluster (or its push-to-talk client unit). In this case, the cluster management server computer 403 also needs the location information of the user of the push-to-talk client unit 401 to confirm the current cluster member, and accordingly not only for all potential cluster members, Also for the user of the push-to-talk client unit 401, the first SUBSCRIBE message 427 is sent to the location server computer 404. However, in the subsequent description, it is assumed that the first criterion is that the cluster member must be located in the town of Hamburg.

As mentioned, the first SUBSCRIBE message 427 transmitted to the location server computer 404 separately for each potential cluster member, then in step 415, the location server computer 404 uses a separate first NOTIFY message In response to 429, the first NOTIFY message 429 includes the location status of the respective cluster member.

Similarly, in step 416, for each cluster member, a second SUBSCRIBE message 428 may be sent to the presence server computer 405, and the presence server computer 405 transmits a second NOTIFY message 430 to the cluster. The management server computer 403 responded. The second NOTIFY message 430 contains information about whether each potential cluster member is currently in a working state.

The cluster management server computer 403 uses the information transmitted in step 415 and step 416 to check whether each potential cluster member meets the first criterion and the second criterion in step 417 to confirm the current cluster member. In step 418, the cluster management server computer 403 uses a third NOTIFY message 431 to transmit the current member list (current_member_list) to the push-to-talk control server computer 402. In this example, the third NOTIFY message 431 is in a form based on SIPNOTIFY, and is displayed in Table 4.

<tables><img file="twi403148b_d0006.tif" he="662" id="i0006" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1798" /></tables><tables><img file="twi403148b_d0007.tif" he="898" id="i0007" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1818" /></tables>

After receiving the third NOTIFY message 431, the push-to-talk control server computer 402 has information about the current cluster member user. Optionally, steps 412 and 420 can also be performed now. In step 419, the push-to-talk control server computer uses a MESSAGE message 432 to send the current group member list (current_group_list)-in another embodiment, only the number of the current group members-to the push-to-talk Client unit 401. The MESSAGE message 432 is in the form of SIP MESSAGE. SIP MESSAGE is described in [6].

In step 420, the push-to-talk client unit 401 responds with a second MESSAGE message 433, which is also in the form of SIP MESSAGE, specifically specifying that it is really necessary to start a push-to-talk call with the current cluster member.

In step 421, the push-to-talk control server computer 402 sends a second INVITE message 434 to all current cluster members, in this example, to all additional push-to-talk client units 406. The second INVITE message 434 is in the form of SIP INVITE. Specifically, step 421 is also an action of inviting all additional push-to-talk client units 406 to join the established push-to-talk call. This is done in the traditional way. In response, each additional push-to-talk client unit 406 sends a first 200 OK message 435 (according to SIP 200 OK) to the push-to-talk control server computer 402.

By sending the first 200 OK message 435, one of the additional push-to-talk client units 406 (or its related user) accepts the invitation and joins the established push-to-talk call. When the push-to-talk control server computer 402 has received the first 200 OK message 435 (in other words, after one of the current cluster members has received an invitation to join the push-to-talk call), the push-to-talk control server The device computer 402 sends a second OK message 436 to the push-to-talk client unit 401, which notifies that one of the current cluster members has accepted the invitation to join the push-to-talk call.

Now all friends of the user of the push-to-talk client unit 401 who meet the first and second criteria (and have accepted the invitation to join the push-to-talk call) conduct the push-to-talk call.

Figure 5 shows a message flow diagram 500 according to an exemplary embodiment of the present invention.

In the same way as the exemplary embodiment described with reference to Figure 4, the displayed message flow is a push-to-talk client unit 501, a push-to-talk control server computer 502, a cluster management server computer 503, and a location server computer 504. There is a server computer 505 and an additional push-to-talk client unit 506. In this exemplary embodiment, it is assumed that the user of the push-to-talk client unit 501 wants to start a push-to-talk conversation with all push-to-talk users who are currently in the same university and are not currently working. The terms "current cluster member" and so on used below are the same as those of the exemplary embodiment described with reference to FIG. 4.

In step 507, the push-to-talk client unit 501 transmits a group_generation_request message 524 to the cluster management server computer 503 to request the establishment of a push-to-talk cluster. The group_generation_request message 524 contains the specification of the first criterion (criteria_1), which states that the cluster member must be in the push-to-talk first period, in other words, the push-to-talk cluster is used during the push-to-talk event, and the group The users of the push-to-talk client unit 501 are located in the same university. The group_generation_request message 524 contains the specifications of the second criterion (criteria_2), which states that the current cluster member (that is, the push-to-talk cluster) must not be in a working state. By way of example, the group_generation_request message 524 is in the form shown in Table 5, and the user transmits the group_generation_request message 524 to establish a push-to-talk cluster dynamically defined by the first criterion and the second criterion.

<tables><img file="twi403148b_d0008.tif" he="1032" id="i0008" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1821" /></tables><tables><img file="twi403148b_d0009.tif" he="994" id="i0009" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1812" /></tables>

Now the cluster management server computer 503 needs to determine all the push-to-talk users that meet the first criterion and the second criterion.

In one embodiment, which is not shown in Figure 5, the cluster management server computer 503 performs the following actions. Compared with the embodiment described with reference to FIG. 4, the push-to-talk client unit 501 does not transmit the list of potential cluster members to the cluster management server computer 503. Therefore, the cluster management server computer 503 confirms a list of potential cluster members as basic information, and is undoubtedly a list of general members. For this purpose, the cluster management server computer asks one or more network units for a list of known or appropriate push-to-talk client units. By way of example, these network units are (from the push-to-talk client unit 501 and the cluster management server computer 503, which provide the same operator of the communication network for communication) local location registration center (HLR), A "super" local area location registration center (meta HLR), in other words information that has been stored in the local area location registration center of different operators, or different local location registration centers of different operators.

The list of potential cluster members that has been requested in this way is clearly used by the cluster management server computer 503 as a kind of basic information, which is the same as the steps 413 and 414 described with reference to Figure 4, for each potential The cluster member sends a SUBSCRIBE message to the location server computer 504 or the presence server computer 505, and in this way confirms the location information and presence information of each potential cluster member needed to determine the current cluster member list. Then, the cluster management server computer 503 confirms the current cluster member list (current_member_list). Because the list of potential cluster members confirmed by the cluster management server computer 503 in this embodiment may generally be very large, in fact, the establishment of the list of potential cluster members requires a very high level of complexity in sending messages. Therefore, the embodiment described in Figure 5 below is preferable.

In step 508, the cluster management server computer 503 sends a first SUBSCRIBE message 525 to the location server computer 504. The first SUBSCRIBE message 525 is sent not only to the location server computer 504, but also to all appropriate location servers, in other words to the location server that manages the location information from the push-to-talk client unit.

By way of example, the remaining sequence of using the location server computer 504 is explained. The first SUBSCRIBE message 525 transmitted in step 508 has a specification specifying the first criterion (it is a clear location specification). For example, the first SUBSCRIBE message 525 is in the form shown in Table 6.

<tables><img file="twi403148b_d0010.tif" he="318" id="i0010" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1795" /></tables><tables><img file="twi403148b_d0011.tif" he="1520" id="i0011" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1818" /></tables>

In step 509, the location server computer 504 responds to the SUBSCRIBE from the cluster management server computer 503 by sending a first NOTIFY message 526 to the cluster management server computer 503, in other words the first SUBSCRIBE message 525. In this method, the location server computer 504 sends a message to the list of (push-to-talk) users that meet the first criterion (matched_users_list_1) (or a list of push-to-talk client units used by the user) to The cluster management server computer 503. For example, the first NOTIFY message 526 is in the form shown in Table 7.

<tables><img file="twi403148b_d0012.tif" he="401" id="i0012" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1833" /></tables><tables><img file="twi403148b_d0013.tif" he="1155" id="i0013" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1830" /></tables>

Steps 510 and 511 are performed in the same manner as steps 508 and 509. That is to say, in step 10, the cluster management server computer 503 sends a second SUBSCRIBE message 527 with the second criterion specification to the presence server computer 505 (by way of example, in the same manner as the above, a transmission Other second SUBSCRIBE messages to all appropriate storage server computers). In step 511, the presence server computer 505 sends a second NOTIFY message 528 to the cluster management server computer 503 to perform a list of users that meet the second criterion (matched_users_list_2) (push-to-talk) (Or a list of push-to-talk client units used by the user) response.

In step 512, the cluster management server computer 503 obtains a list of users that meet the first criterion (or the push-to-talk client unit used by the user) and users that meet the second criterion ( Or a list of push-to-talk client units used by the user to confirm the cluster member list in a way of forming their intersection.

In another embodiment, the second SUBSCRIBE message 527 is only sent to the storage server computer that manages information about the user (or the push-to-talk client unit used by the user) listed in the NOTIFY message 526 . Specifically, the cluster management server computer 503 only queries users who meet the first criterion. Accordingly, in step 511, the cluster management server computer 503 only obtains the presence information of users meeting the first criterion. Using the presence information and the information obtained in step 509, the cluster management server computer 503 confirms the list of cluster members in step 512.

The remainder of this process has nothing to do with how the current cluster member list is confirmed. For example, especially as described above, when the cluster management server computer 503 first uses one or more local locations to log in to the center to request appropriate Information method, when confirming the list of potential cluster members, the following process will also be carried out.

In step 513, the cluster management server computer 503 transmits a group_client_response message 529 to the push-to-talk client unit 501 to respond to the request generated by the push-to-talk client unit 501 in step 507. The group_client_response message 529 contains the unique cluster identification used to establish the push-to-talk cluster, in this case sip: myfriends@abc.de, and contains the current cluster member list (or instead, only the current cluster member list Part of the number of users).

In step 514, at a later time, the user of the push-to-talk client unit 501 selects the push-to-talk cluster to match the push-to-talk cluster using the first push-to-talk client unit 501 The cluster members are currently engaged in a push-to-talk call. In addition, in the push-to-talk cluster, the current components of the push-to-talk cluster also need to be considered. In other words, the current cluster members (even if they change during the push-to-talk call) must always be The part of the push-to-talk call (if it receives an invitation).

By way of example, in the process of the push-to-talk call, the cluster members need to be invited immediately after they meet the first criterion and the second criterion. To achieve this goal, the user sets an automatic update flag (automatic_update_flag).

In step 515, the user uses the first push-to-talk client unit 501 to send a first INVITE message 530 to start the push-to-talk call. In this example, the first INVITE message 530 is a form based on SIP INVITE, which conforms to the identity of the unique cluster. The first INVITE message 530 includes an automatic update flag specification that has been sent, for example, by including this specification in the first INVITE message 530 as a method of a call initiation protocol header. Accordingly, the first INVITE message 530 is in the form shown in Table 8.

<tables><img file="twi403148b_d0014.tif" he="655" id="i0014" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1801" /></tables>

In step 516, the push-to-talk control server computer 502 that has received the first INVITE message 530 confirms that it cannot be stubborn with the push-to-talk cluster specified by the cluster identification. In step 531, it therefore uses a third SUBSCRIBE message 531 to request the cluster management server computer 503 to confirm the current cluster membership. The third SUBSCRIBE message 531 is in a form based on SIP SUBSCRIBE, and is shown in Table 9.

<tables><img file="twi403148b_d0015.tif" he="781" id="i0015" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1812" /></tables>

In step 518, the cluster management server computer 503 transmits the current member list to the push-to-talk control server computer 502 by using a third NOTIFY message 518 to respond to the third SUBSCRIBE message 531. The third NOTIFY message 518 is in the form shown in Table 10.

<tables><img file="twi403148b_d0016.tif" he="812" id="i0016" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1812" /></tables><tables><img file="twi403148b_d0017.tif" he="903" id="i0017" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1839" /></tables>

After receiving the third NOTIFY message 518, the push-to-talk control server computer 502 has information about which users are current cluster members. Optionally, steps 519 and 520 can now be implemented. In step 519, the push-to-talk control server computer 502 uses an UPDATE message 533 to send the current member list (current_member_list)-and in another embodiment, only the number of the current cluster members-to the click That is, the client unit 501. The UPDATE message 533 is in the form of SIP UPDATE (or alternatively, it is in the form of SIP INFO).

In step 520, in this embodiment, the push-to-talk client unit 501 responds with a second UPDATE message 534, which is also a SIP UPDATE form, to specify that the push-to-talk with current cluster members should actually be started. That is talking.

The push-to-talk client unit 501 can send a CANCEL message (according to SIP CANCEL, refer to [4]) to the push-to-talk control server computer 502 by replacing the second UPDATE message 534 at this time to terminate The sequence.

In step 521, the push-to-talk control server computer 502 sends a second INVITE message 535 to all current cluster members, in this embodiment, to all additional push-to-talk client units 506. The second INVITE message 535 is in the form of SIP INVITE. Step 521 obviously invites all additional push-to-talk client units 506 to participate in the established push-to-talk call. This is done in a traditional way. In response, each additional push-to-talk client unit 506 transmits a first 200 OK message 536 (according to SIP 200 OK) to the push-to-talk client unit 501.

By sending the first 200 OK message 536, one of the additional push-to-talk client units 506 (or related users) receives the invitation to participate in the established push-to-talk call. When the push-to-talk control server computer 502 has received the first 200 OK message 536 (in other words, once one of the current cluster members has accepted the invitation to participate in the push-to-talk call), the push-to-talk control server The computer sends a second 200 OK message 537 to the push-to-talk client unit 501, notifying that one of the current cluster members has accepted the invitation to participate in the push-to-talk call.

The push-to-talk call is now conducted by a user who meets the first criterion and the second criterion (and accepts the invitation to participate in the push-to-talk call).

When the message flow described in Figures 4 and 5 is performed, as explained, the first push-to-talk client unit 401, 501 and the push-to-talk from the list of current cluster members are created Set up a push-to-talk call between client units. The following text refers to FIG. 6 and FIG. 7 to explain the steps performed according to an exemplary embodiment of the present invention when the composition of the current cluster member list changes.

Figure 6 shows a message flow diagram 600 according to an exemplary embodiment of the present invention.

Consistent with Figures 4 and 5, the displayed message flow is a push-to-talk client unit 601, a push-to-talk control server computer 602, a cluster management server computer 603, a location server computer 604, and additional The push-to-talk client unit 605 is performed, which corresponds to the relevant network elements shown in Figures 4 and 5. In addition, the newly added push-to-talk client unit 606 is included in the displayed message stream.

As pointed out, it is assumed to establish a push-to-talk call with the current cluster member as a participant, and it is assumed that the automatic update flag has been set, and the push-to-talk control server computer 602 has been notified, for example, and In other words, the method of transmitting the first INVITE message 530 in step 515 is used.

It is assumed that the newly added push-to-talk client unit 606 (or the user of the newly added push-to-talk client unit) has not participated in the push-to-talk call so far. By way of example, the current cluster member list is confirmed based on the criteria that the current cluster member (together with the push-to-talk client unit) must be located in Hamburg, but the new user who joins the push-to-talk client unit 606-in This is marked as Friend_17-not in Hamburg town so far, but returning to town Hamburg during the established push-to-talk call.

It is also assumed that the cluster management server computer 603 has asked the location server 604 for the location information of the user Friend_17. For example, in step 413, an appropriate second SUBSCRIBE message 427 to the user Friend_17 has been transmitted. The location server 604, therefore, the user Friend_17 appears in the list of potential cluster members. The user also meets any of the above-mentioned criteria for confirming the availability of the current cluster member list, for example, it is already in an appropriate state of existence.

In step 607, the cluster management server computer 603 is consistent with its request, and is notified by a first NOTIFY message 614 that the new user Friend_17 who has joined the push-to-talk client unit 606 has now returned to Town Hamburg. In other words, the The cluster management server computer 603 is notified about the location status (location_status_17) of the user Friend_17. When the first NOTIFY message 614 has been obtained, the cluster management server computer 603 reconfirms the current cluster member list in step 608, again explicitly filters according to the criteria, and confirms that the user Friend_17 now meets all the pre-defined criteria. Set guidelines.

As described above, the push-to-talk control server computer 602 has also sent a SUBSCRIBE message to the cluster management server computer 603 (for example, the first SUBSCRIBE message 426 in step 412), and requests Be notified about the current composition of the push-to-talk cluster.

Accordingly, the cluster management server computer 603 sends a second NOTIFY message 615 to the push-to-talk control server computer 602 in step 609, informing the push-to-talk control server computer 602 that a new one has now been added Current cluster member (new_member_17).

The subsequent steps 610 and 611 are optional implementations.

In step 610, the push-to-talk control server computer 602 sends a first MESSAGE message 616 (according to SIP MESSAGE) to the push-to-talk client unit 601, and therefore informs the push-to-talk client unit 601 about the new Joined current cluster member.

In response, the push-to-talk client unit 601 sends a second MESSAGE message 617 in step 611, where the push-to-talk client unit 601 is used to confirm that the connection is in progress, in other words invite the user Friend_17 to participate in the push-to-talk Talk about the action of the call. In step 612, the push-to-talk control server computer 602 invites the newly added push-to-talk client unit 606 to participate in the push-to-talk call. This is accomplished by transmitting an INVITE message 618. The newly added push-to-talk client unit 606 responds to the INVITE message 618 with a 200 OK message 619 in step 619. Steps 612 and 613 are implemented in a traditional way based on SIP INVITE and SIP 200 OK. The user Friend_17 then participates in the push-to-talk call.

FIG. 7 shows a message flow 700 according to an exemplary embodiment of the present invention.

As in Figure 6, the message flow shown is the one-click-to-talk client unit 701, the push-to-talk control server computer 702, the cluster management server computer 703, the location server computer 704, and the additional click-to-talk Said between the client unit 705. At the beginning of this sequence, the assumption described with reference to Figure 6 is also applied, but at this time, during the push-to-talk call, no new user (or new push-to-talk) is added to the push-to-talk call. Client unit), but the leaving push-to-talk client unit 706 marked as Friend_05 by the user leaves the push-to-talk call.

First, suppose that the user Friend_05 uses the leaving push-to-talk client unit 706 to participate in the existing push-to-talk call. In particular, the user Friend_05 has so far met the criteria used to determine the current cluster membership. It now assumes that the user Friend_05 violates one of the criteria. By way of example, one criterion is that the current cluster member needs to be located in the town of Hamburg, and the user Friend_05 using the exit push-to-talk client unit 706 is leaving the town of Hamburg.

In the same way as step 607, the location server computer 704 then sends a MOTIFY message 714 to the cluster management server computer 703 in step 714 to notify the cluster management server computer of the latest location status of the user Friend_05.

In the same way as step 608, the cluster management server computer 703 reconfirms the components of the current push-to-talk cluster in step 708. In this case, the cluster management server computer 703 confirms that the user Friend_05 does not meet the criteria that the current cluster member must meet.

According to this and in the same way as step 609, it uses a second NOTIFY message 715 in step 709 to notify the push-to-talk control server computer 702 that the user Friend_05 is no longer a current cluster member.

Steps 710 and 711 are optional implementations. In step 710, the push-to-talk control server computer 702 sends a first MESSAGE message 716 (according to SIP MESSAGE) to the push-to-talk client unit 701, and therefore informs the push-to-talk client unit 701, the User Friend_05 is no longer a member of the current group (remove_member_05). In step 711, the push-to-talk client unit 701 uses a second MESSAGE message 717 (according to SIP MESSAGE) to confirm that the user Friend_05 will be removed from the existing push-to-talk call.

In step 712, by sending a BYE message 718 from the push-to-talk control server computer 702 to the leaving push-to-talk client unit 706, the push-to-talk control server computer 702 changes from the existing The exit push-to-talk client unit 706 is removed during the push-to-talk call.

This is confirmed in step 713 by the exit push-to-talk client unit 706 using a 200 OK message 719. For example, steps 712 and 713 are implemented in a traditional way.

The user Friend_05 is then no longer part of the existing push-to-talk call.

The following text refers to Fig. 8 and Fig. 9 to describe an exemplary embodiment for another application.

Figure 8 shows a message flow 800 diagram according to an exemplary embodiment of the present invention.

In the same way as the above-described exemplary embodiment, the displayed message flow is a push-to-talk client unit 801, a push-to-talk control server computer 802, a cluster management server computer 803, a location server computer 804, and a presence server Between the computer 805 and the additional push-to-talk client unit 806.

Consider that the push-to-talk control server computer 802 has the following functional block units: a call controller 807 and a media regulator 808. The call controller 807 is used to send messages related to the push-to-talk control server computer 802. In other words, it actually does the message sending operation that should be implemented by the push-to-talk control server computer 802. For example, In other words, send a letter to invite a push-to-talk client unit to participate in a push-to-talk call. These sending operations are implemented on the basis of the call initiation protocol. The media regulator 808 controls the push-to-talk call event to distribute the communication data to all the push-to-talk client units participating in the push-to-talk call.

In this exemplary embodiment, it is assumed that the push-to-talk client unit 801 is a push-to-talk client unit of a Berlin taxi company's taxi control center. The push-to-talk cluster labeled "Taxi" can include all taxi drivers (which have one of the individual additional push-to-talk client units 806). Every time the taxi control center receives an order for transporting passengers, it needs to start the push-to-talk communication during a push-to-talk call, and all of them are within the radius of the transported passenger x kilometers, and its settings The taxi driver (or the push-to-talk client unit used by him) who has the status "Taxi Idle" and is not currently transporting another passenger needs to participate in the push-to-talk call.

As explained below, the push-to-talk communication in the push-to-talk call is uniquely distinguished by an identification, and the push-to-talk communication is in the push-to-talk communication (it is the subset of participants in the push-to-talk call) Participants of (in the push-to-talk call event and the push-to-talk communication event) exchange voice data. Specifically, (between all taxi drivers and the taxi control center), for example, in the process of a push-to-talk call, there are multiple set of push-to-talk communications throughout the day, and they have related content. The plural voice data of is transmitted during these push-to-talk communication (between the participants of the corresponding push-to-talk communication).

Compared with (for each order) generating plural push-to-talk calls, generating plural push-to-talk communication in a push-to-talk call (each is for an input order) has the effect of reducing the time required for sending The advantage of complexity.

First, set up a push-to-talk call between the push-to-talk client unit 801 and the additional push-to-talk client unit 806 (this step is not shown), which is as pointed out, the additional push-to-talk client Unit 806 is the push-to-talk client unit for all registered taxis, in other words, all taxis currently providing services (regardless of whether the taxis are idle or in use). This can be done in a traditional way, for example, with reference to the example illustrated in Figure 1. For the remaining part, does it contain a "one-to-many-to-one" topology (in other words, the push-to-talk client unit 801 receives communications from all additional push-to-talk client units 806 during the push-to-talk call Data, but the additional push-to-talk client unit 806 does not receive communication data equally, that is, it does not receive communication data from other individual push-to-talk client units of the additional push-to-talk client unit 806), or A "one-to-many" topological relationship (in other words, the push-to-talk client unit 801 and the additional push-to-talk client unit 806 both receive all communication data from the additional push-to-talk client unit 806, that is, each other Listen clearly in between) is not important.

In the same manner as the above-described exemplary embodiment, for example, in the same manner as steps 413 and 415 in Figure 4, between the cluster management server computer 803 and the location server computer 804 for each from the additional The push-to-talk client unit of the push-to-talk client unit 806 exchanges a first SUBSCRIBE-NOTIFY message pair 833, so as described above with reference to Figure 4, the location server computer 804 always informs the cluster management server Computer 803, the current location status of the additional push-to-talk client unit 806.

Similarly, in step 810, a second SUBSCRIBE-NOTIFY message pair 834 is exchanged between the cluster management server computer 803 and the presence server computer 805. Therefore, in the same manner as the exemplary embodiment described above, the presence server The server computer 805 always informs the cluster management server computer 803 about the current status of the additional push-to-talk client unit 806.

In step 811, there is a push-to-talk call between the push-to-talk client unit 801 and the additional push-to-talk client unit 806.

Now suppose that the passengers required for the first order received by the taxi control center are located in Berlin's Alexanderplatz. The following sequence steps are used by the taxi control center in an existing push-to-talk call to establish push-to-talk communication with those additional push-to-talk client units 806, where the additional push-to-talk client Unit 806 is-participating in the existing push-to-talk call-located within a radius of 3 kilometers of Alexanderplatz in Berlin (in this example, the first criterion), and-its existence status is "Taxi Idle" (in this example) Middle is the second criterion).

These push-to-talk client units from the additional push-to-talk client unit 806 will later be referred to as participants of the push-to-talk client unit.

In step 812, the push-to-talk client unit sends a re-INVITE message 835 (which is based on SIP re-INVITE) with an appropriate content format (Application/Criteria_xml, refer to Table 2) to the push-to-talk The control server computer 802 is used to specify the first criterion and the second criterion. In one embodiment, the re-INVITE message 835 includes a unique push-to-talk communication identification (PK_id_prop). In step 813, the push-to-talk control server computer 802 generates (its own) push-to-talk communication identification (PK_id). In step 814, the push-to-talk control server computer 802 sends a confirmation (clearly as a preliminary response) to the push-to-talk client unit 801, which is in the form of a 183-session-processing message 836 (according to SIP 183 In the form of session processing), it is used to notify the push-to-talk communication identification PK_id.

By way of example, the push-to-talk communication identification is a kind of port number that can uniquely meet the application specification data. In one embodiment, there are two push-to-talk communication identifications, for example, the push-to-talk communication identification PK_id_prop located in the push-to-talk client unit 801 part, and the push-to-talk control server computer 802 Part of the push-to-talk communication identifies PK_id.

In step 815, the push-to-talk control server computer 802 sends a SUBSCRIBE message 837 to the cluster management server computer 803, which is used to notify the push-to-talk communication identification PK_id, the first criterion and the second Guidelines.

As explained above, the cluster management server computer 803 is always notified about the current location status and current existence status of each push-to-talk client unit from the additional push-to-talk client unit 806. According to this information, the cluster management server computer 803 confirms in step 816 that all the push-to-talk client units that become participants, in other words, all come from the additional push-to-talk client unit 806, and meet the first criterion Push-to-talk client unit with the second criterion.

The push-to-talk client unit 806 that becomes a participant is specified by the cluster management server computer in the cluster member list (current_member_list). In step 817, the cluster management server computer 803 sends a NOTIFY message 836 to the push-to-talk control server computer 802, and uses the message 836 to notify the current cluster member list, which is used for the push-to-talk The current cluster member list of the communication is specified by the push-to-talk communication identification PK_id included in the SUBSCRIBE message 837.

Steps 818 and 819 are optional implementations. In step 818, the push-to-talk control server computer 802 uses a first MESSAGE message 839 to inform the push-to-talk client unit 801 of the push-to-talk from the additional push-to-talk client unit 806 The client unit meets the first criterion and the second criterion. In another embodiment, the push-to-talk control server computer 802 only informs the number of push-to-talk client units that will become participants, in other words, additional push-to-talk clients that meet the first criterion and the second criterion The number of cells 806 (#_of_members).

In step 819, the push-to-talk client unit 801 informs whether it is necessary to establish a push-to-talk communication with the push-to-talk client unit specified by the current cluster member list. In this example, it is assumed that there is no need to establish any push-to-talk communication for the push-to-talk client unit specified by the current cluster member list. By way of example, the current push-to-talk client unit list has a specification of 100 push-to-talk client units, and the user in the taxi control center will decide whether there are too many.

Accordingly, the push-to-talk client unit 801 sends a second MESSAGE message 840 to the push-to-talk control server computer 802 in step 819, specifying that it does not need to establish (accept=no) any member of the current cluster The push-to-talk communication of the push-to-talk client unit specified in the list. In addition, the second MESSAGE message 840 includes a revised criterion (criteria_update). For example, when the first criterion is changed to the push-to-talk client unit that wants to participate, it does not have to be within three kilometers of Alexanderplatz in Berlin. It is within one kilometer of Alexanderplatz in Berlin. Consistent with the revised criteria, confirm a (new) current cluster member list in the same way as steps 815, 816, and 817, especially when the push-to-talk control server computer 802 and the cluster management server computer 803 are located. A third SUBSCRIBE-NOTIFY message exchanged to 841.

In the same way as step 818, the (new) current cluster member list is sent (not shown) to the push-to-talk client unit 801. It is now assumed that a push-to-talk communication must be established with the push-to-talk client unit specified by the new model pre-cluster member list. Accordingly, the push-to-talk client unit 801 sends a third MESSAGE message 842 to the push-to-talk control server computer 802 in step 821. The push-to-talk client unit 801 uses this message to specify the need and reason. The push-to-talk client units participating (which meet the revised criteria) together establish a push-to-talk communication.

Using a PK_start message 843, the call controller 807 informs the media modifier 808 that a new push-to-talk communication has been generated in the existing push-to-talk call in step 822. The PK_start message 843 includes the push-to-talk communication identification PK_id for the generated push-to-talk call and the current cluster member list.

In step 823, the media modifier 808 uses an OK message 844 to confirm receipt of the PK_start message 843. In step 824, the push-to-talk control server computer 802 responds to the re-INVITE message 835 by sending a 200 OK message 845.

In step 825, the push-to-talk client unit 801 sends a Floor-Request message 846 to the push-to-talk control server computer 802 to request the right to speak in the generated push-to-talk communication event, in other words The right to send communication data. The Floor-Request message 846 includes the push-to-talk communication identification PK_id used to generate the push-to-talk communication.

In step 826, a decision is made as to whether the push-to-talk client unit 801 has the right to speak; this can be determined by the call controller 807 or the media modifier 808, and therefore, the call controller 807 can communicate with the media The regulator 808 exchanges messages, or directly transmits the Floor-Request message 846 to the media regulator 808. It is assumed that the push-to-talk client unit 801 has the right to speak. Accordingly, according to the push-to-talk control server computer 802 functional block unit that recognizes the right to speak, the media regulator 808 or the call controller 807 sends a Floor-Granted message 848 in step 827 or the call controller 807 in step 828. The push-to-talk client unit 801 is used to recognize that the push-to-talk client unit 801 has the right to speak.

(According to the push-to-talk control server computer 802 functional block unit that recognizes the right to speak,) the call controller 807 in step 829, or the media modifier 808 sends a Floor-Taken message 849 in step 830 To all the push-to-talk client units that can participate, to notify the push-to-talk client units that can participate. In other words, the notification comes from the additional push-to-talk client unit 806 specified by the current cluster member list. For the client unit, in the push-to-talk communication event specified by the push-to-talk communication identification Pk-id included in the Floor-Taken message 849, its voice has been assigned to the push-to-talk client unit 801.

In step 831, the push-to-talk client unit 801 now transmits the communication data 850 to the media regulator 808 during the generation of the push-to-talk communication specified by the push-to-talk communication identification Pk_id for sending to Push-to-talk client unit that can participate. In step 832, the media regulator 808 sends the communication data 850 notified in advance in step 822 to the push-to-talk client units that can participate.

When an additional order is received in the taxi control center, the re-INVITE message in the same manner as in step 812 is used to start additional push-to-talk communication, regardless of the push-to-talk communication that has been generated. In this method, the taxi control center can direct a separate push-to-talk communication in an existing push-to-talk call for each order.

By generating additional push-to-talk communication in the event of the existing push-to-talk call, it is also possible to implement sub-cluster communication in cluster communication, or to implement sub-cluster communication in parallel in the cluster communication. Some members can participate, such as "whispering" and "sidebars".

Fig. 9 shows a message flow 900 according to an exemplary embodiment of the present invention.

In the same way as the message flow described with reference to Figure 8, the message flow shown in Figure 9 is a push-to-talk client unit 901 (a taxi control center), a call controller 907 and a media regulator 908 The push-to-talk control server computer 902, the cluster management server computer 903, the location server computer 904, the presence server computer 905, and (belonging to the taxi driver) additional push-to-talk client unit 906 are performed.

The exemplary embodiment described below is a variation of the exemplary embodiment described with reference to FIG. 8.

Steps 909, 910, and 911 are performed in the same manner as steps 809, 810, and 811.

In step 912, the push-to-talk client unit 901 sends a Floor-Request message 934 to the push-to-talk control server computer 902 to replace the re-INVITE message 835 as in step 812.

In steps 913 and 914, and steps 916 and 917, if the media modifier 908 controls the allocation of the right to speak, messages are exchanged between the call controller 907 and the media modifier 908.

Steps 915, 918 to 927 are performed in the same manner as steps 813 to 823 (however, an OK message is transmitted in step 918 instead of the 183-session-processing message as in step 814). In this exemplary embodiment, the 200 OK message 845 corresponding to the re-INVITE message 835 is not sent back. Of course, it is consistent with the message flow shown in Fig. 9 and it is not sent. In addition, the Floor-Request message 846 is not transmitted because the Floor-Request message 934 has already been transmitted in step 912. Similarly, step 826 is omitted. In the same way as steps 827 and 828, in steps 929 and 928, a Floor-Granted message 935 is sent to the push-to-talk client unit 901, which is a response to the Floor-Request message 934. The additional steps 930 to 933 are performed in the same manner as steps 829 to 832.

In the same way as the sequence described with reference to FIGS. 6 and 7, in the embodiments shown in FIGS. 8 and 9, the cluster members can also join or leave a cluster. This can be done in the same way with reference to Figures 6 and 7, and will not be described in detail here.

Figure 10 shows a message flow 1000 diagram according to an exemplary embodiment of the present invention.

The displayed message flow is a push-to-talk client unit 1001, push-to-talk control server computer 1002, cluster management server computer 1003, location server computer 1004, presence server computer 1005, and additional click-to-talk The client unit 1006 is configured as described with reference to Figure 3. The second push-to-talk client unit 302 and the third push-to-talk client unit 303 correspond to the additional push-to-talk client Unit 1006.

In the exemplary embodiment described below, it is assumed that the push-to-talk client unit 1001 wishes to start a push-to-talk call with the following members-all of its friends;-the object currently in the same town as its counterpart (in this example) It is the first criterion, criterion_1);-objects that are not currently working (in this example it is the second criterion, criterion_2).

For this purpose, the user of the push-to-talk client unit 1001 sends a group_generation_request message 1023 in step 1007 to establish a push-to-talk cluster in the cluster management server computer 1003. In order to define the push-to-talk cluster, the user transmits the list (member_list) in the group_generation_request message 1023, which contains twenty different users (the users friends-that is, potential cluster members) and the According to the first criterion (criteria_1) defined in the group_generation_request message 1023, these friends must be in Hamburg while the push-to-talk cluster is used.

The group_generation_request message can be transmitted using an instruction obtained by a Hyper File Transfer Protocol (HTTP), such as the form shown in Table 1.

<tables><img file="twi403148b_d0018.tif" he="422" id="i0018" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1810" /></tables><tables><img file="twi403148b_d0019.tif" he="1506" id="i0019" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1824" /></tables>

The instruction to get the hyperfile transfer protocol connection is described in [3] (the cluster management operation using the hyperfile transfer protocol is described in [2]).

In Table 1 and subsequent tables, in accordance with the exemplary embodiment, the entities provided for traditional messages will be indicated in bold.

In step 1008, the cluster management server computer 1003 responds to the push-to-talk client unit 1001 by sending a group_generation_response message 1024, which contains the unique cluster identification for the push-to-talk cluster, in this case , The recognition is sip: myfriends@abc.de.

In step 1009, the user of the push-to-talk client unit 1001 selects the push-to-talk cluster and specifies the second criterion (criteria_2) (both the first criterion and the second criterion may include plural criteria) to use The push-to-talk client unit 1001 starts a push-to-talk conversation with potential cluster members that meet the first criterion and the second criterion in the push-to-talk cluster. The first criterion and the second criterion dynamically describe the push-to-talk cluster, so as time passes, the potential cluster members that meet the first criterion and the second criterion may change, in other words, it is displayed in the group_generation_request The user list contained in the message 1023 may change.

The user of the push-to-talk client unit 1001 wishes to be able to take into account the current components of the push-to-talk cluster during the initial push-to-talk call. The push-to-talk cluster is established by potential cluster members meeting the first criterion and the second criterion at any time. In particular, during the push-to-talk call, potential cluster members who are not currently participating in the push-to-talk call meet the first criterion and the second criterion (compared to the previous non-compliance situation). ), you need to be invited to the push-to-talk call. To achieve this, the user of the push-to-talk client unit 1001 sets the automatic update flag (sutimatic_update_flag).

In step 1010, the user initiates the push-to-talk call by sending an INVITE message 1025 to the push-to-talk control server computer 1002. The INVITE message 1025 is set according to a SIP INVITE. SIP INVITE is described in [4]. The INVITE message 1025 includes the specifications of the second criterion (criteria_2) and the automatic update flag specifications that have been set. For example, this is done using a catalog format, which has a definition that is new to the prior art. For example, the INVITE message 1025 is in the form in Table 2.

<tables><img file="twi403148b_d0020.tif" he="1541" id="i0020" img-content="drawing" img-format="tif" inline="yes" orientation="portrait" wi="1830" /></tables>

In step 1011, the push-to-talk control server computer 1002 has received the INVITE message 1025 and determines that it needs to determine the push-to-talk cluster. In other words, it needs to determine which clusters the current push-to-talk cluster is. Produced by members.

Accordingly, the push-to-talk control server computer 1002 transmits a cluster determination request message (cluster determination request) 1026 in step 1012 to request the cluster management server computer 1003 to determine the current (existing) cluster members, in other words , Decide which cluster members are the current push-to-talk clusters. The cluster decision request message 1026 contains a unique cluster identification for the push-to-talk cluster, which in this case is sip: myfriends@abc.de.

After receiving the cluster determination request message 1026, the cluster management server computer 1003 uses a cluster determination response message 1027 to respond to the push-to-talk control server computer 1002 regarding the cluster-related parameters that have been specified in the group_generation_request message ( List of potential cluster members and/or criteria 1. Maximum number of members in the cluster (optional), other service specification parameters (optional)) (step 1013).

In the subsequent step 1014, the push-to-talk control server computer 1002 confirms that it is on the list of potential cluster members (if available) and meets all criteria_1 (if available) and criteria_2 (if available) Participants; these participants thus form a current member list (the push-to-talk control server computer 1002 confirms that the method of these participants is related to the criteria; refer to the application examples described above).

Because the push-to-talk control server computer 1002 needs the current location (location status) of the potential cluster member (or the push-to-talk client unit used by the potential cluster member) to confirm the current cluster member , The push-to-talk control server computer 1002 in step 1015 (according to SIP SUBSCRIBE) sends a first SUBSCRIBE message 1028 to the location server computer 1004 to subscribe to the location server computer 1004 and obtain information about the Information about the location status of each potential cluster member.

In addition, the push-to-talk control server computer 1002 needs information about whether the potential cluster member is currently working to confirm the current cluster member. This information will exist in the presence information item (presence state) managed by the presence server computer 1005 for this cluster member for each potential cluster member. Accordingly, the push-to-talk control server computer 1002 sends a second SUBSCRIBE message 1029 to the presence server computer 1005 in step 1016. The first SUBSCRIBE message 1028 and the second SUBSCRIBE message 1029 are transmitted for each potential cluster member. For the first cluster member with the identification sip: freund01@web.de, as shown in the example in Figure 10, the identification exists in the first SUBSCRIBE message 1028 and the second SUBSCRIBE message 1029.

As mentioned, the first criterion is its friend, in other words, the potential group member must be located in the town of Hamburg. Alternatively, the first criterion may also be a location criterion related to the location of the user (or the push-to-talk client unit 1001). By way of example, the first criterion can be that the user or the push-to-talk client unit 1001 is located within a radius of 5 kilometers and belongs to the potential cluster member of the cluster (or its push-to-talk client unit). In this case, the push-to-talk control server computer 1002 also needs the location information of the user of the push-to-talk client unit 1001 to confirm the current cluster member, and accordingly not only for all the potentials. The cluster members also send the first SUBSCRIBE message 1028 to the location server computer 1004 for the users of the push-to-talk client unit 1001. However, in the subsequent description, it is assumed that the first criterion is that the cluster member must be located in the town of Hamburg.

As mentioned, the first SUBSCRIBE message 1028 that is transmitted to the location server computer 1004 separately for each potential cluster member, then in step 1017, the location server computer 1004 uses a respective first NOTIFY message In response to 1030, the first NOTIFY message 1030 includes the location status of each cluster member (for example, location_status_01).

Similarly, in step 1018, the second SUBSCRIBE message 1029 that may be sent to the presence server computer 1005 for each cluster member, then the presence server computer 1005 transmits a second NOTIFY message 1031 to the instant Click-to-talk to control the server computer 1002 to respond. The second NOTIFY message 1031 contains information about whether each potential cluster member is currently working.

The push-to-talk control server computer 1002 can use the information transmitted in step 1017 and step 1018, and in step 1019, use the method of checking whether each potential cluster member meets the first criterion and the second criterion to confirm the Current cluster members.

Therefore, the push-to-talk control server computer 1002 has information about the current cluster member users. Optionally, steps 1020 and 1021 can also be performed now. In step 1020, the push-to-talk control server computer 1002 uses a first MESSAGE message 1032 to send the current group member list (current_group_list)-in another embodiment, only the number of the current group member-to the instant Push-to-talk client unit 1001. The MESSAGE message 1032 is in the form of SIP MESSAGE. SIP MESSAGE is described in [6].

In step 1021, the push-to-talk client unit 1001 responds with a second MESSAGE message 1033, which is also in the form of SIP MESSAGE, specifying that it really needs to start a push-to-talk call with the current cluster member.

In step 1022, the push-to-talk control server computer 1002 sends a second INVITE message 1034 to all current cluster members, in this example, to all additional push-to-talk client units 1006. The second INVITE message 1034 is in the form of SIP INVITE. Specifically, step 1022 is also an action of inviting all additional push-to-talk client units 1006 to join the established push-to-talk call. This is done in a traditional way. In response, each additional push-to-talk client unit 1006 sends a first 200 OK message 1035 (according to SIP 200 OK) to the push-to-talk control server computer 1002.

By sending the first 200 OK message 1035, one of the additional push-to-talk client units 1006 (or its related user) accepts the invitation and joins the established push-to-talk call. When the push-to-talk control server computer 1002 has received the first 200 OK message 1035 (in other words, after one of the current cluster members has received an invitation to join the push-to-talk call), the push-to-talk control server The device computer 1002 sends a second OK message 1037 to the push-to-talk client unit 1001, which notifies that one of the current cluster members has accepted the invitation to join the push-to-talk call.

Now all friends of the user of the push-to-talk client unit 1001 who meet the first and second criteria (and have accepted the invitation to join the push-to-talk call) conduct the push-to-talk call.

If the automatic update flag has been set in the first INVITE message 1025, the push-to-talk control server computer 1002 will now continue to observe whether a previous cluster member no longer meets the criteria, or whether a new participant is in the Whether the criterion is met in the average time, it always knows the composition of the current cluster, and can therefore cancel or provide invitations to the cluster members appropriately.

In another embodiment, the communication service used in the present invention is "IMS Conferencing" specified by the Third Generation Partnership Project (3GPP). This is a discussion communication service based on the structure of the multimedia subsystem of the Internet protocol. In this case, the functional blocks of a cluster management server computer are covered by a discussion policy server. A discussion policy server uses a discussion policy document to manage the rules and states used in the discussion.

In this embodiment, a discussion client unit sends a criterion to the discussion strategy server according to the discussion strategy control protocol (CPCP), which stores the criterion in an appropriate form in the discussion strategy document, and dynamically creates a discussion participant accordingly Cluster. In one embodiment, the discussion policy server records the criteria and the current cluster member list in the discussion policy file. The discussion strategy server confirms the information needed to generate the current cluster list (for example, the existence information and location information as described above) in the same manner as the above-mentioned discussion exemplary embodiment.

The exemplary embodiments described above have already dealt with (immediately) inviting to join a communication service (for example, a push-to-talk call) when the participant (or the corresponding client unit) meets the predetermined criteria.

However, the present invention can also be used when the potential user (or the corresponding client unit) is not invited, but needs to be dialed by itself, in other words needs to be initiated by the participant itself. An example of this is a chat call (or push-to-talk call), where the user needs to access himself.

As an example, a user wants to use a client unit that is used to dial a push-to-talk control server computer that provides a push-to-talk call. For example, by sending a dial message according to SIP INVITE, it can become the Participants in a push-to-talk call. In the same way as the above embodiment, the criteria are specified and the push-to-talk control server computer checks whether the user who wants to dial meets the prescribed criteria, for example, inquire a cluster management server computer in the same manner as above. Only when the user (or the client unit it uses) meets the criteria, the call is accepted and confirmed (for example, consistent with SIP 200 OK), and the user can then become a participant in the push-to-talk call. If the user does not meet the criteria, the dialing message will receive a rejection response, such as using a rejection message based on SIP REJECT, which can also include the reason for the rejection, and a user will not be able to be in the push-to-talk call Participants.

The follow-up document is the reference of the patent application [1] 3GPP TS 22.250 V6.0.0 (2002-12), "IP Multimedia Subsystem (IMS) group management" [2] Push to talk over Cellular (PoC); List Management and Do -Not-Disturb; PoC Release 2.0[3]RFC "Hypertext Transfer Protocol-HTTP/1.1"[4]RFC3261"SIP:Session Initiation Protocol"[5]RFC3265"Session Initiation Protocol(SIP)-Specific Event Notification"[6 ]RFC3428 "Session Initiation Protocol(SIP) Extension for Instant Messaging"[7]WO 00/16209[8]WO 02/103570 A1[9]US 2002/0107008 A1[10]US 2004/0203907 A1

<p>300Communication System</p><p>301First Push-to-Talk Client Unit</p><p>302Second Push-to-Talk Client Unit</p><p>303Third Push-to-Talk Client Unit</p><p>304Interface</p><p>305Push-to-talk participant server computer</p><p>306Push-to-talk control server computer</p><p>307Location Server Computer</p><p>308Cluster Management Server</p><p>309 exists on the server computer</p><p>100, 200, 400, 500, 600, 700, 800, 900, 1000Message flow icon</p><p>106-116, 205-215, 407-422, 507-522, 607-613, 707-713, 809-832, 909-933, 1007-1022, 1036 sequence steps</p><p>120-128, 216-223, 423-436, 523-537, 614-619, 714-719, 833-850, 934-950, 1023-1035, 1037 messages</p>

Exemplary embodiments of the present invention will be described in the drawings and described in detail below.

Figure 1 shows a message flow chart according to the prior art.

Figure 2 shows a message flow diagram according to an exemplary embodiment of the present invention.

Figure 3 shows a communication system according to an exemplary embodiment of the present invention.

Figure 4 shows a message flow diagram according to an exemplary embodiment of the present invention.

Figure 5 shows a message flow diagram according to an exemplary embodiment of the present invention.

Figure 6 shows a message flow diagram according to an exemplary embodiment of the present invention.

Figure 7 shows a message flow diagram according to an exemplary embodiment of the present invention.

Figure 8 shows a message flow diagram according to an exemplary embodiment of the present invention.

Figure 9 shows a message flow diagram according to an exemplary embodiment of the present invention.

Figure 10 shows a message flow diagram according to another exemplary embodiment of the present invention.