A METHOD FOR AUTOMATICALLY CLASSIFYING COMMUNICATION BETWEEN A SENDER AND A RECIPIENT

INTRODUCTION

The invention relates to a method of communicating messages between a sender and a recipient in an electronic message system, e.g. e-mail messages, voice, fax or data calls. The system includes a database which contains a collection of identities of potential future senders of messages from whom the receiver has previously requested information. In the following, this list will be referred to as an evidence collection.

BACKGROUND OF THE INVENTION

An increasing growth of the popularity of electronic mailing systems for exchanging information globally has caused an increasing desire of reducing the number of received messages by automatically filtering out unwanted messages. Spam mail, i.e. mail messages which are forwarded to a large number of recipients which may or may not be interested in the information, as an example if the information is purely for advertising a product.

Today, the predominantly used anti-spam approach is a Bayesian statistical filter as described by Paul Graham in "A Plan for spam"

(http://www.paulgraham.com/spam.html). In this approach, a statistically calculated value is assigned to every message that indicates whether a given email is likely to be spam, not spam or whether the question is undeterminable. There are other solutions used at the present time. Most of these solutions either use an adopted version of a Bayesian filter or heuristic/Static filter rules to determine spamminess of a message, i.e. likelihood of being spam.

Another filter type is described in US 6,199,102 where a prompt is designed to require manual operation whereby an automatic reply set up by a computer system, e.g. a computer system adapted for forwarding messages to a large

group of recipients, are filtered out. The required manual operation could be a required response to a question, e.g. "what is the colour of the sky", or "what is the current month". In such a system, there is always a potential risk that people of interest to the recipient get annoyed over the problems, and give up trying to reach the recipient e.g. after having given a wrong answer, e.g. by misspelling the colour of the sky.

In other filters, a fixed list of approved potential senders is examined when a new message arrives. If an ID of the sender is included in the approved list, the message is delivered to the intended recipient. Since the arriving messages are judged from a fixed list, there are typically a tremendous amount of rejected messages. In professional use of e-mail servers, maintenance of the filter is required, e.g. by having employees dedicated to update the list of approved potential senders or an analogue list of non-approved potential senders.

One common issue with the filter methods in use today is that they sometimes incorrectly classify a message as being spam (False-Positive) or they assign a message as being undeterminable because the likelihood of being spam is close to 50 %. Most recipients find that False-Positive are just as critical or even more critical than intercepting spam. A False-Positive could cause a recipient to miss an order, a flight booking, or to miss other types of critical messages. To aggravate the problem, the existing spam filters have improved over the last years and they have therefore created a tendency that recipients no longer review messages that have been blocked by the filter.

Another problematic area today is fee free or low cost IP based phones, fixed phone and mobile phone carriers. The problem with unsolicited (promotion) calls/SMS has already started to become a burden on this type of communication systems. Today one can configure most of these real time communication systems to accept only calls from people or other devices which are already known. As an example one can accept only calls from persons in an address book. But often a user will have communicated with a person via a different communication channel before receiving a call. This received call will be

blocked unless the person receiving the call has added the contact details the calling entity.

DESCRIPTION OF THE INVENTION

It is an object of a preferred embodiment of the invention to reduce the number of groundlessly rejected messages or calls and to facilitate a less burdensome maintenance of a message system. Accordingly, the invention, in a first aspect, provides a method of communicating messages between a sender and a recipient in an electronic message system. The message system is of the kind comprising an evidence collection with common identifiers of potential future senders of messages. These potential future senders have previously been contacted by the recipient. The invention comprises the steps of:

- sending in a first format, a first message from the recipient to a potential future sender,

- normalizing an identity of the potential future sender to provide a common identifier,

- including the common identifier in the evidence collection,

- receiving from a sender, a second message which is intended for the recipient and which is in a second format being different from the first format,

- providing an identity of the sender of the second message,

normalizing the identity of the sender to provide a common identifier, and

- comparing the common identifier of the sender with common identifiers in the evidence collection.

Accordingly, messages from a sender which has previously been contacted by the recipient are not filtered out but delivered to the intended recipient.

The current invention helps recipients in minimizing the false-positive by checking all messages or messages blocked as spam against the evidence collection of the recipient. The invention can then allow a message to be relayed to the recipient even if the context of the message has a high or medium spamminess, thereby, eliminating a high percentage of False-Positives and still keep real spam messages blocked. To avoid the manual and burdensome task of manually maintaining a white list, the current invention can be used for maintaining an evidence collection based on who the receiver has previously contacted across protocols and message formats.

To be able to compare Identities from different protocols and formats, it may be necessary to normalize a specific Identifier to a generalized Identifier called a common identifier. For instance the HTTP identifier BookFiightsForFun.com can be normalized to bookFlightsForFun.

The most simple form of a Normalizer is to make no changes to the identifier and use that as the common identifier. For instance: booking@bookfnghtsforfun.com Identifier booking@bookflightsforfun.com Common Identifier

The method can be combined with any of the known filtering methods, e.g. so that a sender of a message is firstly compared with a fixed list of approved senders and subsequently with the evidence collection. If the sender appears in just one of these lists, the message in question is delivered to the intended recipient.

In this regards, the first message can be a request provided on the internet, a message by telephone or in general by any electronic media for communication. As an example, the first message can be sent from the recipient to the potential

future sender when the recipients browse the internet and enters the potential future sender's web-address. Since the internet address is reached as a consequence of a request from the recipient being received by the potential future sender, this action is, in fact, equivalent to sending a message from the recipient to the potential future sender.

The identity of the potential future sender can be any kind of insignia which defines the sender, e.g. an e-mail address, a web address, a telephone number, a physical mail address, or simply the name of the potential sender. Correspondingly, the identity which is provided of the sender of the second message can be an e-mail address, a DNS address of a computer through which the sender sends the second message, a transport-protocol identifier of the sender, e.g. mail from specified in RFC 2821, or the sender can be identified from a message format e.g. the "from" field in mime code as specified in RFC 2822 of the sender. The sender of the second message can also be identified from the contents of the second message.

When the recipient visits an internet page, the domain name of the internet page can be written into the evidence collection. When at a later point in time an e-mail is received, it is analyzed if a domain name from the evidence collection is included in the e-mail address of the sender of the e-mail. For this purpose, the e-mail address of the sender can be broken down to fragments, e.g. between each delimiter in the name, e.g. so that the word between each full stop in the e-mail address is compared with the identifiers in the evidence collection.

A match between identities can mean any kind of relationship between the identities, e.g. identical names, numbers etc, or identical phrases in names or identical digit-combinations in numbers. A match can even be identical groups of interest. The recipient may e.g. have visited a woodworking company, and the word woodworking becomes an identifier in the evidence collection. Whenever a company which can be identified with the word "woodworking" sends an e-mail, the e-mail is delivered to the recipient due to the match between the words "woodworking" . As an example, woodworking can be included in the company

name, example: Ohio woodworking company or e.g. a person's e-mail address where woodworking is included (paui@iouis. woodworking. com )

When a match between an identifier in the evidence collection and the identity of a sender of a second message has been found, the second message is forwarded to the intended recipient. The message may e.g. be associated with an additional message to the recipient that the message past the filter due to registered interest of the recipient in the sender's web page or due to other contact with the sender and initiated by the recipient, e.g. in connection with the full details of such contact.

If no match between any identifiers in the evidence collection and the identity of a sender of a second message can be found, delivery of the message to the intended recipient may be rejected or other rules or filters may be applied to verify if the message can be delivered based on other criteria. If the message is not delivered to the intended recipient, a message may be generated and send to at least one of the recipient and the sender informing at least one of these two parties of the session that delivery of a message has been refused. The recipient may e.g. be informed that requesting information from a web-page owned by the sender may lead to an approval of the sender and thus the release of the refused message.

It may be advantageous, before the delivery of a second message to a recipient, to evaluate not only if the recipient has previously shown interest in the sender, but also by which communication medium the recipient has initiated contact to the sender. Accordingly, the evidence collection may comprise not only the identities of potential future senders but also corresponding formats or protocols in which the first message was sent to the potential future sender. As an example, the identity can be a web address and the format can be hypertext markup language (HTML) etc.

The evidence collection can be updated one by one each time the recipient contacts an entity or the list can be updated in batches to reduce the number of updates of the list.

The evidence collection can be generated and updated by a third party provider, e.g. as a consequence of the recipient requesting information about a potential sender from a third party information provider. As an example, the recipient may have used a telephone number provider or used an internet search engine (Google, Yahoo, etc) to request information about a certain entity. An identifier of this entity is then added to the evidence collection and the entity is thereafter cleared to send messages such as e-mails to the recipient.

The evidence collection can be shared amongst a group of recipients. As an example, all employees belonging to a company or to a specific department may share one list. A group can also be a group of friends, relatives, people or companies with the same interests etc. that share a common evidence collection. In addition to the shared list, each individual may have its own list, i.e. a collection of "private" evidence identifiers.

In a second aspect, the invention provides a communication system adapted for communication between a sender and a receiver in accordance with at least two different communication protocols, the system comprising a sending entity, a receiving entity, a data base containing an evidence collection comprising names of potential future senders of messages, the system comprising processing means adapted to:

- sending in a first format, a first message from the recipient to a potential future sender,

- normalizing an identity of the potential future sender to provide a common identifier,

- including the common identifier in the evidence collection,

- receiving from a sender, a second message which is intended for the recipient and which is in a second format being different from the first format,

- providing an identity of the sender of the second message,

normalizing the identity of the sender to provide a common identifier, and

- comparing the common identifier of the sender with common identifiers in the evidence collection.

In particular, the system could be a client/server computer system in which the evidence collection entries are generated by a central system, e.g. a computer system, e.g. by a gateway, a pbx or a proxy server.

DETAILED DESCRIPTION OF THE INVENTION

In the following, embodiments of the invention will be described in further details with reference to the drawing in which :

Fig. 1 illustrates an overall system architecture of a communication system,

Figs. 2 and 3 illustrate particular of an evidence collector plug-in,

Fig. 4 illustrates diagrammatically an Enterprise implementation,

Fig. 5 illustrates an embodiment of a software implementation of the invention,

Fig. 6 illustrates diagrammatically a client side of a software system according to the invention,

Fig. 7 shows a diagrammatical view of a system according to the invention, and

Fig. 8 shows a diagrammatical view of a system according to the invention.

In one embodiment, the invention can be split into the following components that can be implemented either in one entity or in multiple entities.

Evidence collection

An evidence collection is a data structure that stores a collection of all the evidence collected for a specific recipient or a group of recipients or a combination thereof. The evidence collection can be stored on any kind of accessible storage media or memory, but preferably on a solid state storage media or on a hard-disk to preserve the collection over time. The common way to store and search the evidence collection is to use a database.

The minimum information for an evidence collection is a table with one field per row. This field is known as a common identifier and it can be used across different transport protocols and message format protocols.

For instance:

Name as char 100

It is recommendable to choose a common identifier that is easily searchable and easily obtainable from different protocols. A name can be used as this field; a name could be either a company name, a company name split in a new record for each separate word in the company, real person name, etc. If a name is used as the common identifier, it is advisable to use a string splitting algorithm (see Evidence Normalizer) to separate a company name into it's individual pieces and merged words. Thereby avoiding common company classifiers like (INC,SA,Ltd, etc.) and making the evidence more searchable :

For instance

Imencro Software INC. could be split into Imencro and ImencroSoftware.

A common identifier can be more than one type of identifier to identify different types of entities.

For instance

ImencroSoftware Company Name ThomasX Person's Name

IceVessel Entity Name

Different kinds of field types can be used for the common identifier. An example of this is a hash of the Name. The hash algorithm could be constructed in such a manner that it allows almost identical names to be found by one and the same search.

A single field evidence row is not enough if the implementation needs to allow different protocols as clients. Assuming that the evidence is used for allowing only incoming calls from known sources and at the same time is used for allowing False-Positive emails to be forwarded to the recipient, the evidence row should be expanded to include a protocol identifier.

For instance

Name as char 100

Protocol as char 5

The contents of such a table could be:

For instance

ImencroSoftware , Http

Thomas X, Email

Bank One, Telex ZYX, Phone

It is also possible to have more than one table in the collection if more than one unique common identifier is needed.

For instance

Table one:

Name as char 100 Protocol as char 5 LastContact as datetime Table two:

DNSName as char 100 Protocol as char 5 LastContact as datetime

In the above example, the second table stores the DNS name of servers which have been contacted and the protocol on which the connection was made. The LastContact field is used for determining when the identity was last contacted. This field can be used to invalid rows after a specific time has passed.

In combination, these two tables can be used for allowing incoming messages.

For instance

Recipient A browses to webpage wj/vw _; thjsjsajiej(anτBJex£rn

The evidence collection is now updated to appear as follows. Table one thisisanexample, HTTP, 01-01-2006 11 :00 AM Table two thisisanexample. com, HTTP,01-01-2006 11 :00 AM

Recipient A calls Thomas X and the tables are now updated to appear as follows.

Table one thisisanexample, HTTP, 01-01-2006 11 :00 AM

ThomasX, Phone, 01-01-2006 11 : 10 AM Thomas X, Phone, 01-01-2006 11 : 10 AM

Table two thisisanexample. com, HTTP,01-01-2006 11 :00 AM

Evidence Collector:

The evidence collector is used by the system to collect evidence into the evidence collection. In most implementations, the Evidence Collector will have two modes or one of the two modes. The first mode is the batch collector which uses an event to be activated and then collects the accumulated evidence into the Evidence Collection. In this mode, the evidence collector obtains the evidence from the evidence provider by pulling it (E.G. Browser history log, Proxy server, phone PBX etc.). It does so by preferably calling an API on the evidence provider to get access to a log of evidence. Sometimes, it may be desired to implement the evidence collector so that it monitors a first, primary, request and ignores requests resolving from the primary request.

Referring to Fig. 1, when a user uses his browser 101 to browse a page, the browser stores a history of the pages visited by the user in a data structure 102. The browser history 102 normally consists of the time when the page was visited and http link of the page which was visited. As a minimum for the evidence collector 105 to work the information in the history must consist of at-least address information about the pages visited the user. The evidence collector 105 uses a timer 106 to be activated periodically. When the evidence collector 105 receives a signal from the timer 106 it calls the web Browser API to access the browser history 102. Some browser implementation may not expose an API 104 to access the browser history in which case the evidence collector 105 access the history data 102 directly.

The evidence collector 105 collects history items that have not been previously collected from the API 104 or directly from the Browser History 102. After collecting the history items, the evidence collector calls the Evidence Normalizer 108 which normalizes the collected item to the common Identifier of the

Evidence collection. A simple but effective normalization of web requests can be done by removing the TLD and prefix from the domain name. The Normalizer returns the common identifier to the evidence collector which puts the identifier into the evidence collection 107 together with the time when the identifier was visited last time and the protocol type that was used which is HTTP in this example. If the user has browsed to a common identifier which already existed

in the evidence collection with the same protocol, the existing entry is updated with the current time.

The above principle can be used on devices, applications and gateways that support getting an identifier of the contacted entity, no matter what protocol is used, if a way to normalize the identifier into a common identifier exists (see Evidence Normalizer for more on how to normalize identifiers).

An evidence collector does not necessarily use the transport protocol to collect evidence but can also use the Message as a source for getting the Identifier See Fig 1.

The second mode is to use the evidence collector in plug-in mode which has the advantage that evidence collection can acquire evidence in real-time when the evidence provider allows it.

Evidence Collector plug-in :

Referring to Fig 2, if a browser 201 allows for third-party plug-in, the evidence collector 203 can plug directly into the browser 202. This approach makes the evidence more accurate when a common identifier needs to be tested as against the Evidence Collection. Using a plug-in makes no changes to the way the Evidence collector collects evidence compared to Fig 1 other than the fact that plug-in 202 delivers the history items directly to the evidence collector in real- time 203. To further improve the plug-in collector it could be implemented to add only the primary requests address (Those appearing in the address bar of the browser) and not any subsequent request generated by the primary requested page (could be adds, pictures etc).

Evidence Normalizer:

The Evidence Normalizer is used for converting different protocols or message formats identifiers into a common comparable identifier (From now on and previously called the common identifier). One preferable common identifier is a

Name which can identify anything like a Company, Person or any entity that can be identified by a name. The Normalizer can be constructed to have collisions.

For instance

An email is send to Thomas.X@testing.com A phone call is made to Thomas Tester

In the above example, a Normalizer could be constructed to only use the first name which would be Thomas for both messages even if the communication takes place with two different persons. These collisions do not disrupt the system but may allow anyone called Thomas to be validated against the evidence collection. Since, in a preferred embodiment, the system uses a field in the Evidence collection to keep track of the last contacted time, the impact of the collisions will be minimal.

If the common name is not directly obtainable from the message format or transport protocol the Normalizer can use a third party common identifier provider to obtain the name to be normalized.

If a system uses different protocols, it may be an advantage to use a unique Normalizer for each protocol. This is especially meaningful if the protocols or message formats also use different identifiers.

The common identifier of the sender may be compared with entries in the evidence collection in a strict manner so that coincidence is only indicated upon literal, identical match between the identifier of the sender and an identifier in the evidence collection. The common identifier of the sender may also be compared with entries in the evidence collection in a less strict manner so that coincidence is indicated at least a matching phrase in the identifier of the sender and an identifier in the evidence collection. In one embodiment, the evidence checker is adapted to return a value that describes how close an identifier of a sender matches an identifier in the evidence collection, i.e. how great the similarities are. This could be done by making a suitable hash of the identifiers

to be compared and by returning the minimum distance between the values. The returned value can be used either to allow a message to be received or the output can be used as an indicator together with other values.

For instance

http: www.imencrosoftware.com/testinq.htm

FAX: +41 26 456 545 545 12

In this example, two Normalizers can be used. The first Normalizer would be a HTTP Normalizer that normalizes the address to Imencrosoftware Http Normalizer rules described in Evidence Collector fig 1. The second Normalizer can use a Third party common identifier provider to lookup the phone number and get the name of the called entity. The entity called can then be normalized to Imencro, ImencroSoftware and ImencroSoftwareSA if the name return by the Third party provider is Imencro Software SA.

Evidence Checker:

The evidence checker is used to check incoming communication identifications against the evidence collection. The evidence checker compares a common identifier to the evidence collection and returns a value, e.g. a Boolean with the outcome of the comparison. This comparison can be a strict or a loose comparison depending on the implementation. The returned value can be used to either allow a message to be received or the output can be used as an indicator together with other values.

The returned value could be used together with a calculated spamminess of the message. In such a system one could make a rule that specifies that if the spamminess of message is less than 65% and the Evidence Checker returned true the message would be forwarded. But if the spamminess of the message is above 50% and below 65% and the Evidence Checker returns false the message is quarantined. And if the spamminess is above 65% the message will always be quarantined no matter what the Evidence Checker Returns.

Common Identifier Black List:

A common identifier Black list can be used for filtering out commonly used names to avoid that names which are currently in the evidence collection can be predicted by people who wants to send spam. The black list can also be updated to remove identifiers which are already WhiteListed in other places of the system.

Evidence providers:

Evidence providers can be any system that allows any kind of electronic messages or communication and that upholds the following three rules:

1. Has a transport and/or a message protocol that enables the receiving entity to be identified.

2. Provides a way to access real-time traffic monitoring or a way to access logs of communication including the receiving identification.

3. That a Normalizer can be constructed to normalize the identifier to a common identifier.

An evidence provider applying to the above 3 rules can be used for collecting evidence (Common Identifiers) and evidence providers that also apply to the following optional 4 ^th rule can also use an evidence checker:

4. An evidence provider that also supports incoming communication can use an Evidence Checker for filtering the incoming requests if the incoming communication allows at least the sender identification to be extracted and this identifier can be normalized to a common identifier.

As an example of implementation of the 4 ^th rule, a proxy server will normally only support outgoing request for a user and can therefore not be used together with an Evidence Checker according to rule 4, whereas a SMTP server can, if configured to do so, both relay messages for a user and receive messages for a user. According to rule 4, this means that it can use an Evidence Checker.

A proxy server will normally only support outgoing request for a user and can therefore not be used together with an Evidence Checker according to the rule, whereas a SMTP server can, if configured to do so, both relay messages for a user and receive messages for a user. According to rule 4, this means that it can use an Evidence Checker.

For instance Common Evidence Providers:

Web browser

Phone

Cell Phone IP Phone

Tapi application

SMTP engine

Proxy server

PBX (IP or Old Fashion private branch exchange) Provider based phone central

Provider based phone based logs

Telex machine / Telex Server

Fax machine / Fax Server

PSTN

Third party common identifier providers:

A third party common identifier provider is used when the evidence provider does not provide an identification that can be used directly by the Normalizer to construct the common identifier. Assuming that the common identifier is a Name as described previously, the Normalizer would not be able to convert a phone call into the name of the called person or entity. For this purpose, a third party common identifier can be used for translating one identifier into an identifier that can be used by the Normalizer.

In Fig. 3, a user using phone 301 makes a call to the person using phone 302 by dialling the number +41 26 999 888 55. The Evidence Collection Plug-In 303 is notified by the phone 301 that an outgoing call is taking place by supplying the Phone number to the Evidence collector 303. As previously described, the Evidence Collector plug-in 303 forwards the Identifier to the Evidence Collector 304 which, in turn, calls the Evidence Normalizer 305. The common Identifier for

this sample is the Name which the Normalizer cannot construct from the Phone number, and it therefore calls the Third party common identifier provider 306 which looks up the called phone number in the white/ Yellow pages and returns the Name ZYCX C/0 to the Normalizer. The Normalizer 305 normalizes the Name to zycx and returns it to the Evidence Collector 304 which stores it on the Evidence Collection database 307.

For instance Common Third party common identifier providers:

White/Yellow pages (Any phone book which can be accessed by the system) Ripe.net

Address books

IP phone directory ( _. http://ww etc.)

Global address book

Currently the inventor does not know of any address book providers that publish global address books but they could easily be constructed and will be to the advantage for the current invention. A global address can be used as a Normalizer because it can resolve all communication entries to common identifiers.

For instance Global address book

Common Identifier: AD994E74-04C9-4798-810A-536992093E4A Fax numbers: +41 255 2411 2554, +41 255 2411 2555 Email address: support@bookflightsforfun.com, bogj<[πg_@bθ£kjjjgh_tsfpj^uji^gjπ Domain names: bookflightsforfun.com

Phone Numbers: +41 255 2511 2554, +41 455 2411 2554 ... Mobile numbers: +41 79 213 321 140, +41 79 213 321 141 ...

Common Identifier: AD994E74-04C9-4798-810A-536992093E41 Fax numbers: +41 255 2411 2554

Email address: hms,3JiάerseR@hQθkfMhtsfwlUD _^ com, hans@hansenemail.com

Phone Numbers: +41 255 2511 2554 Mobile numbers: +41 79 213 321 140

In the above example, a lookup of hMls.ajideise^ would resolve to the common identifiers AD994E74-04C9-4798-810A-536992093E41 and AD994E74-04C9-4798-810A-536992093E4A, while hans@hansenemaJLcom _. would only resolve to AD994E74-04C9-4798-810A-536992093E41.

System implementation suggestions

The system can be implemented in many different ways, but the preferred implementations are as follows:

Single Device implementation

An implementation where the Evidence Collection, Evidence Collector, Evidence Plug-ins, Evidence Normalizers, Evidence Black list and Evidence Checker are constructed in such a way that they run on a single device per installation. This kind of implementation is useful for single devices which are accessed by one or more users. If the implementation is meant for PC's the normal implementation will use a Evidence collector that obtains evidence from Web browsers, IP Phones and Email Client, etc. The evidence checker will be called from the IP Phone applications and Email Clients to allow email and calls.

Enterprise Implementation

In this type of implementation, the different parts of the system can be implemented separately so that each part can run on different servers. Each part can then communicate with other parts using Web service, RPC, etc. It is also possible to combine two or more parts into one part if needed. In most enterprise implementations, an authentication module maybe desired so that evidence from different users can be identified and later be used by that user only or by a group of which the user is a member. Common evidence providers in this type of implementation are Proxy servers, SMTP mail gateways, PBX, IP

PBX, etc. The evidence checkers would normally be used for e-mail and phone calls.

Fig. 4 illustrates an embodiment of Enterprise Implementation. A User X wants to book a flight and decides to book this via book flights for fun. X starts booking the flight by opening a browser and typing www.bookflightsforfun.com in the address bar. The desktop computer browser sends the HTTP request to www.bookflightsforfun.com via the Proxy server. On the Proxy server, there is a Evidence Collector Plug-In that listens to outgoing requests to web pages. The Plug-In calls the Evidence Collector running on the Evidence Server via a web service. The Evidence Collector uses a HTTP Evidence Normalizer that normalizes the web request to bookflightsforfun. The User x completes the booking on the webpage and when asked for an email the user writes the email which is the email of the person for whom the booking is made. The webpage also asks for a phone in case there is an issue with the booking, here X supplies the mobile number of B. The "book flights for fun" backend servers generate a confirmation email which is sent to b@organisation.com via "book flights for fun" email server to the SMTP server of the organization. The SMTP server receives the email and during the SMTP transport, the email address is extracted from the "mail from" (RFC 2821). The email address is checked using SenderID to confirm that the email address sender is the true owner of the email address. After the email has been received by the SMTP server, it is first checked for viruses. The SMTP Evidence checker is then called and checks the email address bookings@bookflightsforfun.com against the Evidence collection using a SMTP Normalizer and the Evidence Checker on the evidence server. The Normalizer normalizes the email address to bookflightsforfun and this common ID is then checked against the evidence collection on the evidence server. Since the common id is found in the evidence collection, the email skips the spam check and is released directly to the corporate email server. A person working at Book Flights For Fun finds that there is a double booking for B and decides to call B with the supplied mobile number to ask why this was made. The call is received via GSM by B's mobile phone; before the phone notifies the user by ringing, the incoming Identification (Callers phone number) is checked against the evidence

collection using a GSM Evidence Checker. The Checker calls the web service evidence checker on the evidence server via GPRS with the phone number of the caller. The evidence checker uses a Phone number Normalizer to normalize the phone number. The Normalizer first gets the name of the calling entity using a external phone book provider via a webservice. The Normalizer normalizes the name Book flights for fun to Bookflightsforfun and the Evidence checker checks this against the evidence collection. In this example, the Bookflightsforfun exists in the evidence collection and the evidence checker, therefore, returns true to the mobile phone. The mobile phone alerts the user B with a specific ring tone that enables B to distinguish that this call is coming from a source he or someone he knows has communicated with lately.

Service Provider Implementation

The service provider implementation is very similar to the enterprise implementation with the exception that the evidence collection, Common identifier black list, Evidence checkers and the Normalizers are running in a central location supported and run by the service provider. In some cases the services can even be split so that some run at the service provider and others at the service subscriber. In most cases this will only concern evidence collectors as these can be implemented easily at the subscriber and give the evidence collection access to otherwise inaccessible evidence. The service provider also needs to implement an authentication schema that enables the different subscribers of the service to be uniquely identified. This authentication is then used for associating subscribers with specific Evidence collections and other specific subscriber services. The authentication can also be used for associating different subscribes in groups.

Fig. 5 illustrates a simple embodiment of the invention which allows emails to be delivered to the recipient even if a spam filter classified the specific email as spam by performing the following : 501 is the email client executing on a client computer receiving an email. 502 is one or more build-in or third-party content scanner which classify the spamminess of an incoming mail. 503 if a content scanner determines that the incoming email is not likely to be spam, the email is

delivered to the recipient's inbox. 504 is the inbox of the email client, which displays or stores the incoming emails. If the email is classified as spam, the sender's identification is extracted from the incoming emails from header (RFC822 or RFC3822) and is then normalized by using an email Normalizer 505. As an example, the Normalizer could normalize the email testing.User@mimetest.com to TestingUser, mimetest and mimeTest.com. 506 The evidence checker is called to check if the normalized common identifier exists in the evidence collection. If there is a match, the email is forwarded to the inbox. If no match has been found, the email is put in Quarantine 507.

Referring to Fig. 6, a block diagram of a normal client embodiment is shown, 601 is the receiving email client's message getter (E.G. POP) executing on a computer. 610 checks if sender's identification is on the white list. If it is on the white list the email is put directly in the inbox 604. If not the email is passed onto the content scanner 602. 602 is one or more built-in or third-party content scanners that check if the incoming mail is spam. 603 the email client decides if the incoming email is spam based on the content scanner result, the inbox 604 which either stores the incoming mail or which displays the incoming email to the recipient, 605 is activated when an email arrives in Quarantine 607. 605 Email address Normalizer normalizes the From RFC2822/RFC822 to the common identifier. The common Identifier is then checked against the Evidence Collector using the Evidence Checker 606. If the common identifier is found in the collection, the email is removed from the Quarantine 608 and the sender's From address is added to the WhiteList 609 and subsequently delivered to the inbox 604. If the common Identifier is not found in the evidence collection, the email is left in the Quarantine store 607.

Referring to Fig. 7, 701 is a PC with means for communicating messages between a sender and a recipient in an electronic message system. As an example, the communication could be between a browser and a web server. The user sends a first message 702 to the webpage. This message could e.g. be a request for viewing a specific web page, and it could be in Html format and transported via an http transport protocol. Such a message could be: www.bookflightsforfun.com which is hosted on the Webserver 703. The Evidence

Collector collects the identifier www.bookflightsforfun.com and includes the normalized common identity (E.G. bookflightsforfun) of the potential future sender in the interest evidence collection on a database server 709. The user books a flight and receives from server 705 a message in a second format. This message could e.g. be a mail message which is in the Mime format. The user's e-mail server 707 receives the email from the 705 server and normalizes the identity bookings@bookflightsforfun.com to bookflightsforfun. The common identifier is then checked against the evidence collection and the message is delivered to the user on PC 701 as the common identifier, in fact, was in the evidence collection.

In the following claim 1 is described in relative to one specific embodiment with reference to an exemplified communication. Referring to fig 8:

- the person with the cell phone 801 calls the company IT Global Support 802 to get support on a current issue. This is done by dialling the number +41 56 212 2114 and sending the call via GSM to the fixed phone 802. This corresponds to one embodiment of the specification "Sending in a first format, a first message from the recipient to a potential future sender" in claim 2.

- the phone uses an external evidence system provider 803. The cell phone sends the identification of the recipient (+41 56 212 2114) taken from the GSM protocol to the server 803 which normalizes the identifier by using a third party common identifier provider to look up the phone number owners name. It then normalizes the name ITGIobal Support to ITGIobalSupport. This corresponds to one embodiment of the specification "normalizing an identity of the potential future sender to provide a common identifier" in claim 1.

- A common identifier is added to the evidence collection on server 804. This corresponds to one embodiment of the specification "including the common identifier in the evidence collection."

- the support person emails (805) a opening support ticket to the person whom made the call. The calling person's cell phone receives the email which is mime encoded via GPRS. This corresponds to one embodiment of the specification "Receiving from a sender, a second message which is intended for the recipient and which is in a second format being different from the first format" in claim 1.

- a program running on the cell phone intercepts the incoming email before it is placed in the inbox and extracts the FROM address from the received email (E.G. SMBP.ort#lTGJ.oMLSuP.POXt-.co.m)- This corresponds to one embodiment of the specification "Providing an identity that can be normalized of the sender of the second message" in claim 1.

- the program running on the cell phone sends a request to the server 803 to check the identity support@ITGlobalSupport.com against the evidence collection. The server 803 uses a Normalizer to normalize the email address to ITGIobalSupport and checks this against the evidence collection. This corresponds to one embodiment of the specification "normalizing the identity of the sender to provide a common identifier" in claim 1.

- As the common identifier is present in the evidence collection the server responses with a "TRUE" (E.G. Sender identity is on the evidence collection) to the cell phones program request. This corresponds to one embodiment of the specification "normalizing the identity of the sender to provide a common identifier" in claim 1.

- The program running on the cell phone puts the email in the inbox on the phone so that the user can read it. This corresponds to one embodiment of the specification "Delivering the second message to the recipient if the provided common identity matches a common identity in the evidence collection" in claim 2.