WO2006038036A1

WO2006038036A1 - Processing electronic communications

Info

Publication number: WO2006038036A1
Application number: PCT/GB2005/003891
Authority: WO
Inventors: Alastair Duncan Hadfield Crawford; Dominic Michael Blackburn; Alex Ristic; Stefan Salzbrunn
Original assignee: I-Cd Publishing (Uk) Limited
Priority date: 2004-10-08
Filing date: 2005-10-07
Publication date: 2006-04-13
Also published as: GB0422441D0

Abstract

A method of processing electronic communications using a communication analyser associated with a communication agent, said method comprising: analysing one or more electronic communications transmitted from a first communication agent used by a first user to a second communication agent used by a second user, to derive relationship data, said relationship data being indicative of one or more characteristics of a relationship between the first user and the second user; and transmitting first shared relationship data derived from said analysis to a store of shared relationship data such that a third party has access to said first shared relationship data or data derived therefrom.

Description

Processing Electronic Communications

Field of the Invention

The present invention relates to a method of processing electronic communications, in particular but not exclusively to processing electronic mail messages. The present invention further relates to computer software and apparatus adapted to carry out the method.

Background of the Invention The use of computer networks such as the Internet is rapidly growing. A major use of these networks is the exchange of electronic communications between users of the network. Such users may for example be individuals or companies. With the increase in use of these networks, the number of users transmitting electronic communications between each other is also increasing. Examples of such electronic communications include e-mail messages and

Instant Messaging (IM) services which are transmitted and received using communication agents.

Many users of these computer networks often receive e-mail messages from users who are unknown to them. Often these messages transmitted by an unknown user are unwanted by the recipient. Such unwanted e-mail messages are referred to as 'spam' or junk e-mail and are often discarded or left unread by the recipient.

With a large number of users of a computer network, it is useful for a user to know an identity and contact details of another user of the network, especially if the other user sends an electronic communication to the user.

Additionally, contact details of a user may occasionally change. It is useful for a user of the network to be informed of changes to a different user's contact details.

Systems are known which allow a user of a computer network, for example the Internet, to identify characteristics of different users of the network. One such system is provided by Plaxo Inc. which allows a user of the Plaxo system to request updated contact details of a contact in an address book of their e-mail messaging application. The user needs to know the identity of the contact in order to request up-to-date contact details for them. Once up-to- date contact details are received, the user's address book is updated with these details. If the contact is also a user of the Plaxo system, the user's address book will be automatically updated if the contact's details subsequently change.

Another known system is provided by Linkedln™ which allows a user to enter their own personal contact details into the system. In addition the user invites other users to enter their own personal contact details. Upon receipt of these personal details, the Linkedln™ system forms links between the different users. The system builds a personalised network of users for each user of the system. A user can search their personalised network to identify users having a certain set of criteria. International patent application WO2004/030296 Al describes a method and devices for prioritising electronic messages. E-mail messages are received and classified using a set of rules. The classification rules include adaptive rules which change in accordance with a user's behaviour concerning previously received e-mails, hi classifying each message, an importance class indication is assigned to each e-mail message. The classification of each e-mail message depends on certain features of the message, such as a subject of the message or key words identified in a message body of the message. Classification of each message also uses information of a position of a recipient and a sender of each e-mail message within an organisational hierarchical structure. The organisational hierarchical structure defines positions of individuals, relative to each other, within a defined organisation. The organisational hierarchical structure, including individuals and links between individuals, is pre-defined by an administrator. For individuals who are not identified in the organisational structure, the administrator is required to manually add the details of the new individual into the organisational structure. Summary of the Invention

It is an object of the present invention to provide an improved method of processing electronic communications. In accordance with one aspect of the present invention, there is provided a method of processing electronic communications using a communication analyser associated with a communication agent, said method comprising: a) analysing one or more electronic communications transmitted from a first communication agent used by a first user to a second communication agent used by a second user, to derive relationship data, said relationship data being indicative of one or more characteristics of a relationship between the first user and the second user; b) transmitting first shared relationship data derived from said analysis to a store of shared relationship data such that a third party has access to said first shared relationship data or data derived therefrom.

Electronic communications, for example e-mail messages, are analysed in order to derive relationship data indicative of a relationship between a first user and a second user. The derived relationship data includes first shared relationship data which is transmitted to the store of shared relationship data. The shared relationship data includes, for example, data of a type of the relationship between the first user and the second user, such as a friend or a business type relationship type, or a strength of the relationship which indicates a level of establishment of the relationship. By allowing a third party to access the store of shared relationship data, details of the relationship between the first user and the second user are obtainable by a third party such as a user who has had no previous knowledge of the relationship. Using this shared relationship data, such a user can influence a personal impression they have of characteristics of an unknown user, such as an identity, a reputation and a trustworthiness. A user of an electronic network can use this personal impression to influence their behaviour towards the formerly unknown user. Without having this impression of an unknown user, the user may behave in an inappropriate manner towards the unknown user. Additionally, if the third party is alternatively an application provider, the shared relationship data, or the data derived from this shared relationship data, can be used within any application which they may provide.

Note that the third party is any entity, for example a user, who is not the first or second user. The third party may be a service provider who provides as a software application which a user installs on a client terminal, which analyses communications on the client terminal and which transmits the first shared relationship data, or data derived therefrom, to the shared data store, hi such a case the service provider may control access to the relationship data derived from the communications between the first and second user.

Deriving relationship data from subsequently transmitted electronic messages between the first communication agent and the second communication agent allows the store of relationship data to be dynamically updated with relationship data which reflects a change in the relationship between the first user and the second user, hi this way, the shared relationship data is indicative of a current state of the relationship between the first user and the second user. A third party or a user accessing the store of shared relationship data is therefore informed of the current state of the relationship. m a preferred embodiment of the present invention, the method comprises providing a local database associated with a communication agent, the local database storing local relationship data.

The derived relationship data is stored as local relationship data in the local database. The local database stores data indicative of relationships between a local user and remote users. By storing this data locally, the local relationship data is made readily available to locally installed computer software components of the present invention, for example a communication classifier. Furthermore, with at least some of the local relationship data being specific to relationships of the local user, relationship data derived from subsequently transmitted or received electronic communications of the local user can be used to readily update the local relationship data to ensure that the local relationship data is indicative of a current state of relationships of the local user. In a preferred embodiment of the present invention, the method comprises updating the shared relationship data in response to updating of the local relationship data.

Thus, when the local relationship data is updated with further derived relationship data, the shared relationship data is updated also. The shared relationship data is therefore kept up-to-date with changes in relationships between users of the present invention. Consequently the third party can readily access up-to-date data of relationships between any users of the method of the present invention. In a preferred embodiment of the present invention, the method comprises querying the store for shared relationship data, and storing local relationship data derived from the shared relationship data in the local database.

If relationship data is derived, locally, by the communication analyser for a particular remote user and the local database does not include data indicative of the relationship between the local and the particular remote user, the store of shared relationship data is queried and relationship data indicative of the unknown relationship is obtained and stored in the local database. As a result, the local database can be updated with previously unknown relationship data. Additionally, data indicative of a relationship between two users can be transmitted to the store of shared relationship data from local databases of a plurality of different users. Consequently, the shared relationship data of the relationship is relatively more reliable as it is comprises an accumulation of relationship data received from a plurality of different sources, each different source helping to build a quality and reliability of the relationship data. In a preferred embodiment of the present invention, the method comprises updating local relationship data in a local database in response to updating of the shared relationship data.

When the store of shared relationship data is updated with new relationship data, a local database of a local user having out-of-date relationship data for a particular relationship is updated automatically with the new relationship data. As a result the relationship data stored in the local database is kept up-to-date and the local relationship data is relatively reliable and accurate.

In accordance with a further aspect of the present invention, there is provided computer software arranged to analyse e-mail messages, including one or more e-mail messages transmitted from a first client terminal used by a first user to a second client terminal used by a second user, to derive relationship data which is indicative of a relationship between the first user and the second user, wherein said computer software is arranged to transmit shared relationship data derived from said analysis to a store of shared relationship data such that a third party has access to said shared relationship data or data derived therefrom.

In accordance with a further aspect of the present invention, there is provided a method of processing electronic communications using a communication analyser associated with a communication agent, said method comprising analysing an electronic communication transmitted from a first communication agent used by a first user to a second communication agent used by a second user, said electronic communication including a message header containing one or more message transmission parameters, and a message body containing text, wherein said analysis includes parsing a plurality of parts of said text and rating each part using a plurality of rating rules, selecting at least one of said parts with a rating indicative of a high likelihood of contact details of said first user being found in said selected part, and deriving one or more contact details from said selected part.

In a preferred embodiment of the present invention, the rating rules are adapted to tend to identify a signature part of the electronic communication.

It is useful for a recipient of an electronic communication, for example, an e-mail message, to know contact details of a user transmitting an e-mail message. This allows the recipient user to identify the user sending the message and also provides the recipient user with information on how to contact the sender. With knowledge of the identity of the sender, the recipient user can influence a personal impression they have of the sender. Text in a message body of e-mail messages often includes signature text which is indicative of contact details of the user sending the message. By parsing and rating the text of an e-mail message, a signature part of the e-mail message can be identified. Contact details of the sender of the message are derived from this signature part and made available to the recipient of the message in an efficient manner. This avoids the recipient user needing to perform awkward text and data manipulation procedures in order to obtain contact details of a sender.

Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings.

Brief Description of the Drawings

Figure 1 shows schematically an overview of a system arranged to perform parts of the method of the present invention.

Figure 2 shows schematically components of user software arranged to perform parts of the method of the present invention.

Figure 3 shows schematically components of software arranged to process data for a graph in accordance with an embodiment of the present invention.

Figure 4 shows a flow diagram illustrating steps of an initialisation process in accordance with an embodiment of the present invention.

Figure 5 shows a flow diagram illustrating steps of analysing an electronic communication in accordance with an embodiment of the present invention.

Figure 6 shows a flow diagram illustrating steps of analysing an electronic communication in accordance with an embodiment of the present invention.

Figure 7 shows a flow diagram illustrating steps of processing an electronic communication in accordance with an embodiment of the present invention. Figure 8 shows schematically data records of derived contact data in accordance with an embodiment of the present invention.

Figure 9 shows schematically data records of derived relationship data in accordance with an embodiment of the present invention. Figure 10 shows a flow diagram illustrating steps of classifying an electronic communication in accordance with an embodiment of the present invention.

Figure 11 shows schematically an exemplary trusted network in accordance with an embodiment of the present invention. Figure 12 shows schematically a peer to peer network in accordance with an embodiment of the present invention.

Detailed Description of the Invention

Apparatus Overview

Apparatus arranged to perform aspects of the present invention will further be described, in order to provide an overview of the features of the present invention.

Figure 1 shows a schematic overview of a system for performing parts of the method of the present invention, hi accordance with one embodiment of the present invention the system comprises a client terminal 2 which includes a central processing unit (CPU) 4, memory 6, a data storage device such as a hard disc drive (HDD) 8 and a I/O device 10 which facilitates interconnection of the client terminal with screen including a display element 12, a first data input device, for example a keyboard 14 and a second data input device, for example a pointing device such as a mouse 16.

Operating system software 18 is stored on the hard disc drive 8, which controls, in a known manner, low level operation of the computer terminal 2.

Further software 20 is also stored on the hard disc drive 8, which controls, in a known manner, outputs to a user via associated devices and output data stored on the hard disc drive. The associated devices include the display 12 as an element of the screen, the pointing device 16 and the keyboard 14, which receive input from, and output information to, the user via further I/O devices (not shown).

Additionally stored on the hard disc drive 8 is communication application software 22, communication processing software 24 and client software 26, each of which will be explained later in further detail.

The system further comprises a server terminal 28 which includes a central processing unit (CPU) 30, memory 32, a data storage device such as a hard disc drive (HDD) 34 and a I/O device 36 which facilitates interconnection of the server terminal 28, via an I/O device, with client terminals, including the client terminal 2 and a further client terminal which in this embodiment is a so- called 'smart' mobile telephone 38.

Server operating system software 40 is stored on the hard disc drive 34, which controls, in a known manner, low level operation of the server terminal 28. Further software 42 is also stored on the hard disc drive 34, which controls further operations and functions of the server terminal 28.

Additionally stored on the server hard disc drive 28 is graph processing software 44 and server software 46, each of which will be explained later in further detail. An Internet browser terminal 48 and a further server terminal 50 can also interconnect with the server terminal 28 across a communication network, for example the Internet, via an I/O device. A Telnet terminal 52 can also directly interconnect with the server terminal 28 via an I/O device.

Additionally, at least part of the computer software of the present invention is stored by a provided data carrier.

Client-Side Software

Having provided an overview of apparatus of the present invention, features of client-side software will now be described. Figure 2 shows, schematically, components of the communication application software 22 and the communication processing software 24 of the client terminal 2. The communication application software 22 includes a communication agent 54 which is arranged to receive data or to transmit data relating to an electronic communication. In embodiments described in the following description the electronic communication is an electronic mail (e- mail) message, a first communication agent associated with a first user which is arranged to transmit an e-mail message and the communication agent is a second communication agent 54 associated with a second user which is arranged to receive an e-mail message transmitted by the first communication agent. The communication application software 22 further includes a contact data database 56 connected to the second communication agent 54 and a communication data database 58 connected to the second communication agent 54. The communication application software has an Application Programming Interface (API) 60 which allows the communication processing software 24 to connect via a link 62 with the communication application software 22. The communication processing software 24 includes a communication analyser 64 which functions in accordance with a set of analysis rules 66 and which uses a signature extractor 68 which functions in accordance with a set of signature data rating rules 70. The communication processing software 24 further includes a communication classifier 72 which functions in accordance with stored classification rules 74.

The communication classifier 72 uses a filter 76 which in this embodiment is used to filter unwanted e-mail messages. Such unwanted e-mail messages may be referred to as 'spam'. The spam filter 76 functions in accordance with stored filter settings 78. The communication classifier 64, the communication analyser 72, the data synchronisation tool 80 and the contact data updater 84 each access a provided local database which is associated with a communication agent used by the user. The provided local database stores local relationship data and local contact data. In this example the local database 88 is associated with the second communication agent 54. The local database 88 stores local relationship data 90 and local contact data 92 which will be described in further detail later. Server-Side Software

Having described features of the client-side software, features of server- side software will now be described. Referring to Figure 3, components of the graph processing software 44 and the server software 46 are shown schematically.

The server software 46 includes a server agent 94 and an API 96.

The graph processing software 44 includes a communication graph agent

100 which accesses a permissions database 102, a registration database 104, write request queue data 106, a request execution history database 108, a request history database 110, graph XML data 112, a contact data store 114 and a graph relationship data store 116.

The graph processing software 44 also includes a graph representation agent 118 which accesses the contact data store 114, the graph relationship data store 116 and graph update data 120 and graph representation data 122.

A graph management system comprises the communication graph agent 100, the contact data store 114, the graph relationship data store 116 and the graph representation agent 118.

The graph processing software has an API 124 which allows the server software 46 to communicate via a link 126 with the graph processing software 44. The Telnet terminal 52 connects 128 with the graph processing software using the API 124.

The relationship data and contact data collected from all client-side users can be used for a variety of different purposes. The API 124 is made available to allow other applications and systems to have access to the data. The API 124 allows a third party application to perform searches on the graph management system, including searches on the contact data stored in the contact data store 114 and searches on relationship data stored in the graph relationship data store 116. The API 124 allows the graph management system and the storage mechanisms as well as algorithms and decision matrixes stored in the application to be used by external providers and partners. This allows third- party applications to integrate into a network of identities, described later, and store/retrieve their data as well as shared data from the network.

Communication between the Client-Side Software and Server-Side Software

A communication between the client-side software and the server-side software will now be described, in accordance with embodiments of the present invention.

The communication processing software 24 and the graph processing software 44 are arranged to cooperate so as to perform a method of processing electronic communications, in this example e-mail messages, in accordance with the present invention.

The communication processing software 24 also includes a data synchronisation tool 80, which functions according to synchronisation rules 82 and a contact data updater 84 which functions using update settings 86.

The data synchronisation tool 80 connects with the communication processing software 24 on a client terminal or with a server, to the graph processing software 44. The data synchronisation tool 80 is arranged to upload data from a client terminal, for example the second client terminal 2, to the graph processing software 44 on the server terminal 28 and to download data from the graph processing software 44 on the server terminal 28 to a client terminal, for example the second client terminal 2.

The client software 26 of the client terminal 2 connect, via a link 98, with the server software 46. The server agent 94 manages this connection between the server software 46 and the client software 22. In preferred embodiments the connection uses HTTP protocol.

Client-Side Software Functionality

Aspects of the functionality of the client-side software will now be described, with reference to Figure 4 which shows the steps involved in a typical initialisation process of the communication processing software 24 on the terminal 2.

In order to perform the method of embodiments of the invention on the client terminal 2, the communication processing software 24 firstly performs an initialisation process in which it associates itself (step 132) with the second communication agent 54 which in this embodiment is, for example, Microsoft Outlook™. The association involves connecting with Outlook 54 using the API 60 and may additionally involve editing entries of a registry file which determines functionality of software of the client terminal 2. The communication processing software 24 accesses (step 134) the communication data database 58 of Outlook 54 which stores previous e-mail messages received thereby and which have been transmitted by another, different, communication agent (not shown) used by a different user. In this example the other communication agent is also embodied with Microsoft Outlook™ software. Each previously stored e-mail message has been received into, or transmitted out from, the second communication agent 54 as data 59. The communication data database 58 also stores copies of previous e-mail messages which have been transmitted by the second communication agent 54 to a different communication agent (not shown) used by a different user. The communication analyser associated with the second communication agent 54 is a second communication analyser 64 which analyses (step 136) one or more e-mail messages and determines (step 138) whether each e-mail message has been transmitted by the second communication agent 54 or has been received by the second communication agent 54. The analysis of communications in and out of the client terminal 2 allows a profile of communication between, in this example, the second user and their contacts to be created.

This initialisation process will now be described in more detail. If the analyser identifies that the e-mail message has been received by the agent 54 (rather than sent), the analyser 64 derives (step 140) relationship data from the received e-mail message. The derived relationship data is indicative of one or more characteristics of a relationship between the sender and the user. Further details of the nature of this relationship data are provided later under 'Relationship Data'. Additionally, the analyser 64 derives 142 contact data from the received e-mail message. The derived contact data includes contact details of a user, in this example the sender of the message. Further details of the contact data is provided later under 'Contact Data'. The derived relationship data from the received e-mail message is stored (step 144) locally as local relationship data 90 in the local database 88, and the derived contact data from the e-mail message is stored (step 146) as local contact data 92 in the local database 88.

At step 148 the analyser 64 determines whether the e-mail message having just been analysed is the last of a plurality of e-mail messages previously stored in the communication data database 58. If this is the case the initialisation process is complete. If the e-mail message is not the last of the plurality, a further e-mail message is analysed (step 136), and the process repreated until all of the plurality have been analysed and for which relationship data and contact data has been derived and stored.

Considering the case where the analyser 64 identifies that a message has been transmitted by the communication agent 54, relationship data, similar to the relationship data derived from the received e-mail message described above, is derived (step 150) and is stored (step 152) as local relationship data in a second local database 88. Once this local relationship data has been derived and stored, it is determined (step 148) whether the analysed transmitted e-mail message is the last of the plurality of transmitted e-mail messages. In this described embodiment the relationship data derived from an e- mail message received by the second communication agent 54 is first local relationship data and relationship data derived from an e-mail message transmitted by the second communication agent 54 is second local relationship data. In a different embodiment, it is alternatively envisaged that relationship data derived, using a communication analyser associated with the first communication agent and in the manner described above, from an e-mail message transmitted by, or received by, the first communication agent is first local relationship data which is stored in a first local database (not shown) associated with the first communication agent. In accordance with another embodiment of the present invention, following the initialisation process described above, e-mail messages can be analysed in response to transmission or receipt thereof. Such analysis methods will now be described, with reference to Figure 5.

Figure 5 shows a method of analysing a further e-mail message which has been transmitted (in real-time) by the second communication agent 54. The second user uses the second communication agent 54 to write text of a message body of an e-mail message and then, having specified an e-mail address for a recipient user of the e-mail message in at least the main transmission address field, uses the second communication agent 54 to transmit (step 204) the e-mail message to the specified e-mail address. It is envisaged that the user may also specify an e-mail address in the carbon copy transmission field address. The transmitted e-mail message is analysed (step 206) by the communication analyser 64 to derive (step 208) relationship data, in a similar manner to that described earlier, from the transmitted e-mail message. Relationship data stored with the local relationship data 90 of the second local database 88 relating to the relationship between the second user and the recipient user of the e-mail message is updated (step 210) with the derived relationship data. If relationship data relating to the relationship between the second user and the recipient user is not stored with the local relationship data 90 of the second local database 88, the communication processing software 24 accesses shared relationship data held in the graph relationship data store 116 and updates the local relationship data 90 of the local database 88. The updated local relationship data of the local database 88 is then updated with the derived relationship data. A further explanation of this updating of the local database is given further below. It is further envisaged that a communication analyser is provided which is associated with the first communication agent (not shown) used by the first user. In a similar manner to analysing the e-mail message transmitted by the second communication agent 54 to derive relationship data and update local relationship data in the second local database, the communication analyser associated with the first communication agent derives relationship data from one or more e-mail messages transmitted by the first communication agent and stores local relationship data stored in a first local database used by the first user with the derived relationship data. If relationship data relating to the relationship between the first and second user is already held in the first local database, the stored local relationship data is updated with the derived local relationship data. If local relationship data relating to the relationship between the first and the second user is not already stored in the first local database, the communication processing software accesses shared relationship data in the graph relationship data store 116.

Figure 6 shows a method of analysing a further e-mail message which has been received in real-time by the second communication agent 54 from a different communication agent, for example the first communication agent (not shown) used by the first user. The second user uses the second communication agent 54 to read text of a message body of the received e-mail message. The further e-mail message is received 212 by the second communication agent 54 and is analysed 214 by the communication analyser 64 to derive 216 relationship data, in a similar manner to that described earlier, from the received e-mail message. Contact data is derived 218 by the analysis of the received e- mail message, in a similar manner to that described earlier. Relationship data stored with the local relationship data 90 of the second local database 88, which relates to the relationship between the first user and the second user of the e- mail message, is updated 220 with the derived relationship data. If relationship data relating to the relationship between the first user and the second user is not stored with the local relationship data 90 of the second local database 88, the communication processing software 24 accesses shared relationship data held in the graph relationship data store 116 and updates the local relationship data 90 of the local database 88. The updated local relationship data of the local database 88 is then updated with the derived relationship data. A further explanation of this updating of the local database is given further below.

Additionally contact data which includes contact details of the first user, which is stored with the local contact data 92 of the second local database 88 is updated 222 with the derived contact data. If contact data of the first user is not stored with the local contact data 92 of the second local database 88, the communication processing software 24 accesses shared contact data held in the contact data store 114 and updates the local contact data 92 of the local database 88. The updated local contact data of the local database 88 is then updated with the derived contact data. A further explanation of this updating of the local database is given further below.

In an alternative envisaged embodiment of the present invention, at least part of the communication processing software including the communication analyser is installed on a server, for example a Microsoft Exchange™ Server having a plurality of e-mail clients configured to cooperate therewith. The software first extracts a list of all the users and their e-mail addresses. Once this information has been gathered the software scans each e-mail on the server, searching through all mailboxes of the users, extracting all the e-mail addresses which e-mail messages have been received from, transmitted directly to or transmitted to using the carbon copy transmission address field. The software builds a database for each user listing all of the e-mail addresses and how many e-mails have been received from and transmitted to, either directly or using the carbon copy field, to that address. The software also stores the date of the first and last contact made and scans the e-mail message for indications of the type of contact, for example, a business contact or a friend. The type of contact is decided by scanning the e-mails transmitted and received from the individual and applying rules to decide the type of contact.

In a further envisaged embodiment of the present invention at least part of the communication processing software including the communication analyser is installed on a so-called 'smart' telephone which may be a mobile telephone. The software analyses logs, stored on the telephone, of telephone calls made by a user and creates a list of all contacts in the telephone and also a list of all telephone numbers that calls have been made to and received from. The software builds a database using all these contacts and stores a frequency of calls to and from that number, a date and time of a first and last telephone call ^' and any classification information that is extracted from a store of contact details held by the telephone.

Contact Data

An example of the derivation of contact data from an e-mail message will now be described in further detail, with reference to Figure 7, which is a flow diagram showing a method of processing an electronic communication to derive contact details

Firstly, an e-mail message is analysed (step 192) in a similar manner to the analysis of e-mail messages described earlier, and involves analysis of the one or more e-mail messages for deriving the relationship data and contact data, as described previously. The same reference numerals are used to indicate that features and processes of the analysis described earlier should be taken to apply here also.

Typically, the e-mail message being analysed includes a message header containing one or more message transmission parameters such as a main transmission address field, a carbon copy transmission address field and a message subject field. The e-mail message also includes a message body containing text. The text of the message body has a plurality of parts of text and each of the plurality of parts is parsed (step 194) and each part is rated (step 196) using a plurality of rating rules. Once each part of the text has been rated (step 196) at least one of the parts of text is selected. The selected part of text has a rating which is indicative of a high likelihood of that part comprising contact details of a user, for example the first user. Accordingly, contact data, including one or more contact details of a user, in this case of the first user, are derived from the selected part of text. In this embodiment the signature extractor 68 extracts and rates selected parts of the text in this manner by parsing (step 194) the e-mail message body text, rating the plurality of parts of text, selecting the part of text and deriving contact details form the selected part. The signature extractor uses the signature data rating rules 70 which are adapted to tend to identify a signature part of the e-mail message.

The signature extractor 68 is an add in component of the communication analyser 64 and is primarily used for further analysis of e-mail messages transmitted and received by a communication agent of a user, in this example the second communication agent 54. It is envisaged that the communication analyser software may alternatively be used to analyse other forms of electronic communication where further contact data is contained within the electronic communication. In one example the signature extractor may be able to extract contact data from, for example, voice based electronic communications such as telephone calls using voice recognition technology.

In at least one embodiment, the signature extractor 68 functions at a same time as the communications analyser 64. When an e-mail message is analysed, the signature extractor 68 analyses the e-mail to identify 198 a signature part of the text, extracts 200 the signature part from the text contact information and derives 202 contact data corresponding to whichever user transmitted the e-mail message.

During parsing of the e-mail message the signature extractor 68 searches for certain, and ignores other, keywords of the text within the e-mail message. In this embodiment it is assumed that each part of the text comprises a line of text. The signature extractor 68 scans each line and rates each line using the rating rules 70. The rating rules 70 are used to rate each line using characteristics of each line of the e-mail message. Such a characteristic is, for example, a location of the line within the e-mail message or a frequency of each line comprising a keyword such as, for example, 'telephone', 'mobile' and 'e-mail'. Having rated each line within the e-mail, the signature extractor analyses the scores to identify an area of the e-mail with the highest rating. This area having the highest rating corresponds to signature data of the e-mail. Typically signature data contains lines of contact details and generally occurs towards an end of the e-mail text. The signature data, once extracted, is stored with the contact data of the user. Signature data includes, for example, contact data having at least one of the following contact details: an e-mail address, a name, a title, a company name, an address, a telephone number, a facsimile number and a mobile telephone number.

The ratings rules 70 include text rating rules and text block separation rules. Examples of the rating rules 70 include, for example, at least one of the following: identifying a block of lines of text which contains at least two lines and does not exceed fifteen lines; identifying a block of lines of text by identifying one line of text which follows the block of lines and which is at least three characters in length (this exemplary rule allows the block of text to include a line including solely a control character such as, for example, <CR> or <LF>); identifying a block of lines of text by identifying one line of text which follows the block of lines and which is greater than forty-five characters in length; identifying signature data anywhere within the message body text; identifying a block of lines of text where a line following a block of text begins with text including, for example, at least one of the following characters: '*', '<' or '&'; identifying a block of lines of text where a line following a block of text contains text including, for example, at least one of the following words which are characteristic of an e-mail message having been replied to: 'from:', 'to:', 'cc:', 'subject:', 'original' or 'message'; identifying a block of text where a line following a block of text contains text which includes, for example, at least one of the following words: 'kind', 'Rgds', 'the best', 'regards', 'sincerely', 'your', 'always', 'dear', 'humbly', 'bless', 'warm', 'wish', 'thank', subscribe', 'cheers' or 'faithfully'; and identifying signature data by locating a display name of the user who transmits the e-mail message, part of the display name of the user who transmits the e-mail, or identifying the e-mail address of the user transmitting the e-mail. Each line of the text can also be rated using the rating rules 70 in accordance with a contact detail of contact data which is identified in a line of text. Table 1 gives examples of a type of contact detail which is identified in a line of text and a rating which is assigned to the identified contact detail. The rating has a decimal value or a hexadecimal value. One such example is where a line including an identified contact detail of a company name is given a rating having a decimal value of 2 or a hexadecimal value of 0x00000002 and a line including an identified contact detail of a mobile telephone number is given a rating having a decimal value of 48 or a hexadecimal value of 0x00000040.

Table 1

Examples of text of a contact detail which is identified as being of a website type of contact detail include: 'www' or 'http://'. Examples of text of a contact detail which is identified as being of a company name type of contact detail include: 'ltd.', 'limited', 'co', company', 'pic', 'international', 'media' or 'publishing'.

Examples of text of a contact detail which is identified as being of a title, for example an executive title, type of contact detail include: 'ceo', 'executive', 'chief, 'director' or 'manager'.

Examples of text of a contact detail which is identified as being of an address type of contact detail include: 'street', 'road', 'park', 'avenue', 'crescent', 'house', 'square', 'floor', 'yard' or 'garden'. Examples of text of a contact detail which is identified as being of a fax number type of contact detail include: 'fax' or 'f followed by numerical text.

Examples of text of a contact detail which is identified as being of a telephone number type of contact detail include: 'tel', 't', 'phone' or 'telephone' followed by numerical text. Examples of text of a contact detail which is identified as being of a mobile telephone number type of contact detail include: 'm', 'mob' or 'cell' followed by numerical text. A contact detail which is identified as being of an e-mail address type of contact detail includes, for example, text of the e-mail address of the sender of the e-mail message. An example of text of a contact detail which is identified as being of a name type of contact detail includes one word of a full display name. For example, if a full display name is 'Alastair Crawford', the line with the text 'Mr. Crawford' has the one word of 'Crawford' of the Ml display name.

An example of text of a contact detail which is identified as being of a some names type of contact detail includes more than one word of a full display name. For example, if the full display name is 'Alastair Crawford Junior', the line with the text 'Crawford Junior' has the words of 'Crawford' and 'Junior' of the full display name.

An example of text of a contact detail which is identified as being of a display name type of contact detail includes all the words of a full display name. For example, if a full display name is 'Alastair Crawford', the line with the text 'Mr. Crawford' has the one word of 'Crawford' of the full display name.

An example of text of a contact detail which is identified as being of a display name type of contact detail includes all words of a full display name. For example, if the full display name is 'Alastair Crawford Junior', the line with the text 'Crawford Junior Alistair' has the words of 'Crawford', 'Junior' and

'Alastair' of the full display name but having a different order.

An example of text of a contact detail which is identified as being of a full display name type of contact detail includes all words of a full display name having a same order as the full display name. For example, if a full display name is 'Alastair Crawford Junior', the text of the line will include the words 'Alastair Crawford Junior'.

If a line includes more than one contact detail, an overall rating of the line is a sum of the individual rating given to each contact detail in the line. For example a line including a company name and a mobile telephone number is given an overall rating having a decimal value of 50 according to the sum of the decimal value 2 and the decimal value 48. The rating rules 70 provide the signature extractor 68 with a plurality of examples of text which are characteristic of a particular contact detail. For example, characteristic text for a company name contact detail includes, for example, 'ltd.', 'limited', 'co', 'company', 'pic', 'international', 'media' or 'publishing'. Characteristic text for a mobile telephone number includes, for example, 'mob', 'mobile' or 'cell' followed by a plurality of numerical text. It is envisaged that the ratings rules 70 can be modified to include, for example, further text which is characteristic of a contact detail.

A block of lines of text which is identified as signature data has a sum of the rating of each line of text of the block which is greater than a sum of ratings of lines of different blocks of text in the e-mail message body. Different blocks of text may only contain one line of text but when combined will produce signature text. Different blocks of text are joined if a rating of each different block is different. The sum of a block is a sum of ratings of constituent lines of text within the block. This is the case, for example, when more than one block of text comprises one line of text and when combining these blocks of text forms a satisfactory block of signature data text. To confirm that the identified text is signature data, it is checked that the identified text includes text which is characteristic of a display name of a user, includes part of text which is characteristic of a user or includes text which includes an e-mail address which is characteristic of a user.

An example of text of a signature, including control characters, found in the message body of the e-mail message is given below:

John Wardlaw <CR><LF>

HighwayOne Corporation <CR><LF> 7 Oasis Park

Eynsham

Oxford <CR><LF>

OX8 ITP

Tel. 01865 882333 The second communication agent 54 displays this exemplary signature text to the second user without the control characters as follows:

John Wardlaw

HighwayOne Corporation 7 Oasis Park

Eynsham

Oxford

OX8 ITP

Tel. 01865 882333

The signature data is parsed further and lines of text of the signature data are divided into a plurality of component parts. This process uses rules which, in a similar manner to the rating of the message body text described above, are used to rate each line of text of the signature data using keywords of the text. Each component part corresponds to a contact detail, for example the name or the title, of contact data for the user, in this case the first user. As detailed earlier, a date of the signature data being extracted and stored is recorded in the contact data of the local database.

In accordance with embodiments of the present invention, contact data derived from an e-mail message will now be described in further detail.

Figure 8 shows several exemplary data records 172 of the derived contact data, each of which includes derived contact data defining contact details of a user. The derived contact data includes identification data which uniquely identifies a user (e.g. by an e-mail address), which in this embodiment is conveniently stored in the graph relationship data store 116. Each user record 172 includes a plurality of data fields which hold data representing contact details of the contact data for a user. A user e-mail address field 174 of each user record 172 holds data representing the e-mail address of the user and other data.

Data fields include: a name field 176 holding data representing a name of a user; a title field 178 holding data representing a title of a user, for example the title may be a title of a role of the user within a company; a company field 180 holding data representing a company name where a user works; an address field 182 holding data representing an address of a user, for example a company address; a telephone number field 184 holding data representing a telephone number of a user; a fax number field 186 holding data representing a facsimile number of a user; a mobile telephone number field 188 holding data representing a mobile telephone number of a user.

As described above, the analysis of the e-mail message includes deriving contact data from signature data of the e-mail message. A signature date field 190 of the derived contact data holds data representing a date on which signature data for a user was most recently obtained. Relationship Data

Relationship data derived by the second communication agent 54 associated with the second user from an e-mail message will now be described in further detail. For the purposes of this description, a user transmitting an e- mail message is a sender and a user receiving the transmitted e-mail message is a recipient.

Figure 9 shows several exemplary data records of the derived relationship data. Each relationship data record includes data indicating a relationship between a sender and a recipient. Each data record 154 comprises a plurality of data fields which in this embodiment include: a first user e-mail address field 156, a second user e-mail address field 158, an e-mail message received or transmitted field 160, a date of first e-mail field 162, a date of last e- mail field 164, a transmission address field 166, a message frequency field 168 and a relationship type field 170. The first user e-mail address field 156 holds identification data relating to a first user (e.g. a sender) which uniquely identifies the first user. The second user e-mail address field 158 holds identification data of a second user which uniquely identifies the second user (e.g. a recipient).

The e-mail message received or transmitted field 160 holds data which indicates whether either the first user is a sender and the second user is a recipient, or whether the first user is a recipient and the second user is a sender.

The derived relationship data also indicates a strength of the relationship between the first user and the second user. The strength of the relationship effectively quantifies the level of establishment of the relationship between the users and the level of efficiency with which the users communicate with one another. The strength can be defined with reference to a plurality of categories and a score calculated in respect of each category. The value of the score, in each category, provides a measure of the strength of the relationship in relation to that category, as will be described in the following passage. One such category is a date of a first e-mail message from the first user being received by the second communication agent 54, or a first e-mail message being transmitted to the first user by the second communication agent 54 and the score indicative of the strength is a date on which the analysed first e-mail message was received or transmitted by the second communication agent 54. The date of first e-mail field 162 holds data representing the date. A further category indicative of strength is a date of a last e-mail message from the first user being received by the second communication agent 54, or a first e-mail message being transmitted to the first user by the second communication agent 54 and the score indicative of the strength is a date on which the analysed last e-mail message was received or transmitted by the second communication agent 54. The date of last e-mail field 164 holds data representing the date.

A further category indicative of strength is a transmission address field which specifies a field of a message header of the e-mail message which specifies the type of recipient of the e-mail. The type in this case may be, for example, one of: 'main' or 'CC. The skilled person will appreciate that 'Main' indicates that the e-mail address of the recipient is specified in a main transmission address field, causing the e-mail message to be transmitted directly to the specified e-mail address of the recipient, while 'CC indicates that the e- mail address of the recipient is specified in a 'carbon copy' transmission address field, causing a copy of the e-mail message to be transmitted to the specified e- mail address, rather than the e-mail message being transmitted directly to the specified address of the main field. The transmission address field 166 holds data representing the transmission address field in which the e-mail address is specified. For an e-mail message received by the second communication agent 54, the e-mail address in the transmission address field is the e-mail address of the second user.

A further category indicative of strength is a message frequency and the score indicative of strength in this case is a number of e-mail messages transmitted between the first user and the second user of a relationship during a specified time period. The message frequency field 168 holds data representing, for a given relationship, the frequency of the second communication agent 54 receiving e-mail messages from the first user or transmitting e-mail messages to the first user. As an example, a relatively high frequency indicates a relatively strong relationship and a relatively low frequency indicates a relatively weak relationship. The relationship data also indicates a type of the relationship between the first user and the second user. The type of relationship is also represented by at least one of a category and a score indicative of the type. In this embodiment the relationship type field 170 represents the category of the type and holds data representing a type of the relationship between the first user and the second user. This data held in the field represents the score indicative of the type of the relationship and may, for example, be: 'friend', indicating a friend type of relationship between the first user and the second user, or 'business', indicating a business type of relationship between the first user and the second user. It is envisaged that over a period of time a relationship type may change, for example from a business type relationship to a friend type relationship.

User Registration Process

In accordance with another embodiment of the present invention, a user can provide contact data to the store of shared contact data via a user registration process which is stored in a local database associated with a communication agent, hi one arrangement the user registration process can be part of the initialisation process described earlier with reference to Figure 4, and contact data provided such a user registration process can be transmitted to the shared contact data store 114. The user registration process can be used to collect additional information about the user, which is used to build further data indicating the nature of relationships between users. Such additional registration information can be stored as registration data in the shared registration database 104.

This additional information can include details relating to the user, such as business and social information. Table 2 gives examples of details of professional information and details of personal information of a user collected during registration. The user may choose whether or not to provide certain details. During the registration process the user is shown the number of new relationship links between the user and other users.

Table 2

By collecting and analysing data such as that listed in Table 2, relationships between users can be identified so as to establish a 'common ground link'. A common ground link is a relationship between at least two users who are linked by a personal detail which is common between them. For example, if one user specifies that they attended a certain school for a certain time period, a common ground link is established between the one user and each other user who has registered that they attended the same certain school during the same time period. Individual users who are of the same age as the one user have stronger links than users who attended the same certain school but have a different age. A stronger link is a relationship having a relatively great strength. A weighting is applied for a type of common ground link which indicates the strength of the link. The weighting varies in dependence with the type of common ground link. For example, a link between a given user and a close family member tends to be a stronger link than a link between the given user and a user who works in the same company as the given user. In this manner, derived relationship data is created. By gathering the additional information the software is able to build up a profile of information for each user. This allows a network to be built, using derived relationship data, which indicates users which the given user knows even if electronic communications are not exchanged between the one user and these other users.

The weighting applied to this relationship data derived by the user registration process is scored in a different manner to the relationship data derived by the communication analyser 64. As described earlier, the communications analyser 64 derives relationship data which is scored according to a strength and a type of the relationship. In this case e-mail messages are generally transmitted bi-directionally between the two users in two directions, which allows the derived relationship data to be validated by independent sources of derived relationship data, in this example the communication analyser used to send the message and the communication analyser used to receive the message. The score indicative of the strength and the type of the relationship is consequently relatively more reliable than a score indicative of a relationship between one user and at least one further user where the registration information provided by at least one of the users is not derived by a communication analyser, but is provided by the user himself. Furthermore, relationship data which is indicative of a type of a relationship between users and which is derived using information provided by at least one user himself does not indicate a strength of a relationship, but merely a common ground link between the users.

Data Classification

Having created the contact and relationship data in the manner described above, each electronic communication can be classified using local relationship data and/or shared relationship data. Accordingly a method of classification will now be described with reference to Figure 10. The communication classifier 72 accesses (steps 224 and 226) the local relationship data store 90 and the local contact data store 92. In this example, the communication classifier 72 determines whether the first user associated with the e-mail being classified is recognised (step 228). Accordingly, the communication classifier 72 determines from the local relationship data of the second local relationship data store 90, whether the relationship between the first user and the second user is known. Additionally the communication classifier 72 determines from the local contact data of the second local contact data store 92, whether the contact details of the user sending the message, namely the first user, are known. If the relationship and the contact details are known, the e-mail message is classified into an appropriate classification group as described later below.

If₅ having accessed the local relationship data store 90, the relationship data of the relationship between the first user and the second user is unknown, the method of the present invention comprises querying the shared relationship data store, in this case the graph relationship data store 116 and storing local relationship data derived from the shared relationship data in the local database. In this example, the graph relationship data store 116 is queried (step 230) using the data synchronisation tool 80 and shared relationship data for the relationship between the first user and the second user is downloaded and stored (step 232) in the local relationship data store 90. Additionally, if, having accessed the local contact data store 92, the contact details of the first user are unknown, the method of the present invention comprises querying the shared contact data store, in this case the contact data store 114 and storing local contact data derived from the shared contact data in the local database, hi this example, the contact data store 114 is queried (step 234) using the data synchronisation tool 80 and shared contact data indicative of contact details of the first user is downloaded and stored (step 236) in the local contact data store 92.

Querying the graph representation data store 116 or the contact data store 114 involves submitting a request requesting shared relationship data or shared contact data respectively. Information is transmitted from the graph management system to the communication classifier 72 concerning whether the first user, in this example, is identified as a user in the graph system. If the first user is identified then the user is known and data indicative of a degree of separation between the first user and the second user is transmitted to the communication classifier 72. A degree of separation indicates a number of constituent relationship links, indicating relationships between different users, which together form one particular relationship link connecting one user and a further user. The one particular relationship link indicates a relationship between the one user and the further user. In this case, once local relationship data and local contact data have been stored for the unknown first user and data of the degree of separation between the first user and the second user is received, the first user is recognised (step 228).

Once the communication classifier 72 determines that the first user is recognised, the e-mail message is assigned (step 238) a score. The score is assigned to the e-mail message using information which includes data concerning a nature of electronic communications between the first user and different users. Using this data, a score is assigned to the e-mail message which scores a relationship between the first and the second client.

The score assigned to the e-mail message is based on a variety of factors concerning the relationship between the first user and the second user. Such factors include, for example, a common ground link, a frequency of communication between the first user and the second user, an age of electronic communications transmitted between the first user and the second user and a type of the relationship between the first and the second user.

Data from the registration database 104 is used to determine if there are any common ground links between the first user and the second user. Such common ground links are used to cumulatively increase the score. The effect of the common ground links on the score is considered to be of a relatively low reliability as the data provided to determine a common ground link is based on a user entering data himself, rather than the information being collected automatically. The frequency of transmitting electronic communications between the first user and the second user is analysed to produce a score. This score is a relative score based on a total volume of e-mail messages transmitted by the second user and a percentage of this total volume that have been transmitted to the first user. This score is partially dependent on the total volume of e-mail messages transmitted by the second user. For example, if the second user sends one hundred e-mails per week to the first user and sends a total volume of one thousand e-mails per week, the score assigned to the e-mail message from the first user will be relatively greater than if the second user sends one e-mail per week to the first user and sends a total volume often e-mails per week.

The communication classifier 72 considers the e-mail messages exchanged between the first user and the second user in respect of the age and a length of time since the date of first receiving an e-mail message from the first user. The score is degraded with an increase in the age of e-mail messages. This degradation of the score with the age is in accordance with a logarithmic scale so that the score cannot degrade below a certain value.

As described earlier, the type of relationship between the first user and the second user determines at least in part, the score. The communication classifier determines whether the type of relationship is a friend type or a business type. Greater granularity of the type of relationship is envisaged; for example, a business type relationship may be subdivided into sub categories of a type of relationship based upon a content of the e-mail message.

The communication classifier 72 classifies (step 240) each e-mail message by creating a score for each user in the local database 88 indicating a strength and a type of a relationship between the second user and each other user. The scores for each user are recorded in the communication data database 58 which allows the second user, in this case, to easily classify each electronic communication.

As described earlier, in this example the communication application software 22 is Microsoft Outlook™ and the communications classifier 72 is preferably installed on the client terminal 2 as described earlier. The communication classifier 72 attaches (step 242) classification data which includes a data field defined by the second user, in this case, to each e-mail message stored in the communication data database 58. The user defined field includes, for example, a data field indicative of an e-mail frequency classification group and a type of relationship classification group into which each e-mail message is classified. The e-mail frequency classification group is indicative of a frequency of e-mail messages transmitted to, and/or received by, the second user from the first user. Each e-mail message is classified into one frequency classification group of, for example, 'More than 100 e-mail messages', 'More than 50 e-mail messages', 'Newsletter' or 'spam'. Additionally each e-mail message is classified into one type of relationship classification group of, for example, 'Friend' or 'Business.'

The communication agent associated with the communication classifier 72 indicates (step 244) a classification of an electronic communication to a user. Electronic communications having different classifications are indicated differently to the user. In this embodiment the indication of classification is visual.

In this embodiment the communication agent is the second communication agent 54 which indicates the classification of each electronic communication, in this example an e-mail message, to the second user. The e- mail messages indicated are those stored in the communication data database 58. The second communication agent 54 provides a graphical user interface (GUI) which visually displays a list of e-mail messages of the second user. The classification of each e-mail message, in accordance with the score assigned to the e-mail message, is indicated visually to the second user. In this embodiment, text representing an e-mail message to the second user has a colour indicative of the classification group, for example the e-mail frequency classification group, assigned to the e-mail message. The representative text includes, for example, a name of a user who transmitted the e-mail message to the second user or a subject of the e-mail message. Different e-mail messages represented by text of the same colour indicate that each e-mail message belongs to the same classification group. Different e-mail messages represented by text of different colours indicate that each e-mail message belongs to a different classification group. The second communication agent also displays a key to the second user so that the second user can interpret that an e-mail message indicated by a particular colour belongs to a particular classification group.

By classifying the e-mail messages in this way, each e-mail message is colour coded based upon the relationship between, in this example, the second user and the first user. This enables e-mail messages to be prioritised according to an importance of a user transmitting the message to the second user. By using a data field defined within the second communication agent 54 by the second user, the second user can create customised rules using the user defined data fields in order to sort different e-mail messages within the second communication agent 54.

The classification of each e-mail message is derived by applying a Bayesian filtering technique to a content of each e-mail message, hi order to achieve this, the second user specifies certain individual users and the type of relationship he has with each of them, for example a friend type of relationship or a business type of relationship. The communication processing software then analyses all e-mail messages transmitted to, and received from, each individual user and builds a dictionary of words used within these e-mail messages and determines a frequency of e-mail messages transmitted to, and received from, each individual user. Using this dictionary of words and message frequency data, a Bayesian analysis technique is applied to each e-mail message to determine whether a relationship between an individual user and the second user is of a friend type or a business type.

A user trains the Bayesian filtering technique such that the classification group assigned to each e-mail message has a sub category of a type of relationship. For example, users having a business type relationship may be working on at least one different work project. E-mail messages from business type users can therefore be classified by the Bayesian filtering technique of the communication classifier 72 according to the work project that the user is working on.

The communication classifier 72, by indicating a classification group of each e-mail message, for example an e-mail frequency or whether a user transmitting an e-mail message to the second user is known to the graph, creates a white list of user contacts. This white list is a list of approved users which is used to filter out unwanted e-mail messages such as 'spam', whilst ensuring that no e-mail messages which are not 'spam' are filtered out.

The method of the present invention comprises analysing one or more electronic communications to identify potentially unwanted electronic communications and classifying any potentially unwanted electronic communications. This analysis identifies potentially unwanted electronic communications using a Bayesian filter technique.

In this embodiment the electronic communications are e-mail messages and a potentially unwanted e-mail message is referred to as junk mail or ' spam' . The spam filter 76 is an additional software component of the communication classifier 72. The spam filter 76 allows a user, in this example the second user, to block receipt of and manage spam type e-mail messages which are received by the second user. The spam filter 76 functions in accordance with the spam Filter settings 78. The spam Filter 76 combines a known Bayesian spam filter technique with the local relationship data and/or the shared relationship data of the graph of the present invention. Using this relationship data the spam filter 76 can determine whether an e-mail message received from a particular user has a high likelihood of being spam. Known Bayesian spam filter techniques operate by building dictionaries of words commonly used in spam type e-mail messages and of words commonly used in non-spam type e-mail messages. The Bayesian filtering technique is used to predict whether or not a received e-mail message is of a spam type. This prediction is based upon textual words occurring within the e-mail message. Using Bayesian spam filtering techniques alone can result as an e-mail message being filtered incorrectly as a 'false positive'. A false positive occurs where an e-mail message is incorrectly predicted to be, and is treated as being of, a spam type message. This proves to be a problem if a user such as the second user does not read e-mail messages classified as spam and, in doing so, does not read any e-mail messages classified as spam but are in fact false positives. In the present invention such a Bayesian spam filter technique is combined with the local relationship data and/or the shared relationship data taken from the graph relationship data store 116. The relationship data is used by the spam filter 76 to determine whether a user transmitting an e-mail message to the second user has a relationship with the second user. If this is the case, information on the features of the relationship, such as a type of relationship and a strength of the relationship, are used to analyse the e-mail message. This analysis is carried out prior to analysing the received e-mail message using the Bayesian filtering technique in order to reduce the chance of the e-mail message being classified as a false positive. Furthermore, if an e-mail message is received from an unknown user which the second user does not have a relationship with, a search of the graph by the graph management system is performed. The search establishes whether there is a degree of separation between the unknown user and the second user. If there is a degree of separation, this is used to classify the e-mail message as being of a non-spam type. If the unknown user is identified as a user on the graph but is not related to the second user, information on the unknown user is downloaded from the graph, using the data synchronisation tool 80. The spam filter 76 uses this information to weight the Bayesian filtering technique. One example of information being used to weight the Bayesian filtering technique includes a number of users who exchange electronic communications with the unknown user. This information is used to establish a reputation of the unknown user and the spam filter 76 uses this reputation of the unknown user to predict whether the e-mail message is spam or not.

E-mail message spoofing is a process whereby spam type e-mail messages are sent from a user having a name which is known to a recipient user. To prevent such e-mail message spoofing, the communication processing software, for example the spam filter 76, logs all unique Internet Protocol (IP) addresses that an e-mail message is received from and links each IP address to a user. When an e-mail message is received from an IP address which does not match the IP address patterns of the IP addresses linked to the uses, the spam filter 76 automatically marks the e-mail message as suspected spam and the e- mail message is subsequently processed using the Bayesian filtering technique.

It is further envisaged that components of the communication processing software or the graph processing software are adapted to check the contact data and the relationship data, for example the shared contact data and the shared relationship data, for integrity. It is envisaged that attempts will be made to mislead the software of the invention to believe that a user identified on the graph is a real person, rather than an automatically generated user identity which, for example, transmits spam type e-mail messages. The software of the present invention, for example the communication processing software, is adapted to identify characteristics of such automatically generated users and eliminate any nodes on the graph which exhibit such characteristics, or to eliminate nodes which participate with such nodes exhibiting these characteristics.

An example of a classification of e-mail messages provided by the method of the present invention will now be described.

The communication classifier 72 classifies all user contacts according to five different classification groups:

Group 1 - This group contains "best friend" user contacts as the user has very frequent communication with them, for example, user contacts for a user who has transmitted greater than most e-mail messages and received most e-mail messages.

Group 2 - This group represents user contacts with whom the user has had e- mail messages exchanged in both directions such that the user has sent greater than or equal to one message and received greater than or equal to one message. Group 3 - This group represents a start of an exchange of electronic communications. For example, this indicates that a user is transmitting an e-mail message to a user for a first time. This new user could be, for example, a potential business partner but could alternatively be, for example, a spam type e- mail message.

Group 4 - This group represents user contacts that a user has sent 0 e-mail messages to, but that the user has received greater than 1 and less than 50 e-mail messages from the user. This group represents all user contacts of the user from whom the user only receives e-mail messages. This group could contain news e- mail messages or e-mail messages from subscribed lists. Alternatively, this group could include spam type e-mail messages. Group 5 - This group represents user contact that a user has sent 0 e-mail messages to, but that the user has received greater than 50 e-mail messages from.

In addition to classification into these groups, further classification of e-mail messages is performed in a background. E-mail messages are classified according to further classification groups having criteria detailed below: Friends - Classification Groups 1 and 2 joined together. Carbon Copy (CC) Friends - Friend user contacts of a user's friends from whom the user has received an e-mail message, but has never sent an e-mail message to. Examples of CC friends are: Example 1: An e-mail message is received from the e-mail address: albert@192.com, is sent to: vou@192.com and is carbon copied (CC) to: dom@192.com. The user receiving the e-mail message has the e-mail address: you@192.com. albert@192.com is not a friend of you@192.com since you@192.com has never transmitted an e-mail message to albert@192.com, but dom@192.com is a friend of vou@192.com. Since the e-mail message is transmitted to vou@192.com and to dom@192.com who is a friend of you@192.com, it is assumed that as albert@192.com is a friend of dom@192.com, then albert@192.com is a friend ofyou@192.com as well.

Example 2: An e-mail message is received from the e-mail address: dom@192.com, is sent to: vou@192.com and is CC to: albert@192.com. albert@192.com is not a friend of you@192.com since vou@192.com has never transmitted an e-mail message to him, but dom@192.com is a friend of you@192.com. Since the e-mail message is transmitted from dom@192.com, who is a friend of you@192.com, to you@192.com and CC to albert@192.com, it is assumed that albert@l 92.com is a friend of you@192.com as dom@192.com is a friend ofyou@192.com.

New Business Contact - This classification group is for e-mail messages from Group 3 (received for the first time but the user contact is either a cc friend or it is found in the graph.) This means that the user contacts in this classification group are white listed contacts and that a friend of the receipient user knows the sender of the message and that the recipient user has a degree of separation greater than 1 from the user sending the message.

Unsure - This classification group is for e-mail messages classified into Group 3 which are received by the user for the first time. The user sending the message is not found in the graph, nor in the Carbon Copy (CC) Friends Group and the spam filter cannot decide if the e-mail message is spam or not. The e- mail message is made available for the recipient user to decide the classification of the e-mail message. If the user identifies the e-mail message as spam the settings of the spam filter 76 are updated to recognise the content of such e-mail messages so that e-mail messages of this nature are automatically classified as spam. Alternatively, if the user identifies the e-mail message as from a new business contact user, the e-mail message is re-classified into the New Business Contact Group.

Spam - This classification group is for e-mail messages classified into Group 3 which are received by the user for the first time. The user sending the message is not identified as a user in the graph and is not a CC user contact. Following this, the spam filter 76 identifies this e-mail message as spam. Newsletters - This classification group consists of Group 4 & Group 5 combined. Data Transfer

Aspects of data transfer between the client 2 and the server 28 will now be described.

The relationship data derived from the analysis of the e-mail message sent from the first communication agent to the second communication agent 54 is transmitted by the data synchronisation tool 80 to a store of shared relationship data which is accessible to a plurality of users including a third party. In this embodiment the store of relationship data is the graph relationship data store 116 which is accessible to a plurality of users using the API 124. The derived relationship data which is transmitted to the graph relationship data store

116 is first shared relationship data.

The contact data derived from the analysis of the e-mail message sent from the first communication agent to the second communication agent 54 is transmitted by the data synchronisation tool 80 to a store of shared contact data which is accessible to a plurality of users, hi this embodiment the store of contact data is the contact data store 114 which is accessible to a plurality of users using the API 124.

The shared relationship data is updated using the data synchronisation tool 80 in response to updating the local relationship data, hi this embodiment at least part of the shared relationship data in the graph relationship data store

116 is updated when the first local database or the second local database is updated with derived local relationship data.

The shared contact data is updated using the data synchronisation tool 80 in response to updating the local contact data, hi this embodiment at least part of the shared contact data in the contact data store 114 is updated when the first local database or the second local database is updated with derived local contact data.

The data synchronisation tool transmits the data derived by the communication analyser 64 and the signature extractor 68 to the contact data store and/or the graph relationship data store. In this embodiment the transmission of the derived data is an uploading of the derived data. The software collects the derived data, compresses and encrypts the data before uploading the information to the server terminal 28. The uploaded data might be confidential in which case the software encrypts the data before transmission to the server 28. Each different copy of the communication processing software used by a different user has a unique private key which is used to encrypt the data before being uploaded. The unique key is used by the server terminal to authenticate the source of the transmitted data and the integrity of the transmitted data.

The data uploaded to the server terminal 28 is controlled by the user, in this case the second user. The second user can permit the software to update the contact data store 114 and the graph relationship data store 116 with all the derived relationship data, contact data or signature data; or the second user can limit the software to update derived relationship data, contact data or signature data for selected users who are contacts of the second user, for users who have recently been in contact with the second user, for users who have recently been contacted by the second user, or for users where a frequency of message transmission with the second user is over a specified message frequency threshold.

The data for each user that is uploaded includes all the extracted, parsed signature data for each user as well as data representing a message frequency, a date and time of the first and last electronic communication between a user and the second user and a type of relationship between a user and the second user.

It is envisaged that the upload procedure is performed in a batch mode where the data synchronisation tool of the software collects the derived relationship data and the derived contact data and either updates the graph relationship data store 119 and/or the contact data store 114 according to a threshold controlled by time or a threshold controlled by a volume of data. Alternatively it is envisaged that the graph relationship data store 116 and/or the contact data store 114 is dynamically updated in real time such that whenever derived relationship data or derived contact data which is stored in the store of local relationship data 92 of the second local database 88, for example, is updated by a user, or following analysis of a new e-mail message, the graph relationship data store 116 and/or the contact data store 114 is updated automatically using the data synchronisation tool 80 which notifies the server terminal 28 of the change of the data of the local database. In response to updating the shared relationship data stored in the graph relationship data store 116, local relationship data in a local database is updated. In this embodiment, following the updating of the shared relationship data according to the earlier description, the server terminal 28 downloads at least part of the updated shared relationship data to a local database, for example the first and/or the second local database 88, by transmitting the shared relationship data to the data synchronisation tool 80. The downloaded relationship data is local relationship data and the store of local contact data of the first and/or the second local database 88 is updated with the downloaded local relationship data.

When signature data for a user changes and the shared relationship data and the shared contact data is updated, the graph processing software 24 updates the data synchronisation tool 80 with the more up-to-date signature data for the user. The data synchronisation tool 80 receives notification data that the signature data of the shared contact data has changed and updates the local contact data using the up-to-date signature data. Existing signature data for a user which is stored in a local database is enhanced with any new signature data of the signature data of the shared contact data. For example, if a user adds a mobile telephone number to an existing signature, the data synchronisation tool 80 downloads data of the mobile telephone number of the user and updates the signature data for that user with the mobile telephone number data.

Permissions

A third party, in this example a third user who is different to the first user and the second user, has access to the first shared relationship data from the graph relationship data store 116, or has access to data derived from the first shared relationship data. Additionally, the third party, in this example the third user, has access to the first shared contact data from the contact data store 114, or has access to data derived from the shared contact data.

The relationship data and contact data uploaded to the server, in particular to the graph relationship data store 116 and to the contact data store 114, includes a relatively large amount of confidential and private data. Each user, for example the second user, is given complete control of specifying users who can access shared relationship data and shared contact data of the user. In this case, the second user can also specify how the shared data is accessed by different users. Relationship data and contact data of a contact detail of a user which is uploaded to the server, or provided during the registration process, contains permission data which is provided by, in this case, the second user. The permission data includes user permissions which, for example, determine which of a plurality of users can access a user's shared contact data, or which determine which of a plurality of users can access specified data fields of a data record holding a user's contact details. The permissions data is stored in the permissions database 102.

A user can, for example, set standard permissions for a user to access all contact data records of a user's shared contact data, set an individual permission for each user of a plurality of users to access specified contact data records, or set an individual permission for each user of a plurality of users to access specified data fields of specified contact data records.

In this way one user, in this example the second user, controls users who are permitted to access shared contact data of the one user. The second user can, for example, specify a group of users who are permitted to access the shared contact data of the one user in a specified manner. Examples of such user groups are given below.

One exemplary user group allows access to only the second user. This allows the second user to use the shared contact data store 114 of the server terminal 28 as a backup system which provides a backup copy of the local contact data stored in a local database, in this case the second local database 88. In this way the second user can access their contact data using different terminals including, for example, an Internet browsing terminal or a mobile telephone using a Wireless Application Protocol (WAP).

A further exemplary user group allows access to only at least one named individual user of a group of named individual users. This allows the second user to share their shared contact data amongst, for example, a group of friends, or a group of work colleagues working in a same company department as the second user. This user group allows a relationship between a user working for one company and a user working for a different company to be identified. This user group also allows single points of user contact in a business to be unified. A further exemplary user group allows access to at least one user who has a relationship with a specified degree of separation from the second user. This allows users which are known to the second user, for example a direct friend having a degree of separation of one, or a friend of a friend having a degree of separation of two, to access the shared contact data. The second user can, for example, permit a group of users having a degree of separation of one to access all the contact details of the second user, but permit a group of users having a degree of separation of two to access contact data indicating the only users that the second user knows and not to access contact details of these known users. A further exemplary user group allows access to at least one user who has, for example, a friend type relationship with the second user, or a business type relationship with the second user. In this way the second user can separate access to the shared contact data by allowing friends to only access contact data for friends of the second user and allowing business contacts to only access contact data for business contacts of the second user.

A further exemplary user group allows access to at least one user who has a registered link with the second user. The registered link in this example is a common ground link which is, for example, a relationship between the second user and a user who attended the same school. A user having this registered link can only access shared contact data of the second user for other users with whom they have the registered link. A user accessing the shared contact data can only access an e-mail address for the users having the registered link.

A yet further exemplary user group allows at least one user to establish contact with a user who is known to the second user and whose contact details are included in the shared contact data, but without disclosing the known user's contact details. Such a user group is termed a 'blind contact' user group as a user can contact another user blindly, without being informed of any contact details of the user they are contacting. Li order for a user to blindly contact another user, a user composes an e-mail message and transmits the message to the server terminal 28 which in turn transmits the message to the unknown user. The user who receives the message receives contact data of the user who transmitted the message. Using this received contact data, the recipient user can decide whether or not to transmit a reply message to the user transmitting the message. The recipient user can also decide whether or not to disclose contact data including contact details of the recipient user to the user transmitting the message.

A yet further exemplary user group allows the second user to control and filter requests by users to establish contact with a user known to the second user. For example, one user wanting to establish contact with a different user needs to transmit a message to the second user explaining why they wish to contact the different user. The second user, having received this message, decides in-turn whether to transmit the message of the one user to the different user.

Graphical Representation The graph management system is responsible for storing the shared contact data and the graph relationship data.

The graph representation agent 118 uses the shared contact data of the contact data store 114, the shared relationship data of the graph relationship store 116, the graph update data 120 and the graph data 122 to generate a graphical representation of a plurality of users and relationships between them.

Each user is identified by unique identification data which, as stated above in this embodiment is an e-mail address of the user, and the unique ID forms a node of the graphical representation, thereby representing one particular user. A relationship between two users is represented by a pair of directed links between two nodes, each of the two nodes representing one of the users in a relationship. One of the pair of directed links is directed from one of the two nodes (associated with one user) to the other of the two nodes (associated with a different user) and indicates characteristics of the relationship which the one user has with the different user. The other directed link of the pair is directed, in an opposite direction to that of the directed link just described, from the other node to the one node and indicates characteristics of the relationship which the different user has with the one user.

The unique identification data includes a plurality of electronic mail addresses. Each electronic mail address identifies the same user in the shared relationship data store. Although each user is uniquely identified by one e-mail address, one person may use a plurality of different e-mail addresses. As a consequence a plurality of nodes, each node representing a different e-mail address, is represented in the graph. An 'equality' link connects each node representing an e-mail address of one person. Two nodes connected by such an equality link are not considered to be separated by one degree of separation. Traversing such an equality link from one node to a different node does not increase a degree of separation.

Persons represented in the graph are either registered users or non- registered users who are contacts of a registered user. Each contact is represented by at least one node in the graph. Only a registered user is able to publish a list of their contacts, build a representation of a graph of relationships between their contacts and access the graph to obtain information of potential relationships between himself and other users represented on the graph. A number of registered users is smaller than a total number of users represented on the graph. A Breadth-First Algorithm can be used to traverse the graph in order to identify each node representing a user on the graph, or to identify nodes representing users on the graph which are closest to a particular node. A Breadth-First Algorithm is a known algorithm for traversing a graph of a plurality of connected nodes. Firstly, starting from an initial node, each link which connects the initial node directly to a first neighbouring node is traversed in turn. Secondly, each link which connects each first neighbouring node to a second neighbouring node is traversed in turn. This method is continued until every link connecting nodes of the graph has been traversed. It is envisaged that a modified version of the Breadth-First Algorithm can alternatively be used to traverse the graph. Any modifications made to the Breadth-First Algorithm may be made in response to changes in the graph such that traversing the graph may be performed in a more efficient manner.

A relationship between one registered user and one other user may be identified via a direct route of links between registered user nodes, or alternatively via a node representing a non-registered user having a relationship with the one registered user and the one other user. A relationship may also be identified which satisfies certain criteria based on properties of relationship links between nodes. Relationships of a different type are represented by attaching at least one attribute such as, for example, a strength of the relationship, an age of the relationship, or a recency of the relationship. A recency of a relationship indicates any relationships which were established within a specified time period prior to a present time. In order to identify relationship types, a type of a relationship and the attributes are not hard coded, but are pluggable interpretations of the information of the type of relationship.

Features of the graph processing software 44, as introduced earlier, will now be described in further detail.

The graph processing software 44, is accessed by the server software 46 or the Internet browser terminal 48 which sends URL encoded request commands to the graph management system.

The server software 46 acts as a permanently connected entry point for terminals to connect to the graph management system. The server software 46 exposes the external API 124 of the graph processing software 44 to client terminals. In this example, the server software is 'Tomcat 5' HTTP server software.

All functionality of the graph management software is deployable into the server software 46 as a Java application. The Java application handles HTTP and HTTP(S) protocol, extracts XML requests and transmits XML responses to client terminals. The software 46 filters request data and only allows request data for the external API 124 to pass to the external API 124.

The software 46 monitors an availability of the graph management system and sends any necessary error messages to the client terminals. The HTTP server software performs load balancing of data between several instances of the graph management system and controls an execution of write request data onto a dedicated instance of the graph management system. The HTTP server software

46 also switches read instances of the graph representation in accordance with new graph representation data 122. Communication with the graph management system is performed using a configurable TCP/IP port where the graph management system listens for requests. It is possible to connect to the graph management system via a telnet session 128 and issue internal API requests.

The graph management system is able to export data, including the contact data from the contact data store 114 and graph relationship data from the graph relationship data store 116, to an XML file which is stored as the graph

XML data 112.

The communication graph agent 100 is responsible for listening on the port, retrieving and parsing XML requests and performing a co-ordination function of executing requests. It controls concurrent execution of simultaneous requests in the graph management system.

The contact data store 114 includes a hash table of data representing all e-mail addresses known to the graph management system. It is envisaged that a large quantity of e-mail address data is stored in the graph management system and the hash table is a custom implementation allowing memory requirements to be a minimum. The contact store 114 is interface based to allow alternative implementations.

The graph relationship store 116 is the internal object representation of the relationship data of the graph representation. It is interface based to allow alternative implementations.

The graph representation agent 118 is a facade to prevalent behaviour of the graph management system. The graph representation agent 118 implements a command pattern where every modification to the graph representation is encapsulated as a command in a form of a transaction. Each transaction is saved as graph update data 120 before execution on the graph. At a certain time the graph representation agent 118 stores all data, in an internal format, of a current graph representation as the graph representation data 122. All graph update data 120 is then deleted.

When operation of the graph management system is stopped and subsequently restarted, it automatically loads the latest representation of the graph using the graph representation data 122. AU graph update data 120, created since the last instance of storing the current graph representation, is then applied to the graph representation. This restores the graph representation to its state before operation of the graph management system stopped. If operation of the graph processing software stops, for example in a

'crash' situation, all currently running transactions do not complete. The server software 46 detects this situation and sends a response with an error code to a client terminal indicating that the graph management system is not available.

Upon restarting the graph management system interrupted transactions are executed. AU requests to the graph management system are allowed to be repeated. Therefore, if a client repeats a request that received an error response, the request operates as an update to the graph representation so that no duplicate data records are created.

The request history database 110 is an application log which is used by the graph management system to log information, having a configurable level of detail, about each request. The request execution history database 108 is a trace file which provides detailed information about execution of requests for profiling purposes.

The graph management system allows the graph representation data 122 to be searched. This search includes searching the shared relationship data stored in the graph relationship data store 116 to identify characteristics of a relationship between two different users.

The graph management system operates as a search engine allowing a degree of separation between two different users to be determined. The graph management system makes available an API which allows software components of, for example, the communication processing software and the graph processing software, to search and explore the graph relationship data in order to determine a degree of separation.

The graph management system is operable to respond to requests for relationship data relating to a relationship link between two individual users in the graph. The graph management system analyses the relationship links between each user on the graph to see how the two individual users are linked and returns data of all relationship links which exist between them. The returned relationship link data is scored according to a strength of the relationship link and a number of degrees of separation between the two individual users.

The graph management system allows a communication classifier, for example the communication classifier 72 of a client terminal, to inform one user who has received an e-mail message from an unknown user, of a degree of separation between the unknown user and the one user receiving the e-mail message. The graph management system also allows a user to search the graph to understand a relationship link between himself and a different user on the graph. The user is able to search the graph in accordance with user permissions, as detailed earlier.

A search further includes searching the shared contact data stored in the contact data store 114 to identify contact details of at least one user. As an example, a user can search the graph for a managing director of a company. The search identifies that the managing director attended a school with a user who the user performing the search used to work with. Additionally, the search identifies that the managing director is a friend of a user who is a business contact with whom the user performing the search is in frequent contact with.

The graph management system identifies in a search all relationship links between two users, and displays a detailed map showing all these relationships. A user can use this map to identify different methods of establishing contact with the other user.

Using, for example, the data synchronisation tool 80 and the graph management system, a user can search the graph to identify further users and their contact details, since the data synchronisation tool 80, can update local contact data 92 with contact data including these contact details. In addition to performing a search, the graph management system is able to validate a sender of an e-mail address of a user using all known e-mail addresses of users on the graph.

The graph which is created using the shared contact data, representing user identities, and the shared relationship data, representing relationship links between user identities, is considered to be a 'trusted network.' Figure 11 shows schematically an exemplary trusted network. Each node 252 represents a user on the trusted network and each link 250 between two of the nodes 252 of the network provides validation of the user identity to a certain degree. The more validated a user identity becomes, then the more trusted the user identity becomes.

There are two types of user identity on the trusted network: users that have registered and provided their own contact data, and users that have not registered themselves but for whom contact data has been uploaded by a different user to form part of the different user's user relationship graph. Both registered and non-registered user identities are validated by a number of links which connect to a node. Where two registered users are linked together, the value of a relationship link connecting each node of the user is relatively high as both users vouch for each other and the relationship link is relatively less likely to have been faked.

For unregistered identities, trust is created by the number of trusted relationship links that link to the node of the user identity. This builds confidence that the user identity is real and trusted.

Networks of identities that are independent and not linked to a wider identity will score lower than identities in a much larger network such lower scored identities have a low trusted ranking. By way of example, figure 11 indicates users having a high trusted ranking 254 and users having a low trusted ranking 256.

The trust element for a user identity can also be reduced by reports from other users regarding that user identity, relating to, for example, spamming or ID theft. A trust score for each user, as determined using the trusted network, can then be made available for a wide range of applications to use, including for example, a spam filter, or third party applications such as ID Checking.

The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. For example, it is envisaged that the contact data updater 84 of the communication processing software updates the contact data database 56 with local contact data stored in the local database 88.

Further details of the contact database updater 84 will now be described.

The contact data updater 84 is a piece of software which runs on a server or device which is used to update the local contact database 56 with the information that has been extracted by the communication analyser 64 and the signature extractor 68.

The software of the contact data updater 84 goes through each individual contact held in the local database created by the communications analyser 64 and signature extractor 68, and checks the device or server's local database, such as the local content database 64, to see if the contact exists already. If the contact does not exist the software creates a new contact data entry with all the information gleaned by the communication analyser 64 and signature extractor 68 and also stores a complete version of the signature in the entry as well.

If the entry already exists, the software will analyse the date of the last update to the entry and compare it with the date of the signature to build an understanding of which contact information is the most up to date. The software will then bring the entry up to date and add any missing information which has been found by analysing the contact information. Again the software will store the complete signature and any update information with the entry so a user can see what contact data has been updated and the source the contact information came from.

This contact data update process can be performed automatically or can be performed as an interactive process with the user. The interactive process allows the user to choose which entries are updated and with what information. The user can also control which contacts are updated into the local address book by setting various parameters. The parameters used are the frequency of contact, the date of the last contact and the type of contact. For example a user may choose to update their address book with only the top 10% of their friends who they have been in contact with over the last year. Alternatively a user may choose to update their address book with only business contacts who they have transmitted a communication to.

It is further envisaged that a third party terminal, such as the third party server 50, connects with the computer software of the present invention, for example the graph processing software. This allows third party applications to utilise features of the present invention, for example data or software components.

As will be appreciated by the skilled person, the trusted network has a range of applications for enhancing other types of services. Exemplary applications that can take advantage of the trusted network and graph management system API will now be described. The term "sites" used in such descriptions should be taken to mean "websites". Auction Sites

Third party auction sites are able to validate at least one buyer's and seller's identity and e-mail addresses using validation information provided by the trusted network of the present invention. Furthermore a buyer can verify a seller's user identity and level of trust, and even understand degrees of separation between themself and the seller to give greater confidence in the purchase process of an auction.

Dating Sites

Third party dating sites are able to validate the user identity of at least one person on the dating service. Further, the dating site can give an individual a confidence that the people they are dealing with when using the dating site are real people and are traceable. Furthermore, by analysing degrees of separation information, dating sites can provide more effective people matching techniques by understanding connections between people.

Chat Rooms

Third party chat rooms are able to validate users of a chat room, particularly online chat rooms, using the trusted network of the present invention. Consequently, the likelihood of paedophiles impersonating younger people in chat rooms can be reduced and users of the chat room can understand their connections and relationships with people they are chatting with.

ID Checking

By analysing a user's personal information and matching this user identity information provided by the trusted network, a customer, as a third party, can validate an online identity and have greater confidence in dealing with individuals. Information about false identities or bad experiences, for example a fraudulent credit card transaction, can therefore be used to protect users from people using fake identities for fraudulent purposes. Telephone Services

The trusted network of the present invention may be used by a third party telephone service provider. One purpose is to build up a user's contact network in order to promote user activity of the telephone service network, and a second purpose is to control and moderate use of the telephone service network.

The telephone service may be a Voice over IP (VoIP) service, or a telephone service provided over alternative means, as will be appreciated by the person skilled in the art.

When a new user signs up to the telephone service, the user enters personal details in a registration process. These personal details are used to create a user identity for the new user. At this point the third party telephone service may access the trusted network provided by the present invention, which includes the shared relationship data, to validate the identity of the new user. If the new user's identity does not meet certain validation criteria, for example that the new user must be known on the trusted network, or that the new user's location on the trusted network does not exceed a specified degree of separation from a further user, the new user may not be permitted to call certain telephone numbers, or to access certain features on the telephone service network (such as features that require a level of trust such as getting credit, making calls outside the network, or calling multiple users at once).

The new user may wish to create a network of contacts available for them to telephone using the telephone service. The third party service may automatically create this network for the new user by analysing their previous electronic communications, rather than the new user manually creating their network of contacts on their own and likely creating a more comprehensive telephone service network which reflects their real contacts rather than their perceived contacts. In order for the third party service to create a user's telephone contact network, the third party service may also access the trusted network of the present invention in order to validate any user for adding to the new user's contact network. A user is added to the new user's contact network if their user identity meets certain validation criteria, and the user is not added if their user identity does not meet the validation criteria. The validation criteria may be set by the new user, or may be set by the third party telephone service. Setting up the new user's contact network in this way helps to ensure that the new user's contact network consists of only validated users who the new user can telephone and of validated users who can telephone the new user. This ensures that the new user does not receive unwanted telephone calls, such as spam telephone calls, via the telephone service or is subject to other abuse or fraud.

If the identity of a contact of a particular user of the service changes, thus modifying the relationship between the particular user and the user whose identity has changed, it is checked whether the changed user identity meets the validation criteria and the particular user's contact network is updated accordingly. Updating a user's contact network in this way may be initiated by the third party service. Updating may alternatively be initiated when a user makes a telephone call to a certain user on his contact network. In this case the third party service, before connecting the user to the certain user, accesses the trusted network of the present invention and validates the identity of the certain user, and most likely checking that the degrees of separation (DOS) between that caller and the recipient of the call are less than the minimum DOS required by that user. If the certain user's identity is validated, and the DOS is acceptable, the user is connected to the certain user, but if the certain user's identity is not validated, or the DOS is unacceptable, the telephone call is not connected.

Through this functionality, a third party network can control and regulate the users in the telephone service network, and allow more telephone service network activity because they are able to offer users the ability to allow calls from users whom they do not know, but with the important optional filter that they do not receive calls from either unknown users, or callers that are more than, for example, two or three degrees of separation away from them, without permission from the recipient user

The example described above describes that the telephone service is provided by a third party which accesses the trusted network of the present invention. It is further envisaged that computer software for providing a telephone service includes computer software in accordance with the present invention. In this way, a telephone service provider can establish a trusted network in accordance with the present invention, by analysing electronic communications, such as e-mail messages, of a user if the service. Consequently, validation of an identity of a user of the service can be performed without having to access a trusted network of a third party rather by accessing their own proprietary network which is created using the invention. Relationship data, or data derived from the relationship data, of this trusted network of the telephone service may then be made accessible to third parties.

Social and Business Networking Sites

A further third party application is for a social networking application. An example of such a social networking application is Passado™. A social networking application based on the Passado™ system allows individuals to become linked to each other within a network of social individuals. The links between the users are established using details provided by each user in a registration process.

In accordance with such a social networking application and the present invention, it is further envisaged that a different user who does not use the communication processing software of the present invention, provides shared contact data which is transmitted to the shared contact data store from a contact data store associated with a website. It is envisaged that the different user provides this contact data using a website accessed using the Internet browsing terminal 48. This website is, for example, a website of a social networking application. By analysing who a person knows through the client of the service, the client is able to provide to a social and business networking application person to person links which are independent and less likely to be biased; include weaker ties or links which social and business networking products require in order to be effective; and/or include the rapid inclusion of hundreds of links.

An unregistered user of the social and business networking application will sign in via a home page. The home page may include a search box allowing a user to search on the basis of common ground criteria, for example to find their school. A user would search or browse for the school, then enter the registration process (see below) and then finish the rest of the registration process with this common ground, in this case the school, already entered.

In a registration process a user provides name, username, password, and personal and business profile data.

In order to register social connections of a user, a user enters criteria which allow matching results, for example common ground connections based on existing databases of common ground connections, to be obtained.

After registration completes, the user will be transmitted a validation code to the login e-mail address.

Different types of social and business networks may be provided as detailed by the following examples.

Common Ground Networks

A user can link to multiple common ground networks, such as schools, universities, companies he was employed at, industry associations organisations he belongs to, and/or clubs. All links of this type mean that there is no specific contact to another identity, but a general connection to other identities share the same common ground. Some common ground networks provide the user with further common ground restrictions such as time-constraints, by allowing the user to specify that "I was at school A from 1990-1994", or ask "how strong is my common ground to someone who was there from 1948-1952?" For a school common ground network, teachers and other school employees will be included in the common ground connections for all the years the teacher was there at the school.

For a university common ground network, universities need to be separated from schools. Country specific issues may also arise in such a network. Such a common ground network needs to include details of departments, and degrees obtained.

For the network, a user has the ability to link to other contacts by a contact link. The following link types exist: a one-way link where a user links to another person. This type of link is possible between other registered users or unregistered users; and a confirmed link which is a two-way link which is possible to other registered users.

Each link also has a certain weight or strength (related to a simple, good, endorsed link. An endorsed link is a trusted link). A user can build their network by adding links such as common ground links and links to contacts such as family, friends, and business contacts. By automatically analysing the e-mail history of a user, a list of people best known to a user can be used for selection of common ground links. For adding contact links, the most active links with a user are determined. For a user who is not part of the social network, an invitation can be sent to this user. Also, a user can specify permissions of users who can access certain fields of his user profile. He can also specify who can access his contacts.

A user can view a graphical representation of a timeline showing links of a user in accordance with time.

A user can request an endorsement from a list of their contacts. An e-mail is transmitted asking for an endorsement and then the contact writes an endorsement and the user approves it before it goes live on the network.

A user can view their network, for example a user can display all common ground connections and display all contact connections. A user can also search or browse their network to, for example, find people, find a business, find hobbies, find a wants, find a haves, find an industry, find an old school friend, find an old university friend, and/or find an old work friend. When a person is selected in the network, a user can see the person's photo, their profile, the number of people that have contacted them and seen their profile, their membership options, their main contacts and any contact info which has been unlocked.

The network can be used for forum or chat services. This may allow a meeting to be set up, such as a school reunion, or a discussion on particular common topic or hobby. In order to set up a meeting, a user can: select a name for meeting, describe the meeting, propose a date, propose a venue (this may be virtual, real, or to be voted on), invite members (a specifically mentioned member can receive an invitation), and/or determine if attendee list is public or only visible to the organiser.

If a venue is voted a user would accept the invitation and can then vote on different venues, different times and the most votes win. A user may also view meetings.

For example, if a user is interested in golf and a meeting has been set-up regarding golf then the user would see proposed golf days in his country when he logs in. If the user was specifically invited then he would receive an invitation.

Further details of such an exemplary social and business networking application in accordance with the present invention will now be described. A migration from an existing social network application, for example a website allowing individuals to be reunited with individuals who attended the same school, to the social networking application, for example the Passado™ system, is envisaged.

An example will now be described. School reunion sites can migrate from that existing business model to a full social and business networking site.

However the problem that such sites have is that users that have already registered, often years earlier are reluctant to return to the school reunion site to enhance their registration with the additional information necessary to participate in the improved site.

The school reunion site includes the functionality of the Social and Business (S&B) Networking site. By differing a user incentives of being a member of the S & B site, in exchange for the user updating their registration information.

A school reunion club is therefore able to move from one business model to another, and in addition receive a massive number of new fully registered members in a short period of time.

It is further envisaged that computer software of the present invention, including the communication processing software and the graph processing software provides a "Peer to Peer" networking functionality.

By installing the client software in accordance with the present invention on local devices, such as a local terminal, the user has the option of uploading digital documents or information to a server, such as a server terminal, or has the option of making the data available through a peer to peer (P2P) network.

A Peer to Peer (P2P) network is a network of nodes which are joined together in a dynamic manner to participate in data traffic routing, data processing and bandwidth intensive tasks that would otherwise be handled by at least one central server, such as the server terminal described previously.

As the size of the network of the present invention increases and the number of clients sharing data grows, the costs and complexity of remotely hosting such data, for example on a server, may become more and more prohibitive. Using the processing and storage of such data is likely to remove these costs.

For implementation of the present invention on a P2P, as described above, the client software running on each user's client terminal will act as one node on the P2P network. Each user has a unique ID and makes available the data, such as relationship data and contact data, in a similar manner as for the central server. The client software processes, analyses and scores each contact, including extracting the signature information and storing this signature information locally to the client software, for example on the client terminal. Information, such as derived contact data and relationship data, is made available to other users using the client software. The user controlled permissions will also be made available in this way.

When a contact data search, for example, is initiated by a user, the client terminal will send a search request to all the contacts in its address book. The search request will be received by the client software of each of the contacts of the address book, which will then try and answer the search request and, if not successful, forward the search request to all the contacts in its own database, such as an address book, of contacts. By distributing the functionality of the graph management system to multiple clients via a P2P network, and executing the search in this logical process, the costs of managing the database are removed, and the performance of the search is greatly enhanced as each peer checks to see if it can answer the search locally before passing the request on to a further peer.

Unlike conventional P2P networks such as Gnutella™, the request is only transmitted to the nodes that are linked to the originating node through some means of commonality rather than broadcasting the request to all nodes on the network. By performing searches this way, the P2P network is far more scalable and efficient and minimises the volume of requests travelling across the network.

A conventional peer network is illustrated schematically in Figure 12. Nodes 260 and links 262 between the nodes 260 are indicated, as well as a client terminal 264 issuing a search request "Where is file A?" As illustrated, a further client terminal 266, having received the search request, locates the requested file A and confirms that it has located file A. The operation of a search for information is illustrated in figure 12. When searching for information content, the searching process is more efficient as all the nodes linked to the searching terminal have something in common, as each node is related to each other in accordance with the trusted network. Therefore it is very likely that the nodes will contain information which the searcher is seeking so by passing through a degree of separation route the search is more likely to be fulfilled in a fast and efficient manner. A further weakness of conventional P2P networks is that most of the nodes are anonymous or do not provide much identifying information about themselves. By overlaying the graph of the present invention, as described previously, over the top of the P2P network, it is possible for a user to understand more about the sources of information and the relevancy of these sources to the user. Furthermore this also works the other way in that a user can control and see who has access to their information in a far more controlled manner.

Users, when they register their identity on the trusted network of the present invention, and use the P2P client software, are then able to distribute not only their contact data over the network, but also to allow access to other types of data they have created.

By using the P2P network, a user can share their digital documents or contact information with other users without needing to upload it to the server. This allows a user to maintain full control of access, for example of other users, to their data and also to see which users access their data in real time.

Any digital media on their devices, such as the client terminal, can be shared with other users using the permissions database managed by the system of the present invention. For example, a user may publish their photo through their P2P client terminal and only make their photos available to their friends. Alternatively a user may publish a white paper available to all users, but unlike conventional P2P networks, other users can see further information about the identity of the publisher and the degrees of separation between the other users and the publisher, while the publisher can see and record which users have accessed that information. Thereby, a closed group for other communications in the future is created. Such sharing of digital media is not limited to implementation over a P2P network, but may be implemented over alternative networks.

By distributing data over the P2P network, as previously described, the requirements for the server's storage capacity are significantly reduced and this consequently provides a range of additional functionality. The P2P client software on a user's device can be used to allow communication with other users using a variety of different mediums including Instant Messaging, P2P E- mail and Voice over IP.

By moving the communication away from standard communication protocols, the identity of the sender, and of the receiver, of an electronic communication is controlled and managed in accordance with the present invention, thus allowing a more reliable and secure means of communicating. By using a communications system in accordance with the present invention, a certain user can apply the permissions database, as described previously, to control which other users can contact them and when. The certain user can also view the identities of other users who have accessed the information.

By basing the communication upon a particular user identity, a user has control of information that is released about them and can control where communications are transmitted without the need for releasing address information (e-mail address, telephone number) to other users.

The description of the present invention details the communication processing software being installed on the client terminal 2. It is envisaged that further client terminals, for example the further client terminal 38 which is a so- called "smart" mobile telephone, a server computer, a client computer, a Personal Digital Assistant (PDA) or further digital communication devices, include communication application software and communication processing software in accordance with descriptions given earlier. These further client terminals are arranged to connect with the graph processing software of the server terminal and function in accordance with the description of the client terminal 2 given earlier. The communication application software and the graph processing software are described in an embodiment of the present invention as being installed on the client terminal 2. It is alternatively envisaged that all of, or at least some components of, the communication application software and the graph processing software, are installed on a server terminal. In one further envisaged embodiment, the communication application software installed on a server terminal is not Microsoft Outlook™ but is alternatively Microsoft Exchange™.

In the described initialisation process of the communication processing software, the communication analyser analyses e-mail messages from the communication data database of the communication application software. It is alternatively envisaged that the communication analyser analyses data of logs of electronic communications transmitted from one user to a different user.

The electronic communications described in accordance with embodiments of the present invention are e-mail messages. It is further envisaged that the present invention processes different types of electronic communications, for example voice messages or electronic instant messages.

In accordance with embodiments of the present invention described earlier, relationship data and contact data is derived from electronic communications. It is anticipated that characteristics of a relationship between two users, represented by the relationship data, and characteristics of contact data of a user, represented by the contact data, are not restricted to the features described. It is envisaged that the relationship data and the contact data are indicative of further characteristics of user relationships and contact details of users. For example, it is further envisaged that the relationship data includes data representing a time at which an e-mail message was transmitted, or a time at which an e-mail was received, by a user. This e-mail message time is used to indicate a strength of a relationship between a first user and a second user.

Parts of the method of the present invention are described as being performed in accordance with settings or a set of rules. It is envisaged that different settings and rules may alternatively be used to perform parts of the method.

The server software described previously is detailed as being installed on the server terminal. It is anticipated that in further embodiments of the present invention that the server software is installed on a dedicated server terminal, which in a preferred embodiment uses HTTP protocol.

The previous description of the method of the present invention details features which are performed automatically by computer software in accordance with the present invention and features which are performed manually by a user of services provided by the method of the present invention. It is envisaged in further embodiments of the present invention that different features of the method are performed automatically and that different features of the method are performed manually.

It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments.

Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims

1. A method of processing electronic communications using a communication analyser associated with a communication agent, said method comprising: a) analysing one or more electronic communications transmitted from a first communication agent used by a first user to a second communication agent used by a second user, to derive relationship data, said relationship data being indicative of one or more characteristics of a relationship between the first user and the second user; b) transmitting first shared relationship data derived from said analysis to a store of shared relationship data such that a third party has access to said first shared relationship data or data derived therefrom.

2. A method according to claim 1, wherein said first shared relationship data includes data representing a frequency of transmitting electronic communications from the first communication agent to the second communication agent.

3. A method according to claim 1 or 2, wherein said first shared relationship data includes data representing a date and/or a time at which an electronic communication was transmitted from the first communication agent to the second communication agent.

4. A method according to claims 1, 2 or 3, wherein said first shared relationship data indicates a type of the relationship between the first user and the second user.

5. A claim according to claim 4, wherein said type is indicated as at least one of a category and a score indicative of said type.

6. A method according to any preceding claim, wherein relationship data indicates a strength of the relationship between the first user and the second user.

7. A method according to claim 6, wherein said strength is indicated as at least one of a category and a score indicative of said strength.

8. A method according to any preceding claim, comprising providing a local database associated with a communication agent, said local database storing local relationship data.

9. A method according to claim 8, comprising storing first local relationship data derived from said analysis in said local database.

10. A method according to claim 8 or 9, comprising updating said shared relationship data in response to updating of said local relationship data.

11. A method according to claim 8, 9 or 10, comprising querying said store for shared relationship data, and storing local relationship data derived from said shared relationship data in said local database.

12. A method according to any of claims 8 to 11, comprising providing a communication analyser associated with said first communication agent, using said first communication analyser to derive relationship data from one or more electronic communications and storing local relationship data in a first local database associated with the first communication agent.

13. A method according to any of claims 8 to 12, comprising providing a communication analyser associated with said second communication agent, using said second communication analyser to derive relationship data from one or more electronic communications transmitted by the communication agent used by the second user and storing second local relationship data in a second local database associated with the second communication agent.

14. A method according to any of claims 8 to 13, comprising updating local relationship data in a local database in response to updating of said shared relationship data.

15. A method according to any preceding claim, wherein said method further comprises transmitting shared contact data indicative of one or more contact details of a user to a store of shared contact data such that the third party has access to said shared contact data.

16. A method according to claim 15, comprising analysing said one or more electronic communications to derive contact data and transmitting shared contact data derived from said contact data analysis to said shared contact data store.

17. A method according to claim 16, wherein said analysis of one or more electronic communications to derive shared contact data includes deriving contact data from signature data of an electronic communication.

18. A method according to any preceding claim, comprising a user providing contact data during a registration process, and transmitting said contact data provided by the user to the shared contact data store.

19. A method according to any of claims 15 to 18, wherein said contact data includes identification data which uniquely identifies a user in said shared relationship data store.

20. A method according to claim 19, wherein said unique identification data includes an electronic mail address.

21. A method according to claim 20, wherein the unique identification data includes a plurality of electronic mail addresses, each of which uniquely identifies a same user in said shared relationship data store.

22. A method according to any of claims 15 to 21, wherein said contact data includes contact details including at least one of: a name, a title, a company name, a address, a telephone number, a fax number, a mobile telephone number.

23. A method according to any preceding claim, comprising providing a local database associated with a communication agent, said local database storing local contact data.

24. A method according to claim 23, comprising querying said store for shared contact data, and storing local contact data derived from said shared contact data in said local database.

25. A method according to claim 24, comprising storing first local contact data derived from said analysis in said local database storing local contact data.

26. A method according to claim 24 or 25, comprising storing second local contact data provided by said first user in a local database associated with the communication agent used by the first user.

27. A method according to any of claims 23 to 26, comprising updating local contact data in response to updating of shared contact data of said store.

28. A method according to any of claims 15 to 27, comprising transmitting shared contact data to the shared contact data store from a contact data store associated with a website.

29. A method according to any preceding claim, comprising searching the shared relationship data of the store to identify characteristics of a relationship between two different users.

30. A method according to any of claims 15 to 28, or to any of claims

15 to 28 and claim 29, comprising searching the shared contact data of the store to identify contact details of at least one user.

31. A method according to any preceding claim, comprising classifying one or more electronic communications using a communication classifier associated with a communication agent, wherein each of said one or more electronic communications is classified using local relationship data stored in a local database and/or shared relationship data stored in the store.

32. A method according to claim 31, wherein the communication agent associated with the communication classifier indicates a classification of an electronic communication to a user.

33. A method according to claim 32, wherein electronic communications having different classifications are indicated differently to the user.

34. A method according to claim 32 or 33, wherein said indication of classification is visual.

35. A method according to any of claims 31 to 34, comprising analysing one or more electronic communications to identify potentially unwanted electronic Communications and classifying any potentially unwanted electronic communications.

36. A method according to claim 35, wherein said analysis to identify potentially unwanted electronic communications includes using a Bayesian filter technique.

37. A method according to any preceding claim, comprising analysing a set of previously stored electronic communications.

38. A method according to any preceding claim, comprising analysing an electronic communication in response to transmission or receipt of an electronic communication.

39. A method according to any preceding claim, wherein each electronic communication is an electronic mail message.

40. Computer software arranged to perform the method of any preceding claim.

41. Computer software arranged to analyse e-mail messages, including one or more e-mail messages transmitted from a first client terminal used by a first user to a second client terminal used by a second user, to derive relationship data which is indicative of a relationship between the first user and the second user, wherein said computer software is arranged to transmit shared relationship data derived from said analysis to a store of shared relationship data such that a third party has access to said shared relationship data or data derived therefrom.

42. A data carrier storing the computer software of claim 40 and/or claim 41.

43. Apparatus arranged to perform the method of any of claims 1 to 39.

44. A method of processing electronic communications using a communication analyser associated with a communication agent, said method comprising analysing an electronic communication transmitted from a first communication agent used by a first user to a second communication agent used by a second user, said electronic communication including a message header containing one or more message transmission parameters, and a message body containing text, wherein said analysis includes parsing a plurality of parts of said text and rating each part using a plurality of rating rules, selecting at least one of said parts with a rating indicative of a high likelihood of contact details of said first user being found in said selected part, and deriving one or more contact details from said selected part.

45. A method according to claim 43, wherein said rating rules are adapted to tend to identify a signature part of the electronic communication.