WO2008055302A1

WO2008055302A1 - Enhanced mobile service provision

Info

Publication number: WO2008055302A1
Application number: PCT/AU2007/001706
Authority: WO
Inventors: Malcolm David Macnaughtan; Craig Andrew Scott; Stephen Brown
Original assignee: Seeker Wireless Pty Limited
Priority date: 2006-11-07
Filing date: 2007-11-07
Publication date: 2008-05-15

Abstract

A system, method or apparatus for detecting one or more incompatibilities in a mobile terminal for delivering mobile services via an application installed on a SIM card or on a mobile radio terminal. A series of compatibility tests are conducted to detect and determine the type of incompatibility and the results of these tests may be used to provide one or more enablements to mitigate the incompatibility.

Description

ENHANCED MOBILE SERVICE PROVISION

TECHNICAL FIELD

This invention relates to methods and apparatus for improving the delivery of services to mobile subscribers having a mobile radio terminal in a radio communications network.

PRIORITY

This application claims priority from Australian Provisional Patent Application No. 2006906192 entitled "Enhanced Mobile Service Provision" filed on 7 November 2006. The entire content of this Provisional Application is hereby incorporated by reference.

INCORPORATION BY REFERENCE The following documents are referred to in the following description:

- Co-pending PCT/AU2006/000478 entitled "Enhanced Terrestrial Mobile Location" to the applicant of the present application;

- Specification 3GPP TS 31.111 - sections 6.4.6, 6.6.15, 6.6.16, 6.6.21 and

6.6.22

the entire contents of which are hereby incorporated by reference.

BACKGROUND

The ability to rapidly develop and deploy new services for mobile subscribers is an advantage for mobile telephone network operators. In practice however, the relatively long development cycles for mobile radio terminals combined with the multi-year lifetime for terminals in the marketplace means that rapid service innovation can be difficult. To address this issue several facilities have been developed that enable applications to be developed separately from the mobile radio terminals and deployed after a subscriber has purchased a mobile radio terminal.

One example of such a facility is based on the smart card in which subscriber specific information is typically stored securely. In GSM such a smart card is referred to as a Subscriber Identity Module (SIM). Many such smart cards support a limited ability to run stored programs. One example is the limited support for Java programs via a JavaCard Virtual Machine (JCVM). Such programs may offer so-called mobile commerce applications. Another set of applications that can be deployed on smart cards are location based applications. Such applications may access a subset of the capabilities of the mobile terminal through a set of commands defined in an application programming interface (API). These commands typically provide facilities such as presenting text on the terminal display, obtaining radio measurements from the mobile terminal and also receiving periodic notifications to trigger some repeated activity. Collectively these commands are often referred to as the SIM application toolkit or USIM application toolkit - in the case of 3G mobile radio terminals.

In addition to the ability to develop and deploy applications after the subscriber has purchased a terminal, another advantage of running such applications from the SIM is that it enables mobile operators to customise their service offerings on a standard platform. This is preferable to having to negotiate specific feature development with multiple handset manufacturers to support a new service initiative. A problem that may arise in using an API such as SIM toolkit for instance, to deliver a service to mobile subscribers is that some terminals may not fully support all the facilities defined in the API specification. In some terminals a subset of the features may not be supported at all. In others, the implementation may be defective. Such limitations may be present in handsets already widely distributed in the marketplace meaning that it may not be economically viable to repair or upgrade them. This means that if a service is to be launched that relies on particular API features, the service will not be available to all handsets or mobile radio terminals in the marketplace, representing lost opportunity for the operator.

SUMMARY

According to one aspect of the present invention, there is provided a method for determining the compatibility of a mobile radio terminal with an application residing on a smart card in the mobile radio terminal in a radio communications network, the method comprising: performing at least one test on the mobile radio terminal, to determine whether the mobile radio terminal supports a given function required by the application; and determining as a result of the at least one test, whether the mobile radio terminal is compatible with the application.

In one form, upon determining that the mobile radio terminal is incompatible with the application, the method further comprises suspending the application in relation for the mobile radio terminal.

In another form, upon determining that the mobile radio terminal is incompatible with the application, the method further comprises enabling the mobile radio terminal to be compatible with the application. In a further form, upon determining that the mobile radio terminal is incompatible with the application, the method further comprises providing an option to a user of the mobile radio terminal to proceed with the application.

In one aspect, the determination of compatibility is performed only once for a given mobile radio terminal.

In another aspect, upon power on, the application checks the identity of the mobile radio terminal and compares this with the identity of a mobile radio terminal stored at a previous power on.

In one form, the identity of the mobile radio terminal stored at the previous power on is stored by the application.

In another form, the identity of the mobile radio terminal stored at the previous power on is stored by a server in the radio communications network.

In one form, if the identity checked by the application is different to the identity stored by the application, the application proceeds to determine the compatibility of the mobile radio terminal with the application.

In one aspect, the at least one test is a test of a timing facility of the mobile radio terminal.

In another aspect, the at least one test is a test of a display facility of the mobile radio terminal. In yet another aspect, the at least one test is a test of the mobile radio terminal's ability to report radio measurements.

In one form, the method comprises performing two or more of the tests as described above.

According to another aspect of the present invention, there is provided a method for enabling a mobile radio terminal to be compatible with an application residing on a smart card in the mobile radio terminal, the method comprising: performing at least one test on the mobile radio terminal to determine whether the mobile radio terminal supports a given function required by the application; determining as a result of the at least one test, whether the mobile radio terminal supports the given function; and if it is determined that the mobile radio terminal does not support the given function, performing at least one step to enable the given function.

In one form, the method further comprises determining whether the given function is able to be enabled before performing the steps to enable the given function.

In another form, if it is determined that the given function is not able to be enabled, issuing a notification of incompatibility of the mobile radio terminal with the application.

In one aspect, the given function is a timing facility.

In one form, the at least one step comprises enabling a polling facility. In another form, the at least one step comprises providing a timer rate correction factor to the application.

In another form, the given function is a display facility of the mobile radio terminal. In one form, the display facility is a setup idle text facility.

In another form, the at least one step comprises invoking a service provider name (SPN) file.

In a further form, the at least one step comprises transmitting a text notification from a server in the radio communications system.

In one aspect the server transmits a text message notification to the mobile radio terminal.

In a further form the given function is a capability of the mobile radio terminal reporting radio measurements.

In another form, the given function is a capability of the mobile radio terminal reporting radio measurements in idle mode.

In another aspect, the at least one step comprises causing the mobile radio terminal to enter dedicated mode.

In another form, the method further comprises causing the mobile radio terminal to enter dedicated mode by initiating a network connection. According to another aspect of the present invention, there is provided a method of improving the performance of an application in a mobile radio terminal, the method comprising: determining the compatibility of the mobile radio terminal with the application; and if the mobile radio terminal is determined to be incompatible, modifying the operation of the application to mitigate the effect of the incompatibility .

In one form, the step of determining the compatibility of the mobile radio terminal with the application comprises determining whether the mobile radio terminal supports one or more functions required by the application.

According to another aspect of the present invention, there is provided an application for performing the method of any one of the preceding aspects of the invention.

According to another aspect of the present invention, there is provided a smart card containing an application according to the preceding aspect.

According to another aspect of the present invention, there is provided a radio communications network for performing the method of any one of the preceding aspects.

According to another aspect of the present invention, there is provided a mobile radio terminal for use in a radio communications network including at least one network processor, the mobile radio terminal comprising: a memory device having stored thereon an application configured to perform at least one test on the mobile radio terminal to determine whether the mobile radio terminal supports a given function required by the application. In one form, the application is further configured to determine, as a result of the at least one test, whether the mobile radio terminal is compatible with the application.

In an alternative form, the application is further configured to report the result of the at least one test to the at least one network processor to determine whether the mobile radio terminal is compatible with the application.

In a further form, the application is further configured to receive a signal from the at least one network processor indicating whether the mobile radio terminal is compatible with the application.

In another form, the application is further configured to perform at least one step to enable the given function in the mobile radio terminal if it is determined that the mobile radio terminal is incompatible with the application.

In one form, the memory device is integral to the mobile radio terminal.

In another form, the memory device is a smart card inserted into the mobile radio terminal.

According to a further aspect of the present invention, there is provided a memory device for use in a mobile radio terminal for use in a radio communications network including at least one network processor, the memory device having stored thereon an application configured to perform at least one test on the mobile radio terminal to determine whether the mobile radio terminal supports a given function required by the application. In one form, the memory device is further configured to determine, as a result of the at least one test, whether the mobile radio terminal is compatible with the application.

In another form, the application is further configured to report the result of the at least one test to the at least one network processor to determine whether the mobile radio terminal is compatible with the application.

In another form, the application is further configured to receive a signal from the at least one network processor indicating whether the mobile radio terminal is compatible with the application.

In another aspect, the application is further configured to perform at least one step to enable the given function in the mobile radio terminal if it is determined that the mobile radio terminal is incompatible with the application.

In one form, the memory device is a smart card.

In a further form, the smart card is a Subscriber Identity Module (SIM).

According to another aspect of the present invention, there is provided a server coupled to a radio communications network, the server comprising: a processor for determining whether a mobile radio terminal coupled to the radio communications network is compatible with an application in the mobile radio terminal, as a result of at least one test performed on the mobile radio terminal to determine whether the mobile radio terminal supports a given function required by the application.

In one form, the server further comprises a receiver for receiving the result of the at least one test from the mobile radio terminal.

In another form, the server further comprises a transmitter for transmitting instructions to the application to perform the at least one test.

In a further form, the transmitter is also for transmitting instructions to the mobile radio terminal to enable the given function.

According to another aspect of the present invention, there is provided a system comprising: a mobile radio terminal for use in a radio communications network, the mobile radio terminal having stored thereon an application configured to perform at least one test on the mobile radio terminal to determine whether the mobile radio terminal supports a given function required by the application; and a server for receiving a signal indicative of the result of the at least one test and for determining, as a result of the at least one test, whether the mobile radio terminal is compatible with the application.

According to another aspect of the present invention, there is provided a method of determining the compatibility of a timing facility in a mobile radio terminal for an application in the mobile radio terminal in a radio communications system, the method comprising: invoking at least one timer management command; determining that the timing facility of the mobile radio terminal is incompatible with the application if the mobile radio terminal returns a failure code.

According to another aspect of the present invention, there is provided a method of determining the compatibility with a timing facility in a mobile radio terminal for an application in the mobile radio terminal in a radio communications system, the method comprising: issuing a request to the application in the mobile radio terminal to respond after a given time period; and determining that the timing facility of the mobile radio terminal is incompatible with the application if the response is not received at the given period of time.

According to another aspect of the present invention, there is provided a method of determining the compatibility of a timing facility in a mobile radio terminal with an application in the mobile radio terminal in a radio communications system, the method comprising: requesting the application to transmit a pair of transmissions separated by a known time period; measuring the time period between the transmissions; and determining that the timing facility is incompatible with the application if the measured time period is different to the known time period.

According to another aspect of the present invention, there is provided a method of making compatible an incompatible timing facility of a mobile radio terminal with an application on the mobile radio terminal, the method comprising: enabling a polling facility in the mobile radio terminal. According to another aspect of the present invention, there is provided a method of making compatible an incompatible timing facility of a mobile radio terminal with an application on the mobile radio terminal, the method comprising: determining a time rate error correction factor related to a difference between a time rate required by the application and a time rate provided by the timing facility of the mobile radio terminal; and providing the time rate error correction factor to the application.

According to another aspect of the present invention, there is provided a method of determining the compatibility of a display facility in a mobile radio terminal with an application in the mobile radio terminal in a radio communications system, the method comprising: issuing from the application a command instruction to the mobile radio terminal to display text; and determining that the display facility is incompatible with the application if a failure code is returned.

According to another aspect of the present invention, there is provided a method of making compatible an incompatible display facility of a mobile radio terminal with an application on the mobile radio terminal, the method comprising: upon the display facility returning a failure code in response to a setup idle text request from the application, writing the text for display into the service provider name (SPN) elementary file on the SIM card and invoking a refresh request on the terminal to cause it to re-read the SPN file and display the contents on the terminal display. According to another aspect of the present invention, there is provided a method of determining the compatibility of a display facility in a mobile radio terminal with an application in the mobile radio terminal in a radio communications system, the method comprising: causing the application to display text on the display facility using a setup idle text facility of the mobile radio terminal; causing the application to present a prompt using a dialog facility of the mobile radio terminal requesting a user of the mobile radio terminal to confirm that the text was displayed; and determining that the display facility is incompatible with the application if the user indicates that no text was displayed.

According to another aspect of the present invention, there is provided a method of making compatible an incompatible display facility of a mobile radio terminal with an application on the mobile radio terminal, the method comprising: transmitting information relating to display information to a server in the radio communications system; determining at the server, text information relating to the display information; and transmitting from the server, the text information to the mobile radio terminal.

According to another aspect of the present invention, there is provided a method of determining the compatibility of a radio measurement reporting facility in a mobile radio terminal with an application in the mobile radio terminal in idle mode, in a radio communications system, the method comprising: causing the application to request from the mobile radio terminal, a report of radio measurements; and determining that the radio measurement facility is incompatible if the mobile radio terminal fails to report radio measurements.

According to another aspect of the present invention, there is provided a method of making compatible a radio measurement reporting facility in a mobile radio terminal with an application in the mobile radio terminal in idle mode, in a radio communications system, the method comprising: causing the mobile radio terminal to enter dedicated mode.

According to another aspect of the present invention, there is provided a method of determining the compatibility of a radio measurement reporting facility in a mobile radio terminal with an application in the mobile radio terminal in idle mode, in a radio communications system, the method comprising: causing the application to request from the mobile radio terminal, a first report of radio measurements; causing the application to request from the mobile radio terminal, a second report of radio measurements; comparing the first report and the second report; and determining that the radio measurement facility is incompatible if the first report and the second report are identical.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects of the present invention will now be described in detail with reference to the accompanying drawings in which: Figure 1 - shows a typical network architecture in which the present invention may be applied;

Figure 2 - shows a mobile radio terminal with an associated SIM card in which is installed an application to support a particular type of service,

Figure 3 - shows a mobile radio terminal with an alternative facility for custom applications to be downloaded and execute on the terminal;

Figure 4 - illustrates one process for detecting and adapting to one or more types of terminal incompatibility;

Figure 5 - illustrates a similar method to that described in relation to Figure 4, but with an alternative action being taken upon detecting a limitation that cannot be successfully worked around;

Figure 6 - illustrates a process for detecting and adapting to one or more terminal incompatibilities;

Figure 7 - illustrates a structure for implementing the timer adaptation in a SIM toolkit application;

Figure 8 - illustrates arrangements for achieving timer rate correction;

Figure 9 - illustrates one test and process for detecting and adapting to timer limitations;

Figure 10 - illustrates a process for detecting and adapting to display limitations; and Figure 11 - illustrates the process for detecting and adapting to terminal limitations in reporting radio measurements in idle mode.

DETAILED DESCRIPTION

The present invention will now be described in detail with reference to one or more embodiments of the invention, examples of which are illustrated in the accompanying drawings. The examples and embodiments are provided by way of explanation only and are not to be taken as limiting to the scope of the invention. Furthermore, features illustrated or described as part of one embodiment may be used with one or more other embodiments to provide a further new combination. It will be understood that the present invention will cover these variations and embodiments as well as variations and modifications.

Throughout this specification, the term "mobile radio terminal" is used synonymously with terms such as "mobile phone" , "cell phone" or "handset", and will be understood to encompass any kind of mobile radio terminal such as a cell phone, Personal Digital Assistant (PDA), lap top or other mobile computer, or pager.

While the various aspects of the present invention are described using examples based primarily on the STK API, it will be understood by one of ordinary skill in the art that the mechanisms and benefits provided are equally applicable to other platforms for deploying custom applications on mobile terminals. Alternative facilities for deploying applications on mobile terminals include the Symbian Series 60 platform supported by many current GSM and 3G handsets. Another example is the BREW platform. Yet another is the Java Mobile Edition (J2ME) virtual machine supported by many devices. In the following description, when processing is described as being carried out in a mobile terminal, it will be understood that the processing could be carried out in the handset, in the Subscriber Identification Module (SIM) that is inserted in the handset, in an additional processing or smart card inserted into the handset, or in a combination of two or more of these.

It will also be understood that much of the processing that occurs in the implementation of various aspects of the present invention can also be distributed between the handset, one or more network elements within the radio communications network and/ or one or more elements outside the radio communications network.

The term 'incompatible' is used throughout the description. In stating that a mobile radio terminal is 'incompatible' with a given application, it is meant that the mobile radio terminal does not implement or support one or more functions as required by the application, or as defined in an applicable specification.

Conversely, a mobile radio terminal will be compatible with a given application if the mobile radio terminal implements or supports one or more functions as required by the application, or as defined in an applicable specification.

One example of such a specification is 3GPP TS 31.111 which defines the interface between a mobile phone and a USIM card and also the services which the phone must provide for use by an application running on the card.

Embodiments of the present invention provide methods, devices, and systems for determining compatibility/ incompatibility of a mobile radio terminal to an application in a radio communication network. A problem may arise in using an API to deliver a service to mobile subscribers in that some terminals do not fully support all the facilities defined in the API specification. In some terminals a subset of the features may not be supported at all. In others, the implementation may be defective. Such limitations may be present in handsets already widely distributed. Therefore, if a service is to be launched/ implemented that relies on at least one API feature, the service may not be available to all handsets or mobile radio terminals.

A variety of 'workarounds' for terminal incompatibilities are also provided in one aspect of the present invention. These workarounds provide alternative mechanisms for achieving a desired result when a terminal incompatibility prevents an application from operating in the standard manner. In some cases a workaround may provide an equivalent level of functionality. In other cases there may be some compromise, e.g., in terms of performance or efficiency. The acceptability of a workaround given any performance degradation or inefficiency may also be a subjective matter. The present invention provides a variety of workarounds for different types of terminal incompatibilities, in a flexible framework which enables an operator to choose which workarounds are acceptable and to enable them either automatically or by manual intervention, perhaps by a customer care representative.

In an example of one aspect of the present invention, an application may be deployed on a SIM card for the purpose of monitoring the location of the radio terminal using radio measurements obtained from the terminal. In one form, at power on, the application would request the equipment identifier associated with the phone and check this against the stored identifier for the phone. If the identifier has changed, indicating that the SIM has been inserted in a different terminal, the application will request some radio measurements from the terminal. The application checks the result of the request, both in terms of the result code as well as the data returned (if any) to ensure that the request was completed successfully. If either of these tests fails and there is no workaround available, the application may disable the service and display a message on the handset screen advising the user of this. Disabling the service in this case may mean, deactivating menu entries relating to the service so that the user cannot attempt to use the service. In addition, the application may send a message to the server in the network, informing it that the current terminal is not compatible. On the network side, this message may in turn affect other aspects of the service including for instance, the response issued when a client connects to the service requesting the current location of the terminal.

In another example, an application may be installed on a SIM card in a mobile phone in order to periodically report the location of the phone based on radio measurements retrieved from the phone. To achieve this periodic operation, the application normally uses the timer management facility defined in the phone to SIM interface specification. On power up, the application checks the identity of the phone as described previously. If the application detects that it has been inserted in a new phone, it exercises the timer management commands to allocate, start and stop a timer. If any of these are not supported, as detected based on the result of the application's requests to the phone, the application will not, without some workaround be able to operate the periodic reporting service. In this case, the application may attempt to use the alternative polling facility, by requesting a specific polling interval and registering for polling event notifications according to 3GPP TS 31.111, section 6.4.6 & 6.6.16. On successful receipt of a polling event, the application enables the service, and sets a variable which causes it to use the polling facility instead of the timer management facility while operating on the present terminal. In this way the application is able to continue to operate successfully on this terminal despite the lack of support for the specified timer management commands.

Figure 1 illustrates a typical scenario in which the various aspects of the present invention may be applied. Shown are a mobile radio terminal 10, in which is inserted a SIM card 11. A Java applet 12, is installed on the SIM card 11 and utilises the capabilities of the mobile terminal 10, via the SIM toolkit API. The terminal 10 communicates with the radio communications network 20, which includes base stations 21, 22 and 23. Also shown is a network based server 60, with which the applet may exchange messages at different times to provide a service to the user of the mobile terminal. A customer care system workstation (70) is also shown from which a representative may issue requests to the service relating to testing and workarounds for terminal incompatibilities.

SYSTEM ARCHITECTURE

The structural aspects of the present invention can be understood by reference to Figure 1. Several architectural alternatives exist as will be discussed in the following paragraphs.

In one embodiment, the methods provided by the present invention may be implemented primarily in the application at the mobile terminal 10, for example in the SIM toolkit Java applet (12). In alternative embodiments, the methods may be implemented in an application that executes partially, substantially, or primarily in the processor of the mobile terminal 10, for example, a Symbian S60 or Qualcomm BREW application. In this aspect, the set of compatibility tests that can be run and the available workarounds should these tests reveal incompatibilities are defined in the applet. The compatibility testing is executed by the applet and the workarounds, if any, are enabled automatically by the applet. An advantage of one form of this aspect is that no message exchanges are required with any remote servers. In another embodiment, the compatibility tests are executed by the SIM applet 12, but the initiation of compatibility tests is controlled from a network based server 60. This might be triggered by reception of an event notification from the applet 12, for instance a terminal power on event. The testing may also be initiated by a customer care representative, or other external party, from a workstation 70. In one aspect, the enabling of one or more workarounds is controlled from the server 60. In this arrangement, server side software is easily modified in response to changing operator requirements and different tests can be enabled or disabled as can selected workarounds with easy software configuration changes or upgrades on the network. Furthermore, in this arrangement, customer care representatives can exercise some control over the testing and workarounds based on service provider policies.

A third alternative is a combination of the preceding two in which the compatibility tests are executed by the SIM applet and controlled either remotely by a network based server or locally by the subscriber from a menu. The workarounds may also be enabled remotely via a message from the server or by subscriber selection at the terminal.

TESTING TO DETECT INCOMPATIBILITIES One step in overcoming one or more incompatibilities in a mobile radio terminal is testing the terminal to identify such incompatibilities. Various aspects of the present invention provide a variety of means for such testing to occur. A terminal incompatibility is considered herein as a characteristic of a particular terminal. An incompatibility may or may not be common to all devices of a particular manufacturer or model. An incompatibility may also exist only in certain releases of a particular terminal model, owing for instance to a defect that is rectified in later releases. In one aspect, the present invention provides a means for testing each specific terminal in which a subscriber attempts to use the application, and enabling adaptations specifically by device. It is still within the scope of the present invention however, to apply the results and subsequent actions in relation to one mobile radio terminal within a subgroup of mobile radio terminals to other mobile radio terminals within that subgroup

One form of incompatibility is that a terminal does not support a given function required by the application. Examples of given functions that may be required by a particular application include, but are not limited to: timing functions, including proactive polling; persistent visual displays; Setup Idle Text Command; and making radio parameter measurements in idle and dedicated mode. These and other given functions will be described in more detail below.

An incompatibility may also be temporal, for instance triggered by a characteristic of the radio network. One example is a defect in the radio which is triggered by poor radio reception conditions when the terminal 'roams' onto another service provider's network.

For potential incompatibilities which are believed to be persistent (i.e. not temporal), it is possible, in one form of the invention, to only test for the incompatibility once for a given terminal (although, the detection could be done upon each power on or other interval as desired). In another form of the invention, compatibility tests might only be performed as necessary, and in one aspect, following power on for the first time after a SIM bearing the applet is inserted in a new terminal. Completing the testing at power on can ensure that any adaptations which are required may be applied before the subscriber commences using the service provided by the application hosted in that particular terminal.

The present invention also provides an option to trigger one or more compatibility tests remotely from a network based server. This facility could be used for example by customer care staff while processing an enquiry from a subscriber in relation to the service supported by the application, such as a zone detection service as described in PCT/ AU2006/ 000478 entitled "Enhanced Terrestrial Mobile Location" to the applicant of the present application. In such an example, a customer may call to complain that the application is incorrectly detecting them as out of the zone when in fact they are in the zone. The customer care operator processing the enquiry could remotely trigger one or more tests of the radio measurement capabilities of the subscriber's phone to determine whether a terminal incompatibility is the cause of the service issues. In this case, the customer care system could be integrated with a network based server which would accept the request from the customer care operator to perform the tests. The server sends a request to the application at the subscriber's mobile to trigger appropriate tests and report the results. The server processes the results and returns an indication to the customer care operator as to whether the radio measurements reported by the subscriber's terminal were accurate.

Another option provided by another aspect of the present invention is for the subscriber to trigger one or more compatibility tests themselves. This might be done for instance when considering subscribing to the service, to determine whether the subscriber's existing terminal is compatible with the application. Using the example of a SIM based application, a menu is provided which enables the user to initiate one or more compatibility tests. When triggered, the SIM application would initiate the tests. The results of the tests would then be reported to the subscriber indicating whether the terminal is compatible with the application and the service.

Figure 2 shows the mobile radio terminal 10 with associated SIM card 11 in which is installed application 12 to support a particular type of service. For example, the application may support a location based service such as a home zone service. Another example of an application might be a positioning service used to lookup points of interest based on the subscriber's current location. Yet another type of application might be a mobile commerce application in which the SIM is used as an electronic wallet to enable subscribers to purchase goods or services using their mobile phone. The application 12 on the SIM 11 may use facilities defined in the API to access capabilities and services of the terminal 10, optionally including a communications facility with a remote network based server 60.

The application 12 on the SIM 11 detects that the SIM 11 has been inserted in a new mobile radio terminal 10 by requesting the terminal identifier each time, following power on. As an example in GSM and UMTS the application 12 can request the International Mobile Equipment Identifier (IMEI) which is unique to each handset or mobile radio terminal 10. The reported IMEI is stored in persistent memory and compared with an IMEI stored on the SIM 11. A change of handset is evident from a change of IMEI, in which case the new IMEI is stored in the SIM after completing any processing to qualify and adapt for the characteristics of the new mobile radio terminal 10. If one or more limitations are detected for which it is possible for the application 12 to apply a workaround, this may be done automatically by the applet. The SIM based applet may in one form of the invention, also notify the server 60 of the results of the terminal capability tests and any adaptations that have been enabled as a result.

Figure 3 shows a mobile radio terminal 10 with an alternative facility for an application 15 to be downloaded and executed directly on the terminal 10, rather than on a SIM card. There may also be provided an application programming interface, optionally including a communications service with a remote network based server 60.

In an alternative arrangement, the applet provides support for the compatibility testing and adaptation but the process is driven from the server 60. In this case, the applet notifies the server 60 upon detecting a new terminal 10. Upon receiving this notification, the server 60 may command the applet to complete one or more compatibility tests, the results of which may be reported back to the server 60. Using the results of these tests, the server 60 may enable one or more adaptations to overcome incompatibilities with the terminal 10.

Figure 4 illustrates one process for detecting and adapting to one or more types of terminal incompatibility. The process commences at step 100 when a SIM card with an application installed is first powered on in a new terminal. In step 110, the application checks the identity of the mobile terminal and compares this identity with the identity stored by the application from the previous power on cycle. In the event that this is the first ever power on cycle, the previous ID will be empty or undefined. Having detected a new terminal, in this case the application initiates a series of terminal capability tests in step 120. In step 130, the method determines whether or not there are any limitations or incompatibilities. If no terminal incompatibilities are found, the application commences normal operation, optionally notifying a network based server of the identity of the terminal and the outcome of the tests (step 170). In the event that one or more incompatibilities are found, the application determines whether the incompatibilities or limitations can be worked around in step 140. If so, the application attempts in step 150 to apply one or more adaptations or "workarounds" as appropriate. In the event that the adaptations are effective in working around the incompatibilities, the application commences normal operation, optionally notifying a server as described above. In the event that some incompatibilities remain unresolved the application may disable the service, as shown in step 160. In this case the outcome may be signalled to a server and optionally information presented on the terminal display to also advise the user that the service is incompatible with the present terminal. This notification can also optionally be provided to customer care to enable further action to be initiated to enable access to the service for this subscriber.

In an alternative form of the method of Figure 4, the steps as described in relation to Figure 4 may be followed, except at step 160', instead of disabling the service, the user may still be permitted to attempt to use the service, however a warning message may be presented advising them that the service may be affected by incompatibilities between the application and the present terminal. This alternative form is shown in Figure 5, where like steps of Figure 4 are labelled accordingly. Customer care may also optionally be advised of the outcome.

Figure 6 shows another method according to another aspect of the present invention. After starting at step 200, the application issues a notification to a network based server after power on in step 201, providing the terminal identity. The server then determines whether the transmitted terminal identity has changed since the last power on, at step 202. In the event that this is the first power on cycle in this terminal the server initiates a series of tests at step 203 by issuing commands to the application. On completion of the tests, the server decides whether there are any incompatibilities at step 204. If not, the service is provided as normal operation. If at step 204 it is determined that there is one or more incompatibility, the server determines whether the incompatibility can be worked around in step 205. Alternatively, it would be possible to record the incompatibilities and then alert a customer care representative who could enable one or more workarounds. If so, the system enables the workarounds as appropriate in step 207 and ends at step 208 to then proceed to provide the service as normal. If it is determined in step 205 that one or more of the incompatibilities cannot be worked around, the system advises the user in step 206 of possible problems with the service. As previously discussed, it is also possible to completely disable the service.

INCOMPATIBILITIES IN TIMER FACILITY

One facility commonly used by SIM based applications is timers. Terminal based timer notification for a SIM based application is needed because SIM cards typically do not have a clock. Therefore if an application on the SIM (11) involves any repeated activity, it is necessary for the application to receive some form of periodic notification driven by the mobile radio terminal (10). One such facility is specified for instance in section 6.6.21 of 3GPP TS 31.111.

Multiple types of tests are provided by various aspects of the present invention. In one type of test the application (12) may issue a request to the terminal (10) to allocate a timer and then request that the terminal start the timer. If the terminal refuses either request, returning any failure code, the application notes this as a failure. In another form of test, a server may issue a request for the application to wait for a given period of time and then issue a response. In the absence of a response, the server may conclude that the timer facility needed by the application to issue the time delayed response is lacking in the present terminal. Alternatively if the response is received either too early or too late, the server can detect errors in the timer rate supported by the terminal. In yet another type of test the application may issue a pair of messages to a server separated by a nominal interval known to the server. Any difference between the nominal interval and the actual measured interval between messages at the server can be used to detect timer rate offsets.

MECHANISM FOR ADAPTING TO TIMER INCOMPATIBILITY

In GSM and 3G phones, there is an alternative periodic notification facility known as proactive polling. If the terminal lacks support for the more flexible timer management facility, the application can be switched to instead use the proactive polling facility. Figure 7 illustrates a possible implementation for this capability. Within the application there are likely to be one or more modules which require periodic notification in order to trigger some periodic processing. Two such modules are shown as application module 1 and application module 2. A typical design would encapsulate the functionality relating to periodic timer functionality into a timer module 3. To implement the ability to workaround a timer limitation, this module would be designed to encapsulate functionality for providing periodic notification using the SIM Toolkit Timer Management commands. In figure 7 this is illustrated as the Timer Management sub-module 4. Similarly the functionality for providing periodic notification based on Proactive Polling could be implemented in another sub-module, here shown as Polling 5. When enabled, this polling module would register for the event defined in the STK API as EVENT_STATUS_COMMAND. It would request the terminal to set the Poll Interval based on the rate of periodic notification required by the application modules. The outer Timer Module 3 would support either Timer Management or Polling based operation, depending on the outcome of timer compatibility testing. In this way those components of the applet which require periodic inputs can be designed to operate independently and the timer compatibility detection and workaround can be implemented transparently.

MECHANISM FOR ADAPTING TO TIMER RATE INCOMPATIBILITY In some cases the timer rate may be fixed, typically at a rate faster than required by a SIM based application. The application (12) can request the terminal (10) to report the actual polling rate and apply an adjustment as described below. In other cases, the terminal (10) may run the timer at a different rate from that requested or may incorrectly report the actual rate of periodic notifications. Assuming a timer rate offset such as this is detected using one of the tests described above, one form of the present invention provides a timer rate correction factor to be applied by the application (12) on the SIM (11).

In one form of this aspect of the invention, for a terminal (10) that does support timers but have an offset in the rate, the application (12) adjusts the time interval requested from the terminal (10) by the appropriate factor. For a terminal (10) which runs at a fixed rate faster than required by the application (12), the application implements a "divide by N" counter using only every Nth timer notification. This is illustrated in Figure 8 (a). In the simple case where the terminal timer rate is a multiple of the required rate, say 4 times faster than required, the application may discard 3 out of every 4 timer notifications using only every fourth. For cases where there is a fractional difference between the timer interval measured by the terminal and the true required rate a fractional division may be achieved by running the terminal at a faster rate and dividing down. To illustrate, assume that we wish to correct the rate by increasing it by 50 percent (in other words to reduce the interval between timer events by 1/3). In this case the application configures the terminal for a rate 3 times higher than the nominal rate as illustrated in Figure 8 (b). The application then divides this rate by a factor of 2, discarding every second timer event. The result is an output timer interval 2/3 of the original interval. Figure 9 shows a method in which a test of the terminal timer facilities is initiated, incorporating several of the options discussed above. After starting at step 300, the method proceeds to invoke timer management commands in step 301 as described above. The method will then determine whether timer facilities are supported (i.e. whether there are any incompatibilities of the timer functions with the application) at step 302, by checking the response code returned by the terminal. If the response code does not indicate successful completion of the request, an alternative mechanism for periodic activity is enabled at step 303 (for example enabling the polling facility as described above). In the example of Figure 9, the application, in step 304, then issues a message to a network based server. Using whichever timer mechanism is currently enabled, the application waits for a nominal period of time (N seconds as shown in step 305) as measured by the terminal timer before sending a second message to the server in step 306. In step 307, the server measures the interval between the messages and compares it with the nominal interval. In step 308, the server determines whether the interval is correct. If it is, the process ends at step 310 to continue to function normally. If there the determined interval is incorrect, a rate calibration factor is calculated and sent to the application in step 309 for use in achieving the correct interval. INCOMPATIBILITIES IN DISPLAY FACILITIES

For some applications, it may be necessary to present a persistent visual indication (as distinct from a brief pop-up notification) to subscribers. Using the example of the STK API, one such facility is supported by the Setup Idle Text Command (3GPP TS 31.111, section 6.6.22). In some terminals however, this facility may not be supported. In particular, in some terminals, when an application invokes a setup idle text request, the terminal returns a failure code. In other terminals however, a success code may be returned but no text actually displayed in which case it is not possible for the application to automatically detect the lack of terminal support. For such cases, another form of the present invention provides a further means to detect the lack of support. The application displays some text on the screen using the setup idle text facility and then presents a prompt using the more widely supported dialog facility requesting the subscriber to confirm that the preceding message text was displayed correctly. If the user indicates that no text was seen then the application is able to detect and report the terminal lack of support.

USE OF ALTERNATIVE DISPLAY MECHANISMS

For terminals that do lack support for the setup idle text facility, a workaround is applied involving a file known as the Service Provider Name (SPN) elementary file (EF) on the SIM. This file is defined in the GSM & UMTS SIM specification (designated as EF_SPN). By default it is used to store a text string containing the name of the service provider. The terminal can read this text from the file and present the contents persistently on the display. For SIM based applications that require a persistent display facility, this file can be used. Whenever the SIM application needs to update the text displayed to the user, it writes the new text to EFjSPN and then issues a refresh request to the terminal, causing the terminal to re-read the elementary file and display the updated text on the screen. In another form, the present invention also provides a means for an operator to remotely enable or disable this workaround. In the event that no workaround is possible, one form of the present invention provides an alternative means to provide textual notifications to a subscriber. By reporting the results of the tests to the server and in particular the lack of a suitable display facility for use by an application, the server can assume the responsibility for issuing text notifications. This can be achieved for instance by sending server originated text SMS to the terminal which will be presented on the display. In the case of a zone based service for example, implemented using a SIM based application, it is an option to advise the user of their current zone status and therefore the tariff that will be applied if they use any network services. If a persistent display facility is not available on the terminal, an alternative may be to advise them whenever the system considers that their zone status has changed and their call tariff is changed. For subscribers using terminals that lack a persistent display facility for the SIM application, the server can instead issue notifications to the subscriber whenever the zone status is updated using text SMS.

Another alternative when there is no support for a persistent display of the information on the handset is to instead convey the information via an audio notification played to the user at call setup. As an example, in a zone based variable tariff scheme, hen the subscriber places a call, the call may first be routed to an intelligent peripheral which plays back a message indicating the current tariff that applies enabling the user to cancel the request if desired.

Figure 10 illustrates a process for detecting and adapting to display limitations according to one form of this aspect of the present invention. After start step 400, the process will initiate the idle screen text in step 401. If as a result of this initiation step, it is determined in step 402 that the idle text facility is not supported, as described above, an alternative mechanism (such as SPN) is activated in step 403 and the request repeated. Using the prompt display facility, the application may then, in step 404, request the user to confirm that the text was displayed correctly. A check to see if the text was properly displayed is then made in step 405. The outcome is notified to the server in step 407. If the user indicated that the text was not displayed correctly (as determined in step 405), the application then causes the terminal to request of the server, an alternative means of presenting text notifications to the user, as shown in step 406. This may be via text SMS generated directly form the server as described previously. The process then ends at step 408.

INCOMPATIBILITIES IN RADIO MEASUREMENTS Another type of incompatibility exists in some terminals in reporting radio parameter measurements via an API. There are different types of radio parameter measurement limitations for which this aspect of the present invention provides targeted solutions as described in the following paragraphs (see 3GPP 31.111, section 6.6.15).

In some cases, the terminal may only report detailed radio measurements while in dedicated mode. In idle mode the reporting may be limited to Cell Identities only. In one form of this aspect of the present invention, the terminal based application tests for this type of limitation by requesting radio measurements from the terminal as part of evaluating the capabilities of the terminal. During these tests, the application monitors other events that may be reported by the terminal to ensure that the terminal remains in idle mode for the duration of the testing. This is because if the terminal activates a connection and therefore reports detailed radio measurements, the terminal application would incorrectly conclude that idle mode measurements are supported. The events monitored include any that indicate SMS transmission or reception and also call establishment. If the test does coincide with a connection to the network, the test is restarted. If no detailed radio measurements are reported then the application records the fact that the terminal does not support the detailed radio measurements.

For terminals having this limitation, the SIM based application enables a mode of operation in which the application initiates a network connection first before requesting detailed radio measurements. This involves for example sending an SMS or starting a call to put the terminal in dedicated mode.

Another radio measurement related limitation exists in other terminals. While in idle mode, such terminals do report detailed radio measurements. However these may be stale in the sense that the values reported are those measured at the time of the last connection with the network. If the terminal has moved in the mean time, such stale measurements are less useful for localisation type applications. The terminal based application in the present invention tests for this by comparing the results of successive radio measurement requests and if they are identical, recording the fact that the terminal appears to report stale radio measurements in idle mode. The expectation that successive radio measurements should not be identical arises from the characteristics of mobile radio propagation where random channel variations give rise to rapid random variations in signal levels. In such terminal once again, the application enables the adaptation to force a connection before requesting measurements. Tables 1 & 2 below show an example from a terminal exhibiting this kind of limitation. These measurements were obtained from a Sony Ericsson K750i mobile terminal by a SIM toolkit applet. The tables show two consecutive measurement cycles, in which the PROVIDE LOCAL INFO command was used to obtain the location and network measurement results. In this case the results from the two cycles are identical because the terminal continues to report measurements saved at the last connection to the network.

TABLE 1 : measurements from first measurement cycle

TABLE 2 : measurements from second measurement cycle

Table 3 shows the results of a third measurement cycle initiated after first sending an SMS from the phone to force it to establish a connection to the radio network. In this case the measurements have changed since the previous request. The same cells are reported but the signal levels have all changed marginally. In addition the last two cells have reversed in order as the weakest cell in the initial two cycles is now measured with a higher signal level than the one immediately above it in the previous cycles.

TABLE 3 : measurements from third measurement cycle after sending SMS

Yet a further variation on this exists with a number of handsets currently in existence. In these devices, there is generally no support for detailed radio measurements in idle mode. There is an exception however and this is immediately following an idle cell reselection. Such reselection events occur frequently, especially when the terminal is in motion. On such terminals, if a SIM application requests detailed measurements immediately following a reselection, the terminal provides them despite remaining in idle mode. The SIM application of the present invention therefore synchronises its requests with the terminal idle cell reselection by registering for the Location Status event. When this event occurs, the application issues a request for the measurements and obtains a valid set of detailed measurements. This enables the application to continue to perform the processing for which it requires detailed radio measurements while the terminal is in idle mode.

In yet another type of limitation, a radio terminal may report detailed radio parameters but one or more of the parameters may in some cases be erroneous. The SIM based application in the present invention detects several types of such errors and adapts to them. One example is exhibited by some GSM mobile terminals which incorrectly report signals having a greater received level than -47 dBm. The most significant bit is not set in this case meaning that values swing from -47dBm to -HOdBm. The application detects this from the fact that neighbour cells are expected to be weaker than the serving cell. If a serving level is reported much weaker than one or more neighbour cells then this is wrapped around.

In this aspect of the present invention the SIM application may also use the assistance of a network based server to detect erroneous radio measurement reports by a terminal. The advantage of using the server is that the server can be equipped with a radio network configuration database and therefore validate the measurements. One example of an error seen in some GSM devices is occasional incorrect reporting of BSIC values of zero. While zero is a legitimate value for the BSIC associated with a GSM cell, it is rarely used in networks. Because the value is legitimate, it is not possible for the SIM application to determine in isolation whether the BSIC is correctly reported or whether it is due to a terminal error. The server however can analyse the cells in the vicinity of the mobile and check whether there is a cell configured with a BSIC of zero. If not, and if zero is not used in the network then the server can enable an adaptation in the application in which zero value BSICs are flagged as invalid reports. The effect of this flagging will depend on the specific processing being performed. If the processing is for zone detection as described in PCT/ AU2006/ 000478 entitled "Enhanced Terrestrial Mobile Location" to the applicant of the present application, then this particular cell report may be excluded from the cost calculations. Alternatively all other reports may be matched first and then a match for this cell sought in the profile using the ARFCN only.

Figure 11 illustrates the process for detecting and adapting to terminal limitations in reporting radio measurements in idle mode. Starting at step 500, when the test is initiated, the application attempts to read some NMR measurements from the terminal while it is in idle mode in step 501. The result of this attempt is obtained in step 502. If successful, the application notifies the server of the results in step 507. Alternatively if the terminal does not support the request in idle mode, the application repeats the test after putting the terminal in dedicated mode by initiating a call in step 503. The result of this repeated test is then determined at step 504. If this test fails the application notifies the server and the process concludes at steps 507 and 508. At this stage the server may disable the service on the terminal and notify the subscriber and customer care. If the test is successful however, the application also tests whether NMR results are available after SMS transmission (step 505) and location status events (step 506). The server is then notified accordingly in step 507.

For example, in certain embodiments utilizing a Symbian S60 software platform, the application could obtain network measurements from the terminal via an API such as Mobinfo or ETeBrdParty. The application could first make a ETeBrdParty API function call such as GetCallStatus to determine whether the terminal was currently in idle mode. While in idle mode, the terminal could make a function call such as GetSignalStrength to attempt to obtain network measurements in step 501. The result of this function call is returned in step 502. If the call is successful, the application notifies the server in step 507. However, if the GetSignalStrength function is not supported, the method will return an error message such as

'KErrNotSupported'. The application may then repeat the test after putting the terminal in dedicated mode by initiating a call using, for example, the EstablishDataCall or DialNewCall functions in step 503. The result of this repeated test is then determined at step 504. If this test fails the application notifies the server and the process concludes at steps 507 and 508. The server may disable the service on the terminal and notify the subscriber and customer care. However, if the test was successful the application may repeat the test after SMS transmission and location status events as described above.

HANDLING ADDITIONAL NEW INCOMPATIBILITIES

The continual introduction of new handsets into the marketplace poses further issues for operators seeking to deploy services on SIM cards. Each new handset brings the possibility of additional limitations which have not: been anticipated. Such new incompatibilities could preclude the service from being used with new handsets.

Various aspects of the present invention provide means for addressing this issue. The applet which is deployed on subscriber SIM cards is designed to support over the air update (OTA). In the event that a new type of compatibility is detected two options are afforded. If the incompatibility can be detected by exercising existing facilities in the applet, then the server based diagnostic process can be extended to exercise the facility. Alternatively the applet can be updated over the air, adding additional functionality to exercise the terminal in a fashion which detects the presence of the incompatibility in affected terminals. Once the incompatibility is able to be detected by the applet, depending on the nature of the incompatibility, either server based or applet based features are added to work around the incompatibility. For features needed in the handset an OTA upgrade can be performed. This can be done either globally to all subscriber SIMs or individually, only as required for subscribers with affected handsets as highlighted by the results of incompatibility testing on individual terminals.

In the preceding sections the term SIM is frequently used when referring to the smart card bearing the mobile client software of the present invention. It should be noted that the term SIM is used as a specific example and should not be construed as a limitation of the present invention. It will be understood by one of ordinary skill in the art that the invention may equally be applied for instance to USIMs in 3G terminals and similarly in other mobile terminal applications developed to run against terminal based APIs including Symbian Series 60 and BREW.

It will also be appreciated that the one or more application could be stored on a resident or integral memory device of the mobile radio terminal itself. The present application is also intended to cover applications for performing the various methods described above, including memory devices such as computer memory, CDs, DVDs, and any other portable memory device storing the one or more applications.

It will also be understood that the present application will cover various network elements or processors such as a server, which may be used in performing one or more aspects of the present invention as described in detail above, as well as a system incorporating one or more elements described above, such as the mobile radio terminal, the application and the server. It will be understood that the term "comprise" and any of its derivatives (eg. comprises, comprising) as used in this specification is to be taken to be inclusive of features to which it refers, and is not meant to exclude the presence of any additional features unless otherwise stated or implied.

Claims

THE CLAIMS:

1. A method for determining the compatibility of a mobile radio terminal with an application residing on a smart card in the mobile radio terminal in a radio communications network, the method comprising: performing at least one test on the mobile radio terminal to determine whether the mobile radio terminal supports a given function required by the application; and determining as a result of the at least one test, whether the mobile radio terminal is compatible with the application.

2. A method as claimed in claim 1 wherein upon determining that the mobile radio terminal is incompatible with the application, suspending the application for the mobile radio terminal.

3. A method as claimed in claim 1 wherein upon determining that the mobile radio terminal is incompatible with the application, enabling the mobile radio terminal to be compatible with the application.

4. A method as claimed in claim 1 wherein upon determining that the mobile radio terminal is incompatible with the application, providing an option to a user of the mobile radio terminal to proceed with the application.

5. A method as claimed in any one of claims 1 to 4 wherein the determination of compatibility is performed only once for a given mobile radio terminal.

6. A method as claimed in claim 5 wherein upon power on, the application checks the identity of the mobile radio terminal and compares this with the identity of a mobile radio terminal stored at a previous power on.

7. A method as claimed in claim 6 wherein the identity of the mobile radio terminal stored at the previous power on is stored by the application.

8. A method as claimed in claim 6 wherein the identity of the mobile radio terminal stored at the previous power on is stored by a server in the radio communications network.

9. A method as claimed in claim 6 wherein if the identity checked by the application is different to the identity stored by the application, the application proceeds to determine the compatibility of the mobile radio terminal with the application.

10. A method as claimed in any one of claims 1 to 9 wherein the at least one test is a test of a timing facility of the mobile radio terminal.

11. A method as claimed in any one of claims 1 to 9 wherein the at least one test is a test of a display facility of the mobile radio terminal.

12. A method as claimed in any one of claims 1 to 9 wherein the at least one test is a test of the mobile radio terminal's ability to report radio measurements.

13. A method as claimed in any one of claims 1 to 9 wherein the method comprises performing two or more of the tests as claimed in any one of claims

10 to 12.

14. A method for enabling a mobile radio terminal to be compatible with an application residing on a smart card in the mobile radio terminal, the method comprising: performing at least one test on the mobile radio terminal to determine whether the mobile radio terminal supports a given function required by the application; determining as a result of the at least one test, whether the mobile radio terminal supports the given function; and if it is determined that the mobile radio terminal does not support the given function, performing at least one step to enable the given function.

15. A method as claimed in claim 14 further comprising determining whether the given function is able to be enabled before performing the steps to enable the given function.

16. A method as claimed in claim 15 wherein if it is determined that the given function is not able to be enabled, issuing a notification of incompatibility of the mobile radio terminal with the application.

17. A method as claimed in any one of claims 14 to 16 wherein the given function is a timing facility.

18. A method as claimed in claim 17 wherein the at least one step comprises enabling a polling facility.

19. A method as claimed in claim 17 wherein the at least one step comprises providing a timer rate correction factor to the application.

20. A method as claimed in any one of claims 14 to 16 wherein the given function is a display facility of the mobile radio terminal.

21. A method as claimed in claim 20 wherein the display facility is a setup idle text facility.

22. A method as claimed in claim 21 wherein the at least one step comprises invoking a service provider name (SPN) file.

23. A method as claimed in claim 20 wherein the at least one step comprises transmitting a notification to a server in the radio communications system.

24. A method as claimed in claim 23 wherein the server transmits a text message relating to the notification to the mobile radio terminal.

25. A method as claimed in claim 20 wherein the given function is a capability of the mobile radio terminal reporting radio measurements.

26. A method as claimed in claim 25 wherein the given function is a capability of the mobile radio terminal reporting radio measurements in idle mode.

27. A method as claimed in claim 26 wherein the at least one step comprises causing the mobile radio terminal to enter dedicated mode.

28. A method according to claim 27 comprising causing the mobile radio terminal to enter dedicated mode by initiating a network connection.

29. An application for performing the method of any one of claims 1 to 28.

30. A smart card containing an application as claimed in claim 29.

31. A radio communications network for performing the method of any one of claims 1 to 28.

32. A mobile radio terminal for use in a radio communications network including at least one network processor, the mobile radio terminal comprising: a memory device having stored thereon an application configured to perform at least one test on the mobile radio terminal to determine whether the mobile radio terminal supports a given function required by the application.

33. A mobile radio terminal as claimed in claim 32 wherein the application is further configured to determine, as a result of the at least one test, whether the mobile radio terminal is compatible with the application.

34. A mobile radio terminal as claimed in claim 32 wherein the application is further configured to report the result of the at least one test to the at least one network processor to determine whether the mobile radio terminal is compatible with the application.

35. A mobile radio terminal as claimed in claim 34 wherein the application is further configured to receive a signal from the at least one network processor indicating whether the mobile radio terminal is compatible with the application.

36. A mobile radio terminal as claimed in claim 33 or 35 wherein the application is further configured to perform at least one step to enable the given function in the mobile radio terminal if it is determined that the mobile radio terminal is incompatible with the application.

37. A mobile radio terminal as claimed in claim 32 wherein the memory device is integral to the mobile radio terminal.

38. A mobile radio terminal as claimed in claim 32 wherein the memory device is a smart card inserted into the mobile radio terminal.

39. A memory device for use in a mobile radio terminal for use in a radio communications network including at least one network processor, the memory device having stored thereon an application configured to perform at least one test on the mobile radio terminal to determine whether the mobile radio terminal supports a given function required by the application.

40. A memory device as claimed in claim 39 further configured to determine, as a result of the at least one test, whether the mobile radio terminal is compatible with the application.

41. A memory device as claimed in claim 39 wherein the application is further configured to report the result of the at least one test to the at least one network processor to determine whether the mobile radio terminal is compatible with the application.

42. A memory device as claimed in claim 41 wherein the application is further configured to receive a signal from the at least one network processor indicating whether the mobile radio terminal is compatible with the application.

43. A memory device as claimed in claim 40 or 42 wherein the application is further configured to perform at least one step to enable the given function in the mobile radio terminal if it is determined that the mobile radio terminal is incompatible with the application.

44. A memory device as claimed in claim 39 wherein the memory device is a smart card.

45. A memory device as claimed in claim 44 wherein the smart card is a Subscriber identity Module (SIM).

46. A server coupled to a radio communications network , the server comprising: a processor for determining whether a mobile radio terminal coupled to the radio communications network is compatible with an application in the mobile radio terminal, as a result of at least one test performed on the mobile radio terminal to determine whether the mobile radio terminal supports a given function required by the application.

47. A server as claimed in claim 46 wherein the server further comprises a receiver for receiving the result of the at least one test from the mobile radio terminal.

48. A server as claimed in claim 46 or 47 wherein the server further comprises a transmitter for transmitting instructions to the application to perform the at least one test.

49. A server as claimed in claim 48 wherein the transmitter is also for transmitting instructions to the mobile radio terminal to enable the given function.

50. A system comprising: a mobile radio terminal for use in a radio communications network, the mobile radio terminal having stored thereon an application configured to perform at least one test on the mobile radio terminal to determine whether the mobile radio terminal supports a given function required by the application; and a server for receiving a signal indicative of the result of the at least one test and for determining, as a result of the at least one test, whether the mobile radio terminal is compatible with the application.

51. A method of improving the performance of an application in a mobile radio terminal, the method comprising: determining the compatibility of the mobile radio terminal with the application; and if the mobile radio terminal is determined to be incompatible, modifying the operation of the application to mitigate the effect of the incompatibility".

52. A method as claimed in claim 51 wherein the step of determining the compatibility of the mobile radio terminal with the application comprises determining whether the mobile radio terminal supports one or more functions required by the application.