GB2463112A - Mobile communications which use presence attributes - Google Patents

Abstract

In a mobile telecommunications network including a plurality of user devices each configured to communicate across the network via at least one mode of communication, a method of a first user device obtaining an indicator regarding the suitability of at least one mode of communication in relation to at least one other user device, the method comprising: determining first contextual information in relation to the first user device; determining second contextual information in relation to each of the at least one other user device and for each of the at least one mode of communication, determining the suitability indicator using the first and second contextual information. The invention aims to use contextual information such as status, location, current activity, phone capabilities, network capabilities, time-zone or battery status from each user in a communication to enhance the interface and user experience. Therefore data will be provided as appropriate to the user, taking into account their job at hand or situation at any given point in time.

Description

MOBILE COMMUNICATIONS METHODS AND ASSOCIATED SYSTEMS

The present invention relates to a mobile telecommunications system and associated techniques. More particularly, the present invention relates to a system and method for facilitating communications using presence attributes.

Field of the Invention

Modem communications is currently one of the fastest evolving technologies, particularly in regard to advancements made in transitioning users from communicating via wired telephones in fixed locations, to communicating via mobile handsets in mobile telecommunications networks. The actual location of the users communicating is now unimportant in terms of receiving and initiating communications; provided a user's handset is within range of a mobile base station of an appropriate network, communications are possible.

Mobile devices are in turn becoming more and more advanced, providing users with not just the ability to communicate wirelessly, but with additional services and functions such as instant text messaging and mobile internet access.

The advent of mobile telecommunications has created its own problems however, particularly in regard to the appropriateness of one user to try to contact another.

Although people generally keep their personal mobile device in their vicinity at all times, it will not always be appropriate for them to receive a call from another person. For instance, the intended recipient may be in a meeting, asleep or driving a vehicle and unable or unwilling to answer their telephone. Various measures have been devised to address such a problem, such as blocking incoming calls and implementing "silent" and "meeting" modes for the device, in order to make incoming communications non-intrusive or at least less likely to disturb. However, users do not always remember to switch their devices over to such modes, particularly when they are busy or, for instance, regularly transiting from being contactable to non-contactable for whatever reason.

From the caller's point of view, they are completely unaware of the user's circumstances, and hence ignorant of the undesirable situation they may be causing.

These problems are particularly manifested when a user travels overseas to a different time zone. A caller may be made aware that the party they are calling is overseas, by their telecommunications service provider providing the caller a different calling tone, but unaware of whether a difference in time zone exists such that their call is likely to be unappreciated by the called party.

It has been proposed in 3GPP TS 23.141 to allow a particular user's device to provide other parties with "presence attributes" allowing the other parties to see the particular user's status, such as that they are willing to take a call or are busy.

In a networked computing sense, this approach is similar to that utilised by the MSN Messenger TM product.

Whilst this provides other parties with greater awareness of the particular user's status, there is a need for improved information delivery. For instance, MSN Messenger, in particular, assumes "instant" communication is required, which is not always appropriate or desirable.

Further, it is also desirable for all users concerned to have a simple and user-friendly graphical user interface (GUI). The increase of available information inevitably leads to a more crowded and convoluted display of information. It is desirable that each user is presented with data that is easy to comprehend, and that S 3 the data is appropriate to them, particularly in regard to their job at hand, or situation, at any given point in time.

S

Summary of the Invention

According to a first aspect the present invention provides, in a mobile telecommunications network including a plurality of user devices each configured to communicate across the network via at least one mode of communication, a method of a first user device obtaining an indicator regarding the suitability of at least one mode of communication with another user device, the method comprising: determining first contextual information in relation to the first user device; determining second contextual information in relation to the other user device; and for each of the at least one mode of communication, determining the suitability indicator using the first and second contextual information.

According to a second aspect the present invention provides a presence client manager configured for use with a device communicable with a mobile telecommunications network, the presence client manager including: a database of users associated with a user of the device; an interface configured to receive first contextual information relating to at least one of the associated users; and a processing engine configured to: determine second contextual information relating to the device; and determine a suitability indicator for at least one mode of communication between the device and at least one of the associated users, using the first and second contextual information.

By utilising contextual information from each user in a communication, or a proposed communication, it is possible to provide an enhanced interface and user experience. Previous arrangements have only been able to utilise information relating to one of the parties, specifically the called party, and the "contextual" information that has been available has been limited. The present invention has * 4 expanded on the meaning of "contextual" information to not only cover information regarding the user's status, but also information regarding the user's S location, current activity, phone/terminal specifications/capabilities, network capabilities for the user's current location and/or current phone/terminal status (e.g. based on battery status).

In this way, by using information from both parties, suitable means of communication between the parties can be determined, and notified to one or more of the parties in order to improve the chances of a successful communication attempt.

Brief Description of the Drawings

Figure 1 illustrates a mobile telecommunications network useful in explaining the operation of the embodiments of the invention; Figure 2 illustrates a sequence of menus and submenus that may be used to present information according to an embodiment of the invention; Figure 3 illustrates the sequence of menus and submenus for demonstrating a further example of the Figure 2 embodiment of the invention; and Figure 4 illustrates a communication log that may be used to present information according to a further embodiment of the invention.

Detailed Description

Key elements of a mobile telecommunications network, and its operation, will now briefly be described with reference to Figure 1. Figure 1 incorporates elements from a GSM network, a IJMTS network and an LTE network. These are O 5 just examples of a network environment within which the present invention may be implemented, and other network formats are possible.

Each base station (BS) in the network serves a respective cell of its cellular or mobile telecommunications network and receives calls from and transmits calls to a mobile device in that cell by wireless radio communication in one or both of the circuit switched or packet switched domains. Such a subscriber's mobile device (UE) is shown at I. The mobile device may be any form of mobile communications device, including a handheld mobile telephone, a personal digital assistant (PDA) or a laptop computer (e.g. a laptop equipped with a mobile telecommunications network datacard, a laptop having an attached dongle modem, or indeed a laptop with an embedded mobile telecommunications network modem chipset).

In a GSM mobile telecommunications network, each base station includes a base transceiver station (BTS) and a base station controller (BSC). A BSC may control more than one BTS. The BTSs and BSCs comprise the radio access network.

In a UMTS mobile telecommunications network, each base station comprises a node B and a radio network controller (RNC). An RNC may control more than one node B. The node Bs and RNCs comprise the radio access network.

in the proposed LTE mobile telecommunications network, each base station comprises an eNode B. The base stations are arranged in groups and each group of base stations is controlled by a Mobility Management Entity (MME) and a User Plane Entity (UPE).

Conventionally, in a GSMJUMTS network, the base stations are arranged in groups and each group of base stations is controlled by one mobile switching * 6 centre (MSC), such as MSC 2 for base stations 3, 4 and 5. As shown in Figure 1, the network has another MSC 6, which is controlling a further three base stations S 7, 8 and 9. In practice, the network will incorporate many more MSCs and base stations than shown in Figure 1. The base stations 3, 4, 5, 7, 8 and 9 each have dedicated (not shared) connection to their MSC2 or MSC6 -typically a cable connection. This prevents transmission speeds being reduced due to congestion caused by other traffic.

The MSCs 2 and 6 support communications in the circuit switched domain -typically voice calls. Corresponding SGSNs 16 and 18 are provided to support communications in the packet switched domain -such as GPRS data transmissions. The SGSNs 16 and 18 function in an analogous way to the MSCs 2 and 6. For the sake of simplicity, all future references to an MSC are also to be taken as equivalently covering an SGSN or a Node B. Each subscriber to the network is provided with a smart card (or SIM card) which, when associated with the user's mobile device identifies the subscriber to the network. The SIM card is pre-programmed with a unique identification number, the "International Mobile Subscriber Identity" (IMSI), which is not printed on the card and is not generally known to the subscriber. The subscriber is issued with a publicly known number, that is, the subscriber's telephone number, by means of which callers initiate calls to the subscriber. This number is the MSISDN.

The network includes a home location register (HLR) 10 which, for each subscriber to the network, stores the IMSI and the corresponding MSISDN together with other subscriber data, such as the current or last known location of the subscriber's mobile device. This information is used when paging a mobile device. S 7

The invention relates to a broad definition of "contextual information" including: i) location; ii) availability; iii) capability; iv) device specification; v) device status; S and vi) network status (e.g. available bearer and/or Quality of Service, QoS). The uses of this contextual information will now be described in relation to a mobile device configured for use in a mobile telecommunications network as described above. The network further includes a network entity known as a presence server.

The presence server is a network element that collects and disseminates contextual information As is standard, current mobile devices include a graphical user interface (GUI), with icons for the user to select particular functions or fields, such as an address book, a calendar and menu defining settings for the device. The address book includes contact details for one or more entities or associated users, such as friends, acquaintances, business associates and the like. The contact details for each entity may include one or more mobile phone numbers, landline phone numbers, email addresses, website addresses, home address details and business address details, for example.

The device is configured, such as by using the principles set down in 3GPP TS 23.141 and TS 24. 141, to provide one or more remotely located contacts/associated users with location information of the user's device. These technical specifications define location information based on the identity of the last known Common Gateway Interface (CGI) or Service Area Identity (SAl) and/or corresponding geographic coordinates to the presence server, which is then made available to other users, The present embodiment of the invention may additionally or alternatively obtain positional information using the location of the base stationleNode B with which the user's mobile device is registered. Where the base station is a micro base * 8 station this information should provide location accuracy to within about 20 metres. This information can be obtained in the form of a cell ID of the serving S cell, which is sent to the presence seer from the network or from a presence client manager on the mobile device.

Alternatively, the handset may have a Global Positioning System (GPS) capability, or access to a GPS receiver, such as via Bluetooth [RTM] connection, from which to obtain positional information. Other approaches may also be used, for instance using "in building" localised wireless systems (i.e. short range), such as Wi-Fi, DECT, Bluetooth and near field communication (NFC) wireless systems. Wide area wireless systems, such as WiBro, WiMAX and metropolitan WiFi may also be used.

Preferably this positional information can be made available to contacts of the user, such as to contacts designated in the user's device address book. Even more preferably, the user is able to tailor which contacts in their address book are able see the positional information, and also the level of information detail able to be received by each contact and/or each group/collection of contacts.

A key feature of this embodiment of the invention involves associating the positional information with personalised user information in order to provide location information likely to be of greater use and meaning to third parties. In this way, an interrelationship between the "users" and their "locations" is created in order to enhance the usefulness of the information available. This personalisation may be performed by the presence server and/or the presence client manager on a user's mobile device.

The personalised location information may be obtained from various sources, including: * 9 -from resources on the user's device, such as their personal calendar or diary, S -from external sources such as external databases; and/or -from the particular user (e.g. entered manually into the mobile device via a GUI).

Each of these sources can provide a location information field with a different degree of location information about the user device, with differing degrees of contextual focus.

To manage these different location fields, the presence server and/or the presence client manager may utilise and develop a database associating locations that the user regularly visits with one or more personalised descriptions of each location.

For instance, the database may contain a list of base station identities that the user's mobile device has previously been registered with, which are cross-referenced with specific descriptions relating to the location. These specific

descriptions may provide:

(a) a personal location such as "home", "office", "parent's house" or "away from work"; The personal location descriptions would typically be entered into the database by the user, either at their own volition, or upon the presence client manager/server receiving a prompt from their mobile device's presence client manager. For instance, upon noting a cell ID which is not included in the database, and preferably a cell ID which the user has been registered with at least once before, the presence client manager may send a prompt to the user to enter a personal description of their location, if desired. Of course, since one or more base stations may serve a given location, a plurality of cell IDs may be designated as "home" * 10 etc. Also, the user may enter different personal descriptions for different contacts andior categories of contacts.

I

b) a spatial position or regional description, such as "Newbury, UK" or "Heathrow airport" Spatial positions and areas may be obtained by the presence server and/or the presence client manager using an established database that associates certain cell IDs with popular place names, such as the name of a town (e.g. Newbury, UK), or a certain region of a town (e.g. centre of Newbury), or a place of interest (e.g. at Nelson's column, UK). The spatial area could also specify a particular country (e.g. France) or county (e.g. Berkshire) or a specific home or work area may be designated. To obtain relative spatial positions, such as "within 1km of Nelson's column", the principle of "radius around a point" is preferably used. In this regard, such a description may be used where the base station is known to be located at or very close to Nelson's column, and that base station has a radial range of 1km.

Alternatively, where more precise location determination is required (e.g. 1km north of Nelson's column), GPS or triangulation via three or more proximate base stations may be used.

(c) a vicinity, such as "near Newbury, UK"; In terms of "vicinity", the user's actual location may be specified as a relative location. For instance, an approximation of distance from a particular destination may be made, using the device's current location. This relative measurement may be made from a given third party's location (e.g. being the one who requests the information), or from a specifically designated destination. As an example, a third party could request information on how far away a particular user is from his office address. Similarly, a chronocline, which is a contour of equal time, could be used to give a time approximation based on distance (and estimated average speed), such as within an hour's drive of a particular location.

S (d) a time related description, such as in a particular time zone A time related description is particularly useful when a user is located in a country from which specific location information is not obtainable. In this situation, the home network provider would be aware of the country that the device is located, and therefore be able to proffer a time zone description associated with that country, including a relative time zone description, such as 5 hours ahead of GMT.

(e) a schedule related positional description, such as in a meeting in Newbury, UK; To obtain a schedule related location, the presence client manager is configured to access a database, such as the user's calendar to provide the necessary personalisation. For instance, if the user is scheduled to be in a meeting at client A's premises between 2pm and 4pm, the presence client manager may set this description for the user's location at the appropriate time.

In order to ensure accuracy, however, the presence client manager may first phrase an educated question to the user regarding the actual user's location. For instance, if the presence client manager notices that the user's calendar states the user should currently be in a meeting at client A's premises, then the presence client manager may present the user with the question, "Are you currently at client A's premises?", being a question that simply requires a yes/no response from the user, and accordingly a single push of a button. If the user responds with "yes", then the presence client manager may set the user's location description as "at Client A's premises". For future reference, the presence client manager may also create an entry in the user's personal database, associating the current cell ID with the description "client A's premises". Once the personalised description is in the user's personal database, then it may be extracted and utilised for all return visits by the user to that location. * 12

Another way to ensure accuracy for schedule-based statuses is to implement an override mechanism when the schedule-based situation is in conflict with a network-determined situation. This is to take into account the fact that a user's calendars may not necessarily be up-to-date. For example, if a calendar indicates that a user should be in a meeting, but the presence network indicates that the user is in a car and is moving, then the calendar is the most likely one to be wrong.

Therefore, in this situation, the network determined position takes precedence, and the user's status is set to the "in a car" situation. However, again, a question may be put to the user in order to resolve the discrepancy.

(D an environmental location, such as "in a car", "on the M4" or "on a train".

An "environmental" location description, may be obtained through user input, or through a device's association with a particular environmental entity, such as a particular main road (e.g. on the M4) or on a mode of transport (e.g. on a plane/train to Italy). To achieve the association with the environmental entity, a transponder may be used in the location to notify the user's mobile device of their location. For instance, trains may be fitted with transponders that provide a broadcast over a limited area. The broadcast may be as basic as "train", or more detailed such as "the 10. l5am rail service from London Paddington to Newbury".

The presence client manager may use this broadcast information to define the user's location, preferably for as long as the presence client manager is receiving the broadcast signal. In terms of planes, this could be implemented, where the plane has a micro-base station on board that enables telecommunications to take place whilst the aircraft is in the air, such that the presence server is able to determine the device's location due to being registered with such a special micro-base station. S 13

These location descriptions are typically written descriptions, but they may be S presented in any other form. For example, the location descriptions may also be in the form of a visual description, such as via a map indicating the user's location.

This map may display a plurality of associated users, so that a person viewing the map could, for instance, determine which is the closest to a particular point. This would be useful for a team leader determining which team member to call to a job at a particular location.

In a further alternative for providing a personalised location description, the presence client manager/server has access to a database which associates certain cell IDs with one or more addresses, such as Street post codes and/or geographic coordinate ranges that a particular cell ID serves. Therefore, when a user's mobile device is being served by a particular cell, the presence client manager/server accesses the database to retrieve the one or more addresses that are associated with that cell ID. Since postcodes and geographic coordinates are not necessarily meaningful to users, the presence client manager preferably seeks to provide a personalised description of the location by cross referencing the address with addresses in the user's mobile device address book, in a bid to find a match (e.g. a postcode match).

Where a match is made, the device client may then extract a description associated with the database address entry and use that description in a personalised description of the user's location. For instance, if a match is made with the address of a friend "Claire Small", the location description may state "at Claire Small's house", or "with Claire Small". Similarly the device client may use this correlated information to phrase a question to the user, such as "Are you at Claire Small's house?" * 14 The presence client manager/server can therefore draw on available location information and create a personalised description of that location, and ideally, save the description in relation to the location for future use. Importantly the personalised descriptions can be created with minimal user input.

The invention is thus able to allow the "context" of both or all parties to be assessed and to recommend a "best" or most suitable option.

Alternatively or in addition to contextual information linking "users" with "location", contextual information in relation to availability/capability is incorporated. This further enhances the information available, by providing personalised descriptions of availability and capability, in addition to situation.

Availability and capability contextual information can be based upon various items, events and/or situations, including tasks or projects related to the user, documents relevant to the user, as well as possessions, products and resources. For instance, a user device's presence client manager may extract an appointment from a user diary/schedule on the user's device and use this information in developing an appropriate availability description for the user, such as "Busy -in a meeting in Newbury".

In a further example, the presence client manager may recognise that the user device is plugged into a hands-free car kit. As this is a strong indication that the user is driving, the terminal may choose the availability description as "Car kit enabled voice calls only".

Contextual information may also relate to a user's device specification or status may be utilised, alternatively or in addition to other types of contextual information. For instance, if the user's device is a 20 phone, the presence client S 15 manager may notify the presence client server of this, so that associated users are notified of the communication restrictions that apply to the user. That is, since the phone is only a 2G phone, it is not capable of video conferencing.

Similarly, the presence client manager may inform the client server of the type of device upon which it is installed (e.g. make, model), and send this information to the presence client server. The presence client server would then be able to determine what capabilities the device had from this information, and notify associated users of these capabilities and/or contact-ability based upon these capabilities, where appropriate.

Contextual information may include device status so that the presence client manager may also determine the status of resources on the user's device. For instance, the presence client manager may determine that the battery of the user's device is low and/or that the memory space available is low, and notify the presence client server of such. The presence client server would therefore be able to notify associated users of these resource statuses and/or contact-ability based upon these resource statuses, where appropriate.

Contextual information relating to the network status/availability for a user's location may be utilised, alternatively or in addition to other types of contextual information. For instance if the user's presence client manager resides on a mobile device, and the device is located in an area where no 3G network coverage is available, then this information can be utilised in describing the user's capabilities.

For instance, the user's presence client manager may determine this information from other components on the device, and notify the remote presence client server of such. This information may then be provided to other users, such as in a message due to location, 3G communications, such as video conferencing unavailable". Similarly, the remote presence client server may be notified of * 16 network congestion in the area in which the user's device is located. In this situation, it may notify other users that "due to network congestion, only communication via SMS advisable".

In the invention, a presence client manager on a user device is configured to utilise contextual information (location, availability, situation information, etc.), from both the device user and associated users/contacts in order to determine the appropriateness of contacting the associated users by different means of communication. An enhanced graphical user interface may be provided which utilises the contextual status information, so that informed communication preference decisions can be made.

The presence client manager may generate a plurality of representations of the processed contextual information, for example: an indication of which means of communicating with an associated user are possible/available; which means of communicating are most appropriate to the circumstances; andlor it may determine a hierarchy of the different means of communication based upon the associated user's status, thereby ranking the available modes of communication according to predetermined criteria. For instance, if the associated user's status information indicates that they are in a meeting, then since that user is unlikely to want to be disturbed, the best means of communicating with them would be via voice mail or text message.

The presence client manager is configured to make this determination, by using a look up table defining rankings of communication modes for different status situations, and presenting the result to the device user, the result being represented as appropriate iconography on the device's GUI. S 17

The operation of the invention may be better understood with reference to Figure 2. Here, an example showing the use of associated user status information will be described in relation to a mobile device's presence client manager. Presence client managers in this example are located on mobile devices, but they may equally be located on any networkattached communications device with access to the mobile telecommunications network, including PCs. Indeed, any or all of the determinations may be performed on a network's presence server. In this example, a first person "Andrew" wants to make contact with a second person "Brian". Figure 2 illustrates the information that Andrew's presence client manager may present to him on his mobile device regarding Brian's location, availability and/or capability (i.e. his contextual information).

The user interface shows Andrew's list of contacts, from which it can be seen that "Abbie" is at work, as portrayed by an office building icon, Charles is at home, portrayed by a house icon, and Brian is in a car, portrayed as a car icon. The house icon is also coloured red to indicate that Charles is not currently contactable, the car icon is coloured green to indicate that Brian is contactable, whilst the office building icon is coloured yellow to indicate that Abbie is busy, but contactable to some degree (i.e. a restricted availability). The presence client manager is configured to define the appropriate icon and status indication (e.g. colour) using status information relating to each contact provided by the contact's presence client manager and/or information specified by the particular contact themselves (e.g. Charles may have specifically set his status as uncontactable, due to not wanting to be contacted). The displayed indications also incorporate contextual information from Andrew himself. Charles' presence client manager would typically send the status information to the network's presence server, from where the presence client manager on Andrew's device would typically obtain the information. * 18

If Andrew wishes to contact Brian, he would select the Brian icon and ideally be able to see further details regarding Brian in a submenu. As shown in Figure 2, Brian's availability in the sub-menu is listed as "free". It also indicates that he has a meeting at 2pm and is currently in a car, using hands free in Newbury, UK. In this regard Brian's presence client manager has extracted the relevant schedule information from Brian's calendar and also relevant location information from the network to determine that he is currently located in Newbury, UK. The "in car, hands free" information may be entered by Brian himself, or the presence client manager may determine this information by recognising that a hands free kit is connected to an input socket of Brian's mobile device or via a Bluetooth connection associated with the car.

By selecting the Brian icon, Andrew is also able to determine how best to contact him. This selection would ideally bring up a set of contact options, including a preferential indication for each means of contact. This preferential indication ideally takes contextual information relating to both Brian and Andrew into account. Thus the capability of Brian's device to access a video capability using a 3G bearer will be tempered by the capability of Andrew's device and for example the remaining battery level on the respective devices.

With reference to Figure 2, a sub menu has been created, which includes the contact options of "voice call", "video call" and "create message". The voice call option would be associated with an indication that Brian is capable of receiving a voice call, such as by colouring the voice call option in green or placing a green icon, such as an arrow-shaped bullet point, alongside the option. The video call option is red indicating that initiating a video call with Brian is not appropriate, either due to Brian's current "context" or Andrew's own "context". The "create message" option in turn has an indication that Brian is capable of receiving some form of message (i.e. restricted availability, which in this example is a yellow O 19 coloured indicator). The create message option, when selected, in turn brings up another sub menu, which lists five message options, being "text message", "multimedia message", "audio message", "email" and "instant message".

The audio message option is associated with a green indicator, indicating that Brian is capable of receiving an audio message. The green indicator may also be used to indicate that this is the best approach for communicating with Brian in the current circumstances. The text message, multimedia message and email options are all associated with a yellow indicator, indicating that these messages may also be received by Brian in his current situation, but are not optimal. Finally the Instant Message option is associated with a red indicator indicating that this option is not possible or not recommended.

The appropriate indicators for these call and message options may be determined by the presence client manager using a preference table. In this regard, for a given situation, such as "in car, hands-free", a preference for each of the options is defined, which the presence client manager extracts and presents to other users viewing Brian's contactability. An example of such a preference table for Brian is shown in relation to two different contexts, namely "in car and handsfree" and "in a meeting" below as Table 1: Communication Mode Contextual Information Suitability Indicator Voice Call In Car and handsfree Available Video Call In Car and handsfree Not Available Text Message In Car and handsfree Restricted Availability Multimedia Message In Car and handsfree Restricted Availability Audio Message In Car and handsfree Available Email In Car and handsfree Restricted Availability O 20 Instant Message In Car and handsfree Not Available Voice Call In a meeting Not Available Video Call In a meeting Not Available Text Message In a meeting Available Multimedia Message In a meeting Available Audio Message In a meeting Restricted Availability Email In a meeting Restricted Availability Instant Message In a meeting Not Available The suitability indicators may be preset or editable by Brian, so that he may incorporate his personal preferences. Allowing personal preferences will also allow Brian to control the means of communication that people use to contact him on (e.g. work mobile, home mobile, fixed phone, PC etc).

According to the invention, the presence client manager/server takes into consideration contextual information in relation to the caller's situation/status, in addition to the callee's situation/status. In this regard, before providing a suitability indication for each mode of contact, the presence client manager/server also determines the suitability/appropriateness of the mode of contact for the caller. In this way, the suitability indication presented to a user has relevance to both the user's own status/capabilities, as well as those of the party to be contacted.

Returning, then, to the Figure 2 example, for Brian, the Instant Messaging option is coloured red indicating that that mode of communication is not possible or not recommended. In this embodiment of the invention, this unavailability may be due to one or both of Brian and Andrew not having the Instant Messaging facility (or indeed having incompatible IM facilities). To implement this feature, a preference table (or two separate tables) with entries relating to both Brian and Andrew may * 21 be consulted to determine the suitability indication for this mode of communication. The table may have an "unavailable" indication against Brian and/or Andrew in respect of Instant Messaging, where they do not have an Instant Messaging facility installed on their terminals.

Again referring to the Figure 2 example, and considering multimedia messaging, another communication mode, which is highlighted as yellow in the example, indicating it is a possible means of communication, but not preferred. Andrew's client manager may be aware that both Andrew's and Brian's devices are 3G devices and therefore capable of multimedia messaging. For Brian, this may be an ideal mode of communication, so in the table, Brian's entry in regard to multimedia messaging may be "available". Andrew however, may be in a region with poor 3G network coverage. Andrew's presence client manager may therefore update his entry in the preference table to "restricted availability". With two different entries for the two parties in the table, the presence client manager/server determining the suitability indication would compare these two entries and select the lowest ranking indicator in a predetermined hierarchy, as indicated below in

Table 2:

Table 2

Availability Options Brian Yes Yes Yes Restricted Restricted Restricted No No No Andrew Yes Restricted No Yes Restricted No Yes Restricted No Comparison Yes Restricted No Restricted Restricted No No No No Result In other words, in Table 2 the predetermined hierarchy from lowest to highest is "No", "Restricted" and then "Yes". * 22

It is to be appreciated that whilst these examples have been in relation to a proposed communication between two parties, more than two parties is within the scope of the present invention. This may be the case for a discussion group of three or more parties that wish to communicate together. This is readily implemented in these embodiments of the invention, by referring to a further table entry applicable to each of the additional parties.

These determinations and calculations may be performed by the presence client server and/or a user's presence client manager. For example, Andrew's presence client manager may receive the preferential indications for each of his contacts from the presence client server, and his presence client manager may then compare these indications with Andrew's own contextual information and make changes as appropriate. Alternatively, all of the calculations may be performed on the presence client server, and the user's presence client manager simply informed of the result.

Andrew, viewing Brian's situation and recommended contact options based upon both Brian's and his own contextual information can then make an informed decision of how best to contact Brian, or whether the current point in time is appropriate. For instance, Andrew may be looking to obtain Brian's immediate opinion on the form of a document, but would see from his presence profile that Brian is not currently in a position to review the document, so that Andrew would be better off seeking someone else's advice.

Figure 3 presents a further example to illustrate this embodiment of the invention.

As with the Figure 2 example, in Andrew's display, Abbie is associated with a yellow building, indicating that she is at work and busy, although contactable in some way. Charles is again associated with a red house, and so is at home and * 23 uncontactable. In this exampLe Brian is illustrated by a yellow car indicating that he is in the car, and busy but contactable in some way.

By selecting "option", Andrew can see that Brian's availability indicates that he is currently on a call, but otherwise his position and situation are the same as per the Figure 2 example. In this regard, the presence client manager is configured to recognise when Andrew is utilising his handset to make or receive a call, and update his availability status accordingly. It is also to be noted that in the submenu, Brian's availability of "on a call 00:13:20" is coloured yellow. This indicates that he has been involved in the voice call for a total of thirteen minutes and twenty seconds, and whilst busy, is contactable by other means.

In view of his "on a call" busy status, the most appropriate contact options for Brian are now different to those from the Figure 2 example. Where in Figure 2 the voice call option was coloured green, indicating it was a preferable means of contacting Brian, it is now coloured yellow indicating that it is a possible means of communication with Brian, but not a recommended one (e.g. Brian may be able to receive Andrew's phone call, despite being on a call if he has call waiting).

Where Brian does not have call waiting, or where Brian is receiving a call from a very important person, then the "voice call" option may be coloured red. To implement this feature, Brian may specify certain persons in his address book in relation to who his phone calls are not be interrupted.

All the other options are the same as per the Figure 2 example, with audio message being the only option now coloured green, meaning that it is the best means to currently make contact with Brian. The email, text and multimedia message options are still coloured yellow indicating that they are less preferable as they are less appropriate to Brian's status/situation. * 24

Therefore these examples show that the embodiments of the present invention are not only capable of providing a third user's contacts with more meaningful information regarding the user's location, availability and/or situation but that the contextual status information can be used to maximise a contact's chances of a successful communication with the device user.

Therefore, in this way, not only does a user's device provide the user's presence/status information to contacts/associated users, but it is configured to utilise presence/status information received from such associated users/contacts in directing the device user to make an informed decision regarding contacting those associated users.

It is to be appreciated that although these examples use coloured icons and coloured written descriptions to represent each contact's situation and availability, this is not an essential component of the invention, and that other means of status indication may be used, including varying degrees of grey-scaling, vocalised descriptions or a hierarchical listing of contact options.

A particularly useful implementation of this embodiment of the invention is in relation to users with more than one device, such as a personal mobile phone and a BlackberryTM for their work. The contextual communication network can handle such a situation by communicating "device specific" status information to the user's friends and associates. For example, if A wishes to make a voice call to B, and B has a personal mobile phone and a BlackberryTM, then the presence client manager/server can determine whether one is preferable over the other for voice calls. For example, B may have a list of preferences which specifies that no voice calls are made to the BlackberrylM. * 25

Alternatively, the presence client manager/server may determine the same from network conditions, such as if B is using HSDPA on his phone for data transfer it may not be feasible for it to take a voice call at the same time. As B is not engaged in a conversation, his unavailability for voice calls would not be communicated to A by using the red "unavailable" icon. Instead B's status would be shown as available to accept a voice call using the green "available" icon and the call would be diverted to B's Blackberry1M.

The embodiments described so far have predominantly been in relation to exchanging status information between mobile devices. However, contextual status information can also be obtained from devices in communication with the mobile telecommunications network, such as networked PCs. These PCs may also be associated with their own presence client manager, able to utilise data from the PC's databases as well as data about usage of the PC. For instance, examples of usage that may be used to indicate presence include whether users are logged on or off and when a user last touched the keyboard.

Learning Ability The learning ability of the presence client manager/server is a preferred feature of these embodiments of the invention. In this regard, the presence client manager/server is configured to recognise patterns andlor the regular recurrence of particular events/situations in order to build and collect contextual status information.

For instance, the presence server may notice that all but one member (i.e. member A) of a particular work group are involved in a conference call. Based on this information, the presence server may send a message to the leader of the work group "Invite Member A to conference call?" If the response is "yes", the presence * 26 server would then set in train the required mechanism to invite and include Member A in the conference call.

In another example, the presence client manager may recognise a future telephone conference for a particular work group scheduled at a particular time in the team leader's calendar. Based on this information, the presence client manager may send a message to the team leader, such as "Automated set up of conference call <at the particular time>?" If the response is "yes", the presence client manager would then set in train the required mechanism to invite all the scheduled attendees to the conference call at the scheduled time.

In a further example, the presence client manager may determine that a dropped call has occurred, rather than an intentional end of the call. The presence server, where it is integrated into the cellular network, can detect this condition and set in train the procedure necessary for reconnecting the parties involved in the call. The reason for the call being dropped will be due to a device having lost touch with the network. Therefore, corrective action is best performed from the network side. The presence client manager/server and the mobile network will ascertain when the call can be successfully re-established, and then ring all parties involved automatically, before joining the calls together.

In a still further example, the presence client manager/server may recognise the pattern of two users continually leaving voice mail messages for each other, and being unable to actually establish a voice call. In this situation, the presence client manager/server may be configured to send a message to one of the parties, such as "Set up voice call with Party A?" If the response is "yes", the presence client manager/server would then set in train the required mechanism to set the call up.

Calendars and diary entries for each party may be used to confirm availability at a particular time. * 27

Sin another example, after X has called Y, and the call goes unanswered, Y is made aware of the missed call. So that Y knows when is best to contact X, the presence client manager of Y inserts in the missed call message an indication of X's availability to receive the call.

In a further example, if X wants to make a video-call to Y, but does not know if Y has 3G coverage and/or the right type of phone, X can use the presence client manager/server to determine to which network Y is currently connected to and also the device Y is using. From this information X can determine whether he can make a video call to Y, and if not, what alternative means of communication are available to him.

Another example is in the situation where a user sends an email to three people and the presence client manager recognises that the user has sent an email to the same three people on at least one other previous occasion. The presence client manager is therefore configured to ask "would you like to create a distribution list for these people?" and take steps to create the list if a "yes" reply is received.

In a similar manner, if a user is using the internet via their handset, and upon arriving at a particular location, if the presence client manager recognises that the user has visited the site on at least one other previous occasion, the presence client manager is configured to ask "would you like this location to be stored as a favourite?" These embodiments of the invention have predominantly been described in relation to enabling people to utilise and share contextual status information using a mobile telecommunications network. According to an alternative embodiment of the invention, however, other entities including animals, plants and inanimate * 28 entities, such as vehicles, goods and buildings, may also be associated with a presence client manager and provide information regarding their status. Typically inanimate entities may have a communications presence, based on availability, situation and capability, as well as a functional presence. Therefore, inanimate entities in which a user is interested may be added to the user's contact list. In this way, the user can easily interrogate the entities to ascertain their status.

An inanimate entity may take various forms, including a location such as business premises or a tourist attraction (e.g. a museum or funfair), a vehicle and a package and may be static, mobile or moveable.

Considering the package example, a package being delivered may be associated with its own a presence client manager. Relevant people, such as the customer to whom the package is to be delivered, may then use the information transmitted by the package's presence client manager in order to know: -where the package is; -what the package contains; -how far away the package is; and/or -when the package is likely to be delivered.

In this regard, the presence client manager associated with the package will have a wirelessly locatable "network identity", and relevant people may be provided with the network identity of the package's presence client manager, so that they can keep the package as a "contact" on their mobile device, and be pushed information about the status of the package. For instance, the package's presence client manager may regularly signal location information to the network's presence server, which is in turn provided to the customer's mobile device. The "network identity" may be an equivalent identity to that given to mobile handsets, such as an * 29 IMSI, a temporary IMSI (TMSI), a network assigned token, MSISDN, an IP address, a MAC number andlor an IMEI.

The location information may be determined based upon cell ID, UPS or the like.

Alternatively, it may be determined based upon association with another entity, in order to reduce usage of network resources. For instance, if the package is located on a lorry, rather than locations for both the lorry and package being determined, one could be determined and shared with the other.

Other inanimate entities to which a presence may be applied are cars which could regularly report location status and/or running status to its owner and/or manufacturer. Air conditioners in buildings may report their status to an engineer, so the engineer knows when he is needed for maintenance. Documents may also be an object to which a presence is applied, such that an associated presence client manager intermittently reports an amendment history.

Places may also be given a presence client manager. For instance, a restaurant may communicate its availability based upon its opening hours. If it is booked out, it may also communicate this to regular customers, so they know if there is table availability, before trying to call to book a table.

In another example, homes may be given a presence client manager, and link their presence to a burglar alarm, for instance, so that an owner, away from the house may continually have access to a security status of the house whilst they are away.

In a further example. a car parking space may have a presence client manager and be able to report when it is empty. * 30

With more and more entities, such as people and inanimate objects, obtaining mobile presence identities, the need also arises of being able to manage those S identities so that information may be presented to users in a meaningful way, and with repetition avoided or at least minimised. For instance, expanding on the package example described above, if the package was located on a truck, which also had its own mobile identity, and was driven by a driver, with his own mobile device, and all were heading to a depot, again with its own identity, then the courier company would be able to see the positionlstatus of all four entities.

If the statuses of all four entities are displayed separately, however, the interrelationship between the four is not immediately apparent. Therefore, according to this embodiment of the invention, a number of related entities are grouped into a collection, and a collection presence/profile is established.

Preferably the collection presence is assigned to a "spokesman" or representative of the collection by linking the collection presence to the representative.

Designating a representative is advantageous, as it helps to simplify communication choices and reduce network traffic, since the collection preferably only communicates via the representative. Each entity is still ideally capable of communicating as an individual, but when communications with the core network relate to the collection, they are only performed through the representative.

Collections are preferably entered into an interested user's contact list, with the members arranged in a sub-menu off the collection name, so that each can be separately interrogated. It is also to be appreciated that an entity may belong to more than one collection.

As an example, a lorry L, a package P, a depot D and a driver, Fred, are formed into a collection. Fred is made the representative of the group, and accordingly is assigned the collection presence as well as his own presence. It is preferable that S 31 Fred maintains his own presence, so that friends and family, to whom the collection presence is likely to be irrelevant, may still obtain useful status information regarding Fred. A "presence" is effectively a profile including status information relating to each entity, and typically is made up of one or more fields, such as availability, location and/or capability fields.

The following Table 3 details example status information that may be communicated for each entity and their collective entity. Separate fields have been listed for each entity's "availability", "situation" and "capability", however, this is just one possible approach for displaying the presence profile, and other ways are possible, such as combining the information into one "status" field.

TABLE 3

Entity Fred Lorry Package Depot D Collection Availability In a voice In use In transit Open for Reachable via call business Spokesman Fred Collection has Fred, Lorry L, Package P, Depot D Situation/ In Lorry, Driver is Fred On Lorry Lorry L At depot D Location Moving Contains L, located in Package, package P, At depot Bay 3 At depot At depot D D

D

Capabilities Has lorry Has tail lift Can report Can take Communication car-kit at 10 40 tonne via lorry car-kit and minute lorries and phone O 32 phone intervals capability of * capability Fred From this example it can be seen that the collection's availability field provides information useful for communicating with the collection.

It can also be seen that a collection may comprise any combination of devices usable by people, such as Fred, inanimate static entities/places (e.g. the depot) and inanimate mobile/portable entities (such as the Lorry L and Package P). The "collection" defines the interrelationship between the different entities, and allows the connections between them to be readily determined. Links, such as hyperlinks may be provided between the status entries for each of the entities and their collection presence. A collection may also include other collections.

Whilst ideally a collection only has one "spokesman" representing the collection, it is also possible that more than one spokesman need be designated. For instance, a secondary spokesman may be designated, who represents the group in the event that the main spokesman is uncontactable.

Figure 4 illustrates a use of the contextual status information by the presence client manager/server according to an embodiment of the invention, whereby a user's daily schedule includes location and context fields. In the Figure 4 example, the schedule includes listings of relevant events/people/communications, which are displayed in a table in relation to "people", together with their location and situation/event contexts. The table in Figure 4 has six columns relating to "entry type", relevant "people", "subject", "place", "context" and "date/time". The information in the Figure 4 example is currently sorted by time, although the data may be sorted by any of the six columns. * 33

The first entry in the table is in regard to an email message received from Andrew.

It is apparent that the item is an email message from the "entry type" icon used in the first column. The email was sent in the context of a "Daily Brief", and it has the subject of "today's targets". From the summary, it can also be seen that the message was received at 8.30 and that Andrew is currently at the premises of Client A. The next item in the table is a voice message from Ben, which has the subject of "Let's meet when I arrive at work". To obtain the subject for this item, since it is a voice message, Ben could enter the description in written form via his device or transcoding of his voice may be used. Ben's location is also displayed as 10km from work.

The third item in the table is a textISMS message from Debbie regarding a contract to be signed. The summary shows Debbie to be at work, and the SMS message has the subject of "successful meeting".

The final item in the table is a planning meeting that is scheduled with Ben and Debbie at 11.10, which is going to take place as a "net-meeting".

From this example, it can be seen that the presence client manager may also be used to merge and summarise messages/communications of various types, and associate these with location information regarding the people concerned and also with scheduled appointments and events. The use of a table to display these linked

information fields improves its usability.

Further, by storing communications data on the basis of person, place and context, particularly in the table format of Figure 4, it becomes possible to communicate with appropriate people through location and/or context searching. For instance, * 34 by viewing the table of Figure 2, if it was desired to speak with either Debbie or Ben before their net-meeting, from the table it could be seen that Ben was still on his way to work, whereas Debbie was in the office, making Debbie the best person of the two to contact.

A further advantage of this embodiment of the invention can be appreciated when the example of work-related information being shared in a working group is considered. At a glance, a sales manager would be able to determine where each member of his working group is and what they have done/are doing. Further, should the sales manager have a question to ask one of the group, for instance about stock inventory, the manager could use the group information to determine who in the group is in or near the relevant stock area is currently contactable by voice to ask the question.

In summary, from these embodiments of the invention, it can be seen that the various presence client managers and presence server share data, and that the data can be obtained from various sources, such as from mobile devices, networks including data networks, mobile and fixed communications networks, as well as other devices in communicable relation with the networks. In other words, the embodiments of the invention are applicable to any device/terminal capable of interacting with a mobile network.

In this regard, mobile devices are able to provide data from their databases, such as calendar and contact databases, which may be unique to the device or synchronised with an office system. They can also provide data about user availability, such as being able to indicate when a user is on a call or in a meeting.

This allows the presence client manager/server to build up profiles, for instance on who is called most often and with whom phone conferences have been undertaken lately. O 35

The users of presence client managers may also seek to implement privacy settings, particularly in regard to their personal locations. This may be implemented an individual contact basis. For instance, for a particular contact, the user may specify that they are either listed as "at home", when that location applies, and for any location as "not at home". In other words, the location is specified as one location and a logical operation on this position.

User availability, as used in this specification is intended to be interpreted broadly, and to cover various forms of availability including user reachability, contactability, readiness to communication and scheduled availability. Similarly user capability is intended to be interpreted broadly and to cover situations such as a user's communication environment, a user's preferred communication media, user's device facilities and accessories, network access and network availability.

Further, user situationJlocation is intended to be interpreted broadly and to cover situations such as location in an absolute or relative sense, country location, time zone location and current user activity situation. The expression "user" is also intended to be interpreted broadly and is intended to cover any entity with which a suitable device might be associated and/or which may be represented within the presence service delivered by the invention: the ambit of the term includes both animate and inanimate entities and explicitly includes people, other living creatures, and places as well as static, mobile and moveable objects.

The embodiments of the invention have also been described in relation to users communicating with known contacts/entities over a mobile telecommunications network. The present invention may also be implemented between entities for which no previous relationship has been established. * 36

For instance, a user may decide they require a taxi, and send a message to that end to the presence server. Based upon the subject of message, and the user's location, the presence server may send the user presence data for one or more taxi companies, which may allow the user to see which taxi company is closest, and also, perhaps, the availability of taxis from each. Alternatively, or in addition, the presence server may notify one or more taxi companies of the location of the user, so that they may go and meet the user requiring the taxi. The notified taxi company would be selected based on the user's location, such that preferably the closest taxi company/taxi is notified.

The user may also broadcast a taxi request, preferably to a taxi "collection" in order to allow taxi drivers and/or taxi companies who are a member of the "collection" to see the user and be made aware of the user's location and need for a taxi.

The embodiments of the invention have particularly been described in relation to a GSMIUMTS communication network, however the principles may readily be applied to other network configurations, including the proposed 3GPP LTE (Long Term Evolution) network, which is not yet implemented.

The embodiments of the invention have also particularly been described in relation to their usage in conjunction with databases (such as a user's calendar) located on the mobile terminal, however such databases may also be located in the network or in a remote server accessible via the network. In this regard, most functionalities of the presence client manager may alternatively be performed by the presence server. This aspect is particularly applicable to older devices which do not have the ability to run client programs, and hence are not capable of having their own presence client manager.

For such devices, the network would effectively run the presence client manager for them, and communicate the presence information usually communicated through the GUI/icons via other means, such as SMS. Alternatively, an Interactive Voice Response (IVR) mechanism may be used, which, for example, could provide an acquaintance B's status and invite them to "press 1 to call B or press 2 to leave B a voicemail".

Other features of the invention are defined in the following numbered statements: 1. In a mobile telecommunications network including a plurality of user devices each configured to communicate across the network, a method of communicating contextual information for a collection of user devices, the method including: associating a number of the plurality of user devices as a collection; selecting one of the number of devices as a representative of the collection; defining one or more contextual information fields relating to the collection and associating the one or more fields with the representative device; and using the representative device to communicate the contextual information fields to other devices.

2. A presence client manager configured for use on a communications device, the presence client manager including a schedule monitor configured to: monitor a schedule associated with the communications device; upon detecting a scheduled teleconference, determining one or more participants of the scheduled teleconference; determine a contact telephone number relating to each of the participants; and provide the contact telephone numbers to a call establishment means in order to establish the teleconference between the communications device and the one or more participants.

3. A presence client manager configured for use on a communications device, the presence client manager including a communications monitor configured to: * 38 monitor circuit-switched communications that the communications device is engaged in; and upon detecting a communication termination that is not initiated by the user of the communications device and/or the other participant or participants in the communication, notify a call establishment means in order to re-establish the communication.

4. A presence client manager configured for use with a device communicable with a mobile telecommunications network, the presence client manager including: a processing engine configured to: obtain status information relating to a user of the device; and use the status information to provide personalised user information relating to the user's location, availability andIor capabilities.

5. A presence server configured for use in a mobile telecommunications network with a plurality of user devices in communication relation with the mobile telecommunications network, the server including a processor configured to: obtain status information relating to a user of each device; and use the status information to provide personalised user information relating to each user's location, availability and/or capabilities.

6. The presence client manager for use with a device communicable with a mobile telecommunications network, the presence client manager including: a database of users associated with a user of the device; a status interface configured to receive status information relating to at least one of the associated users; and a processing engine including a display engine for generating a table on a display means of said device, wherein the table merges communications received by the device and user appointments/events from a schedule of the device; and wherein the table is populated with a respective user context for each associated user involved in the communications and user appointments/events. * 39

Claims (28)

1. CLAIMS: S 1. In a mobile telecommunications network including a plurality of user devices each configured to communicate across the network via at least one mode of communication, a method of a first user device obtaining an indicator regarding the suitability of at least one mode of communication with another user device, the method comprising: determining first contextual information in relation to the first user device; determining second contextual information in relation to the other user device; and for each of the at least one mode of communication, determining the suitability indicator using the first and second contextual information.
2. 2. The method of claim 1 further including: determining a first suitability indicator from the first contextual information relating to the first user device; determining a second suitability indicator from the second contextual information relating to the other user device; and selecting the indicator for each communication mode from the first and second suitability indicators.
3. 3. The method of claim 2 wherein the first and second suitability indicators are determined using a preference table linking suitability indicators with different types of contextual information in relation to a plurality of communication modes.
4. 4. The method of claim 2 or 3 wherein the indicator is selected by chosing the suitability indicator with the lowest ranking in a predetermined hierarchy. * 40
5. 5. The method of any one preceding claim wherein the first contextual information is determined from at least one of the following types of information: the network availability for the first user device; a capability of the first user device; a location/situation of the first user device a location/situation of a user of the first user device; and resource availability for the first user device.
6. 6. The method of any one preceding claim wherein the second contextual information is determined from at least one of the following types of information: the network availability for the other user device; a capability of the other user device; a location/situation of the other user device a location/situation of a user of the other user device; and resource availability for the other user device.
7. 7. The method of any one preceding claim further including determining a hierarchy for the modes of communication for each category of contextual information, thereby ranking the available modes of communication according to predetermined criteria.
8. 8. The method of any one preceding claim where this is a plurality of modes of communication with the other user devices and further including determining a preferred mode of communication from the plurality of communication modes.
9. 9. The method of any one preceding claim wherein the step of determining the first contextual information is performed upon identifying a communication set-up request by a user of the first device to the other device; the method further comprising: * 41 transmitting the first contextual information to the second user during a call set-up procedure, such that the contextual information is usable by the second user in determining a purpose of the communication request.
10. 10. The method according to any one preceding claim further including: associating a number of the plurality of user devices as a collection; selecting one of the number of devices as a representative of the collection; defining one or more contextual information fields relating to the collection and associating the one or more fields with the representative device; and using the representative device to communicate the contextual informationfields to other devices.
11. 11. The method according to any one preceding claim further including: monitoring a schedule associated with the first user device; upon detecting a scheduled teleconference, determining one or more participants of the scheduled teleconference; determining a contact telephone number relating to each of the participants; and providing the contact telephone numbers to a call establishment means in order to establish the teleconference between the first user device and the one or more participants.
12. 12. The method according to any one preceding claim further including: monitoring circuit-switched communications that the first user device is engaged in; and upon detecting a communication termination that is not initiated by a user of the first user device and/or the other participant or participants in the communication, notifying a call establishment means in order to re-establish the communication. * 42
13. 13. The method according to any one preceding claim further including: obtaining status information relating to a user of the first user device; and using the status information to provide personalised contextual information relating to the user's location, availability and/or capabilities.
14. 14. The method of claim 13 further including obtaining the status information using at least one of the following sources: a) resources on the first user device; b) network resources; and/or c) a user input means.
15. 15. A presence client manager configured for use with a device communicable with a mobile telecommunications network, the presence client manager including: a database of users associated with a user of the device; an interface configured to receive first contextual information relating to at least one of the associated users; and a processing engine configured to: determine second contextual information relating to the device; and determine a suitability indicator for at least one mode of communication between the device and at least one of the associated users, using the first and second contextual information.
16. 16. The presence client manager of claim 15 wherein the processing means is further configured to: determine a first suitability indicator from the first contextual information; * 43 determine a second suitability indicator from the second contextual * information; and select the indicator for each communication mode from the first and second suitability indicators.
17. 17. The presence client manager of any one of claims 15 or 16, wherein the database of users includes at least one entity selected from a group including people, animals, plants, static inanimate objects, moveable inanimate objects, mobile inanimate objects and collections of such entities.
18. 18. The presence client manager of any one of claims 15, 16 or 17 wherein the database of users is a contact data base associated with the device.
19. 19. The presence client manager of any one of cLaims 15 to 18 wherein the processing engine is configured to determine a preferred mode of communication from the at least one communication mode for each associated user.
20. 20. The presence client manager of any one of claims 15 to 19, wherein the processing engine is further configured to determine the first contextual information using one or more of a user input means, a database of the device, a database of the network, a device user schedule database and a network user schedule database.
21. 21. The presence client manager of any one of claims 15 to 20 wherein the processing engine is further configured to: obtain status information relating to a user of the device; and * 44 use the status information to provide personalised contextual information * relating to the user's location, availability and/or capabilities.
22. 22. The presence client manager of claim 21 further including obtaining the status information using at least one of the following sources: a) resources on the device; b) network resources; and/or c) a user input means.
23. 23. The presence client manager of claim 22 wherein the resources on the device include at least one of: a) a calendar; b) a user schedule; and/or c) a database associating predetermined user positions with one or morepersonalised descriptions.
24. 24. The presence client manager of any one of claims 21 to 23 wherein the status information determined by the processing engine includes positional data, and the processing engine is configured to obtain the positional data from one or more of the following sources: a) satellite positioning equipment associated with the device; b) a base station with which the device is registered; c) a wide area wireless system; and/or d) a short-range wireless system.
25. 25. The presence client manager of any one of claims 21 to 24 wherein the status information determined by the processing engine includes positional data, and the personalised user information that the processing engine is configured to provide includes one or more of the following: S 45 a) a personal location description of the positional data; b) a spatial or regional location description of the positional data: c) a relative spatial location description of the positional data; d) a user schedule-based location described related to the positional data; e) a time zone description related to the positional data; f) an environmental location description of the positional data g) the user's actual location; b) the user's location relative to an associated user; and/or c) a logical expression relating to the user's actual location.
26. 26. The presence client manager of any one of claims 21 to 25 wherein the personalised user information determined by the processing engine includes a plurality of different user status descriptions relating to the status information, and the processing engine is further configured to associate each different user status description with a particular user type or user group.
27. 27. The presence client manager of any one of claims 21 to 26 wherein the processing engine is further configured to transmit the personalised user information to a network presence server, such that appropriate personalised information may be provided to one or more users associated with the device user.
28. 28. The presence client manager of any one of claim 21 to 27 wherein the status information includes availability/capability data relating to a user of the device.