Call completion service in case of called party unavailability

If an attempt by a first user to contact another party fails, a callback server sets a flag. The callback server monitors terminals that have such flags set and is arranged to transmit an alert to the calling party when the called party next becomes available. However, if at the time when the called party becomes available, the calling party is himself no longer available, being now switched off or busy, an additional flag in the store, indicative of activity by the calling party, prevents a callback alert from being generated until the monitoring process can obtain availability indications in respect of both parties simultaneously. Availability may be determined by factors such as available bandwidth or terminal capabilities. A callback may be initiated when a predetermined number of called parties become available to participate in a conference call.

This application is the U.S. national phase of International Application No. PCT/GB2007/000469 filed 9 Feb. 2007 which designated the U.S. and claims priority to EP 06251293.4 filed 10 Mar. 2006, the entire contents of each of which are hereby incorporated by reference.

BACKGROUND 1. Technical Field

This invention relates to callback facilities in telecommunications systems. 2. Related Art

It is well known to provide a facility in a telephone system to allow a caller, on receiving an indication that a call attempt has failed, to be given the opportunity to request notification of the availability of the called party, so that he can make a further, hopefully more successful, attempt to place the call. The call failure mode may be “busy” (“off hook”), “no answer” (remains “on hook” despite ringing) or, in the case of a mobile telephone, “no contact” (switched off or not in range). The notification of the availability of the called party is typically triggered by the called party goes through the transition from an “off hook” state to an “on hook” state at some time subsequent to the request for such notification. In the case of a “no contact” situation, notification may be triggered by the called handset establishing contact with a cellular base station when it is switched on or comes into range.

Such systems are very useful, but have limitations because the calling party may not be in a position to place the desired call at the time the notification is received. This may be simply because the calling party may himself now be “off hook”, unavailable or switched off. In such a situation the callback may fail, but some systems are arranged to only attempt a “callback” when both parties are idle.

Systems of this general type are well-known—a typical example is described in International Patent specification WO00/22802 (Templeton).

BRIEF SUMMARY

There are other circumstances when it might not be appropriate to act on a callback notification, in particular if either or both parties are using a system which allows a mobile user to use different communications modes according to availability. For example, a user may have a handset which allows a broad bandwidth connection to be made when in proximity to a suitable access point, but a narrower bandwidth connection to be used when that is all that is available. The handset may also interface with fixed equipment to allow enhanced communications when such equipment is available. For example, the handset may default to the public cellular network, but have wireless access (“WiFi”) capability to allow the user to connect to higher bandwidth systems and terminal equipment when they are available. This variability of user experience may mean that when a user receives notification that a called party is available, the calling party is no longer in a position to make the call because of current limitations in bandwidth and/or terminal equipment.

According to the present exemplary embodiment, there is provided a telecommunications system providing a callback facility having means for detecting an attempt made by a first party to make a call of a predetermined type to one or more other parties, means for detecting a failure of said call attempt, means for monitoring each party to the call attempt to determine whether they meet criteria indicating that they are capable of participation in a call of the type attempted, and means to generate a notification to the first party when the first party and one or more of the other parties meet the capability criteria. The invention also provides a method of operating a telecommunications system providing a callback facility in which, in the event of failure of a call attempt of a predetermined type being made by a first party to one or more other parties, each party to the call attempt is monitored to determine whether they meet criteria indicating that they are capable of participation in a call of the type attempted, and a notification is sent to the first party when the first party and at least one of the other parties meet the capability criteria. The capability conditions monitored may relate to availability or cost of predetermined bandwidth, or the capabilities of the terminal equipment currently available to each user.

In a preferred embodiment, the predetermined conditions may include temporal conditions. For example, a condition on bandwidth may be relaxed after a predetermined period, to ensure that should the required bandwidth not be available to the called party at any time within that period, a more limited contact is still made at the end of that period. Conditions may be made that are interdependent, for example in a multi-party call, it may be arranged that notification is made when a predetermined number of the parties, or a specified sub-group of the total, meet the predetermined conditions.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

FIG. 1depicts a server1configured to operate according to the invention by controlling the callback facility. A register2is associated with the server: the register stores data corresponding to the stored conditions under which a callback alert should be generated.

A first party3a,3bis depicted as connected to the network9through different communications media4,5, at different times. For illustrative purposes it will be assumed that the same terminal equipment is used in both cases, but that the first medium4is of a greater bandwidth than the second medium5.

A called user6ais also depicted as connected to the network9through a medium7. At other times the user of the terminal6amay be connected to the network, through a connection8, using either the same terminal or, as shown, through a different terminal6b. The transition may be done by having this second user register his presence at the terminal6bmanually, or by means of a operative connection between the terminals6a,6b(e.g. “Bluetooth”). Again, for illustrative purposes it will be assumed that the first terminal6aand/or connection7is of more limited capability than the second facility6b,8.

Referring toFIG. 2, consider now a call request200made by the first user3, who is connected to the network9using his terminal3aby a high bandwidth connection4, to communicate with the other user6(who may be connected through either connection6a,6b, or not at all). The call request is passed to the server1, which attempts to contact the called party6(step201). The call may be answered (202), in which case the connection can be completed (203). However, should the called party6currently be engaged on another call, or have his terminal switched off, or fail to answer the call (21), the callback server would, as in the conventional system, return a “call failed” message22from the network to the user3, by transmitting a message prompting the user3to initiate a process23that sets a flag246in the store2. The callback server1monitors terminals that have such flags set (25) and is arranged to transmit an alert27to the calling party3when the called party6next becomes available. Availability is conventionally identified by some action on the part of the called party6, such as registering with the network9or, if already registered, when it next transitions from “off hook” to “on hook”. (If a call attempt failed through “no answer”, meaning the handset is already “on hook”, the alert27is only generated once the user6has cycled to “off hook” and back to “on hook”). On receipt of the alert28, the user3can make a second call attempt200.

However, at the time when the called party6becomes available, it is possible that the calling party3is himself no longer available, being now switched off or busy. This problem is overcome in a first embodiment of the invention, as shown inFIG. 2, by setting an additional flag243in the store2, indicative of activity by the calling party3. The callback alert is only generated when the monitoring process25can obtain availability indications263,266in respect of both parties3,6simultaneously.

If the original cause of failure21of the original call attempt200,201was “no answer” (line connected and on hook), this is indicative of a terminal that is sometimes unattended—this is of course more likely for a fixed terminal than a mobile one. The indication of availability in such cases is the “off-hook”/“on-hook” cycle, but this is only a reliable indicator of availability for a short period after the “on-hook”. In the event that the calling party3is itself unavailable when this cycle occurs at the called party6, there is a possibility that the called party6will again be unattended when the calling party3next becomes available, resulting in a failure of the callback. For this reason, availability indications263,266generated by an “off-hook/on hook” cycle are arranged to time out after a predetermined period.

In the event that an alert27is generated and not acted upon by the calling party3, despite being both switched on and “on hook” (step29), the flag243is re-set with the availability criterion261for the calling party3arranged to monitor for the next “off-hook/on hook cycle”261, again with a timeout applied. An alert28will therefore be generated when the following conditions are met:1. both terminals are switched on and connected2. both terminals are “on hook”
If the initial call attempt, or a subsequent callback attempt, fails as a result of one party failing to answer a call attempt or callback alert, a third condition is applied in respect of that party before a new alert is generated:3. the terminal has been “off hook” within a predetermined timeout period.

The process25for determining availability of the users3,6operates as shown inFIG. 3. The status of both the calling party3and called party6are checked from time to time (either periodically30as represented inFIG. 3, or by simply cycling through all callback requests in turn). Both the calling party3and called party6are checked to determine whether the user is connected (313,316) and on hook (333,336). If a “timeout” flag has been set (343,346) a further check is made (353,356) to determine if the user has gone from “off hook” to “on hook” within the predetermined timeout period. If all the checks313,316,333,336and (if applied)353,356are positive, the callback alert27is sent to the calling party3, which initiates a new call attempt200, as shown inFIG. 2.

In the event that the calling party3fails to respond to the alert27, the timeout flag243is set (383) so that on future cycles an alert27is only generated if the calling party has used the terminal3within a predetermined period. Similarly, if the call attempt is made and no response is received (21) from the called party6, the timeout flag246is set for that party.

This embodiment increases the likelihood that a callback alert is only sent when it is likely to succeed in connecting the parties. However, at the time of the call attempt, the second user6may be connected to the network (not busy or switched off) but using a terminal6aand/or connection7having limited capabilities. If the first user3aattempts to send the other user6aa large quantity of data which would take a very long time to download, or to attempt to discuss visual data not readable on the terminal6a, the call, although connected, will be unsuccessful in achieving the intentions of the caller3a. It would be preferable for the user3to wait until the called party6is using a more suitable terminal6band or connection8. There is also the possibility that when these conditions are met, the caller himself may have moved to a less suitable connection3b.

FIG. 4illustrates an improved callback process which improves the success of the call attempts by ensuring that both users are connected by way of terminals and connections suitable for the proposed task. In this process the availability criteria263,266are modified to include physical characteristics of the connection such as the type of terminal in use, and the available bandwidth (tests323,326) These criteria may be set by the calling party according to the nature of the communication required. For example, if the caller wishes to transmit a large data file, but it is not urgent, a callback may be requested for a time when both parties are connected to high bandwidth connections4,8. (It may also be appropriate to require that the called party's terminal6bhas sufficient memory to accept the data). If a video conference is required, a callback may be requested for a time when both parties are connected to terminals3b,6bhaving audio-visual capability, and appropriate bandwidth to support it.

The criteria for callback may be set up by the user to meet a “least-cost” principal, for instance a call may be set up between the parties only if both user terminals are connected to the same network, or a call may be set up only if neither party is on a cellular (GSM) connection.

The criteria may have a time element—for example they may be relaxed after a predetermined time, in order that limited contact can be made between the parties if it has not proved possible to establish a connection with the desired characteristics, or so that connection using a network with a time-variable tariff may be permitted at times when the tariff is below a specified threshold.

In embodiments described so far there are only two parties to the attempted call, but the invention may also be used to facilitate multiple-party calls (conference calls). Again, the criteria set by the calling party can allow a call attempt to be made when any one of the called parties, or a predetermined number of them, are identified as available.FIG. 5illustrates such an arrangement. In this arrangement, a call alert is sent to the calling party3provided that at least one of the called parties (identified as6,6a), and the calling party3itself, meet the availability criteria prevailing at the time. The process is as forFIG. 4, except that if the called party6fails one of the tests316,326,336,356, the same tests316a,326a,336a,356aare applied to the other called party, and a call alert27is generated if either of them meet the specified criteria. Variations will be apparent to the person skilled in the art, for example a call alert may be generated if a predetermined number of the called parties (one, some, or all) meet the criteria.

The parties may be tested in parallel or, as shown inFIG. 5for simplicity, the parties may be tested sequentially. A call alert is placed when any of the called parties is identified as available, so the status of any such parties not recently tested (in the current cycle if they are tested sequentially as shown inFIG. 5) is unknown. If it is desired to contact as many parties as possible, the resulting call attempt200may be sent to the called party3identified as available and also to any party3awhose status has not been determined. However, if the calling party3only wishes to contact one of the called parties3,3a,—rather than as many of them as possible—he may instead choose to configure the system to contact only the first called party3,3ato meet the criteria.