WO2008001059A1

WO2008001059A1 - Call handling on a mobile communications device

Info

Publication number: WO2008001059A1
Application number: PCT/GB2007/002365
Authority: WO
Inventors: Dejana Serdarevic; Chris Notton; Neil Mcalphine
Original assignee: Symbian Software Limited
Priority date: 2006-06-26
Filing date: 2007-06-26
Publication date: 2008-01-03
Also published as: GB0612635D0; GB2439371A

Abstract

Multiple telephony applications on a single device are provided with the opportunity to answer telephone calls. All interested applications have to register a category of their interest with an Incoming Call Assignment Component, and are offered calls in sequence, which they may accept or decline. An interest category 1 component (of which there is only one) is offered all incoming calls (10); an interest category 2 component (of which there can be many) are offered calls in a defined order, and may accept them according to their own criteria (20); and an interest category 3 component (of which there is only one) is the application of last resort, and handles all those calls that the other categories have declined (30). The Incoming Call Assignment Component controls the sequencing of call offers and imposes a servicing logic incorporating defined timeouts on all call offers.

Description

Call Handling on a Mobile Communications Device

This invention relates to an improved method of handling calls on a device capable of operating as a mobile communications device, and in particular, to an improved method of handling incoming calls on a mobile communications device in the form of a telephone with an open operating system.

Mobile telephones have developed significantly since their commercial introduction in the early 1980s. Modern mobile devices allow for much greater functionality than that of simple telephony, and there are an increasing number of integrated devices that allow users access to an increasing range of functionality, including but not limited to, the ability to send and receive text messages, store their personal contacts and calendar data, play music, listen to the radio, watch television, take and transmit both still photographs and video clips, read and send electronic mail, participate in instant messaging networks, access the Internet and browse the World Wide Web.

This invention applies to all devices which incorporate mobile phone functionality irrespective of what other functionality they offer.

Additionally, an increasing number of such devices are programmable and allow their users to install a wide variety of after-market applications. Such mobile devices are referred to as being open devices. Applications for open devices may be written to make use of the native operating system (OS) on the mobile device, such as Symbian OS from Symbian Ltd., Windows Mobile from Microsoft, Palm OS from Palmsource or varieties of Linux from a number of vendors. Alternatively, they may be written to make use of programming platforms that span a variety of different operating systems such as Java from Sun.

The default phone application which was provided by the handset manufacturer to allow users to make and receive telephone calls was for many years the only telephony application available on mobile devices, and it traditionally handled all call related functionality. However, the increasing use of open devices has given network operators and various third parties software providers the opportunity to add usefulness and functionality to mobile devices by providing their own applications for manipulating incoming or outgoing calls, thereby talking advantage of the increased functionality and programmability of modern mobile devices.

Examples of applications that might want to manipulate telephone calls include, without being limited to, voicemail or answering machine applications, high security telephone applications that need to encrypt or decrypt voice data, facsimile applications, and data only calls. It is no longer the case, therefore, that the default telephony application can be regarded as the only telephony application running on the device.

When there are multiple telephony applications running on a mobile device, it is essential that there is a mechanism provided which enables them to coexist cooperatively with respect to answering incoming telephone calls. The receipt of incoming telephone calls remains a key function for almost all users of mobile handsets, and they would rapidly find it unacceptable were it to become impossible for them to tell which application might be handling them, or indeed, whether they were being handled at all.

It is known to those skilled in the art of designing operating systems for computing devices, including operating systems for mobile telephone handsets, that where a device resource is needed to be used by multiple applications, the operating system should provide a set of application programming interfaces (APIs) that allow for this to be done in a way which does not jeopardise the functional operation of the device. The APIs need, therefore, to resolve device contention, arbitrate between applications having different priorities, and ensure that the use of the resource is predictable and reliable under all circumstances.

However, open operating systems have generally not provided this type of generic API as a standard feature. One possible reason for this is that the provision of the default phone application on mobile devices has generally been left up to the handset manufacturers, and since the default phone application has until recently been the only phone application, the disadvantages of not having a commonly available OS service have not been widely appreciated. It is not possible for any single phone application to adequately solve the problems presented by the introduction of multiple phone applications on a single device; this is especially true when the nature and capabilities of the phone applications additional to the default phone application may be unknown.

Single applications might ensure that such applications function properly by techniques such as boosting their priority, or hooking into hardware interrupts, in order to ensure that they get first 'look' at any telephony events, in which case they either handle the events themselves or pass them on to any previous application present on the device. It is clear that such solutions could easily cause the behaviour of the device to alter depending on the order in which applications were either installed or loaded; they are neither scalable nor predictable, and handling a chain of applications in this way could easily lead to calls being lost.

It is widely recognised that a solution to this problem is required for all common programming platforms on mobile devices. For example, Sun's Java JSR253 Mobile Telephony API specification faces the same problem but does not resolve it; from http://www.jcp.org/en/jsr/all, it can be seen that the

"MTA [Mobile Telephony API] describes a 'default call application' which has the last-resort responsibility for all call management. In the event that a Java application which has been controlling a call session is terminated unexpectedly (or terminates normally without ending the call), the user must be able to control the call session using the default call application. The MTA specification does not define rules for interaction between applications - such as if two applications attempt to respond to an event by displaying a notification to the user- the device must incorporate rules for which application notification is to be displayed."

Hence, the JSR253 API delegates the problems caused by multiple telephony applications to some other entity on the handset, but does not say what that entity might be. One suggested system-wide solution is the subject of US patent No 5,559,860 entitled "User selectable response to an incoming call at a mobile station". This discloses how incoming calls can be filtered by a component in a mobile device towards particular applications using the caller line identification as the basis for differentiation.

However, this art is an unsatisfactory solution for at least three reasons:

1. Filtering based on the number of the caller is not the only possible criterion; other criteria, such as geographical location, time of day, or whether another essential application is running on the device, could be considered to be equally valid.

2. The method disclosed requires each application to pre-specify its own criteria for the numbers in which it might be interested. This can create much complexity in the processing of each incoming call to find if the number matches the criteria as specified by each application; it creates an additional burden on the platform and slows down the response time considerably.

3. This method offers no guarantee of success, as the overall decision is still largely dependent on some type of application ordering. For example, applications may specify the same criteria for answering incoming calls, which can make the results in practice arbitrary or indeterminate.

According to a first aspect of the present invention there is provided a method of operating a device arranged to function as a mobile telephone, the method comprising arranging for a component responsible for offering incoming telephone calls to those applications running on the device which have registered with the component and notified it of the category of their interest in incoming calls.

According to a second aspect of the present invention there is provided a device arranged to operate in accordance with a method of the first aspect According to a third aspect of the present invention there is provided an operating system for causing a device to operate in accordance with a method of the first aspect.

The present invention will now be described, by way of further example, with reference to figure 1 , which shows an embodiment of the present invention

This invention discloses how the technical problem of deciding which applications have access to incoming telephone calls can be properly decided through the use of an Incoming Call Assignment Component (ICAC) in a mobile telephone at the operating system (OS) level. The ICAC is preferably part of the telephony server in the OS, as it already provides support for a single handset provided default telephone application; where this is the case, the elements of this invention are preferably provided as extensions to an existing API.

A key aspect of this invention is that applications interested in answering calls must register themselves with this ICAC, which can exclusively offer an incoming call for a limited time period to specific applications according to those applications' respective pre-registered interest categories.

In the preferred implementation of the invention, the ICAC defines three interest categories. When applications register with the ICAC, they are required to state their required interest category. These categories are defined as follows:

1. Answer all calls; this can only be granted to one application.

This interest category is used by an application wishing to answer all calls. An example of such an application would be a customised automatic voicemail application. It is quite realistic in practice to constrain this category to only a single application at any one time, because the telephony applications under discussion are user- installable ones, and it is not unreasonable, therefore, to expect the user to resolve any conflicts of interest that arise. The situation is analogous to a personal computer user having multiple web browsers on a computer; clearly, which one is invoked by a web hyperlink or HTML file association must be a user decision. The ICAC cannot be expected to resolve conflicts, though it can avoid them by the imposition of an arbitrary rule (such as granting this interest category to the first application requesting it and subsequently automatically denying it to all others). Where possible clashes arise, the user of the telephone is notified and provided with the opportunity to prioritise one application over another.

2. Answer based on a specific criterion; this can be granted to a plurality of applications.

This interest category will be used by all applications wishing to answer calls according to specific criteria. Some examples that criteria could be based on are: a. the time of the day b. the phone's geographical location c. the caller ID d. the type of the call e. current network f. roaming status or any other criteria that an application might want to use to decide whether to answer a call. If multiple applications are registered in this category, then they are kept in an ordered list. By default, the ICAC is normally arranged to service the applications sequentially on a first registered first served basis. However, the order could be configurable by the user through the user interface (Ul) in the event of any conflicts between applications registered in this category. However, it is envisaged that normally only a single application from those registered in this category would ever be interested in answering any one call, therefore a sequential ordering is likely to be acceptable in practice; applications not interested would simply not accept the call when offered.

3. Answer by default; this can only be granted to one application This interest category is used by a default application that handles all calls that no other application is interested in. The reasons why this is restricted to a single application are clearly similar to those cited earlier in relation to category 1 above; it would be logically inconsistent to have more than one application of this type. It is anticipated that the category 3 application would normally be the default phone application on the platform.

On a mobile telephone, there may not be any category 1 or category 2 applications, but there is always guaranteed to be a category 3 application.

An application that fails to register as a category 1 or category 3 application can either register as a category 2 application, or can abandon all attempts to register for incoming calls.

The ICAC uses the applications' registered interest category, application registration sequence and a time slicing mechanism to decide the order in which application should be notified of calls and offered a chance to accept and answer them. The exact mechanism by which registered application are notified of the various call events is not part of this invention; however, a 'publish and subscribe' notification model is an example of a mechanism that would be appropriate. Such a model is considered to be understood by persons familiar with this art so it will not be described further in the context of the present invention.

A preferred implementation will now be described in more detail with reference to figure 1.

Firstly, the events which occur when an application is notified of and offered an incoming call will be described:

• Any application notified of and offered a call is given a time period within which it must decide if it wishes to accept the call; if this period expires with no action, it is assumed that the application is not interested in the call. The ICAC implements application servicing logic (described below) to calculate the duration of this time period.

• Any application can use this time period to query the various APIs available on the device to check whether its criteria are satisfied; for example, the telephony APIs is able to provide the caller line identification, the type of call and the network identity (if required), the location APIs and the time APIs provide place and time information if required, while various other APIs can be queried if required for information on items as varied as presence and what other applications are running.

• If an application accepts the call, all other registered applications can be notified that there has been an incoming call which has been accepted; but this notification is not accompanied by the offer of the call. Furthermore, registered applications can also be notified when the call has been answered, and again when it has been terminated, or rejected by the user. It is possible to implement this invention in such a way that these notifications are optional for category 1 and category 2 applications; in such an implementation, these applications would indicate when registering whether or not they want to receive any permutation of these notifications.

The sequencing of notifications and offers will now be described:

• When an incoming call is received, the ICAC first notifies and offers the call to the application with interest category 1 (should there be one), as shown by step 10 in figure 1.

• If, however, there is no interest category 1 application, or if that application either chooses not to accept the call or does not respond to the offer of the call during its allocated time period, the ICAC then notifies and offers the call to the first registered application with interest category 2 (should there be one), shown by step 20 in figure 1. If there is no category 2 application, the call is offered to the category 3 application; step 30 in figure 1.

• If the category 2 application either chooses not to accept the call or does not respond not to the offer of the call during its allocated time period, the ICAC will then notify and offer the call to the next registered application on the category 2 list. • As long as the call remains unaccepted, the ICAC will repeat the last step for all applications registered in category 2, in the order that they appear on the list.

• If no category 2 application chooses to accept the call, then the ICAC notifies and offers the call to the application registered in category 3.

• If the category 3 application (which in essence is the application of last resort) chooses not answer the call then it is assumed the call will ring out or go to the user's voice mail. It is assumed that the category 3 default phone application is designed in a way which always allows it to accept and handle the incoming call and then ask the user whether they wish to answer it or reject it.

The application servicing logic that underlies the above sequencing will now be described:

The sequencing of an application depends on its interest category, its registration sequence (for category 2 applications), a pre-defined maximum time allowed to an application to decide whether to accept the offer of a call, and a pre-defined percentage of the maximum time that is allocated to a category 1 application. These predefined elements are normally set by the default phone application, but may also be user configurable. The default phone applications may be defined either at run-time or compile time.

The following terms are used in the examples below of how the application servicing logic works:

• (pre-defined) total servicing time: this is the time duration in which the applications are exclusively offered to accept an incoming call before the application registered for category 3 is offered to answer the call

• percentage servicing time for interest category 1 application: this is a configurable percentage of the total servicing time that should be allocated for servicing the interest category 1 application

• servicing time for interest category 1 application: (pre-defined) total servicing time * percentage servicing time for interest category 1 application • remaining servicing time for interest category 2 applications: (total servicing time) - (servicing time for interest category 1 application)

• time unit for servicing interest category 2 app//caf/ons:(remaining servicing time for interest category 2 applications) / (total number of interest category 2 applications)

• application's order of registration: the order in which the interest category 2 applications register their interest category (or as amended by the user)

• application servicing time = (servicing time for interest category 1 application) + (time unit for servicing interest category 2 applications)*(application's order of registration-1)

To clarify how the applications are serviced, the following examples show the application servicing logic in action:

Example 1 :

Application A has interest category 1 and is interested in answering all incoming calls (automatic voicemail)

Application B has interest category 2 and it is interested in answering the calls based on the phone's geographical location

Application C has interest category 2 and is interested in answering the calls based on the network id.

Application D has interest category 3 and it is the default phone application (pre-defined) total servicing time = 2 seconds

(pre-defined) servicing time for interest category 1 application = 40% of 2 seconds = 0.8 seconds remaining servicing time for interest category 2 applications = 1.2 seconds total number of interest category 2 applications = 2 time unit for servicing interest category 2 applications = 0.6 seconds Giving the following servicing times:

Application A application servicing time = Os Application B application servicing time = 0.8 + 0.6*(1-1) = 0.8s Application C application servicing time = 0.8 + 0.6*(2-1) = 1.4s Application D application servicing time = 2s This means that the ICAC will route the call to application A immediately, to application B 0.8s later, to application C 1 ,4s later than the first application and to application D 2s later than the first application.

Example 2:

Application A has interest category 2 and it is interested in answering the calls based on the phone's geographical location

Application B has interest category 2 and is interested in answering the calls based on the network id

Application C has interest category 2 and is interested in answering the calls based on the time of the day

(pre-defined) servicing time for interest category 1 application = 30% of 2 seconds = 0.6 seconds remaining servicing time for interest category 2 applications = 1.4 seconds total number of interest category 2 applications = 3 time unit for servicing interest category 2 applications = 0.47 seconds Giving the following servicing times:

Application A application servicing time = 0^* + 0.47*(1-1) = Os Application B application servicing time = 0* + 0.47*(2-1) = 0.47s Application C application servicing time = 0* + 0.47*(3-1 ) = 0.94s Application D application servicing time = 1.4s

In this example, there is no application registered as category 1 , so the servicing time for category 2 applications starts at 0.

This means that the ICAC will route the call to application A immediately, to application B 0.47s later, to application C 0.94s later than the first application and to application D 1.4s later than the first application.

Some additional aspects of call acceptance, including a mechanism for cancelling it, will now be described:

• If an application indicates to the ICAC that it wishes to accept the call, the application servicing logic suspends the servicing timer; this ensures that it does not expire and that no other applications will be offered the call. The ICAC assumes in the first instance that by accepting the incoming call the application has also committed itself to answer the call. This allows the application to invoke a user interface (Ul) to display the notification to the user, display the call states, and so on. It is assumed that if the application, for any reason, does not answer the call, then it will either be diverted to a voice mailbox or dropped, and that these actions are handled by the telephone network.

• An application that accepts an incoming call is responsible for implementing the Ul, notifying the user of the incoming call, playing the ringing tone, and handling all aspects of call progress, including a rejection of the call by the user or a failure by the user to answer. Because the application owns the call exclusively, the default category 3 phone application is not invoked under these circumstances.

• The only exception is that the default category 3 phone application is always notified of call events such as connection, rejection or termination. Hence, the system can be arranged such that all other applications can assume that the category 3 application will take care of all necessary call logging because this does not have to be handled by a category 1 or category 2 application.

• Any application that has displayed a Ul which has resulted in the user deciding to reject the call notifies the ICAC that the call is to be rejected; this ensures that the call will be terminated as soon as possible, and also ensures that the ICAC will not offer the call to any other application in error. The notification of rejection can be sent to any interested applications, as described earlier. • An accepting application is allowed to cancel the call acceptance if, for some reason, it decides not to answer the incoming call. If the ICAC receives notification of such a cancellation, it resumes its servicing timer and starts notifying the remaining applications in the sequence of the incoming call. Care must be taken by any application that accepts a call in such circumstances, as it has to consider what the possible behaviour of the canceller might have been, and implement a satisfactory Ul solution for the user. For instance, there would clearly be some confusion with the user if the user sees multiple UIs being displayed for the same number; it may not be clear that the call is one that has already been shown to the user.

This flow of control between the ICAC and registered applications in this invention is shown diagrammatically in Figure 1.

The registration and tripartite categorisation of multiple telephony applications by a single operating system ICAC enables, therefore, the applications to reliably co-exist on a single device; it successfully handles their competing requirements where this is possible, and devolves that responsibility to the user of the device where it is logically impossible.

Although the present invention has been described with reference to particular embodiments, it will be appreciated that modifications may be effected whilst remaining within the scope of the present invention as defined by the appended claims.

Claims

Claims:

1. A method of operating a device arranged to function as a mobile telephone, the method comprising arranging for a component responsible for offering incoming telephone calls to those applications running on the device which have registered with the component and notified it of the category of their interest in incoming calls.

2. A method according to claim 1 comprising three categories of interest in incoming calls of which a first category is used by a single application which may be interested in answering all calls, a second category is used by an application which may be interested in answering calls that conform to specific criteria, and a third category is used by a single application which is a default application that takes all calls in which no other application is interested.

3. A method according to claim 2 wherein there is always at least one application registered with the component in the third category.

4. A method according to claim 2 or 3 wherein applications in the second category are ordered in a list in a sequence corresponding to their order of registration, and wherein the order may be modified by the user of the mobile telephone.

5. A method according to any one of claims 2 to 4 wherein the user of the device is enabled to resolve conflicts arising from multiple applications that wish to register with the component in the first category or in the third category.

6. A method according to the any one of claims 2 to 5 wherein the criteria used by applications in the second category when deciding whether they are interested in a call may be based on any one or more of a. the time of day b. the location of the device c. the identity of the caller d. the current mobile telephone network e. the roaming status of the telephone subscriber f. the nature of other applications running on the device g. presence information available on the device.

7. A method according to any one of claims 2 to 6 wherein incoming telephone calls are first offered to any application in the first category, and then to any applications in the second category in order, and then to the application in the third category.

8. A method according to claim 7 wherein the offer of a call to an application in the first or second categories expires after a preset time period.

9. A method according to claim 8 wherein the preset time period is calculated by the component on the basis of the category, a maximum allocated time, and a percentage of time allocated to an application in the first category, and wherein the time basis of the calculations may be set by the application in the third category at either compile time or run time, or by a user of the device.

10. A method according to any one of claims 2 to 9 wherein the acceptance of a call by an application in the first or second categories causes a suspension of any time periods that may be in progress.

11. A method according to any one of claims 2 to 10 wherein the acceptance of a call by an application in the first or second categories is accompanied by that application requesting an interaction with the user of the device to obtain a decision on whether to accept or reject the call.

12. A method according to any one of claims 2 to 11 wherein the acceptance of a call by an application in the first or second categories may be cancelled by the accepting application, in which case the component resumes offering the calls to the next application in sequence with any time period being resumed from the point at which the call had been accepted.

13. A method according to any one of claims 2 to 12 wherein applications in the first or second categories may register to receive any or all or none of the notifications of call progress from the component.

14. A telecommunications device arranged to operate in accordance with a method as claimed in any one of claims 1 to 13.

15.An operating system for causing a telecommunications device to operate in accordance with a method as claimed in any one of claims 1 to 13.