COMMUNICATION BETWEEN NETWORKED ENTITIES IN A PRESENCE- BASED COMMUNICATION SYSTEM

The present invention relates generally to a presence-based communication system, and in particular to communication between network entities forming part of such a system.

Various types of communication devices such as mobile telephones, laptop or hand held computing devices, desktop computers and the like, can identify themselves to the network using a suitable network identifier. "Presence" refers to, for example, the availability, proximity, activity level or operating state of a presentity, such as a user, object or anything that can have some kind of state. Presence can be loosely defined as knowledge about a presentity that is displayed to a watcher. Status information about the presentity's communication and other conditions is collected by various methods and devices for aggregation and processing or by a presence engine in order to transfer the raw data into some useful form for the watcher.

The ability for users or objects to monitor each other's presence is a feature offered in connection with many applications that support network telephony. For example, instant messaging applications have a contact list feature, in which the user of the application can determine whether selected users or objects are available for engaging in communication. The data retrieved and returned to a watcher in relation to a contact list is referred to as "presence information", and is generally maintained by a presence server in the data network. Typically, the presence server supports a network protocol such as Session Initiation Protocol (SIP). Users or objects can reach the presence server with their communication devices in order to have the presence of the device or objects associated with the device maintained and to allow various programs on the network to facilitate telephony services or other services in which communications are exchanged between network entities. The presence server facilitates communication of each presentity's presence information to one or more watchers.

Additional details about presence and presence modelling are set forth in the Internet Engineering Task Force (IETF) Request for Comment (RFC)

2778 entitled "A model for presence and instant messaging" dated February, 2002, RFC 2779 entitled "Instant messaging/presence protocol of requirements" dated February 2002, and RFC 4480 entitled "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)" dated July 2006. The entire contents of these documents are incorporated herein by reference.

Presence information is conventionally displayed to a watcher as a one dimensional list of entities that indicates a presence status, namely whether that entity is able to accept communications or will reject incoming communications. The watcher is then able to select one of those entities willing to accept incoming communications, and initiate a communication with that entity.

Whilst suitable for use in circumstances involving a limited number of contacts, this rudimentary use of presence information is ill-suited to use in more complex social networking applications. A social network is a personal or professional set of relationships between individuals or entities. In social networking applications, individuals or entities are related by structural characteristics such as proximity to others, frequency of social contact and the type of relationship e.g. spouse, confident, work colleague, relative, friend. Individuals typically have complex relationships with a great number of entities. Each individual may have hundreds or even thousands of contacts with which communication may be desired under certain circumstances or in certain situations. Moreover, communication may be desirable under certain circumstances with entities not previously known to an individual. Commonly understood examples of such communication are the posting of messages on websites known as "forums". Again, the circumstances in which such communications are to be sent and received may vary depending upon a variety of factors.

There currently exists a need to provide a presence-based communications system that simplifies communication between networked entities. There also exists a need to provide a presence-based communication system that provides a rich communication experience for networked entities in a manner that replicates real world social interactions. There further exists a

need to provide the user of a network entity with the ability to control their level of interaction with other entities in a presence-based communication system.

With this in mind, one aspect of the invention provides a method of facilitating communication between networked entities in a presence-based communication system. The method includes the steps of: at a presence server, storing one or more personas associated with each networked entity and contextual information characterising each persona; determining a degree of closeness between the contextual information characterising at least a first persona associated with a first networked entity and contextual information characterising at least a second persona associated with a second networked entity; and providing a notification of the first persona to the second persona if the degree of closeness exceeds a user-variable threshold.

Advantageously, a method including these steps enables a user of a first network entity to vary their level of interaction with other network entities forming part of a presence-based communication system. Contextual information characterising personas associated with each of the networked entities is used to determine those personas that are "closer" to a persona of a user of a first networked entity, and hence identify those personas with which the user is most likely to communicate. Depending upon the persona selected, the user is therefore able to vary the size of the group of personas with which a user persona is willing to communicate at any one time.

The notification step may include the steps of: notifying a present status of the first persona to the second persona, the present status having either an open state or a closed state respectively indicating acceptance or rejection of incoming communications from the second persona; and setting the notified presence status of the first persona to an open state for the second persona if the degree of closeness exceeds a user variable threshold or otherwise setting the notified presence status of the first persona to a closed state.

In one or more embodiments of the invention, the step of determining the degree of closeness includes determining a semantic affinity between the contextual information characterising the first persona and the contextual information characterising the second persona. For example, the contextual

information may include one or more descriptors or interests associated with a persona.

The contextual information may also or alternatively include location data. In this case, the step of determining the degree of closeness includes determining spatial proximity of the first persona and the second persona from the location data.

In some embodiments of the invention, the step of determining the degree of closeness includes combining values of semantic affinity and spatial proximity. Measures of semantic affinity and spatial proximity between personas can be used in order to determine the degree of closeness between a first persona and a second persona that may have not previously communicated with the first persona. Assessing contextual information such as semantic affinity and spatial proximity can therefore be used to match personas that can be thought of as being part of a same "crowd" of personas that have not previously interacted.

In one or more embodiments of the invention, the second persona may be a contact of the first persona. In this case, the step of determining the degree of closeness may include determining a communicative affinity between the first persona and the contact. For example, the communicative affinity between the first persona and the contact may be carried out by storing historical communication instances between the first persona and the contact; and determining the frequency of communication instances between the first persona and the contact. A persona may be considered to be a contact of another persona from having previously communicated with that persona. Alternatively, a persona may be considered to be a contact of another persona by having been entered into a list of contacts accessible to that other persona.

The contextual information may include various other types of information. For example, the contextual information may include message content data characterising the content of messages exchanged between the first persona and the contact. By way of example, the message content data

may include any one or more of the following types of data: message originator, message recipient, resource type, message topic, message location and a time stamp.

The threshold may be able to be varied by a user of the first networked entity over a first range of values in which an open presence status can only be notified to personas that are contacts of the first persona. Over this first range of values, the first persona is therefore able to indicate that they are only willing to receive communications from existing contacts. The particular threshold set by a user determines the number of contacts at any one time with which the user is willing to communicate. As that threshold is varied, the number of contacts in that group are reduced to only those contacts that are closest to the persona selected by the user.

The threshold may also be able to be varied by the user of a first networked device over a second range of values in which an open presence status can be notified to personas that are not contacts of the first persona. In a second range of values, the persona is effectively able to enter a "crowd" of other personas with which communication has not previously occurred and the user threshold level selected to enable communication with those "crowd" personas having contextual information that indicates a closeness with the first persona of the user of the first networked entity. In one example, the threshold values in the second range are greater than the threshold values in the first range.

In one or more embodiments of the invention, a plurality of persons may be stored for each networked entity. In this way, a user is able to select from multiple personas, such as a persona for work, a person for friends and a persona for sport. The method of the invention may include the step of deriving a global threshold based on the user variable thresholds of the plurality of persons.

The global threshold may be user variable. In this case, the method may further include the step of varying the global threshold, and applying a corresponding change to the user variable threshold of each persona.

Conveniently, this enables a user of the first networked entity to apply a single global threshold to vary their desired interaction with other personas, and to

cause that single global threshold variation to be applied to each of the multiple personas associated with that first networked entity.

At some of the contextual information characterising the first persona may be used to modify the use of variable thresholds. In this way, detection of a change in user location or activity, for example, may be used to vary the user variable threshold to a desired level of interaction with other personas.

In one or more embodiments of the invention, a representation of the second persona may be displayed at the first network entity only if the present status is set to an open state. Accordingly, only those personas with which the first persona is willing to communicate are displayed at the first network entity in order to limit the amount of visual information presented to a user of the first networked entity.

Another aspect of the invention provides a presence-based communication system for facilitating communication between networked entities. The system includes a data storage apparatus for storing one or more personas associated with each networked entity and contextual information characterising each persona. The system also includes computing apparatus for determining a degree of closeness between the contextual information characterising at least a first persona associated with a first networked entity and contextual information characterising at least a second persona associated with a second networked entity; and providing a notification of the first persona to the second persona if the degree of closeness exceeds a user- variable threshold.

This notification may be carried out by notifying a presence state of the first persona to the second persona, the present status having either an open state or a closed state respectively indicating acceptance or rejection of incoming communications from the second persona; and setting the notified presence status of first persona to an open state for the second persona if the degree of closeness exceeds a user variable threshold or otherwise setting the notified presence state of the first persona to a closed state.

Another aspect of the invention provides computer software for use with a presence-based communication system for facilitating communication

between networked entities as described above. The system includes computing apparatus and one or more associated storage devices for storing the computer software, the computer software including a series of instructions for causing the computing apparatus to carry out a method as described above.

Yet another aspect of the invention provides a first networked entity for use with the above described presence-based communication system. A first networked entity may include a user actuable control for setting the user variable threshold for the first persona associated with the first networked entity.

A further aspect of the invention provides a second networked entity for use with the presence-based communication system described above. The second networked entity may include a graphic user interface for displaying an icon of the first persona associated with the first networked entity, when the first persona has an open presence status.

In many embodiments, the first networked entity and second networked entity will be combined in a single communication device.

The above described method may further include the steps of, at a first networked entity, setting the user variable threshold for one or more first personas associated with the first networked entity; and transmitting the value of the user variable threshold.

The method may further include the steps of, at a second networked entity, receiving the presence status of the first persona associate with the first networked entity; and displaying an icon of the first persona when the first persona has an open presence status.

Yet another aspect of the invention provides computer software for use in the communication device described above. Communications device may include a processing unit and one or more associated memory devices for storing the computer software. Computer software may include a series of instructions for causing the processing unit to carry out those steps described above in relation to the first and/or second networked entities.

Yet another aspect of the invention provides a method of identifying message content in messages exchanged by networked entities in a presence-based communication system. The method includes the steps of: at a presence server, storing one or more personas associated with each networked entity and contextual information characterising each persona, and contextual information characterising the message content in messages exchanged between personas; determining a degree of closeness between the contextual information characterising a first persona and the contextual information characterising the message content; and providing a notification of the message content to the first persona if the degree of closeness exceeds a user-variable threshold.

The step of determining the degree of closeness may include determining a semantic affinity between the contextual information characterising the first persona and the contextual information characterising the message content.

The contextual information may include location data, and the step of determining the degree of closeness may include determining spatial proximity of the first persona and the messages from the location data.

The step of determining the degree of closeness may further include combining values of semantic affinity and spatial proximity.

In one or more embodiments, the degree of closeness may only be determined between the contextual information characterising the first persona and the contextual information characterising the message content of messages that are exchanged between the first persona and contacts of that first persona.

Alternatively, the degree of closeness may only be determined between the contextual information characterising the first persona and the contextual information characterising the message content of messages from other personas determined to have a requisite degree of closeness to the first persona.

The contextual information characterising each persona may include any one or more of descriptors and interests associated with the persona.

The contextual information characterising the message content may include any one or more of the following types of data: message originator, message recipient, resource type, message topic, message location and a time stamp. A still further aspect of the invention provides a presence-based communication system for identifying message content in messages exchanged by networked entities. The system includes: data storage apparatus for storing one or more personas associated with each networked entity and contextual information characterising each persona, and contextual information characterising the message content in messages exchanged between personas; and computing apparatus for determining a degree of closeness between the contextual information characterising a first persona and the contextual information characterising the message content; and providing a notification of the message content to the first persona if the degree of closeness exceeds a user-variable threshold.

Yet another aspect of the invention provides computer software for use with a presence-based communication system for method of identifying message content in messages exchanged by networked entities. The system includes computing apparatus and one or more associated storage devices for storing the computer software. The computer software includes a series of instructions for causing the computing apparatus to carry out the above- described method of identifying message content.

A still further aspect of the invention provides a method of identifying message content exchanged by networked entities in a presence-based communication system. The method including the steps of: at a presence server, storing one or more personas associated with each networked entity and contextual information characterising each persona, and contextual information characterising the message content exchanged between personas; determining a degree of closeness between a content query submitted by a first persona and the contextual information characterising the message content; and providing a notification of the message content to the first persona if the degree of closeness exceeds a user-variable threshold.

Another aspect of the invention provides a presence-based communication system for identifying message content in messages exchanged by networked entities. The system includes: data storage apparatus for storing one or more personas associated with each networked entity and contextual information characterising each persona, and contextual information characterising the message content in messages exchanged between personas; and computing apparatus for determining a degree of closeness between a content query submitted by a first persona and the contextual information characterising the message content; and providing a notification of the message content to the first persona if the degree of closeness exceeds a user-variable threshold.

A further aspect of the invention provides computer software for use with a presence-based communication system for facilitating communication between networked entities. The system includes computing apparatus and one or more associated storage devices for storing the computer software, the computer software including a series of instructions for causing the computing apparatus to carry the above-described method of identifying message content.

Various aspects and features of the drawing will be more fully understood with reference to the following drawings, in which the invention illustrated in one or more exemplary, but non-limiting embodiments.

In the drawings:

Figure 1 is a schematic diagram illustrating one embodiment of a presence-based communication system according to the present invention; Figure 2 is more detailed schematic diagram showing functional components of a presence server forming part of the presence-based communication system shown in Figure 1 ;

Figure 3 is a domain model showing the inter-relationship between a user of a networked entity forming part of the presence-based communication system shown in Figure 1 , personas associated with that entity and contextual information characterising the persona and contacts of that persona;

Figure 4 is a domain model showing the relationship between users, personas and contacts in the presence-based communication system shown in Figure 1 ;

Figure 5 is a diagram illustrating the comparison of contextual information of various personas involved in the use of presence-based communication system shown in Figure 1 ;

Figure 6 is a flow chart illustrating various functional operations performed by the presence server shown in Figure 2;

Figures 7 and 8 are exemplary screen displays of networked entities forming part of the presence-based communication system shown in Figure 1 ;

Figure 9 is a graph illustrating the change in the number of contact and crown personas available for communication with as the user variable threshold for a particular persona is changed;

Figure 10 is a table showing a comparison of two types of contextual information in order to determine a degree of closeness between two personas;

Figure 11 is a graphical representation of the mapping of communicative affinity of two personas adapted to communicate in the presence-based communication system shown in Figure 1 to discreet values of a user variable threshold set for one of those personas;

Figure 12 is an embodiment of a graphic user interface showing a mixing of contacts of each of a user's three personas according to the user variable threshold set for each persona;

Figure 13 is an example of a graphic user interface used to set user variable thresholds for each of three personas, a global threshold and for entering contextual information in relation to one or more of the personas;

Figure 14 is a flow diagram illustrating the interaction of persona activity, location and user variable threshold settings;

Figure 15 is another flow chart illustrating various functional operations performed by the presence server shown in Figure 2; and

Figure 16 is a schematic diagram showing various function elements of one or more parts of the presence-based communication system shown in Figure 1.

Referring now to Figure 1 , there is shown generally a presence-based communication system 10 including a first networked entity 12 and a second networked entity 14. In this case, the first networked entity 12 is a presentity, whereas the second networked entity 14 is known as a watcher. The terms "presentity" and "watcher" are defined in IETF Standard RFC 2778 entitled "A Model for Presence and Instant Messaging" dated February 2000, within the context of the SIP method defined in the IETF Standards RFC 3903 and 3856 for publishing presence state. The publisher mechanism allows a user to create, modify and remove the user state in a presence server, which manages the presence state for the user. RFC 3856 describes the use of SIP for subscriptions and presence notifications. In Figure 1 , the presentity 1 provides presence information that is to be stored and distributed to a presence server 16. The watcher 14 subscribes to the presence server 16 to receive the presentity's presence information. When the presentity publishes this information to the presence server, the presence server notifies the watcher of the presentity's presence information via a notify message.

The presentity 12 includes a presence user agent 22 for interfacing the presence server 16 and a graphically user interface 24 for displaying presence and related information on a display 26 in the form of icons and/or text strings.

In addition, the graphical user interface 24 may include buttons or other control devices that enable a user to invoke an action of the presentity 12.

Similarly, the watcher 14 includes a user agent 28 for interfacing with the presence server 16 and a graphically user interface 30 for displaying real time presence in related information on a display 32 in the form of icons and/or text strings. In addition, the graphically user interface 30 may also include controls that enable the watcher 14 to invoke an action, such as initiating an instant message, text message, voice communication session or other communication instance with the presentity 12.

Typically, a user Communications device such as a desktop phone, mobile phone, pda, desktop computer, laptop computer etc forming part of the presence-based communication system 10 include both a presentity and watcher of the type shown in Figure 1 , so that presence information is able to be provided from the user communications device to the presence server 16 and presence information associated with other users is able to be monitored at the user communications device.

The presence server 16 includes a TAP engine 34, a contact manager 36, a presence manager 38, a context store 40, and a search engine 42. The TAP engine 32 provides a service to return ranked sets of entities, where each entity has a score given a specific context. The TAP engine 34 is used by other services in the presence server 16. The presence manager 38 receives presence information from presentity forming part of the communications system 10, and notifies watchers of the open or closed state of the presence status of the presentity. The contact manager 36 determines an ordered list of a persona's contacts and an ordered list of personas from a public space based upon an affinity score between the personas. In the case of a persona's contacts, the affinity score is based, in this exemplary embodiment, on a history of communication instances with that contact. In the case of personas from a public space, the affinity score is determined, in this example, on a comparison of semantic tags that describe the persona and interests of that persona, as well as a measure of spatial proximity.

The presence manager 38 calls upon the TAP engine 34 to compare personas and then the presence manager 38 determines the presence status that should be notified to a watcher of that persona.

The context store 40 maintains contextual information for use in determining affinity between personas and content. This contextual information may include location information, persona descriptors, persona interests, a communication history of communication instances between personas, content topic, content timestamps, and like information.

The search engine 42 maintains an indexed copy of the contextual information collected in the context store 40 to enable efficient searches for comparison of personas and content by the TAP engine 34.

The presence server 16 also includes a content manager 44 used to provide lists of content available to a user that matches a search context provided.

Figure 2 shows a more detailed view of the presence server 16 and its functional components. As shown in this figure, a user communications device

50, including both presentity and watcher functions, provides presence information relating to one or more personas associated with the user communication device 50 to the presence manager 38.

The presence manager 38 receives the presence information and then updates contextual information characterising one or more personas 52 stored in the context store 40. The contextual information may include location data

54, descriptors 56, interests 58 and a history 60 of communication instances with other personas. Upon updating the contextual information, the presence manager 38 queries the tap engine 34 to determine the closest personas and evaluate the user threshold. The presence manger 38 then sets rules to control how the presence is notified, and then notifies all watchers according to the rules.

Accordingly, the presence server 16 stores one or more personas associated with the user communications device 50 and other networked entities as well as contextual information characterising each persona. The presence server 16 determines a degree of closeness between the contextual information characterising at least a first persona associated with a first networked entity and contextual information characterising at least a second persona associated with a second networked entity, and provides a notification of the first persona to the second persona if the degree of closeness exceeds a user-variable threshold.

In this exemplary embodiment, notification is carried out by notifying a presence status of the first persona to the second persona, where the presence status has either an open state or a closed state respectively indicating acceptance or rejection of incoming communications from the second persona. The notified presence status of the first persona is set by the presence server 16 to an open state for the second persona if the degree of

closeness exceeds a user-variable threshold or otherwise setting the notified presence status of the first persona to a closed state.

The notification that each persona receives may be a single message with a list of other personas having a degree of closeness exceeds a user- variable threshold, or alternatively individual messages can be sent for each persona. Implementation using a single message on the network is more resource and bandwidth efficient, however multiple notifications enable the system to be more scalable and responsive.

The content manager 44 receives messages that encapsulate content from the communication device 50, then updates contextual information, or resources 62, characterising the content of those messages in the context store 40. The contextual information typically includes location information 64, topic information 66 and timestamp information 68. It will be appreciated that a wide variety of other types of contextual information characterising the message content may also be stored, such as message originator 70, message recipient 72 and resource type 74.

The content manager 44 may also receive requests from the communication device 50 to retrieve content based on a search context, which may be user-defined or may be based upon the contextual information characterising a persona . The content manager 44 queries the tap engine 34 to determine the content that best matches the given search context.

The contact manger 36 provides two services, called "resource list servers", that receives requests from the communication device 50 for lists of personas in either the private space (contacts) or the in the public space (crowd). The contact manager 36 queries the tap engine 34 to determine the personas that match the context provided by the communication device user.

The TAP engine 34 acts to retrieve contextual information from the context store 40 and create an index 70 via the search engine 42. The TAP engine 34 also provides an interface to submit a query for content or contacts that most closely match a particular context for a persona. The TAP engine 34 composes this into a sequence of queries to a search index 72. The TAP

engine 34 also acts to collate the results from potentially multiple searches, and may keep a cache of results for improved efficiency.

The search engine 42 provides a means of creating an index of information about of entities that structures the information in a form that allows the search function 64 to efficiently and effectively retrieve entities that match a search criteria.

Figure 3 shows a domain model of entities involved in the communication system 10. It can be seen from the domain model 80 that a user 82 of the communications device 50 may have one or a number of personas 84. Each persona 84 is an identity that the user 82 chooses to portray to others in the communications network. A user may have different personas, for example, for work contacts, personal contacts and for family members. Each persona 84 is categorised by contextual information. The contextual information shown in Figure 3 includes location data 82, activity data 88, interest data 90 and descriptor classifications 92. The location data 82 categorises the spatial location that a persona 84 is to be portrayed to be located, this may or may not be the actual location of the user communication device 50. The location data 86 may be characterised by a taxonomy of location types 94 so that various levels of accuracy can be specified for a geographical location. The location data associated with each persona can be used to determine the spatial proximity between personas.

The descriptors 92 are "tags" that describe what a persona is like. Exemplary tags may include the following: eyes. blue, height.tall, gender.male, relaxed, energetic, etc. These "tags" are organised in a folksonomy (that is a taxonomy without a controlled vocabulary) forming part of a global descriptor scheme 96. The use of a folksonomy allows semantic meaning between tags to evolve with the evolution and use of the communication system 10. The interests 90 are also "tags" that convey what a persona finds interesting or is interested in. The following are examples of such interest tags: gender.female, clubbing, relationship, etc. The interest tags form part of a global interest scheme 98. The activity 88 relates to a current activity being undertaken by a persona. The activity 88 is selected from a global activity

scheme 100 by way of example, persona activity may be: working, meeting, lunch, relaxing, partying, etc.

Each persona may also maintain associations to a contact entity 102 that maintains a link to other persona that are "contacts" of the persona 84. Contacts 102 of the persona 84 may include other personas with which the persona 84 has already communicated, or alternately personas of users that are already known to user 82 such as work colleagues or family members.

The context store 40 maintains a communication audit 104 of communication instances of the persona 84 and personas identified in the contact entity 102 as being contacts of the persona 84. The communication audit is used to determine communicative affinity between personas in an exemplary embodiment of the invention.

Messages 106 exchanged between personas in the communication system 10 are made up of resources 108 that encapsulate content. These bits of content may have several characteristics associated with them. For example, each resource 108 exchanged at a communication instance may include: resource type 110 - this is the type of media the content is, such as an image, movie, audio file or text file; topic 112 - topic tags describe what the piece of content relates too; location 86 - this is the geographic location where the content was captured; and time stamp 114 - this identifies when content was captured and includes the time zone of the time data. These characteristics are used by the content manger 44 when providing a content discovery service to determine closely matching content to a particular user generated query. Figure 4 shows an example of the relationships that a formed between instances of contacts and persona identities. In this figure it can be seen that user A, referenced 130, has a single persona A_X, referenced 132. User A knows user B, referenced 134, by two different personas, namely persona B_Y, referenced 136 and a persona B_Z, referenced 138. User A's persona A_X, referenced 132, has two contact objects, namely a first contact object B_Y, referenced 140, and a second contact object B_X, referenced 142. Both contact objects 140 and 142 are mirrors of user B's two personas B_Y, referenced 136, and B_Z, referenced 138. This allows user A to "annote" the

contacts of user A with his or her own details, such as a nickname, personal thumbnail image, or ring tone. Similarly, each of user B's two different persona, B_Y, referenced 136, and B Z, referenced 138, have a same contact, namely contact object A_X that mirrors user A's persona A_X, referenced 132.

The persona 84 and contextual information elements 86 to 114 shown in Figure 3 are maintained in the context store 40 of the presence server 16.

In addition to maintaining a list of personas that are contacts of another persona (namely those personas with which communication has already occurred) the communication system 10 also enables communication with personas forming part of a "crowd" with which no contact relationship has been established. In the context of the present invention, a crowd is a group of personas that elected to make their presence information available to other persons. Communication is possible if the user associated with a first persona elects to make available the persona's contextual information such as the persona's descriptors, interests and location data, to other personas. Figure 5 conceptually illustrates a first persona 170 having contextual information 172 in the form of location data 174, descriptors 176 and interests 178. From the location data 174, a geographic zone or area 180 for that persona can be determined which defines the possible locations that the persona is portrayed to be located. When this information is combined with user defined threshold value a expanded a geographic zone or area 182 called an Area of Interest can be determined.

Figure 5 shows the existence of three other personas referenced 184, 186 and 188. A persona 184 has a geographical area or zone of location 190 and an area of interest 192. Similarly, the persona 186 has a geographical area of location 194 and an area of interest 196, whereas the persona 188 has a geographical area of location of 198 and an area of interest 200. By comparing the spatial information associated with each persona, and determining overlapping areas of interest or location between the personas

170, 184, 186 and 188, the TAP engine 34 in the presence server 16 is able to determine those personas having a certain degree of proximity with the persona 170. Controls are provided to the user of the communications device

50 to effectively increase or decrease the area of location 180 and area of interest 182 for the persona 170 in order to increase or decrease the number of personas determined to be closest to the contextual information of the persona 170. These same user controls are also used to effectively increase or decrease the number of contacts (personas with which the persona 170 has establish a relationship with) determined to have a communicative affinity with the persona.

Figure 6 is a flow chart showing the operation of the presence-based communication system 10 in identifying those personas and contacts that have a degree of affinity with a first persona. At step 220, a user of the communication device 50 sets a user variable threshold for use by the presence server in determining whether many personas associated with other users will be determined as having an affinity with a persona associated with the user of the communication device 50, or whether only a few personas and contacts will be determined to have that affinity.

In this example, the user variable threshold has a normalised value which can fall in one of two ranges, namely a first range from 0 to 1 in which an open presence status can only be notified to personas that are contacts of the first persona. There also exists a second range of values for the user variable threshold in which an open presence status can be notified to personas that are not contacts of the first persona. Accordingly, at step 222, the tap engine 34 determines whether the user variable threshold set by the user of the communication device 50 falls within the first range of values. If this is the case, then all contacts maintained in the contact entity 102 as being associated with the persona 84 are then examined in turn at steps 224 and 226. For each contact 102, a determination is made as to the communicative affinity of the persona associated with that contact 102 and the persona 84, at step 228. In this example communicative affinity is determined by determining the frequency of communication instances between the first persona 84 and the contact 102 according to the communication audit 104. The communicative affinity between the two personas is determined at step 228. If this affinity exceeds the user variable threshold, then the presence status of persona 84 is set to open for that contact at step 232. The presence server 16

notifies the communication device 50 of the setting of the presence status for that contact to open, which then causes display of a persona corresponding to that contact at the communication device 50, at step 234.

If the communicative affinity between the two personas is determined to be below the user variable threshold, then at step 236, the presence status of the persona 84 to be notified to the contact is set to a closed state. The closed state of the presence status is then communicated to the user communication device 50 by the presence server 16, and at step 238 an icon of the persona corresponding to that contact is not or is no longer displayed. If it is determined at step 240 that the user variable threshold has been set to a value falling within the second range of values in which an open presence status can be notified to personas that are not contacts of the persona 84, then all personas maintained in the context store 40 are assessed at steps 242 and 244 to determine the degree of closeness between the contextual information characterising the persona 84 and the contextual information characterising other personas maintained in the context store 40. In this example, the degree of closeness between contextual information is determined by examining the semantic affinity of the contextual information of the two personas, as well as the spatial proximity of the two personas. At step 246, the location data 86 for the persona 84 is compared to the corresponding location data for each persona maintained in the context store. A determination is made as to whether there is overlap between the geographical area of location and the geographical area of interest for both personas, and then a proximity score is calculated by comparing the declared area of location of the two personas. Similarly, at step 248, determination is made as to the semantic affinity between the two personas by comparing the descriptor data 92 and interest data 90. At step 250, the results of assessments made at steps 246 and 248 are merged and a degree of closeness between the contextual information of the various personas is made at step 252.

If it is determined at step 252 that the degree of closeness between the contextual information exceeds the user variable threshold, then at step 254, the presence status of the persona 84 to be notified to the "crowd" persona in

question is sent to open and the persona details are added to the crowd resource list in the contact manager 36. A notification is then sent to the communication device 50 and icon corresponding to that persona displayed at step 256 on a display of the communication device 50. If a degree of closeness below the user variable threshold is determined at step 252 however, then the present status of the persona 84 to be notified to the "crowd" persona in question is set to a closed state at step 258, the persona details are removed from the crowd resource list in the contact manager 36 if present and, at step 260, an icon corresponding to that persona is either not displayed or removed from the display of the user communication device 50 associated with the persona 84.

As explained previously, the presence-based communication system communication system 10 provides presence information to the presence server 16. The user variable threshold set by a user of the communication device 50, and communicated to the presence server 16, allows the presentity user to specify a single value that means that the presentity will share different presence information with different watchers based on the closeness of the contextual information of personas associated with the presentity and watchers of that presentity. Figure 7 is an illustration of the information displayed to a user of the communication device 50 on a display. In this example, a first display 280 corresponding to a user A and a second display 282 corresponding to a user Z is shown. The user A client is a presentity for which the user reduces the user variable threshold for determining the closeness between the contextual information of personas, whereas the user Z client is a watcher which receives the presence information. It can be seen in Figure 7 that with the user threshold set to a central value icons corresponding to user A and user Z personas appear on each other's display. However, as seen in Figure 8, when the user variable threshold is reduced to a lower value 286, the persona associated with user Z is determined to no longer have the required degree of affinity to the persona of user A. Accordingly, the icon corresponding to the persona of user Z is removed from the display 280 of the user A client. The icon corresponding to the persona of user A is correspondingly made to

appear "transparent" on the display 282 of the user Z client. Initially both users A and Z are sharing presence information with each other. When user A reduces the user variable threshold, the user A client sets the presence status shown to user Z to a closed state. The user Z client then receives notification that user A has set their presence status to closed, and updates the user Z display to indicate that even though it is still watching user A, user A is not currently indicating a willingness to receive communications from user Z.

If the presence status of a persona is set to a closed state, a persona may still receive incoming communications asynchronously. In other words, direct communication is not possible, but incoming communications are directed to a voicemail or like service so that the communications can be subsequently retrieved by the persona.

Figure 9 illustrates the effect of varying the user variable threshold at the communication device 50 on the number of contacts and personas determined to have a suitable degree of closeness for communication to be possible. The user threshold is a linear representation of a multiple non-linear scales of several characteristics used to control the presence of a persona, and hence the icon displayed to a user of the communication device 50, and hence personas from which communications will be accepted. Figure 9 illustrates how the number of available personas and contacts increase as the user variable threshold decreases. From this figure it can be seen that initially, when the threshold is set to a maximum value, no contacts or personas are determined to have the required degree of affinity to presentity persona. As the threshold is decreased over a first range of values 300, an increasing number of contacts having contextual information that is closest to the contextual information of the presentity persona are identified by the TAP engine 34. The contacts can be ordered so that contacts having a greater degree of affinity with the presentity persona are displayed to the user of the communication device in question before those contacts having a lesser degree of affinity. As the user variable threshold is further decreased over a second range of values, "crowd" personas having a close degree of affinity with a presentity persona are also notified of an open presence status indicating a willingness to receive communications from those in the "crowd".

Again, the "crowd" personas having a greater degree of affinity with the presentity persona may be displayed at a user communication device before those in the "crowd" having a lesser degree of affinity.

As described above in relation to Figure 6, the degree of closeness between contextual information characterising a presentity persona with one or more watcher personas may be determined by combining two or more measures of affinity between the presentity persona and watcher persona. In the example described in relation to Figure 6, values of semantic affinity and spatial proximity are combined in order to determine the relative affinity of the two personas. In order to combine these two measurements, the TAP engine 34 firstly divides each dimension into sub-sets corresponding to discrete levels of the user variable threshold, and then determines an intersection of the subsets for each level. The rules for mapping the threshold level to an intersection of sub-sets are defined for each persona, although in any implementation the rules may be shared or set to a "reasonable" default level. In Figure 10, the table 320 is shown in which spatial proximity and semantic affinity of personas is mapped for threshold levels.

Figure 11 shows a plot 330 illustrating the determination of communicative affinity between a persona and a contact. In this example, the plot shows the telephone number of a contact together with the number of communication instances in the last 30 days. For example, the telephone number 61413742401 has been responsible for 27 communications with the persona over the last 30 days, whereas the telephone number 061419038779 has been responsible for only one communication over the past 30 days. The plot is a stack graph where the height corresponding to each telephone number represents the number of communication instances in the last 30 days with the presentity persona. The scale on the left has been normalised to add up to 100%, and horizontal marks spaced apart by 20% are indicated corresponding to discrete threshold values able to be selected by a user. Table 1 shows the contacts with which the presentity user is willing to communicate (in other words, the contacts that are notified of an open presence status of the presentity persona) depending upon the threshold level selected by the user.

Table 1

It can be seen that when the threshold is initially set to a maximum level, no contacts are communicated at the open presence status of the presentity persona. As the user threshold is decreased (represented in Table 1 by an increasing TAP-level or willingness to communicate) fewer communication instances are required in order for there to be the necessary communicative affinity between the presentity persona and the contact and therefore increasing numbers of contacts are notified of the open presence status of the first persona and are therefore able to directly communicate with that persona.

The above method of determining communicative affinity is relatively simple. More sophisticated models for determining communicative affinity may easily be implemented in alternative embodiments of the invention. For example, differences may be considered between incoming and outgoing communications, communicative affinity may be varied according to the time of day, the relative frequency of communications over different time periods or like criteria.

As explained previously, sematic affinity refers to the likelihood that two personas are willing to communicate based upon complimentary interests or characteristics. The semantic affinity of two personas indicates how close two personas are based upon a comparison of their respective contextual information, that is the descriptor data, interest data, location data and other contextual information maintained in the context store 40 for that persona. In one exemplary embodiment of the invention, two sets or schemes of terms are

used to classify personas, namely descriptors that describe the persona or terms that indicate the interests of the persona. The content of messages communicated between personas is classified according to topics describing the content of the message. Content is classified by location, submitter,

W _h U _t ace _r sse _r owner, source and media type to enable content to be identified by various facets.

For example, it may be desirable to find all content from a persona, all content from around a particular geographic location, all content of a particular media type (e.g. all images) or all images from persona X around location Y. These classifications are recorded as "tags" that are organised in a folksonomy. A folksonomy is a taxonomy of terms without a controlled vocabulary. The use of a folksonomy allows semantic meaning between tags to evolve with the evolution and use of the presence-based communication system 10. Since two difference schemes exist to classify a persona's contextual information for personas that are not already contacts (namely descriptions and interests) four different types of comparison are possible. That is, the interests of a first persona can be compared with the interests of a second persona or descriptors of a second persona, whereas the descriptors of the first persona can be compared with the interests of the second persona or the descriptors of the second persona. The TAP engine 34 performs each of these four comparisons, preferably in parallel, and then combines the results with certain boost values (i.e. weightings) to tune the importance of each comparison.

Table 2 shows an example of a matrix of weightings used to combine the interest and descriptor affinity scores.

Interests Descriptors

Interests 0.75 0.50

Descriptors 1.00 0.25

Table 2

The affinity score is determined by the following formula:

SemanticAffinity = Sum(Query([i,j],Boost[l,j]); 1,J=O..1

Descriptor or interest tags maintained in the context store 40 for a particular persona can be weighted to capture different levels of interest across tags. For example, persona A may have interest tags of pets and dogs. Persona B may have interest of pets and cats whereas persona C may have interest tags of pets, dogs and cats. By applying a weighting to the cats tag of persona C, thereby indicating that persona C likes dogs but prefers cats, the TAP engine 34 is able to allocate a higher affinity of persona C to persona B than to persona A. Spatial proximity is a measure of how likely two people will be interested in communicating with someone at a geographical location. Location data maintained in the context store 40 for a persona is used to restrict searches carried out by the TAP engine 34 to only those personas that have intersecting geographical areas of location and areas of interest. Spatial proximity may also be used by the TAP engine 34 to order those personas within intersecting geographical areas in an order to a first persona. The spatial proximity determined by the TAP engine 34 at step 246 in Figure 6, is calculated by considering the physical distance between geographical areas and the level of accuracy of the geographical location reflected in the size of the area. Location may be specified to various degrees of accuracy, for example, by street address, city or country. As explained previously, a persona's messages and resources all contain a location attribute 86 and each location is classified by a taxonomy according to a location type classification 94 (see Figure 3). The presence-based communication system 10 uses a taxonomy to define different levels of accuracy for a location. When comparing locations, the level in the taxonomy is taken into account to determine the rules to map to the user defined threshold. For example, a location may have the following attributes:

1. name and code to uniquely identify a location within a sub-set 2. area of location (bounding region)

3. reference to nearest neighbours (at same level in taxonomy)

4. neighbours bounding region

5. location type.

In the communication system 10, a spatial context of a persona is defined by two difference areas, as shown in Figure 5, namely an area of interest and an area of location. An area of location is an area which bounds where the user of a mobile communication device 50 may be found depending upon the accuracy of the location defined. The area of accuracy is determined by looking up an address in the taxonomy defined by the location type classification 94 to determine the enclosing area of an address in a sub-set.

An area of interest is an area that bounds the area where the user of a mobile communication device 50 interested in. The area of interest is determined by looking up rules depending upon an area of location and the user defined threshold level. Although the areas of location and interest are depicted as being circular in Figure 5, and it is to be appreciated that any suitable geographic shape may constitute areas of interest or location. The TAP engine 34 may apply a spatial filter to determine all personas having areas of location that intersect with an area of interest of a persona querying the presence server 16 for personas having a spatial affinity, and whose area of interest intersects the querying persona's area of location.

A spatial similarity score may be determined by the TAP engine 34 in order to assess the spatial proximity of personas. The spatial similarity score used in an exemplary embodiment of the invention is the inverse normalise value of the furthest distance calculated between the areas of location of the two personas, that is:

FurthestDistance(L1,L2) = CentroidDistance(L1,L2) + Radius(L1) + Radius(L2) Similarity(L1 ,12) = 1 / FurthestDistance(l1 ,12) ^* NormalisationFactor

The normalisation factor is a value used to reduce all scores between 0 and 1 and so scores can be combined with other scores from other dimensions. The normalisation factor would be the maximum value for the furthest distance calculated. In that regard, any of the types of contextual information maintained in the context store 40 for a particular persona may be evaluated for "closeness" to any other type of contextual information of that or any other persona.

The perceived distance between two locations can be influenced by the density of population or activity in the region. For example, because the cities of Adelaide and Melbourne in Australia have relatively low densities they may be considered to be more spatially proximate to each other than the cities of Paris and Nice in France which have higher densities but may be considered to have a lower degree of spatial proximity.

When a user threshold is modified at the communications device 50, it causes the presence status to be modified for other personas. Moreover, the representations of those personas on display of the communication device 50 may alter. When a persona's threshold level changes, the client interface of the communication device 50 updates to show only those contacts or personas to whom an open presence status has been notified. If there are multiple personas, then icons or lists of personas or contacts that are displayed to the user of the communication device 50 are updated to reflect the relative differences between the user defined threshold values selected for each of the personas. Figure 12 is a representation of a user interface 340 showing user variable threshold levels 342, 344 and 346 respectively for a family persona 348 a friends persona 350 and a work persona 352. It can be seen that each of the threshold values 342 to 346 are set to different levels in this figure, the thresholds are set so that the friends persona is more willing to accept communications from other personas and contacts than are the family or work personas. A contact list 354 is shown in which the displayed contacts include a higher proportion of friends than of family or work colleagues. The mix of personas and contacts able to contact a user via each of the three personas is in proportional to the user variable thresholds set for each of the three personas.

The user variable threshold of a persona may be modified by various means. Firstly, each user variable threshold may be directly modified for each persona. Figure 13 shows an exemplary display 360 in which the threshold values 362, 364 and 366 respectively of three persons 368, 370 and 372 can be individually set. However, this display 360 also includes a global threshold setting 374 set to a value referenced 376. This global threshold value may be determined as the average of the persona threshold levels. In examples

shown in Figure 13, the 3 personas with the tap levels are {(Family, 0.4), (Friends,0.6), (Work,0.20}, so the User TAP level is (0.4 + 0.6 + 0.2) / 3 = 0.4.

When the global user threshold 74 is changed, the threshold values for each of the three personas 368, 370 and 372 all change at a rate such that as the global threshold reaches a minimum or maximum value, all persona threshold values will also reach these values.

The threshold values for each persona should also return to the same value whenever the global threshold level is on the same value if the individual values of the personas have not be changed. To achieve this effect, the following equation is used to calculate the new persona threshold level (I) when the user TAP level (k) changes.

/ = /'+δ x (α - /') where

• / is the new persona threshold • /' is the original persona threshold, that is the level when it was last set explicitly and not calculated as a result of the global threshold change

• k is the global threshold level

• k' is the original global threshold level, that is the global threshold level when the persona threshold levels were last set explicitly.

• α is the threshold limit, that is it is maximum threshold (2) if k - k' ≥ 0, else it is the minimum threshold k - k'

• δ = is the change in threshold a - k

The global threshold level will often be the same whenever the user is performing the same activity at the same location. Accordingly, the TAP engine 42 acts to change the activity and/or location data maintained in the context store 40 for a persona according to the user variable threshold level set. The context store 40 maintains a record of the presence states that link a persona's threshold level, location and activity together for each persona. These records are then used by the presence user client as shown in Figure

14. In other words, an activity 400 acts to modify the threshold 402 for a particular persona. Similarly, a location 404 can act to modify that same threshold level 402. Moreover, a change in the location 404 can act to modify the activity 400 and vice versa.

TABLE 3

Table 3 shows an example by considering changes to a user's presence information, which updates family, friends and work personas.

As mentioned previously, the content manager 44 receives messages that encapsulate content from the communication device 50, then updates contextual information (i.e. resources 62) characterising the message content maintained in the context store 40. This enables the presence server 16 to be carry out "content discovery" in which relevant content is identified and then notified to a persona.

In one embodiment, the content manager 44 is configured to receive requests from a first persona associated with the communication device 50 to retrieve content based on a search context. The content manager 44 queries the TAP engine 34 to determine the content that best matches that search context. Relevant message content can be identified at the presence server 16 by determining a degree of closeness between a content query submitted by a first persona and the contextual information characterising the message content. Notification of the message content can then be provided to the first

persona by the presence server 16 if the degree of closeness exceeds a user- variable threshold.

In another embodiment, the content manager 44 is configured to receive requests from a first persona associated with the communication device 50 to retrieve content based on contextual information characterising the requesting persona. Relevant message content is identified at the presence server 16 by determining a degree of closeness between the contextual information characterising the first persona and the contextual information characterising the message content. Notification of the message content is then provided by the presence server 16 to the first persona if the degree of closeness exceeds a user-variable threshold.

The operation of this content discovery function is illustrated in Figure

15. In this figure, the user-variable threshold indicative of a desired level of engagement or interaction with the communication system 10 is selected at step 420. Each message for which contextual information is stored in the context store 40 is then analysed at step 422 by the TAP engine 34.

The TAP engine 34 then determines a degree of closeness between the contextual information characterising the message content and either (a) the contextual information characterising the first persona or (b) a content query submitted by a first persona. In this example, at step 424, the TAP engine determines the spatial proximity of the first persona and the messages from the location data 64 respectively maintained in the context store 40 for each each message and either (a) the location data 54 maintained in the context store 40 for each persona or (b) location data forming part of the user- submitted content query.

Similarly, at step 426, the TAP engine determines a semantic affinity between the contextual information 64 to 74 characterising the message content and either (a) the contextual information 54 to 60 characterising the first persona or (b) a contextual information - such as key words - submitted by the first persona as part of a content query.

At step 428, the results of the spatial proximity and semantic affinity determinations carried out in steps 424 and 426 are merged. If the degree of

closeness between the contextual information (i.e. spatial and semantic) characterising the message content and the content query or persona contextual information is determined, at step 430, to exceed the user variable threshold then the message content is added by the presence server 16 to a list of discoverable content for the first persona at step 432. If the degree of closeness does not exceed the threshold, then the message content is not added to the list of discoverable content at step 434. Once all messages have been analysed in this way at step 436, then the first persona is notified of the discoverable content at step 438. A restriction may be placed on the messages that are analysed by the presence server 16 in carrying out the content discovery service. For example, only contextual information characterising the message content of messages that are exchanged between the first persona and contacts of that first persona may be analysed. Alternatively, only contextual information characterising the message content of messages that have originated from personas determined to have a requisite degree of closeness with a first persona (as described in relation to Figure 6) may be analysed.

The presence-based communication system 10 may be implemented by using hardware, software or a combination thereof and may be implemented in one or more computer systems or processing systems. In particular, the functionality of the communication device 50, as well as the presence server 16, may be provided by one or more computer systems or processing systems capable of carrying out the above described functionality.

An exemplary computer system 520 for implementing the presence server 16 is shown in Figure 16 It is to be appreciated that similar functional blocks to those shown in Figure 16 may also be used as part of a processing system forming part of the communication device 50. The computer system

520 includes one or more processors such as the processor 522. The processor 522 is connected to a communications infrastructure 524. The computer system 520 may include a display interface 526 that forwards graphics, text and other data from the communications infrastructure 524 for supply to a display unit 528. The computer system 520 may also include a main memory 530, preferably random access memory, and may also include a

secondary memory 532. The secondary memory 532 may include, for example, a hard disc drive, magnetic tape drive, optical disc drive, etc. A removable storage drive 534 reads from and/or writes to a removable storage unit 536 in a well known manner. The removable storage unit 536 represents a floppy disc, magnetic tape, optical disc, etc.

As will be appreciated, the removable storage unit includes a computer usable storage medium having stored therein computer software in a form of a series of instructions to cause the processor 522 to carry out desired functionality. In alternative embodiments, the secondary memory 532 may include other similar means for allowing computer programs or instructions to be loaded into the computer system 520. Such means may include, for example, a removable storage unit 538 and associated interface 540.

The computer system 520 may also include a communications interface 542. The communications interface 542 allows software and data to be transferred between the computer system 520 and external devices. Examples of the communication interface 542 may include a modem, network interface, communications port, a PCMIA slot and card, etc. Software and data transferred via the communications interface 542 are in the form of signals which may be electromagnetic, electronic, optical or other signals capable of being received by the communications interface 542. The signals are provided to communications interface 542 via a communications path 544. Such as a wire or cable, fibre optics, phone link, cellular phone link, radio frequency or other communications channels.

Although in the above described embodiments the invention is implemented primarily using computer software, in other embodiments the invention may be implemented primarily in hardware, using for example, hardware components such as Application Specific Integrated Circuits

(ASICs). Implementation of a hardware state machine so as to perform the functions herein described will be apparent to persons skilled in the relevant art. In other embodiments, the invention may be implemented using a combination of both hardware and software.

While the invention has been described in conjunction with a limited number of embodiments, it will be appreciated by those skilled in the art that

many alternatives, modifications and variations are possible in light of the foregoing description. Accordingly, the present invention is intended to embrace all such alternatives, modifications and variations as may fall within the spirit and scope of the invention as disclosed.