1. Field of the Invention
The invention is related to the field of communication networks and, in particular, to determining the availability of a target party to receive a call prior to setting up the call to the target party.
2. Statement of the Problem
In telecommunications networks, a network presence indicates the status of a party on a communication network, or the communication capabilities of a party for communicating over the communication network. The network presence for a party may include the device or devices of the party, such as a cell phone, a PDA, etc. The network presence may further include services subscribed to or available to the party, such as Instant Messaging (IM), Push-to-Talk over Cellular (PoC), email, etc. The network presence may further include the status of the party, such as mood, location, etc.
To implement a presence service, the target party (also referred to as “presentity”) provides presence information or a presence state via a network connection to a presence server. The presence server then stores a network presence record for the target party that may be distributed to one or more subscribers to the presence service (also referred to as “watchers”). The subscriber(s) is then able to monitor the network presence of the target party to determine how to communicate with the target party.
Assume for example that tie network presence of the target party includes the capability of a phone call. After seeing this communication capability, the subscriber may decide to initiate a call to the target party. However, the target party may be on another call (i.e., busy) and unavailable to receive a call from the subscriber at this time. The presence information typically provided by the presence server only indicates that the target party is capable of phone communications (i.e., presently registered on a communication network), but does not indicate whether the target party is presently available to receive a call. Before a call is placed to the target party, it may be advantageous for the subscriber to know the availability of the target party to receive the call.
There are generally three processes (in known prior art) for determining the availability of a target party to receive a call. For the first process, a presence server triggers on call setup messages and call tear down messages from the target party to determine the availability of the target party, and stores this information in memory. The presence server then transmits an indication of the availability of the target party to any subscriber that has requested to receive such information whenever a change occurs in the call status of the target party.
One problem with this process is that the presence server receives all the call setup messages and call tear down messages in a communication network. In a large network, the presence server may be bombarded with call setup messages and call tear down messages. Further, the presence server transmits an indication of the availability of a target party to all subscribers that are watching the target party. This may be a waste of network resources. As a result, this process does not scale effectively to larger communication networks.
Another process for determining the availability of a target party to receive a call is to have the presence server periodically determine the availability of the target party. For instance, the presence server may periodically query a switching system (e.g., an MSC/VLR) that is serving the target party to determine the availability of the target party. After the availability of a target party is determined, the presence server transmits an indication of the availability of the target party to all subscribers that are watching the target party.
One problem with this process is that there are no triggering events defined in the presence server for determining the availability of the target party on an as-needed basis. The presence server periodically determines the availability of the target party, even if the availability of the target party is not needed at the time. This process may be a waste of network resources.
Another process for determining the availability of a target party to receive a call is a peer to peer approach. Before a call is set up across a communication network from a subscriber to a target party, the subscriber transmits an availability request message over the communication network to the target party or to a switching system that is serving the target party. Responsive to the availability request message, the target party or the switching system transmits an availability response message back to the subscriber indicating the availability of the target party to receive the call.
One problem with this process is that the overhead in determining the availability of the target party is almost equivalent to the actual call setup. Such a process is inefficient.
As illustrated above, the present processes for determining the availability of a target party to receive a call prior to call setup are ineffective.
Embodiments of the invention solve the above and other related problems by having a communication device of subscriber trigger on the initiation of a call to a target party, and having a presence server determine the availability of the target party responsive to the communication device triggering on call initiation. The presence server may then transmit an indication of the availability of the target party to the subscriber's communication device prior to call setup. The subscriber may then see the availability of the target party for receiving the call before call setup is attempted.
In one embodiment, a communication device identifies an initiation of a call to a target party, and transmits an availability request message to a presence server responsive to the call initiation and prior to call setup. The availability request message requests the availability of the target party to receive the call. The presence server receives the availability request message from the subscriber's communication device, and determines the availability of the target party to receive the call. The presence server then generates an availability response message indicating the availability of the target party to receive the call, and transmits the availability response message to the subscriber's communication device prior to call setup. The subscriber's communication device receives the availability response message from the presence server, and displays the availability of the target party to receive the call. The subscriber or the subscriber's communication device may then complete the call to the target party or choose alternative forms of communicating with the target party (e.g., email or IM).
The process of determining the availability of the target party as provided herein is an improvement over present processes. The trigger for determining the availability of a target party is defined in the subscriber's communication device upon call initiation to the target party. The presence server then determines the availability of the target party responsive to the trigger in the subscriber's communication device. This process makes efficient use of the presence server by having the presence server determine the availability of the target party on an as-needed basis when a call is initiated to the target party. This process thus scales effectively to large communication networks.
The invention may include other exemplary embodiments described below.
The same reference number represents the same element or same type of element on all drawings.
Communication network 100 further includes a switching system 120 adapted to serve a target party 122. Switching system 120 comprises any server, function, or other system adapted to serve calls or other communications from target party 122, such as an MSC/VLR, a CSCF, etc. The term “target party” refers to a user and/or one or more communication devices of a user. For instance, target party 122 may represent a user, a cell phone, a PDA, a VoIP phone, a PC, etc. Target party 122 may have the capability of communicating over various media types, such as a phone call, email, text messages, Instant Messages (IM), etc. Target party 122 may have a one or more aliases for communication, such as sip:johndoe@company.com or tel:9195555555.
Although two switching systems are show in
Communication network 100 further includes a presence server 130 having a processing system 134 and a memory 136. Presence server 130 comprises any server, application, database, or system adapted to determine the network presence of target parties 122 and provide presence information to subscribers 114. The network presence for a party may include the device or devices of the party, such as a cell phone, a PDA, etc. The network presence may further include services subscribed to or available to the party, such as Instant Messaging (IM), Push-to-Talk over Cellular (PoC), email, etc. The network presence may further include the status of the party, such as mood, location, etc. In this embodiment, presence server 130 is further adapted to determine the availability of target parties 122 to receive calls prior to call setup as is further described herein.
According to the presence service subscribed to by subscriber 114, presence server 130 determines the network presence of target party 122 on communication network 100 (see
Assume that the network presence of target party 122 includes the capability of a phone call. After seeing this communication capability, subscriber 114 may decide to initiate a call to target party 122. For instance, subscriber 114 may select target party 122 out of the contact list, and select a call initiation to target party 122. However, target party 122 may be on another call or session (i.e., busy) and unavailable to receive a call from subscriber 114 at this time. The presence information provided by presence server 130 only indicates that target party 122 is capable of phone communications (i.e., presently registered on communication network 100), but does not indicate whether target party 122 is presently available to receive a call. Before a call is placed to target party 122, it may be advantageous for subscriber 114 to know the availability of target party 122 to receive the call.
In step 302 of method 300, processing system 204 identifies an initiation of a call to target party 122. For instance, processing system 204 may identify that subscriber 114 has selected target party 122 out of the contact list to initiate the call. In step 304, processing system 204 transmits an availability request message to presence server 130 through network interface 202 responsive to the call initiation. The availability request message transmitted by processing system 204 requests the availability of target party 122 to receive the call being initiated by subscriber 114. The availability request message is transmitted to presence server 130 prior to call setup. Processing system 204 may interrupt normal call setup procedures to transmit the availability request message, and halt the transmission of a call setup message to switching system 110. The availability request message may comprise a SIP SUBSCRIBE message or a message of another protocol.
In step 402 of method 400, processing system 134 in presence server 130 receives the availability request message from communication device 112. In step 404, processing system 134 determines the availability of target party 122 to receive the call responsive to receiving the availability request message. For example, processing system 134 may query switching system 120 that is serving target party 122, such as with a Position Request (POSREQ) message, to determine if target party 122 is on another call. Processing system 134 then generates an availability response message indicating the availability of target party 122 to receive the call in step 406. If target party 122 is on another call, then the indication of the availability of target party 122 will indicate that target party is busy. If target party 122 is not on another call, then the indication of the availability of target party 122 will indicate that target party is available. In step 408, processing system 134 transmits the availability response message to communication device 112 prior to call setup. The availability response message may comprise a SIP NOTIFY message that is transmitted responsive to a previously received SIP SUBSCRIBE message.
If target party 122 is determined to be unavailable (i.e., on another call), then processing system 134 may store or cache the availability of target party 122 in memory 136 for a time period. Processing system 134 stores the availability of target party 122 so that it may respond to other subscribers (not shown) that also want to know the availability of target party 122. Processing system 134 may then avoid having to query switching system 120 or target party 122 to determine the availability of target party 122, as this information is stored in memory 136.
Processing system 134 may have pre-defined parameters indicating how long the availability of target party 122 is stored in memory 136. For instance, processing system 134 may store the availability of target party 122 for a default time period related to the average time that a party is on a call, such as one minute, two minutes, three minutes, or some other time period. Processing system 134 may alternatively apply heuristic rules on a call history of target party 122 to determine the time period that the availability of target party 122 is stored in memory 136. For instance, if processing system 134 processes the call history of target party 122 to determine that target party 122 has a call-time average of ten minutes, then processing system 134 may store the availability of target party 122 for ten minutes.
Referring again to method 300 illustrated in
If target party 122 is available to receive the call, then processing system 204 may operate in a variety of ways. For instance, processing system 204 may automatically transmit a call setup message to switching system 110 to initiate the call. Processing system 204 may alternatively display an option to subscriber 114 to set up the call to target party 122. If subscriber 114 selects this option, then processing system 204 transmits a call setup message to switching system 110 to initiate the call.
If target party 122 is not available to receive the call, then processing system 204 may also operate in a variety of ways. For instance, processing system 204 may display other modes of communicating with target party 122 other than a call, such as email, IM, text message, etc. Upon receipt of the availability request message in presence server 130, presence server 130 may determine a status of other modes of communicating with target party 122 in addition to determining the availability of target party 122 to receive a call. Presence server 130 may then further indicate the status of other modes of communicating with target party 122 in the availability response message. Processing system 204 may then display the other modes of communicating with target party 122 along with a status of the other communication modes. Subscriber 114 may then choose to initiate another type of communication to target party 122.
Processing system 204 may alternatively display an option to subscriber 114 to set up the call to target party 122 regardless of the unavailable status of target party 122. If subscriber 114 selects this option, then processing system 204 transmits a call setup message to switching system 110 to initiate the call. Switching system 120 will then receive the call setup message from switching system 110 and invoke a call waiting feature for target party 122, route the call to a voice mail server for target party 122, or perform another function. Processing system 204 may alternatively display an option to subscriber 114 to stop or quit call setup to target party 122. Processing system 204 may alternatively retry the call to target party 122 at a later time. The retry may be responsive to input from subscriber 114. The retry may also be automatic in that processing system 204 sets a retry call timer, and automatically performs a call retry at the expiration of the retry call timer. Processing system 204 may perform other functions responsive to target party 122 being identified as unavailable.
Subscriber 114 may also choose to be notified when target party 122 becomes available to receive a call. Processing system 204 may display an option to be notified when target party 122 becomes available. If subscriber 114 selects this option, then processing system 204 transmits a notification request message to presence server 130. Presence server 130 may then contact switching system 120 or target party 122 requesting to be notified when target party 122 becomes available. Subsequently, if presence server 130 receives a notification from switching system 120 or target party 122 that target party 122 is now available, then presence server 130 transmits a notification response message to communication device 112 indicating that target party 122 is available. Communication device 112 may then set up a call to target party 122.
If presence server 130 stores the availability of target party 122 in memory 136, then it may respond to other availability request messages by determining the availability of the target party 122 as stored in memory 136. However, a subscriber may want to force presence server 130 to actively determine the availability of target party 122 instead of relying on the information stored in memory 136. “Actively determining” means to query one or more network nodes to determine the present status or availability of a party rather than relying on information stored in memory. For example, assume when communication device 112 initiates the call to target party 122 and transmits an availability request message to presence server 130, that presence server 130 has already stored the availability of target party 122 in memory 136. Processing system 134 in presence server 130 may determine the availability of target party 122 as stored in memory 136, and respond to communication device 112 accordingly.
However, subscriber 114 may want to direct or force presence server 130 to actively determine or pull the present availability of target party 122 by querying switching system 120 and/or target party 122. This is in contrast to presence server 130 identifying the availability of the target party 122 as stored in memory 136. To force presence server 130, communication device 112 may insert a flag in the availability request message (e.g., a SIP SUBSCRIBE message) that indicates a forced active determination of the availability of target party 122 to receive a call. Responsive to processing the flag in the availability request message, processing system 134 in presence server 130 transmits a query to switching system 120 and/or target party 122 to determine the availability of target party 122 instead of determine the availability of target party 122 based on information stored in memory 136. Processing system 134 may then respond to communication device 112 accordingly with the availability of target party 122 that was actively determined.
Subscriber 114 may also want to force presence server 130 to actively determine the availability or status of other modes of communication for target party 122, such as the status of IM, email, etc. Subscriber 114 may identify one or more of the other communication modes of target party 122 that he/she wants a forced status check. To do so, communication device 112 may insert one or more flags in the availability request message (e.g., a SIP SUBSCRIBE message) that indicates a forced active determination of the availability or status of one or more of the other communication modes of target party 122. If communication device 112 inserts one or more flags in the availability request message, then processing system 134 in presence server 130 has to do one or more pulls of the present status of the other communication modes indicated by the flags. Processing system 134 may then respond to communication device 112 accordingly with the statuses of the other communication modes that were actively determined.
As an example of the above concept, assume that subscriber 114 has subscribed to a service to receive a voice call status (e.g., busy or idle) of target party 122 and has subscribed to a service to receive IM session status (e.g., not in an IM session or involved in one or more IM sessions) of target party 122. In this case, subscriber 114 may operate communication device 112 to set the forced flags for none, one, or both of these services. Assuming that subscriber 114 instructs communication device 112 to set the forced flag for both the services in the availability request message, processing system 134 in presence server 130 will have to first pull the present information of target party 122 for each of these services (e.g., by querying the appropriate network elements such as by using a POSREQ for the voice call status, and analogously for the IM session status). Processing system 134 then responds to communication device 112 with the present status information of these services.
The above methods of determining the availability of target party 122 as provided herein are improvements over present processes. The trigger for determining the availability of target party 122 is defined in the subscriber's communication device 112 upon call initiation to target party 122. Presence server 130 then determines the availability of target party 122 responsive to the trigger in the subscriber's communication device 112. This process makes efficient use of presence server 130 by having presence server 130 determine the availability of target party 122 on an as-needed basis when a call is initiated to target party 122. This process thus scales effectively to large communication networks.
Assume that subscriber 114 has selected target party 122 in the contact list for communication. Also assume that subscriber 114 has selected to communicate with target party 122 by initiating a phone call. According to the embodiments provided herein, the availability of target party 122 to receive the call as initiated by subscriber 114 is determined prior to the call being setup.
Responsive to identifying initiation of the call, communication device 112 transmits an availability request message to presence server 130 (see also
Responsive to receiving the availability request message from communication device 112, presence server 130 determines the availability of target party 122 to receive the call. Presence server 130 may query target party 122 or switching system 120 that is serving target party 122 to determine if target party 122 is on another call. Alternatively, presence server 130 may have already determined the availability of target party 122 and stored the availability information in memory 136. Presence server 130 may thus avoid querying target party 122 or switching system 120. Presence server 130 then generates an availability response message that includes an indication of the availability of target party 122, and transmits the availability response message to communication device 112 prior to call setup. If target party 122 is on another call, then the indication of the availability of target party 122 will indicate that target party is busy. If target party 122 is not on another call, then the indication of the availability of target party 122 will indicate that target party 122 is available. The availability response message may comprise a SIP NOTIFY message that is transmitted responsive to a previously received SIP SUBSCRIBE message.
Upon receipt of the availability response message, communication device 112 processes the availability indication in the message. If target party 122 is available, then communication device 112 displays an indication to subscriber 114 that target party 122 is available.
If target party 122 is not available, then communication device 112 displays options to subscriber 114 for proceeding.
Another option is to be notified when target party 122 becomes available. If subscriber 114 selects this option, then processing system 204 transmits a notification request message to presence server 130 to be notified when target party 122 becomes available. Presence server 130 may then contact switching system 120 or target party 122 requesting to be notified when target party 122 becomes available, such as by transmitting a SIP SUBSCRIBE message. When target party 122 subsequently becomes available, switching system 120 or target party 122 notifies presence server 130, such as with a SIP NOTIFY message. If presence server 130 receives a notification from switching system 120 or target party 122 that target party 122 is now available, then presence server 130 transmits a notification response message to communication device 112 indicating that target party 122 is available. Communication device 112 may then set up a call to target party 122.
Another option is to retry the call to target party 122. If subscriber 114 selects this option, then processing system 204 may initiate another call to target party 122. Before a call is placed to target party 122, the availability of target party 122 is determined as described above. Alternatively, if subscriber 114 selects this option, then processing system 204 may set a retry call timer. The retry timer may be set based on a default time period related to the average time that a party is on a call, such as one minute, two minutes, three minutes, or some other time period. Processing system 204 may alternatively apply heuristic rules on a call history of target party 122 to determine the time period for the retry timer. At the expiration of the retry timer, processing system 204 automatically performs a call retry to target party 122.
Another option is to quit the present attempt to communicate with target party 122. Those skilled in the art understand that communication device 112 may provide other options to subscriber 114 in other embodiments.
Although specific embodiments were described herein, the scope of the invention is not limited to those specific embodiments. The scope of the invention is defined by the following claims and any equivalents thereof.