GB2460630A

GB2460630A - Informing a calling terminal when a called mobile terminal is back in service

Info

Publication number: GB2460630A
Application number: GB0809671A
Authority: GB
Inventors: Mangesh Pradhan
Original assignee: Nokia Oyj; Symbian Software Ltd
Current assignee: Nokia Oyj
Priority date: 2008-05-28
Filing date: 2008-05-28
Publication date: 2009-12-09
Also published as: GB0809671D0

Abstract

A method and system that indicate to a caller when a mobile handset, which the caller has tried to contact but has found unavailable (e.g. switched off or out of range), is once again available for connection through a mobile telecommunications network. When a caller attempts to call the handset, in the event that the handset is unavailable, the call is routed S.7.2 to a handset service management controller, which allows the caller to select S.7.14 one of a number of options as to whether and how he wishes to be informed when the handset next becomes available. For example, the caller can select to be sent an SMS message when the handset next becomes available, or to be automatically connected to the handset. Once an option has been selected, the management application monitors S.7.20 for when the called handset next becomes available through the mobile telecommunications network and implements the appropriate selected option.

Description

Method and System for Establishing Handset Availability in a Mobile Telecommunications Network

Technical Field

The present invention relates to a method and system for allowing a third party to establish that a mobile handset is capable of being connected to through a mobile telecommunications network, after a period of unavailability. In particular, the method and system of the present invention allow a third party to be informed when a mobile handset is available, after the period of unavailability of the handset.

Background to the Invention and Prior Art

It is well known in the field of mobile telecommunications that there are various mechanisms by which a user of a mobile handset can find out if a third party has been trying to contact him or her during a period when his handset is unavailable for connection to a mobile telecommunications network (for example by being out of range, or by being switched off). For example, many mobile network service providers provide their subscribers with a voicemail system, to which a call to a user's mobile handset is diverted, if the handset is unavailable. A caller can then leave a message with the voicemail system, which the mobile handset user can then retrieve at a later time, once his mobile handset has become able to connect to the network once again. With some prior art voicemail implementations when a mobile user's handset reconnects to the network after a period of unavailability, and a voicemail message has been left for the user of the handset, then the voicemail system automatically rings the handset repeatedly, until the user answers, whereupon the voicemail message can be played. In other prior art arrangements, instead of ringing the handset, a short message service (SMS) text message is sent to the handset, to inform the user of the handset that a voicemail message is waiting.

In addition to the use of voicemail, the short message service system is also prevalent, whereby mobile handset users can send "text" messages from one to another. The SMS message service is a "store and forward" service, in that if an SMS message cannot be immediately delivered, then it is stored within the network infrastructure, and then delivered to the handset when the handset next becomes available. In this way, a handset user will always receive text messages which have been sent to him, even though his handset may be temporarily unavailable, from the point of the other network.

Figure 1 illustrates in general terms the components of a modem mobile telecommunications network, and in particular a network implemented according to the ETSII3GPP GSM standards.

Here, a user mobile handset 10 (referred to as user equipment or UE) is provided to a user, and the mobile handset 10 is capable of radio communication with a base transceiver station (BTS), being a mobile base station, providing a mobile coverage "cell". Several base transceiver stations can be grouped together, controlled by a single base station controller (BSC) 30, to form a part of the cellular network. The base transceiver stations together with the accompanying base station controller form the base station subsystem (BSS). The base station subsystem is that part of a GSM network which is responsible for providing the radio interface to the mobile handset 10, and for routing calls and data over that radio interface.

The base station controller 30 communicates with the network switching subsystem, which is the component of a GSM system that carries out switching functions and manages communications between the public land mobile network (PLMN) i.e. the cellular network and the public switched telephone network 70 (PSTN). The network switching subsystem comprises one or more mobile switching centres (MSCs) which are the primary service delivery nodes for GSM. An MSC sets up and releases an end to end connection, handles mobility and handover requirements during the call, and takes care of billing systems. A gateway MSC is the MSC in the NSS which interfaces with the public switched telephone network 70. All mobile-to-mobile calls and PSTN-to-mobile calls are routed through a gateway MSC. A gateway MSC also determines which other MSC a subscriber who is being called is currently located within the control of.

Additionally provided as part of the network subsystem is a home location register (HLR) 50, which is a central database that contains the details of each mobile telephone subscriber that is authorised to use a GSM network. There is one logical HLR per PLMN (a PLMN being a single GSM network), although the HLR may be physically distributed across multiple platforms. The HLR stores details of every SIM card issued by the network operator, and each SIM has a unique identifier called an International Mobile Subscriber Identity (IMSI), which acts as a primary key to each HLR record.

Each HLR record also contains the mobile subscriber integrated services digital network number (MSISDN) which is a telephone number associated with a particular IMSI.

There is usually a primary MSISDN associated with a SIM card, which is the number used for making and receiving voice calls and SMS messages, although other secondary MSISDNs may also be associated, for example for fax or data calls. Each MSTSDN is also a primary key to the HLR record.

Additionally, other data is usually stored in an HLR record against an IMSI, such as, for example, the GSM services that the subscriber has requested or been given, GPRS settings, call divert settings, as well as a record of the current location of each SIM.

This will typically be the identification of a visitor location register" (VLR) of another MSC, or an MSC in another network, indicating that the handset is presently located in the coverage area of the MSC.

Therefore, as shown in Figure 1, also provided as part of the NSS is a visitor location register (VLR), which is a temporary database of subscribers who have roamed into a particular area for which a VLR serves. Each base station in the network is served by exactly one VLR, and hence a subscriber cannot be present in more than one VLR at a time. The data stored in a VLR is usually received from the HLR, or else is collected from the MSC, directly from the mobile device itself. The primary function of the VLR is to maintain a record as to the present location of the handset 10 and to allow a record to be kept in the I-ILR of which VLR a handset is presently registered with.

In order to route a call from another mobile, or within the PSTN, to the mobile handset 10, a third party calls the MSISDN of the handset 10, and the call is routed to the mobile network's gateway mobile switching centre (G-MSC). The gateway mobile switching centre then determines the current location of the mobile phone, in order to try and cormect the call. It does this by consulting the HLR 50, which, as described above, knows which VLR the phone is presently associated with, if any.

The MSISDN is therefore used as an index into the HLR, to determine the present VLR with which the handset is presently registered. If a handset is not registered with a VLR, then a handset is unavailable, either because it is switched off, or it is out of the network coverage area. In this case, the HLR returns a number known as the call forward not reachable (CFNRc) number to the gateway MSC, and the call is then automatically forwarded to the CFNRc number. Many network operators set this value automatically to the phone's voicemail number, so that the call is automatically routed to voicemail. However, any number or value can be set in the CFNRc field, such that the call can be diverted elsewhere, if required.

If the handset is presently registered with a VLR then the VLR identifier is returned to the HLR, which allows the MSC to request a temporary number (the mobile station roaming number (MSRN)) from that VLR. This number is relayed to the gateway MSC, which uses it to route the call to another mobile switching centre, called the visited MSC.

When the call is received by the visited MSC, the MSRN is used to find the phone's record in the VLR. Paging then occurs to all mobile phone masts in the phone's location area, as determined from the VLR. When the subscriber's mobile responds, the exact location of the mobile is returned to the visited MSC, which then forwards the call to the appropriate phone mast, and the phone then rings. If the subscriber answers, a speech circuit is created through the visited MSC and gateway MSC back to the network of the person making the call (likely through the PSTN), and a normal telephone call then follows.

It may be that the handset 10 is busy on another call. If this is the case the visited MSC routes the call to a predetermined call-forward-busy (CFB) number. Similarly, if the subscriber does not answer the call after a predetermined period of time, then the visited MSC may route the call to a predetermined call-forward-no-reply (CFNRy) number. As with the CFNRc number, commonly the operator sets this value by default to the voicemail of the mobile user.

In view of the above, it will be seen that from the point of view of a caller calling the user of a mobile handset on that handset the caller does not need to know the location of the handset user in order to make a call. Instead, the mobile network routes the call automatically. Additionally, from the point of view of the caller, the handset user either answers the call, or the call is diverted to voicemail, in a number of conditions. This would be, for example, if the handset is unavailable because it is turned off, or out of network coverage, or if the caller is busy on another call. Alternatively, the same typically also occurs when the user simply does not answer the call. In the first three cases, however, it is not possible for a caller to differentiate as to the reason why the call has been routed to voicemail. It is either because the user is on another call, in which case he can be expected to receive the voicemail message in a relatively short period of time, once the first call has finished, or because the user's mobile handset is turned off, or out of network coverage area, in which case it may be some time before he receives the voicemail message. From the point of view of the caller, however, it is not apparent which of these scenarios will apply. Therefore, even when leaving a voicemail, a caller cannot be certain that a called mobile user will in fact receive the voicemail which has been left for him within a suitable period of time. In some time critical situations, it may be better for the caller to try and employ some other means of communication to access the mobile handset user. In view of the above, it would be beneficial to mobile users if an arrangement could be provided to solve the above problem.

It should be noted that in the field of fixed telecommunications networks, the above problem does not particularly arise. This is due to typically, within a fixed network, an engaged tone being played to a caller, if the number is busy. Additionally, some fixed networks, such as that provided by British Telecommunications plc in the United Kingdom, provide what is called a "ring back" service, for a number which is busy.

Here, a caller is informed that the number is busy, and is then able to set a flag against the number, such that when the called number becomes free, the network automatically calls the caller's own fixed line telephone. Once the caller answers his own fixed line telephone, then the network automatically calls the called line once again, to try and set up a connection. Of course, fixed line telephony provides different solutions to different problems, which problems and solutions are not necessarily applicable to those of mobile networks. For example, whilst it may be possible for a mobile network operator to implement a similar "ring back" service, it would not solve the problem of when a mobile handset is simply out of service altogether, either by being switched off, or being out of range. Of course, in a fixed network, terminal equipment is typically not switched off, and it is not possible for it to go "out of range".

Summary of the Invention

In order to address the above, embodiments of the present invention provide a method and system which indicate to a caller when a mobile handset which the caller has tried to contact but has found unavailable is once again available for connection through a mobile telecommunications network. In particular, in embodiments of the invention a mobile handset is registered with the mobile network service provider for such a service. When a caller attempts to call the handset, in the event that the handset is unavailable the call is routed to a handset service management controller, which allows the caller to select one of a number of options as to whether arid how he wishes to be informed as to when the handset next becomes available. For example, the caller can select to be sent an SMS message when the handset next becomes available, or to be automatically connected to the handset. Once such an option has been selected, the service management controller monitors for when the called handset next becomes available through the mobile telecommunications network, and when it next becomes available, implements the appropriate selected option.

In view of the above, from a first aspect there is provided a method of establishing the service availability of a mobile terminal in a mobile telecommunications network, comprising the steps: routing a call from a calling terminal to the mobile terminal to a service management controller in the event of the mobile terminal being out of service; at the service management controller, logging caller identification information of the calling terminal; monitoring an element of the mobile telecommunications network to determine when the mobile terminal is back in service; and communicating that the mobile terminal is back in service to the or each calling terminal whose identifications were logged.

The first aspect addresses the above noted problems of the prior art, by allowing a calling terminal to be notified as to when the called mobile terminal is back in operation. This will allow a user to decide whether an alternative communications mode should be attempted, and hence improves the user experience and convenience.

Preferably, the logging step further comprises: comparing the caller identification information against a list of caller identifications; and logging said caller identification information in dependence on the information being contained within said list. This allows the user of the mobile terminal to specify only some callers who are to be informed that his mobile terminal is back in operation. This, the privacy of the user of the mobile terminal can be controlled and maintained.

In the preferred embodiment the logging step further comprises: communicating a list of options to the caller, being actions to be taken when the mobile terminal is back in service; and recording one or more selected options against the caller identification information. This provides for increased flexibility of operation, as the caller can select the option which be prefers from the list, and which best suits the situation.

In the preferred embodiment the communicating step comprises communicating that the mobile terminal is back in service in accordance with a selected option previously selected by a caller. This ensures that the option selected by the caller is implemented.

In the preferred embodiment the options comprise one or more selected from the group comprising: i) connecting the calling terminal to the mobile terminal; ii) sending a message to the calling terminal; and iii) sending a message to the mobile terminal.

Preferably the monitoring step comprises periodically checking the home location register (FILR) of the mobile telecommunications network to determine if said mobile handset has come back into service. This provides for convenient operation and means that the invention may be used with existing GSM networks, without requiring significant modification, or extra network components. In this respect, the HLR is a standard component in a GSM network.

Similarly, preferably the routing step further comprises setting an address of the service management controller as a CNFRc value for the mobile handset in the home location register of the mobile telecommunications network. This allows for an indication that a handset as registered for the additional service provided by embodiments of the invention to be conveniently stored and noted in the network. Moreover, by storing the service management controller address as the CNFRc number, then calls will automatically be routed by MSCs to the service management controller when the mobile terminal is unavailable without requiring any further significant modification to existing network infrastructure.

From a second aspect the present invention also provides a system for establishing the service availability of a mobile terminal in a mobile telecommunications network, the system comprising: a service management controller to which calls from a calling terminal to the mobile terminal are routed in the event of the mobile terminal being out of service; a database in which caller identification information of the calling terminal is logged; and a monitor element of the mobile telecommunications network that determines when the mobile terminal is back in service; wherein the service management controller is further arranged to communicate that the mobile terminal is back in service to the or each calling terminal whose identifications were logged in the database.

Within the second aspect the same advantages are obtained as described above in respect of the first aspect. In addition, the same further features and associated advantages may also be obtained.

Brief Description of the Drawings

Further features and advantages of the present invention will become apparent from the following description of an embodiment thereof, presented by way of example only, and by reference to the accompanying drawings, wherein like reference numerals refer to like parts, and wherein: -Figure 1 is a block diagram of a typical GSM network architecture of the prior art, and which can form the basis of an embodiment of the present invention; Figure 2 is a block diagram of a handset 10 according to a first embodiment of the invention; Figure 3 is a block diagram of an MSC and HLR as used in the first embodiment of the invention; Figure 4 is a flow diagram of the steps performed by the handset 10 in the first embodiment; Figure 5 is a flow diagram of the steps performed by a watcher server at the MSC in the first embodiment; Figure 6 is a flow diagram of the steps performed at a gateway MSC when a call is received; Figure 7 is a flow diagram of the steps performed by a watcher controller in the MSC in the first embodiment; and Figure 8 is a flow diagram of a second procedure performed by the watcher controller in the first embodiment of the invention.

Description of an Embodiment

An embodiment of the invention will now be described with respect to Figures 2 to 8.

The first embodiment of the invention provides a system which allows a mobile handset to be registered with a network so as to be provided with an additional service to help callers who attempt to call a handset. More particularly, the handset is provided with a client application, which allows the user to specify particular telephone numbers or other caller IDs, for which, when the handset is called by those numbers, if the handset is not available, the callers corresponding to those numbers are routed to a service management application which allows those callers to register with the application, so as to be informed as to when the called handset next becomes available. Within the network the service management application, referred to herein as the "watcher" application, comprises a watcher server which allows the user to register the numbers which are to be informed, and a watcher controller, which deals with incoming calls to the mobile handset, and also informs callers as to when the handset is again available, in accordance with a previously selected option. Thus, therefore, a caller to an unavailable mobile is able to register his interest in when the mobile next becomes available, and when the mobile next becomes available, the watcher controller informs the caller, and performs an action specified by the caller, such as, for example, connecting the caller automatically with the previously unreachable mobile handset. In this way, callers to unavailable mobile handsets can be made aware as to when the mobile handset is next available. For time critical messages, therefore, the caller may decide to attempt another communication method to try and get a message to the mobile handset user.

A more detailed explanation of the operation of the first embodiment will now be undertaken with respect to the Figures.

Figure 2 is a block diagram of the internal elements of a typical mobile handset 10, and typically a mobile handset known as a "smart phone". Of course, other mobile handsets which are not "smart phones" may also be used with the invention.

A typical smart phone 10 comprises hardware to perform the telephony functions, together with an application processor in corresponding support hardware to enable the phone to have other functions which are desired by a smart phone, such as messaging, calendar, word processing functions, and the like. In Figure 2 the telephony hardware is represented by the RF processor 102 which provides an RF signal to antenna 126 for the transmission of telephony signals, and the receipt therefrom. Additionally provided is baseband processor 104, which provides signals to and receives signals from the RF processor 102. The baseband processor 104 also interacts with a subscriber identity module 106, as is well known in the art.

Also typically provided is a display 116, and a keypad 118. These are controlled by an application processor 108, which is often a separate integrated circuit from the baseband processor 104 and RF processor 102, although in the future it is anticipated that single chip solutions will become available. A power and audio controller 120 is provided to supply power from a battery (not shown) to the telephony subsystem, the application processor, and the other hardware. Additionally, the power and audio controller 120 also controls input from a microphone 122, and audio output via a speaker 124.

In order for the application processor 108 to operate, various different types of memory are often provided. Firstly, the application processor 108 may be provided with some random access memory (RAM) 112, into which data and program code can be written and read from at will. Code placed anywhere in RAM can be executed by the application processor 108 from the RAM.

Additionally provided is separate user memory 110, which is used to store user data, such as user application programs (typically higher layer application programs which determine the functionality of the device), as well as user data files, and the like.

In order for the application processor 108 to operate, an operating system is necessary, which must be started as soon as the smart phone system 10 is first switched on. The operating system code is commonly stored in a read only memory, and in modem devices the read only memory is often NAND flash ROM 114. The ROM will store the necessary operating system components in order for the device 10 to operate, but other software programs might also be stored, such as application programs, and the like, and in particular those application programs which are mandatory to the device, such as, in the case of a smart phone, communications applications and the like. For example, as shown in Figure 2, the smart phone 10 in the present embodiment stores a watcher client program in the NAND flash RUM 114. The watcher client program is loaded from the NAND flash ROM 114 into the RAM 112 when it is to be executed. The operation of the watcher client will be described later, with respect to Figure 4.

Turning now to Figure 3, this illustrates a block diagram of a gateway MSC 40 located in the network subsystem (NSS) of the mobile network. Here, it will be seen that the MSC 40 comprises a master MSC controller 46, which controls the MSC to perform the functions conventionally performed by an MSC in a GSM network. That is, the master MSC controller performs the MSC functions, so as to act as the main routing node for calls within the GSM network. The MSC controller 46 in the MSC 40 communicates with the home location register 50, which contains a database 52, having entries stored therein. As mentioned previously, the HLR database 52 is indexed by IMSI, as well as MSISDN, and also stores, amongst other things, information relating to which VLR a handset is presently registered with, as well as the CFNRc number, which is the number that a call should be forwarded to when the handset is unavailable. For the purposes of the present embodiment, these are the only HLR database fields which are of concern, although it will be appreciated by those skilled in the art that the HLR also contains additional information for each entry, in a typical implementation.

Returning to the MSC 40, the MSC 40 also contains a voicemail controller 47. The voicemail controller 47 provides a voicemail function, as is conventionally known in the art. It should be noted that whilst the voicemail controller 47 is shown here as part of the MSC, this is for illustration purposes only, and the voicemail controller 47 may in fact be a physically and logically separate entity.

In this embodiment, the gateway MSC 40 also comprises a watcher server 43, and a watcher controller 44, provided with an interactive voice response application 45. The watcher server 43 and watcher controller 44 interface with a watcher database 42. The watcher database 42 is a database indexed by IMSI and MSISDN, and which contains for each IMSI and MSISDN a list of MSISDN track numbers, being those MSISDN numbers which, if they attempt to call the handset corresponding to the indexed IMSI or MSISDN, should be able to set a watch on the handset, to determine when it is back in service. Additionally, for each database entry there is a "poll" field, which indicates whether the watcher controller should periodically poli the HLR, to determine whether the handset corresponding to the MSISDN or IMSI is back in service, after a period of unavailability. Additionally, each entry also contains an "action" field, which stores a series of action tupies in the form: (TRK#, option) where TRK#, is the MSISDN number of a caller who has set an action option to be undertaken by the watcher controller when the called MSISDN comes back into service, and "option" is a code relating to the action to be taken. Further details of the available actions will be given later.

The IVR 45 interfaces with the watcher controller 44, and receives and answers calls, presenting options to callers over an established voice channel using a synthesised or recorded voice, and registering their responses, typically by key presses, although in some embodiments speech recognition may be used. The received information is passed to the watcher controller 44, for storing in the watcher database 42, if necessary.

It should be understood that the watcher server 43, watcher controller 44, IVR 45, and watcher database 42 are shown in Figure 3 as part of the MSC 40. However, it should be understood that they are logically separate entities, and hence in other embodiments may be both logically and physically separated from the functions of the MSC controller 46.

Having described the elements of the first embodiment, the operation of those elements will now be described with respect to Figures 4 to 8.

Figure 4 is a flow diagram illustrating the operation of the watcher client program in the user handset 10. The watcher client program is used to allow the user of the handset to register contact details of other people who he wishes to be informed of his handset status, and in particular when his handset becomes available for communication after a period of unavailability. In order to do this, the handset user first registers with the network in advance, so as to be provided with this service. In order to recognise that the user has registered for this service, the CFNRc field in the HLR for the user's IMSI record is modified to include the value "watcher", rather than the typically default "voicemail". This is shown in Figure 3, from where it will be seen that in the HLR database 52 the user with IMSI 456, and MSISDN 246810 has a CFNRc value of "watcher". This value, when it is returned to the master MSC controller 46 in the event that the handset is not available, causes the MSC controller 46 to route a call to the user to the watcher controller 44.

In a similar manner, had the CFNRc field taken the value "voicemail", then the MSC controller 46 would have routed the call to the voicemail controller 47, so as to access voicemail in the conventional manner. By using a value for the CFNRc field in the HLR to indicate that the handset has registered for the service, no additional modifications are required to the conventional MSC or HLR functionality in order to implement the watcher service.

Returning to Figure 4, once the user has registered to be provided with the service, then he is able to use the watcher client program on the handset in order to set third party user contact details (typically telephone numbers (MSISDN numbers)) which are numbers which are permitted to be informed as to when his handset becomes available again, after a period of unavailability. At step 4.2, therefore, the user launches the watcher client application, and in the handset the watcher client application is loaded from NAND flash ROM 114 into RAM 112 and is then executed by the application processor 108. This causes the watcher client interface to be displayed on the display 116, at step 4.4. The user then uses the keypad 118 at step 4.6 to signal appropriate operations to be performed by the watcher client. Available operations are, for example, to add a number, to edit a number, and to delete a number in the user's watcher list, stored in the watcher database 42.

In order to allow the user to easily select telephone numbers, at step 4.8 the watcher client accesses the user's contact list stored in the user memory 110 (not shown), and at step 4.10 the contacts list is displayed to the user on the display 116. The user then uses the keypad 118 to select a particular contact, at step 4.12. After selecting particular contact data, the watcher client application reads the telephone number (MSISDN number) from the contact data, and then builds a message to be sent to the watcher server in the network, at step 4.14. The message is of a known format, and typically

contains the following fields: -

(message type, sender MSISDN, operation, contact data) where message type indicates that it is a message from the watcher client, operation indicates the selected operation i.e. add, edit, or delete, and contact data contains the selected contact data.

The watcher client application then sends the message to the watcher server 43 in the MSC 40. Note that the watcher client application may send this message in a variety of ways. For example, it may establish a data connection with the watcher server 43, if the phone 10 is, for example, GPRS enabled. Alternatively, and more simply, the watcher client may send the message to the watcher server using the SMS protocol. In this case, because the message has been built according to a predetermined syntax, the watcher server can receive the SMS message, and then parse it in accordance with the predetermined syntax, to determine the message contents.

Figure 5 illustrates the steps performed by the watcher server 43 in the MSC 40, when a message is received from a watcher client application in a handset.

More particularly, the message is received at the MSC at step 5.2, and is then passed to the watcher server 43. For example, if the message is an SMS message, it may be sent to a particular number, which the MSC controller 46 knows is a message which must then be passed to the watcher server 43.

At step 5.6 the watcher server parses the message in accordance with the predetermined syntax to determine the following data: the sender IMSI; the operation type; and the contact data. At step 5.8, the watcher server then accesses the watcher database 42 and in particular the database record corresponding to the sender IMSI. At step 5.10 the database record is then updated, in accordance with the operation type, and the contact data. For example, if the operation type is of type "add", then the contact data is added to the "TRK#" field, which itself is a list of MSISDNs. In this case, the telephone number (MSISDN) received in the contact data in the message is added to the list of

numbers stored in the TRK# field.

If the operation type is an "edit" operation, then this is implemented first as a "delete" operation, and then as an "add" operation. In particular, an edit message will indicate first of all the number which is to be edited, and then what the number is to be edited to.

Therefore, the watcher server 43 looks up in the TRK# list the number which is to be edited, and then deletes that number therefrom. The new number is then added at the end of the TRK list. In this way, numbers can be edited.

Where the operation is a "delete" operation, then the contact data included in the message is looked up in the TRK# list, and deleted therefrom.

Once the database record has been updated, it is stored by the watcher server 43 back in the watcher database 42.

With the above operations, therefore, the watcher client program stored in the handset, and the watcher server 43 in the MSC 40, are able to allow the user to update which calling numbers should be provided with the service, so as to be able to be informed as to when the user handset 10 becomes available, after a period of unavailability.

The operation of the watcher controller 44 when a third party attempts to call a user's handset which is registered for the watcher service, and the handset is unavailable, will now be described with respect to Figure 7.

More particularly, assume now that a third party is attempting to call a handset which is registered with the watcher service. The call arrives at the gateway MSC 40, and the master MSC controller 46 looks up the called MSISDN in the HLR database 52, to determine whether the called MSISDN is presently registered with a VLR. With reference to Figure 3, for the purposes of this explanation, assume that MSISDN 246810 is being called, from which it will be seen that the handset with that MSISDN is not presently registered with a VLR. The HLR therefore informs the MSC controller that the handset is not registered with a VLR, and returns the CFNRc value. In this case, because the handset is registered for the watcher service, the CFNRc value indicates that the call should be routed to the watcher controller. Therefore, with reference to Figure 7, at step 7.2 the call is routed to the watcher controller.

Next, at step 7.4, after having received the call, the watcher controller determines the MSISDN of the caller. This information is then used at step 7.6 to determine whether the calling MSISDN is contained within the TRK# list of the called MSISDN. In particular, the database record corresponding to the called MSISDN is retrieved from the watcher database 42, and the calling MSISDN is searched for in the list of MSISDNs contained in the TRK# field of the database record. If the caller MSISDN is not contained within the TRK# list, as determined by the evaluation performed at step 7.6, then processing proceeds to step 7.8, wherein the watcher controller routes the call either to the voicemail controller 47, such that the call is routed to voicemail, or some other action is performed (for example the call could simply be terminated, although this is not preferable).

If, however, at step 7.6 it is determined that the calling MSISDN is contained within the track list (TRK) of the called MSISDN, then processing proceeds to step 7.10. Here, the watcher controller 44 controls the IVR module 45 to operate, and in particular routes the call to the IVR module 45. The IVR module 45 then answers the call at step 7.12, and presents a synthesised or pre-recorded message to the caller, informing the caller that the called handset is out of service, and presenting the caller with a number of options.

More particularly, the IVR 45 reads out a list of options, and informs the user which key to press to select a particular option. The particular options available in the present embodiment are as follows: -i) to connect the calling number to the called number automatically, once the called handset becomes available; ii) to inform the called user that the calling user was trying to reach him or her, by sending an SMS to the called user, when the called user's handset next becomes available; or iii) to send an SMS message to the calling user when the called user's handset next becomes available.

At step 7.14, the IVR listens to the user's response to the available options, and detects the response given. For example, where the user has to press a key on his keypad to select a response, then the DTMF tones generated by the keypad pressed can be listened for by the IVR, to determine the selected option. At step 7.16, after a suitable period of time, if no key press has been made or the caller has hung up then an evaluation is made to this effect, and if no key press has been made, processing proceeds to step 7.18, wherein the IVR terminates the call at its end. In this case, nothing further is done.

If, however, at step 7.14 and step 7.16 the IVR determines that a key press corresponding to one of the options has been set, then processing proceeds to step 7.20.

Here, the watcher controller 44 sets the "poil" field in the watcher database record corresponding to the called MSISDN to "Y", to indicate that the watch controller 44 needs to keep a watch on the user handset corresponding to the called MSISDN, to determine when it comes back into service.

Next, at step 7.22, the watcher controller 44 stores a data tuple in the following form: (calling MSISDN, option) in the "action" field of the watcher database record corresponding to the called MSISDN. This is to indicate what action is to be taken in respect of the calling MSISDN, when the called handset comes back into service.

Once the watcher controller 44 has updated the watcher database record 42, the IVR 45 acknowledges the selected option with an appropriate pre-recorded or synthesised message, and then terminates the call, at step 7.24.

Thus, with the procedure of Figure 7, therefore, when a caller attempts to call an out of service handset which is registered for the watcher service, and the caller is one of the callers which the handset user wishes to be informed as to when his handset comes back into service, then it is possible for the watcher controller to store information and action to be taken in respect of the calling MSISDN, which action is undertaken when the called handset comes back into service.

With the procedure of Figure 7, therefore, the watcher database 42 is updated so as to mark in the "poll" field of each database record whether the watcher controller 44 should look to see whether that handset has come back into service, and to specify what action should be performed when the handset does come back into service. It is then up to the watcher controller to determine when a handset actually has come back into service, and the procedure for doing this is shown in Figure 8.

More particularly, Figure 8 illustrates the procedure which the watcher controller 44 undertakes periodically firstly to "poll" the handsets which have been out of service, and then to take the appropriate action if the handsets come back into service. The procedure starts at step 8.2, wherein a FOR processing loop is commenced, which allows the watcher controller 44 to step through e;ch database record for each IMSI in the watcher database. Each IMSI record is examined in turn.

The first step in the processing loop is step 8.4, wherein the "poll" field of a database record being examined is looked at, to see if the poll flag has been set to "Y" i.e. that the handset has been out of service, and has had an action registered against it. If this is not the case, then no further action need be performed in respect of that particular database record, arid processing proceeds to step 8.10, wherein the next IMSI record in the database is selected. Processing then proceeds back to step 8.2, and the next IMSI record is processed.

If, at step 8.10, it is determined that there are no more IMSIE records in the database to be processed, then processing proceeds to step 8.12, which is a wait condition. Here, the watcher controller 44 simply waits a predetermined amount of time, before the procedure returns to step 8.2, and the polling procedure of each IMSI is undertaken once again. The predetermined amount of time may, for example, be of the order of 30 seconds, a minute, five minutes, or the like.

Returning to step 8.4, imagine now that an IMSI record in the watcher database 42 has had the poii field set to "Y". This will mean that the handset has been out of service, and that a caller has attempted to call a handset, and has registered an action to be undertaken when the handset comes back into service.

In this case, the first step is that the watcher controller 44 accesses the IMSI record in the HLR, at step 8.6. The HLR record is then examined, at step 8.8, to determine whether the IMSI (or MSISDN) is now registered with a VLR. It will be recalled that registration with a VLR means that the handset is now back in service. If the IMSI is not registered with a VLR, then even though the watch controller must keep watch on the handset due to the polling flag being set to "Y", the handset has not come back into service. In this case, there is therefore no point taking any further action, and processing proceeds to step 8.10, wherein the next IMSI record is examined. The handset will be looked at again the next time the FOR loops starts from the beginning i.e. after the wait period of step 8.12.

On the other hand, if at step 8.8 it is determined that the IMSI is registered with a VLR, then this means that the handset has come back into service, after a period of unavailability. In this case, the watcher controller 44 can then process the actions which have been stored against the IMSI and MSISDN by calling users, who have called the handset while it has been unavailable. In this case, processing then proceeds to step 8.14.

At step 8.14, the action field of the IMSI record is examined, to determine the action tuples which are stored therein. It may be that there have been several callers who have attempted to call the handset while it has been unavailable, and each of which selected an action option to be performed when the handset comes back into service. In this case, there will be several action tuples stored in the action field of the IMSI record in the watcher database 42. In order to process each action tuple, therefore, at step 8.16 a FOR processing ioop is commenced, to process each action tuple in turn.

At step 8.16, therefore, on the first iteration the first action tuple in the action field of the IMSI record is accessed. It will be recalled that each action tuple contains the MSISDN of the calling number, as well as the action option which was selected. At steps 8.18, 8.20, and 8.22, a series of evaluations are performed to determine the action option which was selected. In particular, at step 8.18 a first evaluation is performed for the action tuple presently being processed, to determine whether the action option selected was to connect the calling user to the called user, as soon as the called user's handset becomes available. If the action option in the presently processed tuple was to perform this action, then processing proceeds to step 8.28. Here, the watcher controller 44 generates a call to the MSISDN stored in the action tuple, which is the MSTSDN of the calling user. This causes a call to be generated to the calling user. Once the calling user answers, the watcher controller 44, via the IVR 45, plays a recorded or synthesised message informing the user that he is being connected to the called user who he previously tried to call. The watcher controller 44 then places the calling user on hold, and generates a call, via the MSC controller 46, to the called handset, which is now back in service. When the called handset is answered, the watcher controller 44, via the IVR module 45, plays a message to the user informing him that he is being connected to a user who previously called. The watcher controller then bridges the two calls together, so as to connect the calling user to the called user. The call can then proceed as normal.

After step 8.28, once the call has been set up, processing proceeds to step 8.34. Here, the action tuple in the present IMSI record which led to the call being set up is deleted, as the action has been performed, and will not need to be performed again. Thereafter, processing proceeds to step 8.24, wherein an evaluation is performed as to whether all of the action tuples in the present IMSI record have been processed. If they have not, then processing proceeds back to step 8.16, and continues as previously.

Assume for the present explanation that there is another action tuple to be processed. In this case, therefore, processing proceeds, as explained, back to step 8.16, and the action option in the action tuple is examined by the evaluations of step 8.18 to 8.20.

Here, assume that the action option is to inform the called user that he was called. In this case, the step 8.18 will return negative, but the evaluation of step 8.20, will return positive. In this case, processing proceeds to step 8.30, where an SMS message is then sent to the called user, informing him that he was called while his handset was unavailable, by the calling MSISDN. In this respect, the calling MSISDN is contained within the action tuple, and can be incorporated in the SMS message to be sent to the user. Thereafter, processing proceeds to step 8.34, and then proceeds as previously described.

Assume now that the next action tuple in the list contains the action option that the calling user wishes to be informed when the called handset comes back into service. In this case, both steps 8.18 and step 8.20 will return negative, but step 8.22 will return positive. In this case, processing proceeds to step 8.32, where an SMS message is then sent to the calling MSISDN, i.e. the MSISDN stored within the action tuple itself, informing that user that the handset that he tried to call previously, and having an MSISDN corresponding to the MSISDN field of the IMSI record, is now back in service. Thereafter, processing proceeds to step 8.34, as described previously.

Once all of the action tuples in a particular IMSI record have been processed, step 8.24 will return negative, in which case, processing then proceeds to step 8.26. Here, given that all of the action tuples in the present IMSI record have been processed, there is then no need for the watcher controller to examine the IMSI record again until additional action fields have been added, when the handset next goes out of service. Therefore, to prevent the watch controller examining the IMSI record unnecessarily, the poll flag is set to "N" at step 8.26. Thereafter, processing proceeds back to step 8.10, wherein the next IMSI record is examined, as described previously.

With the procedure of Figure 8, therefore, the watcher controller can repeatedly check whether handsets which have been out of service and which other users have tried to call have come back into service. Moreover, if it is determined that a handset has come back into service it is then possible for each of the actions which were previously registered against the handset by calling users to be performed, for example to connect the handset with a calling terminal, or to inform the calling terminal that the mobile terminal is back in operation.

Various modifications may be made to the above described embodiment to provide further embodiments. For example in other embodiments, additional action options may be presented to a calling user. For example, a calling user may be given an option to be informed by SMS as to when the called handset becomes available, and then be routed to voicemail, so as to be able to leave a message. In another example, the called handset may be automatically called by the watcher controller when it comes back into service, and be presented with an option to be connected to the calling user. Various other actions will be apparent to the person skilled in the art, which may be incorporated as alternatives or additions into the presently described embodiment, to provide further embodiments.

In addition, other additions, deletions, or modifications will be apparent to the person skilled in the art which will provide further embodiments, any and all of which are intended to be encompassed by the appended claims.

Claims

Claims 1. A method of establishing the service availability of a mobile terminal in a mobile telecommunications network, comprising the steps: routing a call from a calling terminal to the mobile terminal to a service management controller in the event of the mobile terminal being out of service; at the service management controller, logging caller identification information of the calling terminal; monitoring an element of the mobile telecommunications network to determine when the mobile terminal is back in service; and communicating that the mobile terminal is back in service to the or each calling terminal whose identifications were logged.
2. A method according to claim 1, wherein the logging step further comprises: comparing the caller identification information against a list of caller identifications; and logging said caller identification information in dependence on the information being contained within said list.
3. A method according to claims 1 or 2, wherein the logging step further comprises: communicating a list of options to the caller, being actions to be taken when the mobile terminal is back in service; and recording one or more selected options against the caller identification information.
4. A method according to claim 3, wherein the communicating step comprises communicating that the mobile terminal is back in service in accordance with a selected option previously selected by a caller.
5. A method according to claim 4, wherein the options comprise one or more selected from the group comprising: i) connecting the calling terminal to the mobile terminal; ii) sending a message to the calling terminal; iii) sending a message to the mobile terminal.
6. A method according to any of claims 1 to 5, wherein the monitoring step comprises periodically checking the home location register (HLR) of the mobile telecommunications network to determine if said mobile handset has come back into service.
7. A method according to any of claims 1 to 6, wherein the routing step further comprises setting an address of the service management controller as a CNFRc value for the mobile handset in the home location register of the mobile telecommunications network.
8. A system for establishing the service availability of a mobile terminal in a mobile telecommunications network, the system comprising: a service management controller to which calls from a calling terminal to the mobile terminal are routed in the event of the mobile terminal being out of service; a database in which caller identification information of the calling terminal is logged; and a monitor element of the mobile telecommunications network that determines when the mobile terminal is back in service; wherein the service management controller is further arranged to communicate that the mobile terminal is back in service to the or each calling terminal whose identifications were logged in the database.
9. A system according to claim s, wherein the database further stores a list of caller identifications, and the service management controller compares the caller identification information against the list of caller identifications in the database, wherein said caller identification information is logged in said database in dependence on the information being contained within said list.
10. A system according to claims 8 or 9, and further comprising an interactive voice response module that communicates a list of options to the caller, being actions to be taken when the mobile terminal is back in service; and wherein the database records one or more selected options against the caller identification information.
11. A system according to claim 10, wherein the service management controller is further arranged to communicate that the mobile terminal is back in service in accordance with a selected option previously selected by a caller, as stored in said database.
12. A system according to claim 11, wherein the options comprise one or more selected from the group comprising: i) connecting the calling terminal to the mobile terminal; ii) sending a message to the calling terminal; iii) sending a message to the mobile terminal.
13. A system according to any of claims 8 to 12, wherein the monitoring element is a home location register (HLR) of the mobile telecommunications network, said service management controller being arrange to query said HLR to determine if said mobile handset has come back into service.
14. A system according to any of claims 8 to 13, wherein an address of the service management controller is set as a CNFRc value in the home location register of the mobile telecommunications network, whereby calls to the mobile terminal when it is out of service are routed to the service management controller.