GB2471329A

GB2471329A - Creation of a dynamic contact list in which contacts are ordered depending on their relevance at a point in time.

Info

Publication number: GB2471329A
Application number: GB0911082A
Authority: GB
Inventors: John Raymond Knight
Original assignee: Vodafone Group PLC
Current assignee: Vodafone Group PLC
Priority date: 2009-06-26
Filing date: 2009-06-26
Publication date: 2010-12-29
Anticipated expiration: 2029-06-26
Also published as: GB0911082D0; GB2471329B

Abstract

A method of managing communications with the plurality of communicable entities by creating a communication log for use on a terminal, including: for each communicable entity obtaining communication data relating to a plurality of communication types; creating the communication log of communicable entities, and relevant to a particular point in time, by applying an algorithm relating to a listing order of the communication log, the algorithm defining the relevance of each type of obtained data and any applicable conditions, such that the communication log created lists the plurality of different communicable entities in an order of perceived relative relevance to the user of the terminal based on the plurality of communication types. Preferably the method further includes intelligently determining an appropriate means of communication and indicating this in the communication log. It is also preferable that information from presence networks is utilised in filtering the communication data.

Description

INTELLECTUAL

. .... PROPERTY OFFICE Application No. GBO9 11082.6 RTM Date:15 October 2009 The following terms are registered trademarks and should be read as such wherever they occur in this document:

GSM

UMTS

Intellectual Property Office is an operating name of the Patent Office www.ipo.gov.uk Mobile Communication Device and Method of Operation

Field of the Invention

The present invention relates to a means for and a method of managing data in relation to a communications device, particularly in regard to sorting and/or filtering communication data. In particular, the communication device is a mobile telecommunications device.

Background

Mobile telecommunications have become commonplace in the modern world as a principle form of communication. With this acceptance, mobile phones have developed into an important tool for users, developing from terminals whose main function was to make and receive calls, to multi-functional devices additionally able to send and receive emails and video and the like.

In this regard, in addition to the POTS infrastructure and the mobile communication network infrastructure, the Internet has become a further mechanism for channelling communication products and services. Mobile devices are therefore increasingly becoming the entry point for a disparate range of comnmnication services. In this regard examples of communication products supported by the Internet include "blogs", RSS feeds, widgets and websites, particularly social networking sites (SNS). Communication services that can be directly served over the Internet include voice calls, Short Message Service (SMS) messages, Multimedia Message Service (MMS) messages, video calls, email and IP communications in general.

Therefore, with mobile devices now serving as both communication devices on traditional networks and as entry points for Internet communications products and services, users are faced with an increasing number of communication channels. Indeed as the number of channels of communication increase, contacts and traffic will also increase. This is because, the increase in communication channels exposes users to a greater number of other users (including individual persons and entities such as companies and groups of people) which accordingly results in a corresponding quantitative increase in the number of actual communications. Indeed, many of the Internet-based community communications services are valued because they increase the number of contacts a user has.

However, while opening up available communication channels has facilitated the widening of social circles and fostering of communities, this quantitative increase in communications from a wider range of other users often leaves individual users with an inability to manage the various communication channels easily.

This increase in functionality however, has also resulted in an increased complexity, particularly in regard to its provision of information and ease of use for users.

There is a need for the ability to better manage the communication data available from the various communication channels for use on the communications device. In particular there is a need to manage both communications that the communications device receives from its standard communication networks, as well as from the Internet.

In general, there is a need to overcome or alleviate at least one of the problems

of the prior art.

Summary of the Invention

According to a first aspect, the present invention provides, in a communications network including a terminal configured to communicate with a plurality of different communicable entities, a method of managing communications with the plurality of communicable entities by creating a dynamic communication log of at least a portion of the communicable entities, the log for use on the terminal, the method including: for each communicable entity obtaining communication data relating to a plurality of communication types; creating the communication log by applying an algorithm relating to a listing order of the communication log, the algorithm defining the relevance of each type of obtained data and any applicable conditions, such that the communication log created by the algorithm lists the plurality of different communicable entities in an order of perceived relative relevance to the user of the terminal based on the plurality of communication types.

Advantageously by gathering data for a multitude of communication types (i.e. not just voice calls) a more informative communication log can be defined.

Preferably the relative priority defined in the applied algorithm is dependant upon one or more conditions applicable to the mobile terminal and/or the user of the mobile terminal at a given point in time. For instance, the one or more applicable conditions may include a contextual information availability and/or status applicable to the mobile terminal.

In this regard, by incorporating data from presence networks, a communication log can be defined which has relevance to a user's location at any given point in time.

Advantageously the applicable conditions may relate to classes of contacts that are dependent upon the time of day and/or day of the week. For instance, a contact classified as a work contact could be weighted more heavily, or given a high priority level, during work hours. Correspondingly a lower weighting/priority level may apply outside work hours. In a similar manner, work colleagues may be "black listed" outside working hours so that they do not appear in the communication log at all during non-essential times.

It is also preferable that the conununication data is processed/filtered by recognising communication patterns for one or more particular communicable entity. In particular, this aspect enables communicable entities who communicate with a user according to an hourly, weekly or monthly pattern, for example, to be included in the communication log based upon this pattern.

A communicable entity is typically a friend, acquaintance or "contact" of the user, whose contact information is defined in a database, such as an address book, associated with the user's terminal. The entities may also include corporate entities associated with the user and other individuals not specifically defined in a contact database, but whose contact information can otherwise be provided to the user, such as via streaming or broadcast.

Preferably the communication data includes any combination of historical traffic data, presence network status data and historical traffic pattern data in relation to a user of the communication device and/or one or more contacts, determined from address book data or historical communication data, of the user.

In other words, aspects of the present invention advantageously provide the ability to combine existing communication data, not previously combined in such a way, so as to result in a communication log with enhanced functionality and improved utility for the user of the communication device.

In another aspect, the present invention provides, In a communications network including a terminal configured to communicate with a plurality of different communicable entities, a method of managing communications with the plurality of communicable entities by creating a dynamic communication log of the communicable entities for use on the terminal, and relevant to a particular point in time, the method including: determining any conditions applicable to the particular point in time; where one or more conditions are determined as applicable, for each deternñned condition, determining whether any of the communicable entities are associated therewith; and creating the communication log by applying an algorithm relating to a listing order of the communication log which incorporates the applicable time-related conditions by allocating an appropriate predetermined relevance value to any communicable entities associated with any applicable condition.

Other aspects of the invention are set out in the subsequent set of claims.

Brief Description of the Drawings

Embodiments of the invention will now be described with reference to the accompanying figures in which: Figure 1 illustrates an example of a mobile telecommunications network in which embodiments of the invention may be implemented; Figure 2 illustrates a screen shot of a graphical user interface (GUI) embodying a communication log according to embodiments of the invention; Figure 3 illustrates a schematic overview of the processing capabilities required of data sources according to an embodiment of the invention; Figure 4 illustrates an example of the types of data used by an embodiment of the invention, presented in a look up table; Figure 5 illustrates a table summarising usage pattern weighting data, considered from the time point of a Tuesday at 5pm, according to an embodiment of the invention; Figure 6 illustrates a table providing dynamic status and location data, which can be used to populate communication options in an embodiment of the invention; Figure 7 illustrates an example of a log as displayed on a user terminal, at two different time points, according to an embodiment of the invention; and Figure 8 illustrates an example algorithm that may be utilised in embodiments of the invention..

Detailed Description

Key elements of a mobile telecommunications network, and its operation, useful in explaining the embodiments of the invention, will now briefly be described with reference to Figure 1.

Each base station (BS) serves a respective cell of its cellular or mobile telecommunications network, and receives calls from and transmits calls to mobile terminals in that cell by wireless radio communication in one or both of the circuit switched or packet switched domains. Such a subscriber's mobile terminal (UE) is shown at 1. The mobile terminal may be any suitable portable device, including a handheld mobile telephone, a personal digital assistant (PDA) or a laptop computer equipped with a datacard.

In a GSM mobile telecommunications network, each base station includes a base transceiver station (BTS) and a base station controller (B SC). 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 B's and RNC's 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 it is proposed that each group of base stations will be controlled by a Mobility Management Entity (MME) and a User Plane Entity (UPE).

Conventionally, in a GSM/UMTS network, the base stations are arranged in groups (3,4,5; 7,8,9) and each group of base stations is controlled by one mobile switching centre (MSC), such as MSC 2 for base stations 3, 4 and 5 and MSC 6 for base stations 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 serving 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 is also to be taken as equivalently covering an SGSN.

It is via such a network that UE 1 is able to send and receive communications using various communication channels, including channels for voice calls (circuit switched or packet switched), SMS, MMS, video calls, email and IP communications in general.

Currently, a typical UE, such as a mobile phone, manages these different forms of communication by having folders, such as an "inbox" and "outbox" for each communication form. For instance, the mobile terminal will typically have an inbox for SMS messages, an inbox for emails and an inbox for MMS messages.

These data inboxes and outboxes are typically saved in a "messages" menu or folder, which a user needs to access in order to review their history of past sent and/or received data messages, be they email, SMS, MMS or otherwise. All messages are typically stored chronologically. This arrangement therefore sorts the data, but makes it available in disparate locations, so that a user needs to navigate through multiple menus to extract/review different items of communication data.

Voice communications, on the other hand, are not stored in relation to an "inbox" and "outbox", but instead a "call log" record is kept. This call log keeps track of different categories of historical calls, namely dialled, received and missed calls and stores a list of these calls chronologically or by frequency.

These different call statuses/categories may be displayed in one list or separately. The call log is of finite length and typically operates on a FIFO (first in, first out) principle. In other words, once the maximum entry limit of the list has been reached, older call history records will be dropped off the list as new call entries are included. These lists usually display an identifier of the calling or called party, an indication of the call category (i.e. missed call etc) and also a time stamp (for chronological lists) or counter (for frequency lists).

In terms of chronology, the call log would typically list most recently received calls in a descending time ranking from the present to the past. Logging based on the frequency of communication would typically rank a caller who has called many times higher in the call log than one who rarely calls, albeit recently.

With this background in mind, a first embodiment of the invention will now be defined, which enables a mobile terminal to be configured to provide users with a more relevant communication log. In this regard, whilst frequency and chronology are useful, they do not in themselves ensure relevance.

With reference to Figure 2, an example communication log according to embodiments of the invention is illustrated.

The Figure 2 is a communication log, as opposed to just a call log, as it provides the ability to produce a log of multiple different forms of communication from and/or to the communication device/device user.

Figure 2 is a screen shot of a graphical user interface (GUI) that could be presented to the user, embodying the communication log. The top line of the screen shot shows how the different communication categories may be presented, for instance, all types of communications may be displayed in the one list or separately (i.e. just calls, just SMS messages, just Instant Messages (IM), just email and just Social Network Site (SNS) messages (i.e. fromlto FacebookTM, TwitterTM and the like)).

The example in figure 2 is illustrating the situation where all types of communications are displayed in the one list, so that the list includes a number of contact entries detailing the type of communication made or attempted. Each entry also includes information regarding a suggested or recommended means of contacting each contact in the list, if required. These recommended means of contact may be predefined and associated with a profile of the contact in the user's contact database. Alternatively, the recommended means of communication may be intelligently determined, which will be described in more detail below.

The communication log illustrated in Figure 2 has an entry showing that Sam Park was called at 12.lOpm and recommends that a call is made to Sam Park if a further communication attempt is to be made. The next entry shows that a call was made to Taylor Gordy, and it is suggested that an IM is sent to Taylor Gordy if a further communication attempt is to be made. This suggestion may be based upon a predefined communication preference, or the communication log processor may have recognised that Taylor Gordy is currently logged into an IM account. An example of how this may be implemented in an algorithm is shown in the "Contextual Data" subroutine of Figure 8.

The communication list of Figure 2 also shows that Barry Town called at 10.33 and Chuck Brown at 10.21 and respectively suggests calling and sending an SMS message to those contacts, if a further communication attempt is to be made. As indicated above, these communication suggestions may be based on a stored communication preference for each contact, and/or other information.

For instance, the suggestion of sending an SMS message to Chuck Brown may be based on information gathered by the core network that Chuck is currently engaged on another call or has listed his stattis in a presence network as "busy".

This is also indicated in the Contextual Data subroutine of Figure 8.

Additionally, and again with reference to Figure 2 and the contextual data subroutine of Figure 8, Tim Fuller is included on the list, as a presence network indicates that he is nearby. Tim may not have communicated with the device owner for some period of time, and therefore would not ordinarily appear in the list, but by the communication processing engine utilising additional information to hand, such as the proximity of contacts, greater relevance can be added to the communication log. For instance, since Tim is nearby, the device user may decide to contact Tim to meet tip for a coffee, a communication that would probably not have taken place if the device user was not made aware of Tim's proximity.

The processing engine may make this proximity determination by combining information received from a presence network regarding the location of various communication devices, and their registered users, with contact information of users known to the current device user. These contacts would typically be obtained from an address book database associated with the current user's communication device (i.e. stored on the device or remotely). Where the location of the current user's device is known, and a match is made with a contact proximate the current user's known location, then the processor may incorporate that contact into the communication log. In this way, the compiled communications log may be used by the user to initiate communications relevant to their situation and/or the contacted person's situation.

Therefore, from this description, it is clear that in this embodiment of the invention, the communication log processor is able to aggregate all the communication channels and filter these channels in respect of users known to a particular device user in order to suggest an appropriate means of communication. The communication log incorporates this suggested means of communication, ideally in conjunction with a shortcut to enable the user to quickly and simply implement the suggested communication means with the contact.

In a further embodiment of the invention, and again with reference to Figure 2, in addition to showing historical communication entries, this embodiment also includes entries for contacts that the device user may wish to contact based upon intelligent processing by the communication log processor. For instance Kirsty Dell is included in the list as she is regularly called, although not necessarily recently. For instance, the processor may recognise that communications to/from Kirsty exceed a predefined threshold and therefore has included her on the list so that the user of the terminal may have ready access to her number without having to delve into their contacts folder. The predefined threshold may be for a predetermined period of time, such as a week or a month. The threshold may also be in regard to all types of communication or a subset thereof. An example of how this may be implemented in an algorithm is shown in the Time Sub Routine of Figure 8.

Further, in a particular implementation of this embodiment of the invention, and with reference to the Time Sub Routine of Figure 8, a period of time may be linked to a certain subset of contacts. For instance, during working hours, work colleagues may be weighted more heavily, and correspondingly outside work hours, weighted less heavily. Similarly, if the user regularly plays football of a Monday evening, team members may be given a greater weighting on Monday evenings. These implementations would typically require some user input, such as to specify his/her working hours and work-related contacts.

Another entry in the communication log of Figure 2 is in relation to Gary Pride.

This entry has been included in the list by the processing engine in view of an upcoming meeting with him. In this regard, the processing engine has combined information from the particular user's diary and their contact database to arrive at Gary Pride as a relevant contact that the user may wish to contact. For instance, the inclusion of Gary Pride in the communication log not only serves as a reminder to the user of the upcoming scheduled meeting, but also enables the user to quickly contact Gary before the meeting if need be -for instance to reschedule the meeting. An example of how this may be implemented in an algorithm is shown in the Diary Sub Routine of Figure 8.

This further embodiment of the invention therefore provide the device user with a useful and relevant communication log, by intelligently determining relevant contacts known to the particular device user, to be included in their communication log, preferably in conjunction with entries based on historical communications. The intelligent determining typically combines presence information with a user's contact database and/or a communication threshold based upon all communication types or at least a subset thereof typically with no reference to chronology. A particular advantage of this embodiment of the invention is that contacts with which a user has no recent historical communications may be incorporated into the communication log, for instance based upon presence information or diary entries.

From this it can be seen that the communication log processor collects data relating to entities/people that are known or associated with the mobile terminal user (i.e. "contacts"), via various data sources. Figure 3 provides a flow chart summary of the underlying functionality being implemented in processing this data in order to effect these embodiments of the invention.

The first stage of the flow chart illustrates examples of the data that the processing engine is configured to receive, filter and sort. This includes data relating to a user's contacts, communication history data as well as contextual data detailing, for instance, the location and availability of certain friends/contacts of the user. This data would ideally include an historical log of all communications whether stored remotely or on the mobile terminal, and would typically include time and date of the communication, duration, communication type and an identifier of the other party. This repository of data expands as the user communicates more.

More specifically, data may be collected from databases associated with the user (e.g. address book databases and appointment databases), as well as from communications made via the mobile terminal, including direct communications over the wireless network and also IP based communications.

The types of data that may be collected in regard to communications for each "contact" include: -the contact's name and communication information (e.g. MSISDN) as well as all relevant identifying information such as work, home and mobile numbers, shared resources such as calendars, web addresses, groups etc; -channel address used by contact for each communication, in order to determine relevant communication methods for each contact (e.g. some contacts may communication via email and never by calls); -the frequency with which contacts use each channel; -the location of the contact, particularly in terms of their geographical location which may be determined via the base station address at which they are registered; -contact status/availability data obtained using a presence network. This data may include historical data regarding the time and date of availability of each contact; -what communication device is currently being used by each contact (where a plurality are used) and the usage history of each; -the time and date of all communications; -the status of recent communications on a channel by channel basis. For instance, any communication initiated by the user would typically be given the status of "outgoing", and would include sent messages of various forms and outgoing calls. Any communication sent to the user including received messages and answered calls would typically be given the status of "incoming". In addition, any communication initiated by the user that has not been attended to by the recipient may be flagged as unanswered. Similarly, any communication sent to the user that has not been attended to, such as a missed or unanswered call may be flagged as "missed".

The "contacts" include all contacts stored in the device's address book as well as stored in externally used address books, as well as unsolicited calls coming from unknown users. Further information regarding the contacts may also be derived from these address books including detailed identification information such as work and home numbers, shared calendars etc. The "channels" include ones serviced by a mobile device's wireless network and associated fixed (i.e. cabled) networks as well as secondary networks that are facilitated by a third party server including ones accessible on the Internet.

The processing engine is configured to receive this data from these various sources and parse it in order to arrive at the preferred means of communication for each contact, and also the intelligently determined log entries. That is, the processing engine is configured to filter this collected data in order to determine data relevant to the current user. This filtered data preferably relates to historical communications as well as "dynamically" determined data. In this regard, examples of the historical data which may be determined include: -the frequency of communication with contacts; -the communication history for contacts; -the frequency of channel use -the flag status of all communications; and -the frequency of address use.

Examples of "dynamic" data which may be determined include: -contact's current location; -contact's status/availability; and -contact's current device (where multiple are utilised).

Once this data has been dynamically sorted and/or filtered, it can be used to identify contacts currently relevant to the particular user and provide entries for the relevant contacts in the user's communication log.

The processing engine may be located on the mobile terminal, or be remote therefrom, or a combination of the two. Where a remote server is utilised, it would typically receive the relevant data from the mobile terminal and/or from the core network, process the data, and then deliver the filtered data to the mobile terminal.

According to further embodiments of the invention, the processing engine may utilise the gathered data (alternatively or in addition) to arrive at a relevant order of contacts in the communication log. Examples of the operation of the processing engine for these further embodiments of the invention are illustrated in relation to Figures 4, 5 and 6.

In Figures 4, 5 and 6, the data is presented in the form of look tip tables. It is to be appreciated that this table format is oniy an example of how the data may be managed, and is not essential to the invention.

In the embodiment to be described in relation to Figure 4, as per the previous embodiments of the invention, data from various communication channels are collected for a plurality of contacts. These contacts preferably include contacts from a user's address book, or a subset thereof, as well as other parties who have been in contact, or attempted to make contact, with the user of the mobile terminal. The different contacts are listed in the first column of the table, labelled here as letters of the alphabet between A and Z. The second and third columns list the different types of data gathered in regard to those contacts, for this embodiment, being: -frequency (with a relative ranking, where a ranking of 1 is given to the least regularly in contact, and higher rankings given consecutively up to the most regular in contact) and -chronological history (with a ranking of 1 being the most recent in contact, and 10 being the least recent).

The chronological history ranking is also given a score, with the more recent entities in contact given a higher score. For instance, the least recently used contact is given a score of 1, meaning they are of the lowest priority in regard to the historical data.

In the example of Figure 4 there are ten contacts listed in the table, so each contact is given a relative frequency ranking, from 1 to 10, with 10 being the most used contact and 1 being the least used contact in the list. Similarly, the most recently used contact is given a histoiy score of 10. From the third column it can be seen that contact "Z" was most recently in contact with the user of the mobile terminal, and so is given the highest score (i.e. with reference to the table, since Z is most recent contact, its history rating is "1", so history score is "10"). Similarly, Y is the least recently used contact in the list, and so is given a rating of "10" and a history score of "1" and L has been the third most recent entity to be in contact with the user, and so is given a score of 8'' The fourth column in the table indicates how the frequency and chronology data is then used to derive a relevance ranking for the communication log. In this column a combined score is calculated for each contact, which is determined by multiplying the contact's frequency score with their history score. From Figure 4, it can be seen that there are two contacts which have the same highest score, namely contact L and contact Z, each with a score of 80. L obtained this score with a frequency score of 10 (i.e. most frequent contact) and a history score of 8 (i.e. third most recent to communicate with the user). Z on the other hand obtained the same score with a frequency score of 8 and a history score of 10. Where equal scores are obtained, one type of data may be given priority over the others. For instance, the frequency score may be given priority in any instance of an equal combined score. Alternatively, their ordering from a previously determined communication log may be applied (i.e. if L was previously ranked higher than Z, then this higher position is maintained).

The fifth column illustrates the ranking order of the contacts after taking the filtering of column four into account. This ordering can then be applied to the communication log.

In terms of how this analysis may be implemented in an algorithm, the Historical Data and Frequency Sub-Routine of Figure 8 is an example.

In a further embodiment of the invention, an additional filter based on one or more flag statuses is applied before the ranking order is utilised in the communication log. This is illustrated in the last two columns of Figure 4.

In Figure 4, contacts "A" and "F" have a flag set in the second last column on the basis of a missed call. Contact "U" also has a flag set, due to being proximate the mobile terminal. In this embodiment, these flags are used to override the score calculated in the previous column, or perhaps to provide an additional weighting to the score. For instance, where a contact has unsuccessfully tried to contact the user of the mobile terminal, as is the case for contacts A and F, these contacts are moved to the top of the user's communication log, so that the user's attention is directed to these missed calls.

Ideally the facility for the user to initiate an appropriate means of communication with these contacts is also provided via the communication log, in case the user wants to respond.

Similarly, if a contact (i.e. contact U) is nearby to the user, a proximity flag is set as acknowledgment, and this contact can be moved to, or at least towards, the top of the user's communication log in case the user wants to contact them in view of their proximity.

The effect of these flags is shown in the final column of Figure 4, where contacts A, F and U have been moved to the top of the ranked list. The order of A, F and U may be based on their relative column four scores. Alternatively, or in addition, certain flags may be given higher priority that others. For instance, if the proximity flag is given a higher priority than the missed call flag, then contact "U" would be placed at the top of the rankings, preceding both contacts "A" and "F" with missed call flags tagged. This is also shown in the Contextual Data Sub-Routine of Figure 8.

Other rules may also be applied in relation to the flags. For instance, the proximity flags may oniy apply if the contact is not in the list and then only show at the lowest position.

It i s t o be appreciated that this approach differs from the standard communication log currently in use, as these logs only filter calls, and then only in relation to missed call, received calls, and calls made by the user.

Figure 5 illustrates further summary usage patterns that may be utilised in managing the communication log. This figure illustrates the data in a table for ease of understanding and is a summary of the data collected, as all communications are time and date stamped and dynamically categorised in this way. The summary shows indicative data of patterns of usage.

In the first column a list of entities that have communicated with the user in the past (indicated by a letter from A to Z). Communication data from this past usage has been gathered and analysed so that patterns are recognised. In this regard the second column provides an indication of whether each user is noticeably in communication with the user on a particular day (i.e. labelled as "Busiest Day", and the third column in relation to a particular time of day (i.e. labelled as "Busiest Time). The next four columns then list entities/contacts that have been in communication with the user via a call, an SMS, an IM or an email respectively.

Finally, the last column illustrates the order that an algorithm may arrange the contacts by relevance based upon this gathered data and usage patterns. It is to be appreciated that the exact algorithm is not essential to the invention. An example is illustrated in the Data Type" Sub-Routine of Figure 8.

The ordering of the "contacts" in the final column has been compiled from the perspective of the current time being a Tuesday at 5pm. In this regard: -L is on top of the list in view of a pattern of communications with L at or around 5pm being recognised (i.e. see busiest time column); -A is next on the list in view of a pattern of communications with A at or around 6pm being recognised. A has also recently been in communication with the user by IM, which may also have strengthened A's position as second on the list; -F is third in the list, as F had most recently been in voice contact with the user. This may be an indication that the algorithm utilised in this instance gives higher priority to voice calls than other forms of corn inunication; -0, Y and M respectively, are next in the list. This is likely to be due to a pattern of communications on Tuesday with the user being recognised for these three users. The ordering of 0, Y and M is likely to have been derived directly from their order of relevance from the previous listing (i.e. column 1); -Z is next in the list in view of Z having been in recent contact with the user by a call, an SMS and an IM. The higher priority given to Z over J (who had more recently made a call to the user) is an indication that the algorithm may give a greater weighting to the frequency of communication by whatever means than just a single communication of a particular priority; -X is eighth in the last, after Z, for similar reasons to Z, in that X has been in contact with the user a plurality of times of late, including the most recent SMS message and an IM; -J and U respectively are at the tail end of the list, as both have only been in communication with the user once of late, J by a call and U by an email. Again this ordering is an indication that calls are given a higher priority than other communications, particularly email in this instance.

Figure 5 is just one example of the type of data that may be presented to the processing engine for filtering, and just one example of how a filtering algorithm may function to arrive at the communication log.

Preferably the processing engine is configured to recalculate the communication log order and entries as required. For instance, the engine may recalculate the communication log every time new communication data is obtained. Alternatively, or in addition, the engine may recalculate the communication log periodically, such as every ten minutes or every hour or in real time.

Figure 6 illustrates a further filtering example, this time considering data available from presence networks. Again this information is presented in tabular format simply for ease of reference, and this structure is not to be considered as a key feature of the invention.

The first colunrn of the table of Figure 6 shows the list of contacts/contactable entities. Typically this list will be the communication log that was last compiled by the processing engine. The second column draws on presence information, by providing a flag on any contacts which are proximate the user's mobile terminal. The degree of proximity may be determined by any appropriate means.

The third colunrn also draws on information that would typically be obtained by a presence network as it provides flags to indicate when a contact is online and/or offline. This is particularly relevant for IM and SNS communications.

Where the availability of a user is unknown it is left blank.

The next four columns indicate contacts that have communicated, or sought to communicate, with the mobile terminal recently in terms of calls, SMS, Email and IMs. Each of these lists is compiled by chronology, although frequency may also be taken into account.

The final two columns of the table provide the communication log order (i.e. all view order) as well as a selected mechanism of contact (i.e. all view contact options). The selected mechanism of contact provides the device user with a short cut to a particular means of communication, so that they may quickly initiate a communication to the contact. In this embodiment of the invention, the actual means of communication selected is dependent upon a predetermined user preference and presence data relating to the user and/or contact, as applicable. A default means of communication is also preferably provided.

The communication log order in this example has been arrived at using an algorithm that placed the greatest weight on availability, since L, who is listed as "online" is placed at the top of the list. Also, in view of this online availability, an IM communication shortcut is also provided in the communication log.

The other entries in the communication log are as follows: -A and J are next on the list in view of their location flags being activated, indicating that they are proximate the user's mobile terminal. The communication shortcut provided for both of these contacts is a "call" shortcut which may have been chosen in view of a call being the most suitable means of contacting a proximate friend, in view of it demanding an immediate response from the called party; -F is next on the list due to recently being involved in two calls/call attempts with the user; -Z is next on the list, due to recently being involved in a call and an IM with the user; -X follows on the list, due to recently sending an SMS and an IM to the user. Comparing with X's activity with that ofF and Z, who have also been involved in two communications each, it can again be seen that in this embodiment the algorithm gives a greater weight to calls than SMS messages; -U is next on the list due to having sent one email recently; -Y and M are at the end of the list, due to each not having been involved in any recent communications, and not having any relevant presence information available.

Ideally the communication data gathered in Figure 6 is linked to the user's own presence data. For instance, if the user's status is set as not available, the priority of each form of communication would be changed to suit this non-availability. For example, immediate forms of communication (such as voice calls, and IM) would typically be given a lower priority than other forms of communication which do not require an immediate response (e.g. SMS and email).

It is to be appreciated that although the examples provided by Figure 5 and 6 considered data from presence networks and communication patterns separately, this has only been for ease of reference purposes, and the two forms of data may be taken into consideration by the one processing engine utilising an algorithm combining the two. An example of how this may be implemented is shown in the "Data Type" subroutine of Figure 8.

In this way, the inventive concept is able to provide users with dynamically organised and relevant options for managing communications based upon parsing logged communication traffic data as well as live dynamic communication status data. It enables communication traffic to be filtered in multiple dimensions including chronology and frequency of communication, thereby increasing the relevance of the filtered data. The resulting filtered data can then be displayed in a log containing ranked order of communications for all channels and for each individual channel. In this way, by aggregating the various channels in the one communication log, frequently used contacts are made accessible in the one place. It is also preferable that each contact in the list is associated with a means for contacting them by a relevant channel (e.g. SMS, IM etc), thereby making communication with them easier.

Further, the engine can be configured to recognise regular occurrences (i.e. patterns) of the user contacting, or being contacted by a particular person, and the form of communication used. In this way a customisable and dynamic log of communications can be compiled. Importantly, frequently used contacts are visible in the communication log whatever communication channel is used.

The algorithm may implement any rule and weighting considered appropriate.

For instance, unanswered calls, frequently redialled numbers and/or missed calls may be given a high weighting so that they are always visible in the log.

Similarly, frequently used contacts may be given a high weighting even when their status is determined as "offline". This would then enable the user to easily communication with the contact by a voice call or SMS, for example, rather than non-voice channels, such as IM or SNS, which are not currently possible.

To illustrate how these embodiments of the invention improve on the existing call log situation, if a user receives a missed call from an infrequent contact and replies to them via another channel (e.g. SMS), where they have an ongoing SMS communication. Under the call log, only the missed call would be registered, even though the infrequent contact may become a frequent contact in the SMS channel. Under the present invention, the contact's SMS communications would be recognised and made visible in the user's communication log.

Figure 7 illustrates a example of how the log on a user's terminal may alter over time through the application of the embodiments of the present invention.

This Figure shows what the log may look like at 7pm (first column) and then later at 11pm (second column).

At 7pm the log includes Alison who the user has put to the top of the list manually, perhaps as a reminder. Then there is a missed call from the user's mother -ranked highly as a regular caller and as a historically recent call.

There are then two IM related entries reminding the user that they regularly chat in the early evening with contacts Lucy, Paul and Bev and, if relevant, on particular days. The order of these three entries will be ranked by the frequency of their communication and patterns of use. There are two calls to Tom and Jerry and these appear lower in the list as they are less frequent communicators.

The next entry is for Shirley who occasionally chats on IM in the evening and if relevant on particular days. Lastly, there are two SN entries showing recent messages posted to the user from senders who are less frequent than those listed above.

As time goes on and the communication history and context change the list is updated. At 1 1pm the first position of the log shows a missed call (flagged as top position) from Bill. Then there is a reminder that Alison often calls around this time and if relevant on particular days. As Bill and Alison are more frequent callers than Mum or Dad they appear higher in the list as two missed calls (flagged to higher position than unweighted) and one answered call respectively. There are then three IM related entries showing people (Cheryl, Julie and Clare) who regularly chat around this time in order of frequency and how recently they have communicated. The last three entries are historical communication entries that have carried over from the 7pm log, as more relevant entries have not superseded them. In this regard it is to be appreciated that the algorithm implemented in this embodiment of the invention, actual or attempted communications are retained in the log until superseded. Entries based on historical communication patterns, however, are only retained in the list for a certain predetermined period of time. For example, the entries for Lucy, Paul and Bev, which served as a reminder to the user that these contacts regularly IM around 5pm, may only be retained in the list for, say three hours (i.e. from 4.3Opm to 7.3Opm) and hence do not appear in the 1 1pm log.

As indicated previously, the exact implementation of the algorithm underlying these embodiments of the invention is not essential to the invention. A possible implementation, however would be a simple "if condition Y", "then result Z".

For instance, if at time t=x, x is within a pre-designated range of working hours, then contacts flagged as important during working hours may have a weighting factor of "times 2" applied. In particular, these weightings could be applied to the historical/chronological log order, such as determined in Figure 4.

Figure 8 provides a summary of how such an algorithm could be created. It is to be appreciated that the "algorithm" of Figure 8 is not written in any specific code, and is in fact a functional summary of how an algorithm could be formulated. The algorithm is structured in subroutines, which is also not an essential aspect of the algorithm, but does assist alterations and additions to the algorithm.

With reference to Figure 8, the main structure of the algorithm essentially just introduces the data, and provides a mechanism for running the different sub-routines. The subroutines that have been defined are based upon the embodiments of the invention that have been described. They are: -Historical Data and Frequency Subroutine This is a subroutine that corresponds to the functionality shown in the first five columns of Figure 4.

-Time Subroutine At section (3) of this subroutine, an example is provided of how a contact known to historically communicate with the user at a particular time or during a particular time period can be given a priority weighting to appear towards the top of the log. Further, the priority weighting given depends upon the communication type that the contact typically communicates with. For instance, voice and SMS are given one weighting (A), and other communications types another (B). This is just an example of how different weightings can be applied, and instead all historical communications could be given the same weighting, regardless of communication type.

This subroutine further sets out (sections (4) and (5)) how different weighting values (i.e. priorities) can be given to different contacts or classes of contacts at a certain time or in a certain time period. For instance, at section (5) of this subroutine, outside work hours, a weighting of D is applied to contacts flagged as family and a weighting of E is applied to work related contacts. The weightings may be adjusted as required, but weighting D would typically be a higher weighting to put family contacts towards the top of the log, whilst the weighting E could be a negative weighting to ensure that work contacts do not appear in the log at all or at least towards the bottom of the log.

-Data Type Subroutine This subroutine provides an example of how the communication data can be filtered based upon the number of communications of each communication type that the contacts are involved in with the user during a given time period.

-Contextual Data Subroutine This subroutine shows how data from presence networks may be utilised in defining the log order, particularly in regard to pushing contacts who are nearby towards the top of the log (section (4)) as well as contacts who are logged into an IM account (section (5)).

-Diary Subroutine This short subroutine enables a contact listed in a future event to be included at or towards the top of the communication log in the period leading up to the event. In particular this enables the user to readily confirm the event with the contact or cancel/reschedule if necessary.

As indicated above, these subroutines are to be considered as just one approach for implementing the embodiments of the invention, and that variations and additions are of course possible. For instance, in the Figure 8 example, the ordering of the subroutines control which contacts are inserted at and towards the top. However, an additional comparative subroutine could be introduced to provide greater flexibility in arranging the priority ordering.

It is also to be appreciated that the processing engine/processing functionality may be provided as a component of the user's mobile terminal or separately, such as on a network server in communication with the mobile terminal. It is most preferable that the engine is provided on a network server, as such a server would have greater ease of access to the necessary history information, and also would be able to concentrate the processing power required, and process the contact information for multiple users.

Another feature that may be implemented with these embodiments of the invention is for the user can apply additional filters to the data gathered. For instance, the user may decide they do not want one or more particular contacts to appear in their communication log. They may therefore specify that such unwanted contacts are not included or removed from the communication log.

Similarly, a user manual override functionality may be incorporated, allowing the user to add and remove entries as and when required so that, for example, a contact can be added to the list as a reminder or removed if they are not wanted.

As well as enabling dynamic changes to be made in the way that the log works the user interfaces also includes a settings function whereby the user can define, change and remove all parameters relevant to individual contacts, communication channels and processing as well as individual ones.

Further, the user may specify their own communication options and preferences which may have particular relevance to the user's habits. These personal communication options may override corresponding information in the intelligent communication log. For instance, if the user never wants a contact, Joe Bloggs to be listed in the communication log, this option may be specified.

Claims

CLAIMS1. In a communications network including a terminal configured to communicate with a plurality of different communicable entities, a method of managing communications with the plurality of communicable entities by creating a dynamic communication log of at least a portion of the communicable entities, the log for use on the terminal, the method including: for each communicable entity obtaining communication data relating to a plurality of communication types; creating the communication log by applying an algorithm relating to a listing order of the communication log, the algorithm defining the relevance of each type of obtained data and any applicable conditions, such that the communication log created by the algorithm lists the plurality of different communicable entities in an order of perceived relative relevance to the user of the terminal based on the plurality of communication types.
2. The method of claim 1 wherein the algorithm applied defines the relevance of each type of data by allocating a predetermined relevance value, and creating the communication log further includes: determining a score for each communicable entity using at least one predetermined relevance value that applies to that communicable entity's communication data; arranging the plurality of communicable entities in a listing order based upon the scores.
3. The method of any one preceding claim wherein the communication log is created with reference to a particular point in time, and the method further includes: determining any conditions applicable to the particular point in time; where one or more conditions are determined as applicable, for each determined condition, determining whether any of the communicable entities are associated therewith; and the applied algorithm further creates the communication log by incorporating any applicable time-related conditions by allocating an appropriate predetermined relevance value to any communicable entities associated with an applicable condition.
4. In a communications network including a terminal configured to communicate with a plurality of different communicable entities, a method of managing communications with the plurality of communicable entities by creating a dynamic communication log of the communicable entities for use on the terminal, and relevant to a particular point in time, the method including: determining any conditions applicable to the particular point in time; where one or more conditions are determined as applicable, for each determined condition, determining whether any of the communicable entities are associated therewith; and creating the communication log by applying an algorithm relating to a listing order of the communication log which incorporates the one or more applicable time-related conditions by allocating an appropriate predetermined relevance value to any communicable entities associated with an applicable condition, such that the communication log created by the algorithm lists the plurality of different communicable entities in an order of perceived relative relevance to the user of the terminal based on the time-related condition or conditions.
5. The method of claim 3 or 4 wherein the particular point in time with reference to which the communication log is created is a specific time of day, day of the week or month or a specific time period.
6. The method of any one preceding claim wherein the any conditions that are determined to apply include one or more of the following: a) one or more communicable entities being within a predetermined proximity of the terminal; b) one or more communicable entities being flagged by a presence network as being available; c) one or more communicable entity being logged into an Instant Messaging account; d) one or more communicable entities being listed in a current or forthcoming event; e) one or more communicable entities having an historical communication record relevant to the particular point in time; one or more communicable entities being flagged as relevant to the particular point in time, including where the point in time is within a designated time period, such as normal working hours.
7. The method of any one of claims 2 to 6 wherein the predetermined relevance value is a relative weighting for each data type or a listing position in the communication log.
8. The method of any one preceding claim wherein obtaining data includes, obtaining data from one or more of the following sources for each communicable entity: a) communication traffic data relating to the regularity that the communicable entity has communicated with, or attempted to communicate with, the terminal; b) status information relating to communications with the terminal, in terms of missed calls, incoming accepted calls and/or outgoing accepted calls c) one or more communication channels via which the communication entity has communicated with, or attempted to communicate with, the terniinal; d) contextual data relating to the availability and/or status of the communicable entity; e) a communication device identity relating to the device currently being used by the communicable entity; f) one or more databases on the terminal and/or on a remote network server.
9. The method of any one preceding claim further including using predefined preferences of the user of the terminal in: a) arranging one or more communicable entities in the communication log; and/or b) defining information included in an entry of a communicable in the communication log, such as a preferred means of communication.
10. The method of any one preceding claim wherein the applied algorithm further utilises recognised communication patterns for one or more particular communicable entity in creating the communication log.
11. The method of any one preceding claim further including for at least one communicable entity listed in the communication log: determining an appropriate means of communication with the communicable entity; and incorporating a facility in the entry for the communicable entity in the communication log to initiate the appropriate means of communication with the communicable entity.
12. The method of claim 11 wherein the appropriate means of communication is determined by reference to availability and/or status information for the communicable entity, the information received from a presence network.
13. In a communications network including a terminal configured to communicate with a plurality of different communicable entities, an arrangement for managing communications with the plurality of communicable entities by creating a communication log of at least a portion of the communicable entities, the log for use on the mobile terminal, the arrangement including: receiving engine configured to obtain communication data relating to a plurality of communication types for each communicable entity; processing engine configured to create the communication log by applying an algorithm relating to a listing order of the communication log, the algorithm defining the relevance of each type of obtained data and any applicable conditions, such that the communication log created by the algorithm lists the plurality of different communicable entities in an order of perceived relative relevance to the user of the terminal based on the plurality of communication types.
14. The arrangement of claim 13 wherein the algorithm that the processing engine is configured to apply defines the relevance of each type of data by allocating a predetermined relevance value, and the processing engine is further configured to: determine a score for each communicable entity using at least one predetermined relevance value that applies to that communicable entity's communication data; and arrange the plurality of communicable entities in a listing order based upon the scores.
15. The arrangement of claim 13 or 14 wherein the communication log is created with reference to a particular point in time, and the processing engine is further configured to: determine any conditions applicable to the particular point in time; where one or more conditions are determined as applicable, for each determined condition, determine whether any of the communicable entities are associated therewith; and create the communication log by incorporating any applicable time-related conditions by allocating an appropriate predetermined relevance value to any communicable entities associated with an applicable condition.
16. In a communications network including a terminal configured to communicate with a plurality of different communicable entities, an arrangement for managing communications with the plurality of communicable entities by creating a dynamic communication log of the communicable entities for use on the terminal, and relevant to a particular point in time, the arrangement including a processing engine configured to: determine any conditions applicable to the particular point in time; where one or more conditions are determined as applicable, for each determined condition, determine whether any of the communicable entities are associated therewith; and create the communication log by applying an algorithm relating to a listing order of the communication log which incorporates the applicable time-related conditions by allocating an appropriate predetermined relevance value to any communicable entities associated with any applicable condition.
17. The arrangement of claim 15 or 16 wherein the particular point in time with reference to which the processing engine is configured to create the communication log is a specific time of day, day of the week or month or a specific time period.
18. The arrangement of any one of claims 13 to 16 wherein the condition or conditions that the processing engine is configured to determine as applying include one or more of the following: a) one or more communicable entities being within a predetermined proximity of the terminal; b) one or more communicable entities being flagged by a presence network as being available; c) one or more communicable entity being logged into an Instant Messaging account; d) one or more communicable entities being listed in a current or forthcoming event; e) one or more communicable entities having an historical communication record relevant to the particular point in time; f one or more communicable entities being flagged as relevant to the particular point in time, including where the point in time is within a designated time period, such as normal working hours.
19. The arrangement of any one of claims 14 to 18 wherein the predetermined relevance value that the processing engine is configured to allocate when creating the comnmnication log is a relative weighting for each data type or a listing position in the communication log.
20. The arrangement of any one of claims 13 to 19 wherein the processing engine is further configured to obtain data from one or more of the following sources for each communicable entity: a) communication traffic data relating to the regularity that the coinmunicatble entity has communicated with, or attempted to communicate with, the terminal; b) status information relating to communications with the terminal, in terms of missed calls, incoming accepted calls and/or outgoing accepted calls; c) one or more communication channels via which the communication entity has communicated with, or attempted to communicate with, the ternñnal; d) contextual data relating to the availability and/or status of the communicable entity; e) a communication device identity relating to the device currently being used by the communicable entity; and f) one or more databases on the terminal and/or fro a remote network server.
21. The arrangement of any one of claims 13 to 20 wherein the processing engine is further configured to use predefined preferences of the terminal user in: a)arranging one or more communicable entities in the communication log; and/or b) defining information included in an entry of a communicable in the communication log, such as a preferred means of communication.
22. The arrangement of any one of claims 13 to 21 wherein the processing engine is further configured to utilise recognised communication patterns for one or more particular communicable entity in creating the communication log.
23. The arrangement of any one of claims 13 to 22 wherein the processing engine is further configured, for at least one communicable entity listed in the communication log, to: determine an appropriate means of communication with the at least one communicable entity; and.incorporate a facility in the entry for the communicable entity in the communication log to initiate the appropriate means of communication with the communicable entity.
24. The arrangement of claim 23 wherein the processing engine is further configured to determine the appropriate means of communication by reference to availability and/or status information for the communicable entity, the information received from a presence network.
25. The arrangement of any one of claims 13 to 24 wherein the processing engine is further configured to create the communication log based upon regularity of communication in terms of the time, days of the week or month and/or frequency of communication.
26. The arrangement of any one of claims 13 to 25 wherein the communicable entities in relation to which the arrangement is configured to gather communication data include one or more of: entities that have been in, or attempted communication with, the terminal; and contacts in a contact database, such as an address book, associated with the terminal.
27. The arrangement of any one of claims 13 to 26 wherein the arrangement is configured at least in part on a server of the communication network.
28. The arrangement of any one of claims 13 to 27 wherein the arrangement is configured at least in part on the terminal.
29. A mobile terminal configured to perform the method according to any one of claims 1 to 12.
30. A mobile terminal including an arrangement according to any one of claims 13 to 26.
31. A network server including an arrangement according to any one of claims 13 to 26.
32. A method substantially as herein described with reference to the accompanying figures.
33. A mobile terminal substantially as herein described with reference to the accompanying figures.