+

WO2008031871A1 - Procédé de classification automatique de la communication entre un expéditeur et un destinataire - Google Patents

Procédé de classification automatique de la communication entre un expéditeur et un destinataire

Info

Publication number
WO2008031871A1
WO2008031871A1 PCT/EP2007/059660 EP2007059660W WO2008031871A1 WO 2008031871 A1 WO2008031871 A1 WO 2008031871A1 EP 2007059660 W EP2007059660 W EP 2007059660W WO 2008031871 A1 WO2008031871 A1 WO 2008031871A1
Authority
WO
WIPO (PCT)
Prior art keywords
sender
evidence collection
recipient
evidence
message
Prior art date
Application number
PCT/EP2007/059660
Other languages
English (en)
Inventor
Martin W. Larsen
Original Assignee
Imencro Software Sa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Imencro Software Sa filed Critical Imencro Software Sa
Publication of WO2008031871A1 publication Critical patent/WO2008031871A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/212—Monitoring or handling of messages using filtering or selective blocking

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • IP based phones 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.
  • 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:
  • 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.
  • the current invention can be used for maintaining an evidence collection based on who the receiver has previously contacted across protocols and message formats.
  • 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.
  • the first message can be a request provided on the internet, a message by telephone or in general by any electronic media for communication.
  • 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.
  • 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.
  • the domain name of the internet page can be written into the evidence collection.
  • 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.
  • 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" .
  • 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 )
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • a central system e.g. a computer system, e.g. by a gateway, a pbx or a proxy server.
  • 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.
  • Fig. 8 shows a diagrammatical view of a system according to the invention.
  • the invention can be split into the following components that can be implemented either in one entity or in multiple entities.
  • Evidence collection can be implemented either in one entity or in multiple entities.
  • 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.
  • 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 :
  • 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.
  • 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.
  • Table one Name as char 100 Protocol as char 5 LastContact as datetime Table two:
  • 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.
  • these two tables can be used for allowing incoming messages.
  • Recipient A browses to webpage wj/vw ; thjsjsajiej(an ⁇ BJex£rn
  • Recipient A calls Thomas X and the tables are now updated to appear as follows.
  • ThomasX, Phone, 01-01-2006 11 10 AM
  • Thomas X, Phone, 01-01-2006 11 10 AM
  • the evidence collector is used by the system to collect evidence into the evidence collection.
  • 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.
  • 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.
  • the browser 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.
  • 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
  • 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.
  • 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).
  • 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.
  • 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.
  • the Normalizer can use a third party common identifier provider to obtain the name to be normalized.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 can be any system that allows any kind of electronic messages or communication and that upholds the following three rules:
  • 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:
  • 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.
  • 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.
  • PBX IP or Old Fashion private branch exchange
  • Telex machine / Telex Server
  • Fax machine / Fax Server
  • 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.
  • 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.
  • 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.
  • IP phone directory ( . http://ww etc.)
  • a global address can be used as a Normalizer because it can resolve all communication entries to common identifiers.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 701 is a PC with means for communicating messages between a sender and a recipient in an electronic message system.
  • 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.
  • 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.
  • 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.
  • the server responses with a "TRUE" (E.G. Sender identity is on the evidence collection) to the cell phones program request.
  • TRUE E.G. Sender identity is on the evidence collection

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La présente invention concerne un procédé et un système, en particulier un système informatique, permettant de communiquer des messages entre un expéditeur et un destinataire, par ex. des courriers électroniques. Un ensemble de justification est produit et contient des identificateurs d'entités auprès desquelles un destinataire a demandé des informations, par ex. en visitant une page Internet appartenant à l'entité en question. Si l'entité en question envoie ensuite un courrier électronique au destinataire, une recherche est effectuée dans l'ensemble de justification, et lorsqu'une correspondance est établie entre un identificateur de l'ensemble de justification et un identificateur de l'expéditeur du message électronique, ce dernier est mis à la disposition du destinataire à qui il est destiné.
PCT/EP2007/059660 2006-09-13 2007-09-13 Procédé de classification automatique de la communication entre un expéditeur et un destinataire WO2008031871A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US84408006P 2006-09-13 2006-09-13
US60/844,080 2006-09-13
DKPA200601175 2006-09-13
DKPA200601175 2006-09-13

Publications (1)

Publication Number Publication Date
WO2008031871A1 true WO2008031871A1 (fr) 2008-03-20

Family

ID=38606553

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/059660 WO2008031871A1 (fr) 2006-09-13 2007-09-13 Procédé de classification automatique de la communication entre un expéditeur et un destinataire

Country Status (1)

Country Link
WO (1) WO2008031871A1 (fr)

Cited By (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8086275B2 (en) 2008-10-23 2011-12-27 Microsoft Corporation Alternative inputs of a mobile communications device
US8238876B2 (en) 2009-03-30 2012-08-07 Microsoft Corporation Notifications
US8269736B2 (en) 2009-05-22 2012-09-18 Microsoft Corporation Drop target gestures
US8355698B2 (en) 2009-03-30 2013-01-15 Microsoft Corporation Unlock screen
US8385952B2 (en) 2008-10-23 2013-02-26 Microsoft Corporation Mobile communications device user interface
US8411046B2 (en) 2008-10-23 2013-04-02 Microsoft Corporation Column organization of content
US8560959B2 (en) 2010-12-23 2013-10-15 Microsoft Corporation Presenting an application change through a tile
US8687023B2 (en) 2011-08-02 2014-04-01 Microsoft Corporation Cross-slide gesture to select and rearrange
US8689123B2 (en) 2010-12-23 2014-04-01 Microsoft Corporation Application reporting in an application-selectable user interface
US8830270B2 (en) 2011-09-10 2014-09-09 Microsoft Corporation Progressively indicating new content in an application-selectable user interface
US8836648B2 (en) 2009-05-27 2014-09-16 Microsoft Corporation Touch pull-in gesture
US8893033B2 (en) 2011-05-27 2014-11-18 Microsoft Corporation Application notifications
US8914072B2 (en) 2009-03-30 2014-12-16 Microsoft Corporation Chromeless user interface
US8922575B2 (en) 2011-09-09 2014-12-30 Microsoft Corporation Tile cache
US8935631B2 (en) 2011-09-01 2015-01-13 Microsoft Corporation Arranging tiles
US8933952B2 (en) 2011-09-10 2015-01-13 Microsoft Corporation Pre-rendering new content for an application-selectable user interface
US8990733B2 (en) 2010-12-20 2015-03-24 Microsoft Technology Licensing, Llc Application-launching interface for multiple modes
US9052820B2 (en) 2011-05-27 2015-06-09 Microsoft Technology Licensing, Llc Multi-application environment
US9104440B2 (en) 2011-05-27 2015-08-11 Microsoft Technology Licensing, Llc Multi-application environment
US9128605B2 (en) 2012-02-16 2015-09-08 Microsoft Technology Licensing, Llc Thumbnail-image selection of applications
US9158445B2 (en) 2011-05-27 2015-10-13 Microsoft Technology Licensing, Llc Managing an immersive interface in a multi-application immersive environment
US9223472B2 (en) 2011-12-22 2015-12-29 Microsoft Technology Licensing, Llc Closing applications
US9244802B2 (en) 2011-09-10 2016-01-26 Microsoft Technology Licensing, Llc Resource user interface
US9329774B2 (en) 2011-05-27 2016-05-03 Microsoft Technology Licensing, Llc Switching back to a previously-interacted-with application
US9383917B2 (en) 2011-03-28 2016-07-05 Microsoft Technology Licensing, Llc Predictive tiling
US9423951B2 (en) 2010-12-31 2016-08-23 Microsoft Technology Licensing, Llc Content-based snap point
US9450952B2 (en) 2013-05-29 2016-09-20 Microsoft Technology Licensing, Llc Live tiles without application-code execution
US9451822B2 (en) 2014-04-10 2016-09-27 Microsoft Technology Licensing, Llc Collapsible shell cover for computing device
US9557909B2 (en) 2011-09-09 2017-01-31 Microsoft Technology Licensing, Llc Semantic zoom linguistic helpers
EP3163856A1 (fr) * 2015-10-29 2017-05-03 Xiaomi Inc. Procédé et dispositif de traitement d'appel
CN106657163A (zh) * 2017-03-02 2017-05-10 北京网藤科技有限公司 工业控制动态防御方法和系统
US9658766B2 (en) 2011-05-27 2017-05-23 Microsoft Technology Licensing, Llc Edge gesture
US9665384B2 (en) 2005-08-30 2017-05-30 Microsoft Technology Licensing, Llc Aggregation of computing device settings
US9674335B2 (en) 2014-10-30 2017-06-06 Microsoft Technology Licensing, Llc Multi-configuration input device
US9769293B2 (en) 2014-04-10 2017-09-19 Microsoft Technology Licensing, Llc Slider cover for computing device
US9841874B2 (en) 2014-04-04 2017-12-12 Microsoft Technology Licensing, Llc Expandable application representation
US9858335B2 (en) 2015-04-21 2018-01-02 International Business Machines Corporation Providing searching strategy in connection with answering question in message
US10254942B2 (en) 2014-07-31 2019-04-09 Microsoft Technology Licensing, Llc Adaptive sizing and positioning of application windows
US10291774B2 (en) 2015-07-13 2019-05-14 Xiaomi Inc. Method, device, and system for determining spam caller phone number
US10353566B2 (en) 2011-09-09 2019-07-16 Microsoft Technology Licensing, Llc Semantic zoom animations
US10592080B2 (en) 2014-07-31 2020-03-17 Microsoft Technology Licensing, Llc Assisted presentation of application windows
US10642365B2 (en) 2014-09-09 2020-05-05 Microsoft Technology Licensing, Llc Parametric inertia and APIs
US10678412B2 (en) 2014-07-31 2020-06-09 Microsoft Technology Licensing, Llc Dynamic joint dividers for application windows

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010047391A1 (en) * 2000-03-23 2001-11-29 Kehyeh Szutu Forwarding electronic mail and messages to internet destinations linked with pre-existing unique identifier
US20040258044A1 (en) * 2003-05-22 2004-12-23 International Business Machines Corporation Method and apparatus for managing email messages
US6868498B1 (en) * 1999-09-01 2005-03-15 Peter L. Katsikas System for eliminating unauthorized electronic mail
WO2005067233A1 (fr) * 2003-12-24 2005-07-21 Computer Associates Think, Inc. Systeme et procede de filtrage de messages de reseau

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6868498B1 (en) * 1999-09-01 2005-03-15 Peter L. Katsikas System for eliminating unauthorized electronic mail
US20010047391A1 (en) * 2000-03-23 2001-11-29 Kehyeh Szutu Forwarding electronic mail and messages to internet destinations linked with pre-existing unique identifier
US20040258044A1 (en) * 2003-05-22 2004-12-23 International Business Machines Corporation Method and apparatus for managing email messages
WO2005067233A1 (fr) * 2003-12-24 2005-07-21 Computer Associates Think, Inc. Systeme et procede de filtrage de messages de reseau

Cited By (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9665384B2 (en) 2005-08-30 2017-05-30 Microsoft Technology Licensing, Llc Aggregation of computing device settings
US9218067B2 (en) 2008-10-23 2015-12-22 Microsoft Technology Licensing, Llc Mobile communications device user interface
US9606704B2 (en) 2008-10-23 2017-03-28 Microsoft Technology Licensing, Llc Alternative inputs of a mobile communications device
US8970499B2 (en) 2008-10-23 2015-03-03 Microsoft Technology Licensing, Llc Alternative inputs of a mobile communications device
US8825699B2 (en) 2008-10-23 2014-09-02 Rovi Corporation Contextual search by a mobile communications device
US8385952B2 (en) 2008-10-23 2013-02-26 Microsoft Corporation Mobile communications device user interface
US8411046B2 (en) 2008-10-23 2013-04-02 Microsoft Corporation Column organization of content
US10133453B2 (en) 2008-10-23 2018-11-20 Microsoft Technology Licensing, Llc Alternative inputs of a mobile communications device
US9223412B2 (en) 2008-10-23 2015-12-29 Rovi Technologies Corporation Location-based display characteristics in a user interface
US9223411B2 (en) 2008-10-23 2015-12-29 Microsoft Technology Licensing, Llc User interface with parallax animation
US8634876B2 (en) 2008-10-23 2014-01-21 Microsoft Corporation Location based display characteristics in a user interface
US9703452B2 (en) 2008-10-23 2017-07-11 Microsoft Technology Licensing, Llc Mobile communications device user interface
US8086275B2 (en) 2008-10-23 2011-12-27 Microsoft Corporation Alternative inputs of a mobile communications device
US8250494B2 (en) 2008-10-23 2012-08-21 Microsoft Corporation User interface with parallax animation
US9323424B2 (en) 2008-10-23 2016-04-26 Microsoft Corporation Column organization of content
US8781533B2 (en) 2008-10-23 2014-07-15 Microsoft Corporation Alternative inputs of a mobile communications device
US8892170B2 (en) 2009-03-30 2014-11-18 Microsoft Corporation Unlock screen
US8238876B2 (en) 2009-03-30 2012-08-07 Microsoft Corporation Notifications
US8914072B2 (en) 2009-03-30 2014-12-16 Microsoft Corporation Chromeless user interface
US8548431B2 (en) 2009-03-30 2013-10-01 Microsoft Corporation Notifications
US8355698B2 (en) 2009-03-30 2013-01-15 Microsoft Corporation Unlock screen
US9977575B2 (en) 2009-03-30 2018-05-22 Microsoft Technology Licensing, Llc Chromeless user interface
US8269736B2 (en) 2009-05-22 2012-09-18 Microsoft Corporation Drop target gestures
US8836648B2 (en) 2009-05-27 2014-09-16 Microsoft Corporation Touch pull-in gesture
US9696888B2 (en) 2010-12-20 2017-07-04 Microsoft Technology Licensing, Llc Application-launching interface for multiple modes
US8990733B2 (en) 2010-12-20 2015-03-24 Microsoft Technology Licensing, Llc Application-launching interface for multiple modes
US9766790B2 (en) 2010-12-23 2017-09-19 Microsoft Technology Licensing, Llc Application reporting in an application-selectable user interface
US9870132B2 (en) 2010-12-23 2018-01-16 Microsoft Technology Licensing, Llc Application reporting in an application-selectable user interface
US9015606B2 (en) 2010-12-23 2015-04-21 Microsoft Technology Licensing, Llc Presenting an application change through a tile
US11126333B2 (en) 2010-12-23 2021-09-21 Microsoft Technology Licensing, Llc Application reporting in an application-selectable user interface
US10969944B2 (en) 2010-12-23 2021-04-06 Microsoft Technology Licensing, Llc Application reporting in an application-selectable user interface
US9864494B2 (en) 2010-12-23 2018-01-09 Microsoft Technology Licensing, Llc Application reporting in an application-selectable user interface
US9213468B2 (en) 2010-12-23 2015-12-15 Microsoft Technology Licensing, Llc Application reporting in an application-selectable user interface
US8689123B2 (en) 2010-12-23 2014-04-01 Microsoft Corporation Application reporting in an application-selectable user interface
US8612874B2 (en) 2010-12-23 2013-12-17 Microsoft Corporation Presenting an application change through a tile
US8560959B2 (en) 2010-12-23 2013-10-15 Microsoft Corporation Presenting an application change through a tile
US9229918B2 (en) 2010-12-23 2016-01-05 Microsoft Technology Licensing, Llc Presenting an application change through a tile
US9423951B2 (en) 2010-12-31 2016-08-23 Microsoft Technology Licensing, Llc Content-based snap point
US9383917B2 (en) 2011-03-28 2016-07-05 Microsoft Technology Licensing, Llc Predictive tiling
US9052820B2 (en) 2011-05-27 2015-06-09 Microsoft Technology Licensing, Llc Multi-application environment
US9104307B2 (en) 2011-05-27 2015-08-11 Microsoft Technology Licensing, Llc Multi-application environment
US10303325B2 (en) 2011-05-27 2019-05-28 Microsoft Technology Licensing, Llc Multi-application environment
US11698721B2 (en) 2011-05-27 2023-07-11 Microsoft Technology Licensing, Llc Managing an immersive interface in a multi-application immersive environment
US9158445B2 (en) 2011-05-27 2015-10-13 Microsoft Technology Licensing, Llc Managing an immersive interface in a multi-application immersive environment
US9104440B2 (en) 2011-05-27 2015-08-11 Microsoft Technology Licensing, Llc Multi-application environment
US9535597B2 (en) 2011-05-27 2017-01-03 Microsoft Technology Licensing, Llc Managing an immersive interface in a multi-application immersive environment
US9329774B2 (en) 2011-05-27 2016-05-03 Microsoft Technology Licensing, Llc Switching back to a previously-interacted-with application
US11272017B2 (en) 2011-05-27 2022-03-08 Microsoft Technology Licensing, Llc Application notifications manifest
US9658766B2 (en) 2011-05-27 2017-05-23 Microsoft Technology Licensing, Llc Edge gesture
US8893033B2 (en) 2011-05-27 2014-11-18 Microsoft Corporation Application notifications
US8687023B2 (en) 2011-08-02 2014-04-01 Microsoft Corporation Cross-slide gesture to select and rearrange
US8935631B2 (en) 2011-09-01 2015-01-13 Microsoft Corporation Arranging tiles
US10579250B2 (en) 2011-09-01 2020-03-03 Microsoft Technology Licensing, Llc Arranging tiles
US8922575B2 (en) 2011-09-09 2014-12-30 Microsoft Corporation Tile cache
US9557909B2 (en) 2011-09-09 2017-01-31 Microsoft Technology Licensing, Llc Semantic zoom linguistic helpers
US10353566B2 (en) 2011-09-09 2019-07-16 Microsoft Technology Licensing, Llc Semantic zoom animations
US10114865B2 (en) 2011-09-09 2018-10-30 Microsoft Technology Licensing, Llc Tile cache
US9244802B2 (en) 2011-09-10 2016-01-26 Microsoft Technology Licensing, Llc Resource user interface
US8933952B2 (en) 2011-09-10 2015-01-13 Microsoft Corporation Pre-rendering new content for an application-selectable user interface
US9146670B2 (en) 2011-09-10 2015-09-29 Microsoft Technology Licensing, Llc Progressively indicating new content in an application-selectable user interface
US8830270B2 (en) 2011-09-10 2014-09-09 Microsoft Corporation Progressively indicating new content in an application-selectable user interface
US10254955B2 (en) 2011-09-10 2019-04-09 Microsoft Technology Licensing, Llc Progressively indicating new content in an application-selectable user interface
US10191633B2 (en) 2011-12-22 2019-01-29 Microsoft Technology Licensing, Llc Closing applications
US9223472B2 (en) 2011-12-22 2015-12-29 Microsoft Technology Licensing, Llc Closing applications
US9128605B2 (en) 2012-02-16 2015-09-08 Microsoft Technology Licensing, Llc Thumbnail-image selection of applications
US9450952B2 (en) 2013-05-29 2016-09-20 Microsoft Technology Licensing, Llc Live tiles without application-code execution
US10110590B2 (en) 2013-05-29 2018-10-23 Microsoft Technology Licensing, Llc Live tiles without application-code execution
US9807081B2 (en) 2013-05-29 2017-10-31 Microsoft Technology Licensing, Llc Live tiles without application-code execution
US9841874B2 (en) 2014-04-04 2017-12-12 Microsoft Technology Licensing, Llc Expandable application representation
US10459607B2 (en) 2014-04-04 2019-10-29 Microsoft Technology Licensing, Llc Expandable application representation
US9769293B2 (en) 2014-04-10 2017-09-19 Microsoft Technology Licensing, Llc Slider cover for computing device
US9451822B2 (en) 2014-04-10 2016-09-27 Microsoft Technology Licensing, Llc Collapsible shell cover for computing device
US10592080B2 (en) 2014-07-31 2020-03-17 Microsoft Technology Licensing, Llc Assisted presentation of application windows
US10254942B2 (en) 2014-07-31 2019-04-09 Microsoft Technology Licensing, Llc Adaptive sizing and positioning of application windows
US10678412B2 (en) 2014-07-31 2020-06-09 Microsoft Technology Licensing, Llc Dynamic joint dividers for application windows
US10642365B2 (en) 2014-09-09 2020-05-05 Microsoft Technology Licensing, Llc Parametric inertia and APIs
US9674335B2 (en) 2014-10-30 2017-06-06 Microsoft Technology Licensing, Llc Multi-configuration input device
US9858335B2 (en) 2015-04-21 2018-01-02 International Business Machines Corporation Providing searching strategy in connection with answering question in message
US10291774B2 (en) 2015-07-13 2019-05-14 Xiaomi Inc. Method, device, and system for determining spam caller phone number
US10218846B2 (en) 2015-10-29 2019-02-26 Xiaomi Inc. Call processing method and device
RU2668283C2 (ru) * 2015-10-29 2018-09-28 Сяоми Инк. Устройство и способ обработки вызова
EP3163856A1 (fr) * 2015-10-29 2017-05-03 Xiaomi Inc. Procédé et dispositif de traitement d'appel
CN106657163B (zh) * 2017-03-02 2019-12-17 北京网藤科技有限公司 工业控制动态防御方法和系统
CN106657163A (zh) * 2017-03-02 2017-05-10 北京网藤科技有限公司 工业控制动态防御方法和系统

Similar Documents

Publication Publication Date Title
WO2008031871A1 (fr) Procédé de classification automatique de la communication entre un expéditeur et un destinataire
US10904186B1 (en) Email processing for enhanced email privacy and security
US8301703B2 (en) Systems and methods for alerting administrators about suspect communications
US9684888B2 (en) Online fraud solution
US6779022B1 (en) Server that obtains information from multiple sources, filters using client identities, and dispatches to both hardwired and wireless clients
US9152952B2 (en) Spam filtering and person profiles
CA2467869C (fr) Caracteristiques de provenance/destination et listes de prevention du pollupostage
US7627642B1 (en) Methods and systems for automatically presenting users with option to call sender responsive to email message
US8095602B1 (en) Spam whitelisting for recent sites
US20050015626A1 (en) System and method for identifying and filtering junk e-mail messages or spam based on URL content
US20040143635A1 (en) Regulating receipt of electronic mail
US8321512B2 (en) Method and software product for identifying unsolicited emails
US7620691B1 (en) Filtering electronic messages while permitting delivery of solicited electronics messages
WO2006013403A2 (fr) Procede et systeme pour message instantane utilisant la technologie http url
CN101150535A (zh) 一种电子邮件的过滤方法、装置及设备
US20100255861A1 (en) System and Method for Transferring Contact Information to a Recipient
US8880611B1 (en) Methods and apparatus for detecting spam messages in an email system
JP3871941B2 (ja) 携帯電話のメールサーバーにおける迷惑メール自動処分方法、メールサーバー及びプログラム
US7580981B1 (en) System for determining email spam by delivery path
GB2430335A (en) Pre-filtering of digital messages
US20140040403A1 (en) System, method and computer program product for gathering information relating to electronic content utilizing a dns server
US20070094321A1 (en) General purpose rss catcher
US8112482B1 (en) System and method for securing access to electronic mail
US20070294351A1 (en) Method for the Monitoring the Transmission of Electronic Messages
KR100486821B1 (ko) 링크 유알엘 접속을 통한 스팸메일 자동 차단 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07803472

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07803472

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载