WO2003048960A1 - Method and system for contextual prioritization of unified messages - Google Patents

Method and system for contextual prioritization of unified messages Download PDF

Info

Publication number
WO2003048960A1
WO2003048960A1 PCT/US2002/038103 US0238103W WO03048960A1 WO 2003048960 A1 WO2003048960 A1 WO 2003048960A1 US 0238103 W US0238103 W US 0238103W WO 03048960 A1 WO03048960 A1 WO 03048960A1
Authority
WO
WIPO (PCT)
Prior art keywords
initiator
user
recipient
message
operative
Prior art date
Application number
PCT/US2002/038103
Other languages
French (fr)
Inventor
Eng Siong Tan
Choong Y. Chew
Chee Meng Low
Cy Boon Teoh
Boon Siong Wong
Original Assignee
A New Voice, Inc.
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 A New Voice, Inc. filed Critical A New Voice, Inc.
Priority to AU2002357029A priority Critical patent/AU2002357029A1/en
Publication of WO2003048960A1 publication Critical patent/WO2003048960A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/50Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/53Centralised arrangements for recording incoming messages, i.e. mailbox systems
    • H04M3/5307Centralised arrangements for recording incoming messages, i.e. mailbox systems for recording messages comprising any combination of audio and non-audio components
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Administration; Management
    • G06Q10/10Office automation; Time management
    • G06Q10/107Computer-aided management of electronic mailing [e-mailing]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/214Monitoring or handling of messages using selective forwarding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/226Delivery according to priorities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/56Unified messaging, e.g. interactions between e-mail, instant messaging or converged IP messaging [CPM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • H04L67/306User profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/535Tracking the activity of the user
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/564Enhancement of application control based on intercepted application data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/436Arrangements for screening incoming calls, i.e. evaluating the characteristics of a call before deciding whether to answer it
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2201/00Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/40Electronic components, circuits, software, systems or apparatus used in telephone systems using speech recognition
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2201/00Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/60Medium conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2203/00Aspects of automatic or semi-automatic exchanges
    • H04M2203/45Aspects of automatic or semi-automatic exchanges related to voicemail messaging
    • H04M2203/4509Unified messaging with single point of access to voicemail and other mail or messaging systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/50Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/53Centralised arrangements for recording incoming messages, i.e. mailbox systems
    • H04M3/533Voice mail systems
    • H04M3/53333Message receiving aspects
    • H04M3/5335Message type or catagory, e.g. priority, indication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/50Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/53Centralised arrangements for recording incoming messages, i.e. mailbox systems
    • H04M3/533Voice mail systems
    • H04M3/53333Message receiving aspects
    • H04M3/53358Message preview

Definitions

  • the present invention relates to messaging systems and, more particularly, to unified messaging systems providing relevance indicators corresponding to received messages.
  • Unified messaging facilitates management of all such messages by providing a single point of access to different message types, such as voice, fax, and email, from a variety of communications devices, such as a wireless telephone, personal computer or Web browser through the Internet.
  • a unique icon identifies each message type. Users can also access and manage messages through a telephone interface.
  • a user can dial into his unified messaging system from any telephone to listen and respond to almost any message type waiting in an inbox. For example, the user can listen to their email messages using text-to- speech technology and respond to that email message with a voice message. The user can listen to the header of a fax message, forward that message to
  • a graphical user interface allows users to log in to a unified messaging system and access their messages with a desktop or laptop computer.
  • the present invention provides methods, apparatuses and systems allowing for the contextual prioritization of messages and, in one embodiment, the contextual prioritization of unified messages.
  • Embodiments of the present invention are operative to associate a relevance indicator or category to unified messages by computing the context of the message in
  • Relevance measures allow for a contextual prioritization of unified messages into a plurality of context-based categories.
  • the present invention has application to any unified message type, including voice-based messages, such as telephone calls and voice-mail messages, and multimedia electronic messages, such as electronic mail (email), short message service (SMS), instant messaging, faxes, and the like.
  • voice-based messages such as telephone calls and voice-mail messages
  • multimedia electronic messages such as electronic mail (email), short message service (SMS), instant messaging, faxes, and the like.
  • Figure 1 is a functional block diagram providing an overview of a system according to a preferred embodiment of the present invention.
  • Figure 2 is a functional block diagram setting forth the functionality and process flows associated with computing a message recipient's context relative to an incoming message, according to a preferred embodiment of the present invention.
  • Figure 3 is a process flowchart describing a method for computing a message recipient's interest level in an incoming message, according to a preferred embodiment of the present invention.
  • Figure 4 is a process flowchart describing a method for inferring a message initiator's context based on the initiator's profiled identity and profiled content, according to a preferred embodiment of the present invention.
  • Figure 5 is a flowchart diagram of a preferred method for computing the relevance of a unified message, according to the present invention.
  • Figure 6 is a flowchart of a preferred method for computing the relevance of a telephone message, according to an embodiment of the present invention.
  • Figure 7 is a flowchart diagram setting forth a method for computing the relevance of an electronic mail message, according to a preferred embodiment of the present invention.
  • Figure 1 illustrates a communications network environment in which embodiments of the present invention may operate.
  • the system comprises message handler 11, recipient context module 12, initiator context module 13, relevance engine 14, auto-interaction module 15, and message interface 16.
  • Message handler 11 is operative to interface with a communications network 10 for receiving and sending unified messages on behalf of a user.
  • Recipient context module 12 is operative to compute a recipient's context in relation to a received message.
  • Initiator context module 13 is operative to compute the message initiator's context in relation to a received message.
  • Relevance engine 14 is operative to compute the relevance of a received message based on the recipient's and, optionally, the initiator's respective contexts.
  • Auto- interaction module 15 facilitates relevance computations by auto-interacting with a message initiator on the recipient's behalf. Auto-interaction module 15 is also operative to provide notices or other information to message initiators.
  • Message interface 16 provides an interface to users facilitating access to message sending and retrieval functionality. Message interface 16, in one embodiment is operative to process the prioritized messages into appropriate inbox folders based on relevance measures computed by relevance engine 14 and allows access to messages for perusal by the recipient. Message interface 16, in one embodiment, is also operative to display or otherwise present prioritized messages in a folder-based inbox interface, and further allows recipient users to reply to received messages or to send new messages. .
  • the present invention can be applied to any unified message type, which includes any combination of voice-based messages including but not restricted to telephone calls and voice-mail messages, as well as any multimedia electronic messages, including but not restricted to electronic mail (email), short message service (SMS), instant messaging and faxes.
  • a unified message may be initiated by a human, a software application or a machine.
  • recipient context module 12 For a given unified message from a message initiator, recipient context module 12 computes the Recipient's context to identify a contact relation between the Recipient and the Initiator, and, in one embodiment, potentially a level of interest the recipient may have in the message. In one embodiment, recipient context module 12 categorizes the recipient's context with respect to a received message into one of a plurality of contact relation types relative to the initiator of the message.
  • a. Generating Initiator/Recipient User Profiles involves a background pre-processing step of generating and maintaining user profiles by making inferences based on the user's past communications behavior as recorded by communications log 38.
  • Communications log 38 can acquire data from a variety of sources, such as the logs maintained by the user's telecommunications provider that provide per-call information such as the numbers of calls sent or received, telephone numbers dialed, time and duration of calls made, etc.
  • Other possible sources include email logs or archives that contain per-email information such as sender or recipient addresses, copied addresses, date and time, subject, and message body.
  • an SMTP server associated with a user is operative to transmit data allowing for logging of the user's emails
  • this information is accessed by interfacing the recipient context module 12 to the communications service provider's message handler 11 so all communications going through message handler 11 are logged automatically.
  • another possible data source is contacts database 35 (see Figure 1) containing the user's address book and other contacts information, such as names, addresses, telephone numbers, email addresses, etc.
  • inference module 32 analyzes and makes inferences from the data stored in communications log 38 and contact database 35 to segregate the user's contacts into a pre-defined set of contact relation types.
  • An illustrative set of contact relation types associated with a user profile is as follows:
  • Inference module 32 applies inference rules to data associated with a user in communications log 38 and/or contact database 35 to generate, and later update, contact relation types associated with the user.
  • An exemplary set of inference rules based on contact identity, communication pattern and frequency of communication events in communications log 38 and/or contact database 35, is as follows:
  • the contact has the same email domain, not including domains belonging to Internet email service providers
  • Inference module 32 performs this background profiling step for each user on a periodic basis to populate and later update user profile database 33 to contain the user-contact pairs and profiles of the user-contact pairs encountered by the system.
  • the system of the present invention includes user-access functionalities facilitating access to user profile database 33, such that users can peruse the profile database directly as well as override existing system-defined profiles and contact relation types, or create entirely new ones.
  • Figures 2 and 3 are functional block diagrams illustrating a process flow associated with computing a recipient user's context relative to a received message.
  • recipient context module 12 draws information from user profile database 33, communications log 38, contact database 35, and calendar database 36 to compute a recipient's context and infer a recipient's interest level in a received message based on a set of heuristic rules.
  • the operation of computing a recipient's context relative to a message begins with a retrieval of a contact relation associated with the recipient user from user profile database 33 ( Figure 2, step 202).
  • the retrieved contact relation, together with the message, is passed to recipient context module 12 for heuristic processing of the recipient's contact relation type with respect to the initiator (step 204) (see above) and, if the
  • FIG. 7 6544/53735 initiator is known to the recipient (step 206), an overall Interest level associated with the message (step 208), based on accessible information about the user's context, such as calendar information 36, contact database 35, location and interests.
  • Figure 3 illustrates an exemplary set of heuristic rules that can be applied to determine a recipient's interest level in a received message: • The "VIP" Heuristic (61): This rule checks the priority of the initiator to determine if the message should be marked as "urgent". For example, messages whose recipient-initiator contact relations types are Related or Trusted can be deemed urgent. As another example, initiators appearing in the recipient's contacts database 35 and whose relationship or title indicates the initiator is the recipient's superior, can be deemed urgent.
  • parameters associated with the VIP heuristic are configurable by the user. For example, the user may configure a list of ' VIPs.
  • Recipient context module 12 scans the communications log 38 to detect if the recipient has unsuccessfully attempted to contact the initiator in the recent past.
  • the heuristic rule requires a threshold number of unsuccessful attempts within a predetermined period. This will be reflected in the communications log as a multiplicity of unanswered telephone calls and/or emails from the recipient to this contact. When such an event is detected, the message is marked as "Replying” and will be treated by relevance engine 14 as "urgent" regardless of past communication patterns.
  • the "Meeting Soon" Heuristic (63): This rule checks the recipient's calendar as maintained by calendar database 36 to see if the initiator is a participant in a soon-to-occur event on the recipient's schedule. Recipient context module 12 associates such messages with a "meeting soon" tag. Such messages are further marked with an urgent or moderately urgent message tag. A further variation is to vary the degree of urgency based on additional factors, for example, the sooner the scheduled event to the time
  • the "Meeting Canceled” Heuristic rule (64) This rule applies the “Meeting Soon” rule, and for the case of electronic data messages, further processes the message content for keywords such as “sorry", “cancel”, “postpone”. Such messages are further marked with an urgent or moderately urgent message tag. A further variation is the vary the degree of urgency based on additional factors, for example, the sooner the scheduled event to the time of the call, the greater the urgency the message is accorded.
  • the "Proximity” Heuristic (65) This rule checks if the message initiator is designated as Trustworthy (either through direct user input, or based on system computed contact relation types of Related or Trusted) and whether the message contains any location-based information. The recipient's location-context is checked to see if she is "close by”. If so, the message is marked "Proximity Alert” and its urgency level increased. This rule is particularly apt for mobile-commerce class of messages from recipient's selected list of businesses.
  • the "Topical Interest” (66): This rule checks the message contents for indications that the recipient is interested in this topic.
  • An illustrative examples include use of selected keywords configured by the user to match a category of interest ("sports", “footballs”, “baseball” to match sports- related messages).
  • Another illustrative example is the monitoring of mail logs to identify messages related to a project, for example by tracking discussion threads (emails whose SUBJECT has "RE:” followed by the same topic), scanning for the frequently-occurring distinguishing keywords in the message body (e.g., project name or client name), plus the occurrence of the usual members in the FROM, TO, CC, or BCC list. Such messages are marked “Topical.”.
  • the "Meta-Message” Heuristic This rule checks for a special class of messages that are distinguished from other messages in two ways, namely, the message is from a controlled class of initiators (such as the
  • Illustrative examples include a meta message from the mobile phone operator indicating the recipient has moved into a new cell location code, and updating a location state with the new current location code. This can then be used to trigger the "Proximity" heuristic.
  • a further variation of the above system is the addition of an automatic monitor of the recipient's context, such as location, to determine if changes in the recipient's context warrant a re-computing of the relevance of prioritized messages.
  • a user's location can be determined in relation to the current wireless cell phone area in which the user's wireless device is located.
  • initiator context module 13 determines the initiator's context by computing the initiator's identity profile, and a content profile for the message. 3. a. Initiator Identity Profile
  • An aspect of computing an initiator's context includes a processing step in which the identity profile of the initiator is computed to determine the level of interest a recipient may have for a particular initiator, even if the initiator is unknown to the recipient. This process accesses previously computed initiator identity profiles in database 82, recipient user profiles from user profile database 33, and/or a phone directory 84 that permits reverse directory lookups.
  • initiator context module 13 checks for affinity relations in the initiator's and recipient's communications patterns that can suggest that a recipient would
  • initiator identity profiles can be computed from the following rules based on affinity relations:
  • This rule accesses the user profile database 33 to check if the initiator and the recipient share any Related, Trusted or Familiar contacts, indicating whether the initiator and recipient "travel in the same circles.” In one embodiment, this can be accomplished by matching the entire contact list associated with the user profile for the recipient against the same for the initiator.
  • the number of common contacts, as well as the contact relation types associated therewith, are used in computations of an affinity level. As an illustrative example, a recipient and an initiator are considered "Friend of a Friend" if any one of the following is true: a. there is at least 1 Related contact in common; b. there are at least 2 Trusted contacts in common; c. there are at least 5 Familiar contacts in common; and d. there are at least 10 common contacts of any contact relation type.
  • Affinity rule This rule analyzes the various specific identities of both the initiator and recipient for common background.
  • phone numbers can be searched against phone directory 84, using reverse directory lookup methods, to reveal if the phone number is from a company, a residential address or an unlisted number.
  • the recipient and the initiator are related by "Common Background" if any of these are true: a. Both phone numbers are business numbers and are from the same company; b. Both phone numbers are residential numbers and are from the same residential address; or c. Both email addresses share the same internet domain, unless the domain is associated with an email or internet service provider.
  • a second aspect of initiator identity profiling is to check if the initiator is associated with a bogus identity or bona-fide identity (e.g., phone number, email address, etc.).
  • An initiator identity can be a phone number, an email address or any other suitable identification. This check is especially important for the unified message type of emails. Since the bulk of email messages are not authenticated, forgery of the "From" address is a particularly common practice among email spammers.
  • An illustrative example of computing the bona-fide relation is as follows:
  • Bona-Fide Identity rule This rule accesses the user profile database 33 to retrieve all contacts associated with the initiator. If the initiator has at least 3 Trusted contacts or 10 Familiar contacts, the initiator is marked as Bona-Fide.
  • the actual thresholds used can be varied and fine-tuned. One variation is to permit user programmable thresholds. Another is to adapt the thresholds based on actual system performance. 3. a.3. Identity Profile Database
  • a third aspect of the identity profiling is the maintenance of a database that logs all previously computed identity profiles. This provides a system memory for remembering initiators, and reduced redundant processes associated with computing initiator identity profiles. Hence this database is designed for efficient access. Likewise every new initiator identity profile computed is also logged into the database 82. 3.b. Message Content Profile
  • initiator context module 13 computes a content profile for the message to determine the Ukelihood that the message is a bulk message or SPAM sent by an initiator, alien not only to this recipient but also
  • This process also accesses message content database 86 storing previously computed message content profiles.
  • An illustrative example of processing message content profiles generally comprises the following steps: • Compute a message signature: A representation of the message is computed that is more suitable for processing in subsequent steps.
  • a telephone call can be processed through an automatic speech-to-text recognition processor (such as is available from companies such as Nuance, SpeechWorks, etc.) to obtain the electronic digital version of the message.
  • the electronic digital versions of the message are then stored in a form for efficient processing.
  • an email can be stored as a word-frequency vector (a string of words together with their frequency counts in the message), a representation commonly used in information retrieval applications. • Normahze the message signature.
  • This processing further abstracts the message signature to capture the essential parts of the message and ignore the minor variations of the same message.
  • An illustrative example is the removal of commonly-occurring words (known as stop words in information retrieval applications).
  • Another illustrative example is the removal of all number sequences in the message.
  • Another illustrative example is to store only representations of selective fields in structured messages, such as ignoring the FROM, TO, SUBJECT, and DATE fields and representing only the message BODY.
  • Another illustrative example is to identify and extract contact identities (phone numbers or email addresses) contained in the message.
  • This processing step computes a highly likely unique identification for a given normalized message signature.
  • An illustrative example is the application of the widely used message digest algorithm used in digital signature applications. MD5 processing that takes a string and returns a 128-bit
  • the content profile of a message comprises a unique message identification, a normalized message signature, and a message count), where the message count keeps track of the number of minor variations of the same message encountered by the system, as represented by the normalized message signature.
  • a message content profile database 86 allows for tracking the number of similar messages encountered by a system of the present invention.
  • the unique message identification is used to index the message content profiles, and can be used as a primary key into a database storage, or as a key to a hash table. In one embodiment, if the message of an unknown initiator has a normalized email signature that has a high count, the message is deemed to match a spam content profile.
  • the process flow of computing an initiator's context begins with accessing initiator identity profile database 82 to determine the contact relation type, if any, between the initiator and the recipient (step 91). If a computed contact relation type already exists for the initiator (step 92), the contact relation type is retrieved and the process exits. Otherwise, initiator context module 13 creates an initiator identity profile in initiator identity profile database 82 (step 93) and applies the checks discussed above. If the profile fits an Affinity profile (94), the corresponding entry in initiator identity profile database 82 is updated to reflect this new initiator- affinity pair (95), the profile is marked "Affinity" and the process exits.
  • the identity profile database is updated to reflect this new initiator-profile pair, the profile is marked "Bona-Fide" and the process exits. If the profile is neither an Affinity nor a Bona-Fide, the content profile of the message is computed and the count of the matching content profile is incremented (97), and the results checked. If
  • auto-interaction module provides a means for the system of the present invention to autonomously interact with an initiator, using the same message type used by the initiator, to send, receive and process information. Information gathered by auto-interaction module
  • auto-interaction module 15 allows a system of the present invention to interact directly with message initiators over a wired or wireless telephone.
  • this can include
  • VXML-based speech interface technologies that allows queries from the system to be transformed into appropriate speech for voice-based communication to the caller using text-to-speech conversion.
  • automated speech-to-text recognition software can be employed to capture inputs relayed by the caller to the system for processing.
  • auto-interaction module 15 can interact with calendar database
  • auto-interaction module 15 can help initiating callers schedule a time for callback, by presenting the recipient's open time slots and offering the caller to select a slot. In yet another embodiment, auto-interaction module 15 can select from a user-
  • auto-interaction module 15 can also allow a system of the present invention to interact directly with initiators of email. Auto interaction module 15 can automatically process an email to reply to the initiator with an appropriately worded message. Such a system can be employed for numerous applications.
  • auto-interaction module 15 can include information providing the recipient's contextual information (e.g., he is out of town and won't check email until next Monday).
  • auto-interaction module 15 can request further actions from the initiator to verify an affinity relationship to the recipient or to determine whether the initiator's identity is bona fide. For example, typical email spamming applications do not respond to email messages.
  • auto-interaction module 15 does not receive a responsive email within a threshold period of time, the initiator identification is assumed to be bogus.
  • relevance engine 14 For a given unified message from an Initiator, relevance engine 14, in one embodiment, computes the relevance measure of the message based on the Recipient's and Initiator's contexts provided above. In one embodiment, relevance engine 14 receives a message and sends it to recipient context module 12 to compute the recipient's context comprising at least the contact relation type between initiator and the recipient and, potentially, an interest level. An optional further processing step involves sending the message to initiator context module 13 to compute the Initiator's context. Another optional further processing step involves accessing the auto-interaction module 15 for the system to autonomously interact with the initiator directly on the recipient's behalf to establish relevance of the message. Upon processing these inputs, relevance engine 14 prioritizes the message into a number of contextually prioritized folders.
  • FIG. 6544/53735 Figure 5 is a process flow diagram illustrating the computation of a relevance measure.
  • recipient context module 12 computes the recipient's context relative to a received message (step 111).
  • the computed recipient-initiator profile is tested (step 112). If the initiator is known to the recipient, the interest level is checked to see if the message is urgent (step 113).
  • Urgent messages are processed in PI (step 114) and prioritized into the "Urgent" folder (115).
  • Non-urgent messages are processed in P2 (step 116) and prioritized into one of possibly many folders for known initiators (117).
  • the Initiator's context is computed (step 118).
  • the computed identity profile is tested (step 119). If the profile fits that of a spammer, the spamming message is processed in P3 (step 120) and prioritized into a "Spam" folder (121). Otherwise, if the initiator identity profile is bona fide or is associated with an affinity relation (step 122), then the message is processed as a credible message (step 123) and the message is prioritized into one of possibly many folders for unknown but probably interesting folders (124), or possibly into a "Questionable” folder (126). The remaining messages from truly unknown initiator are processed in P5 (step 125) and the results prioritized into a "Questionable” folder (126), or possibly one of the unknown but interesting folders (124).
  • Figure 6 shows an illustrative example of a process flow for handling a unified message of the type telephone call by a system configured according to an embodiment of the present invention.
  • the communication logs 38 and the daily schedule or calendar 36 of the subscribers to the service are available.
  • the telecommunications service provider has necessary provisioning systems in place to detect if a recipient is a subscriber to this service, and to route only
  • a call made by the initiator to the recipient is received by the telecommunications network 10 where information about the call, such as the caller and recipient identification number, is accessible.
  • a further variation of the present inventive system is to perform a check here to see if the recipient has set the call-screening mode to be on or off (step 131). If call screening is off, then calls are treated as per normal (step 132) and not routed through to the present inventive system. Otherwise, the call information together with the call is then routed to message handler 11.
  • Processing of the call begins with passing the caller and recipient identification number (either a phone number or "unlisted” marking) to recipient context module 12 to compute the recipient's context (step 133).
  • the resulting computed contact relation type is checked (step 134). If the caller is known, the auto-interaction module 15 is invoked to interact on behalf of the recipient to enquire of the caller as to the urgency of the call (step 135).
  • auto-interaction module 15 can prompt the user with the message "Hi I'm sorry John is in a meeting right now. Do you want me to interrupt him? Please say yes or no".
  • auto-interaction module 15 captures the user's input (Yes or No).
  • a further variation of this example is to restrict this urgency checking to only those callers with higher priority levels, for example, to callers whose contact relation types are Related or Trusted, but not for callers whose contact relation types are Familiar or Known.
  • the caller responds that the call is urgent (step 136)
  • the call is put through to the recipient regardless of the screening mode.
  • the call is not connected (e.g., because the recipient did not pick up the phone)
  • a voice message is taken and the missed call is placed into the urgent message folder (137), which is accessed by the message interface 16 to notify the recipient of the new message.
  • calls from known callers but which
  • auto-interaction module 15 is invoked to contextually prioritize calls by scheduling a callback appointment with the caller, using the recipient's daily schedule as a context (step 138).
  • An exemplary prompt by auto-interaction module 15 is "Hi, John is available today for a 15 min call at, option 1, 12:30pm, option 2, 5pm, or option 3, leave a message. Please select an option.”
  • calls from known callers are now prioritized using the schedules of both the recipient and the initiator as contexts.
  • the scheduled callbacks, together with voice messages if any, are
  • step 139 which is accessed by message interface 16 to allow for message retrieval by the recipient.
  • a further variation of this example is to restrict this call scheduling prioritization to only those callers with higher priority levels, for example, to
  • step 138 Another variation of step 138 is to prompt the caller for the times slots when the recipient can call back, rather than presenting the open slot options
  • step 138 is to prioritize missed calls by the initiator's profile; for example, calls from Related callers are ranked before calls from Trusted callers, which are placed before calls from Familiar callers,
  • the caller's identification number (either a phone number or "unlisted” marking) is passed to the initiator context module 13 to compute the initiator's context (step 140).
  • the resulting computed initiator identify profile is checked (step 134
  • step 141 If the computed identity profile matches that of a Spam profile (step 141), then the call is not connected and is placed into a "Spam" folder (step 141).
  • the caller is deemed an unknown but credible caller.
  • the call is then treated as a call from a known caller, and, in one embodiment, re-routed to step 135.
  • the remaining calls are deemed to be from unknown callers who do not match Spammers nor Bona-fide profiles. Such calls cannot be simply ignored, since many calls can be made by close contacts from public phones, new office locations or borrowed phones, etc.
  • processing of these calls involves the use of auto-interaction module 15 to prompt the caller to provide an equivalent identity by supplying a contact or initiator identity previously used to communicate with the recipient (step 144).
  • An exemplary prompt by auto-interaction module 15 might be "Hi, I'm sorry I do not recognize you. To proceed, please enter a phone number or email that you have used to contact John before.”
  • the contact provided by the user is passed to the recipient context module 12 for re-computation (step 145) and the resulting contact relation type is checked (step 146). If the profile indicates the caller is known to the recipient, the call is treated as a call from a known caller, and re-routed to step 135. Otherwise the call is from a truly unknown caller, and the caller is prompted to leave a voicemail message, which is placed into the "voicemail" folder (step 147).
  • Figure 7 illustrates a process flow for handling an email by a system according to an embodiment of the present invention. As above, it is assumed that the communication logs and the daily schedule of the subscribers to the service are available.
  • Emails sent by the sender (the initiator) to the recipient contain header information such as sender's email address in the FROM field, the recipient's email address in the TO field, date and time the email is sent in the DATE field, the SUBJECT field and the BODY field.
  • the email is routed through
  • the message interface notifies the email recipient of presence of urgent emails, and permit perusal of the emails by the recipient according to the prioritized folders in the user's inbox.
  • Processing of the email message begins with passing the email together with the header information to recipient context module 12 to compute the recipient's context (step 151).
  • the resulting contact relation type is checked (step 152). If the sender is known, any interest level computed by recipient context module 12 in step 151 is checked to see if the email is urgent (step 153). If so, the email is passed into a notifier module that can provide more timely and immediate means for alerting the recipient (step 154).
  • notification functionality include pagers, mobile phone alerts, Short Message Service or Instant Messaging.
  • the email is then placed into the urgent message folder (step 155), which is accessed by message interface 16 for retrieval by the recipient.
  • non-urgent emails from known senders are contextually prioritized (step 156) according to the contact relation profiles and interest levels computed in step 151.
  • emails can be prioritized into folders based on the sender's profile priority levels, such as "Very Important" folder for emails from Related or Trusted senders, "Important” folder for emails from Familiar senders and "Regular” folder for emails from Known senders.
  • a variation is to further differentiate emails from senders of a given profile priority by the recentness of communication, so the more recent communications the higher the prioritization.
  • email messages are prioritized based on a combination of the computed contact relation sender profiles and interest levels, such as using a "Important Senders” folder for emails from Related or Trusted senders, a "Time sensitive” folder for email marked with “Returning Call”, “Meeting Soon” and “Meeting Canceled” interest levels, a "Location sensitive” folder for emails containing information specific to where the
  • 21 6544/53735 recipient is and a "By Interest" folder for emails whose content matches the recipient's interest profiles (e.g. email discussion threads related to a project, or emails related to a recipient hobby interest).
  • the email together with its header information is passed to the initiator context module 13 to compute the initiator's context (step 158).
  • the resulting computed initiator identify profile is checked (step 159). If the computed identity profile matches a Spam profile, then the email is placed into a "Spam" folder (step 160) which is accessed by message interface 16 and presented to user when he or she accesses the system.
  • emails can be prioritized into a "Possible Friend" folder for emails from senders who communicate regularly with the recipient's regular contacts, a "Possible Colleague” folder for emails from senders who likely work at the same business as the recipient, a "Credible sender” folder for emails from senders who are likely bona-fide senders (as opposed to automated services and spammers).
  • the remaining emails are deemed to be from truly unknown senders who do not match Spammers or Affinity profiles.
  • processing of these emails involves the use of auto-interaction module 15 to prompt the sender to provide an equivalent identity by supplying a contact previously used to communicate with the recipient (step 163).
  • An exemplary email prompt by auto-interaction module 15 might be "Hi, I'm sorry I do not recognize you. If this is an urgent email, please enter a phone number or email that you have used to contact John before, or enter the phone number or email of the person who referenced you to John. Otherwise this will be marked as an email from an unknown sender.”
  • the message is sent as a reply to the sender's email. Any reply from the sender is scanned for contact information which is
  • step 164 the email 22 6544/53735 then passed to the recipient context module 12 for re -computation (step 164) and the results checked in (step 165). If the supplied contact's profile is known to the recipient, the email is added to the Affinity folders, such as the "Credible Sender” folder, in (step 162). Otherwise the email is placed into an "Unknown Sender” folder (step 166)

Abstract

Methods, apparatuses and systems allowing for the contextual prioritization of messages and, in one embodiment, unified messages. Embodiments of the present invention are operative to associate a relevance measure (14) to unified messages by computing the context (12, 13) of the message in relation to both the message recipient (38, 35, 36, 33, 32) and the message initiator (82, 86). Relevance measures, allow for a contextual prioritization of unified messages into a plurality of context-based categories.

Description

METHOD AND SYSTEM FOR CONTEXTUAL PRIORITIZATION OF UNIFIED MESSAGES
RELATED APPLICATION The present application claims priority from provisional application serial number 60/334,388 filed November 30, 2001 and entitled "Method and System for Contextual Prioritization of Unified Messages."
FIELD OF THE INVENTION The present invention relates to messaging systems and, more particularly, to unified messaging systems providing relevance indicators corresponding to received messages.
BACKGROUND OF THE INVENTION In today's information age, there are a variety of communication methods commonly used by businesses and individuals, including voice, fax, email, instant messaging, etc. As the number of communication methods increase, so does the number of messages business professionals and other individuals must manage and be responsive to every day. Unified messaging facilitates management of all such messages by providing a single point of access to different message types, such as voice, fax, and email, from a variety of communications devices, such as a wireless telephone, personal computer or Web browser through the Internet. In the user's email inbox, a unique icon identifies each message type. Users can also access and manage messages through a telephone interface. Using a telephone interface, a user can dial into his unified messaging system from any telephone to listen and respond to almost any message type waiting in an inbox. For example, the user can listen to their email messages using text-to- speech technology and respond to that email message with a voice message. The user can listen to the header of a fax message, forward that message to
6544/53735 someone else, or even send it to the closest fax machine. In addition, a graphical user interface allows users to log in to a unified messaging system and access their messages with a desktop or laptop computer.
The increasing adoption of unified messaging indicates a growing trend toward the convergence of disparate message types on one device. For example, Handspring®, Inc. and Palm®, Inc. have announced their intention to add call capabilities to their respective lines of Personal Digital Assistants (PDAs). Research In Motion, Inc. intends to add voice calling capabilities to its Blackberry® wireless email devices. Nokia's Communicator® combines PDA functionality with wireless phone technology. Japan's NTT DoCoMo I- Mode hand-phones provide both email and voice-calling capabilities. This trend will only exacerbate the information and attention overload problem caused by the variety of messages accessible on a single device. Already, the overload of unwanted emails alone has received much attention giving rise to the creation of sophisticated spam filters and equally sophisticated methods of evading them. Likewise, the increasing frequency of mobile phone interruptions has lead to development of phone jamming products. Current screening technologies, however, pose certain problems for unified messages. For example, such screening technologies are not adapted to unified messages as they operate only on a single message type. Moreover, such screening technologies are ill-suited to handle the large number of messages a user typically receives, as such filter and screening technologies operate in a binary manner accepting "good" and rejecting "bad" messages.
SUMMARY OF THE INVENTION
The present invention provides methods, apparatuses and systems allowing for the contextual prioritization of messages and, in one embodiment, the contextual prioritization of unified messages. Embodiments of the present invention are operative to associate a relevance indicator or category to unified messages by computing the context of the message in
2 6544/53735 relation to both the message recipient and the message initiator. Relevance measures, in one embodiment, allow for a contextual prioritization of unified messages into a plurality of context-based categories.
The present invention has application to any unified message type, including voice-based messages, such as telephone calls and voice-mail messages, and multimedia electronic messages, such as electronic mail (email), short message service (SMS), instant messaging, faxes, and the like.
DESCRIPTION OF THE DRAWINGS The present invention is described with reference to the following figures:
Figure 1 is a functional block diagram providing an overview of a system according to a preferred embodiment of the present invention.
Figure 2 is a functional block diagram setting forth the functionality and process flows associated with computing a message recipient's context relative to an incoming message, according to a preferred embodiment of the present invention.
Figure 3 is a process flowchart describing a method for computing a message recipient's interest level in an incoming message, according to a preferred embodiment of the present invention.
Figure 4 is a process flowchart describing a method for inferring a message initiator's context based on the initiator's profiled identity and profiled content, according to a preferred embodiment of the present invention. Figure 5 is a flowchart diagram of a preferred method for computing the relevance of a unified message, according to the present invention.
Figure 6 is a flowchart of a preferred method for computing the relevance of a telephone message, according to an embodiment of the present invention.
6544/53735 Figure 7 is a flowchart diagram setting forth a method for computing the relevance of an electronic mail message, according to a preferred embodiment of the present invention.
DESCRIPTION OF PREFERRED EMBODIMENT(S)
1. Exemplary Operating Environment
Figure 1 illustrates a communications network environment in which embodiments of the present invention may operate. In reference to Figure 1, the system, according to one embodiment of the invention, comprises message handler 11, recipient context module 12, initiator context module 13, relevance engine 14, auto-interaction module 15, and message interface 16. Message handler 11 is operative to interface with a communications network 10 for receiving and sending unified messages on behalf of a user. Recipient context module 12 is operative to compute a recipient's context in relation to a received message. Initiator context module 13 is operative to compute the message initiator's context in relation to a received message. Relevance engine 14 is operative to compute the relevance of a received message based on the recipient's and, optionally, the initiator's respective contexts. Auto- interaction module 15 facilitates relevance computations by auto-interacting with a message initiator on the recipient's behalf. Auto-interaction module 15 is also operative to provide notices or other information to message initiators. Message interface 16 provides an interface to users facilitating access to message sending and retrieval functionality. Message interface 16, in one embodiment is operative to process the prioritized messages into appropriate inbox folders based on relevance measures computed by relevance engine 14 and allows access to messages for perusal by the recipient. Message interface 16, in one embodiment, is also operative to display or otherwise present prioritized messages in a folder-based inbox interface, and further allows recipient users to reply to received messages or to send new messages. .
6544/53735 The present invention can be applied to any unified message type, which includes any combination of voice-based messages including but not restricted to telephone calls and voice-mail messages, as well as any multimedia electronic messages, including but not restricted to electronic mail (email), short message service (SMS), instant messaging and faxes. In addition, a unified message may be initiated by a human, a software application or a machine.
2. Computing a Recipient's Context Relative To An Incoming Message
For a given unified message from a message initiator, recipient context module 12 computes the Recipient's context to identify a contact relation between the Recipient and the Initiator, and, in one embodiment, potentially a level of interest the recipient may have in the message. In one embodiment, recipient context module 12 categorizes the recipient's context with respect to a received message into one of a plurality of contact relation types relative to the initiator of the message.
2. a. Generating Initiator/Recipient User Profiles Computing the Recipient's context, in one embodiment, involves a background pre-processing step of generating and maintaining user profiles by making inferences based on the user's past communications behavior as recorded by communications log 38. Communications log 38 can acquire data from a variety of sources, such as the logs maintained by the user's telecommunications provider that provide per-call information such as the numbers of calls sent or received, telephone numbers dialed, time and duration of calls made, etc. Other possible sources include email logs or archives that contain per-email information such as sender or recipient addresses, copied addresses, date and time, subject, and message body. Such log information is already being used by the users themselves or by trusted communications services providers, for services such email archiving, email filtering or call billing. In one embodiment, an SMTP server associated with a user is operative to transmit data allowing for logging of the user's emails
5 6544/53735 for purposes of populating communications log 38. In one embodiment of the invention, this information is accessed by interfacing the recipient context module 12 to the communications service provider's message handler 11 so all communications going through message handler 11 are logged automatically. In addition, another possible data source is contacts database 35 (see Figure 1) containing the user's address book and other contacts information, such as names, addresses, telephone numbers, email addresses, etc.
In one embodiment, inference module 32 analyzes and makes inferences from the data stored in communications log 38 and contact database 35 to segregate the user's contacts into a pre-defined set of contact relation types. An illustrative set of contact relation types associated with a user profile is as follows:
• Contacts that are Related to the user;
• Contacts that are Trusted to the user; • Contacts that are Familiar to the user;
• Contacts that are Known to the user; and
• Contacts that are Unknown to the user.
Inference module 32, in one embodiment, applies inference rules to data associated with a user in communications log 38 and/or contact database 35 to generate, and later update, contact relation types associated with the user. An exemplary set of inference rules based on contact identity, communication pattern and frequency of communication events in communications log 38 and/or contact database 35, is as follows:
• Inference of a Known contact: o The user has sent a unified message to the contact at least once.
• Inference of a Familiar contact: o There are at least 2 sent-and-reply message pairs between the user and the contact. • Inference of a Trusted contact: o A contact who is Familiar to user; AND
6 6544/53735 o The number of messages exchanged between the user and the contact within the last 3 months exceeds 20. • Inference of a Related contact: o A contact who is Trusted to the user AND o Matches at least one of the following "affinity" tests:
■ The contact has the same email domain, not including domains belonging to Internet email service providers
■ Has the same residential OR business number • Otherwise, the contact is an Unknown contact.
Inference module 32, in one embodiment, performs this background profiling step for each user on a periodic basis to populate and later update user profile database 33 to contain the user-contact pairs and profiles of the user-contact pairs encountered by the system. In one embodiment, the system of the present invention includes user-access functionalities facilitating access to user profile database 33, such that users can peruse the profile database directly as well as override existing system-defined profiles and contact relation types, or create entirely new ones. 2.b. Computing Recipient's Context Figures 2 and 3 are functional block diagrams illustrating a process flow associated with computing a recipient user's context relative to a received message. As the following provides recipient context module 12 draws information from user profile database 33, communications log 38, contact database 35, and calendar database 36 to compute a recipient's context and infer a recipient's interest level in a received message based on a set of heuristic rules. The operation of computing a recipient's context relative to a message begins with a retrieval of a contact relation associated with the recipient user from user profile database 33 (Figure 2, step 202). The retrieved contact relation, together with the message, is passed to recipient context module 12 for heuristic processing of the recipient's contact relation type with respect to the initiator (step 204) (see above) and, if the
7 6544/53735 initiator is known to the recipient (step 206), an overall Interest level associated with the message (step 208), based on accessible information about the user's context, such as calendar information 36, contact database 35, location and interests. Figure 3 illustrates an exemplary set of heuristic rules that can be applied to determine a recipient's interest level in a received message: • The "VIP" Heuristic (61): This rule checks the priority of the initiator to determine if the message should be marked as "urgent". For example, messages whose recipient-initiator contact relations types are Related or Trusted can be deemed urgent. As another example, initiators appearing in the recipient's contacts database 35 and whose relationship or title indicates the initiator is the recipient's superior, can be deemed urgent. In one embodiment, parameters associated with the VIP heuristic are configurable by the user. For example, the user may configure a list of ' VIPs.
The "Returning a Call" Heuristic (62): Recipient context module 12 scans the communications log 38 to detect if the recipient has unsuccessfully attempted to contact the initiator in the recent past. In one embodiment, the heuristic rule requires a threshold number of unsuccessful attempts within a predetermined period. This will be reflected in the communications log as a multiplicity of unanswered telephone calls and/or emails from the recipient to this contact. When such an event is detected, the message is marked as "Replying" and will be treated by relevance engine 14 as "urgent" regardless of past communication patterns. The "Meeting Soon" Heuristic (63): This rule checks the recipient's calendar as maintained by calendar database 36 to see if the initiator is a participant in a soon-to-occur event on the recipient's schedule. Recipient context module 12 associates such messages with a "meeting soon" tag. Such messages are further marked with an urgent or moderately urgent message tag. A further variation is to vary the degree of urgency based on additional factors, for example, the sooner the scheduled event to the time
8 6544/53735 of the call, the higher the level of urgency assigned to it by the recipient context module 12.
■ The "Meeting Canceled" Heuristic rule (64): This rule applies the "Meeting Soon" rule, and for the case of electronic data messages, further processes the message content for keywords such as "sorry", "cancel", "postpone". Such messages are further marked with an urgent or moderately urgent message tag. A further variation is the vary the degree of urgency based on additional factors, for example, the sooner the scheduled event to the time of the call, the greater the urgency the message is accorded. ■ The "Proximity" Heuristic (65): This rule checks if the message initiator is designated as Trustworthy (either through direct user input, or based on system computed contact relation types of Related or Trusted) and whether the message contains any location-based information. The recipient's location-context is checked to see if she is "close by". If so, the message is marked "Proximity Alert" and its urgency level increased. This rule is particularly apt for mobile-commerce class of messages from recipient's selected list of businesses.
The "Topical Interest" (66): This rule checks the message contents for indications that the recipient is interested in this topic. An illustrative examples include use of selected keywords configured by the user to match a category of interest ("sports", "footballs", "baseball" to match sports- related messages). Another illustrative example is the monitoring of mail logs to identify messages related to a project, for example by tracking discussion threads (emails whose SUBJECT has "RE:" followed by the same topic), scanning for the frequently-occurring distinguishing keywords in the message body (e.g., project name or client name), plus the occurrence of the usual members in the FROM, TO, CC, or BCC list. Such messages are marked "Topical.". • The "Meta-Message" Heuristic: This rule checks for a special class of messages that are distinguished from other messages in two ways, namely, the message is from a controlled class of initiators (such as the
9 6544/53735 communications service provider or from specially registered applications), and the message's content is intended not for perusal by the recipient himself, but rather is intended to influence the recipient's interest levels in other messages. Illustrative examples include a meta message from the mobile phone operator indicating the recipient has moved into a new cell location code, and updating a location state with the new current location code. This can then be used to trigger the "Proximity" heuristic.
A further variation of the above system is the addition of an automatic monitor of the recipient's context, such as location, to determine if changes in the recipient's context warrant a re-computing of the relevance of prioritized messages. In one embodiment, a user's location can be determined in relation to the current wireless cell phone area in which the user's wireless device is located.
3. Computing An Initiator's Context Relative To An Incoming Message
For a given unified message from an initiator, initiator context module 13 determines the initiator's context by computing the initiator's identity profile, and a content profile for the message. 3. a. Initiator Identity Profile
An aspect of computing an initiator's context includes a processing step in which the identity profile of the initiator is computed to determine the level of interest a recipient may have for a particular initiator, even if the initiator is unknown to the recipient. This process accesses previously computed initiator identity profiles in database 82, recipient user profiles from user profile database 33, and/or a phone directory 84 that permits reverse directory lookups.
3.a.l. Affinity Relations As an aspect of computing the initiator's identity profile, initiator context module 13 checks for affinity relations in the initiator's and recipient's communications patterns that can suggest that a recipient would
10 6544/53735 be interested in communicating with the initiator even if there are no prior communications between them. As an illustrative example, initiator identity profiles can be computed from the following rules based on affinity relations:
• "Friend of a Friend" Affinity rule: This rule accesses the user profile database 33 to check if the initiator and the recipient share any Related, Trusted or Familiar contacts, indicating whether the initiator and recipient "travel in the same circles." In one embodiment, this can be accomplished by matching the entire contact list associated with the user profile for the recipient against the same for the initiator. The number of common contacts, as well as the contact relation types associated therewith, are used in computations of an affinity level. As an illustrative example, a recipient and an initiator are considered "Friend of a Friend" if any one of the following is true: a. there is at least 1 Related contact in common; b. there are at least 2 Trusted contacts in common; c. there are at least 5 Familiar contacts in common; and d. there are at least 10 common contacts of any contact relation type.
• "Common Background with Recipient" Affinity rule: This rule analyzes the various specific identities of both the initiator and recipient for common background. As illustrative examples, phone numbers can be searched against phone directory 84, using reverse directory lookup methods, to reveal if the phone number is from a company, a residential address or an unlisted number. The recipient and the initiator are related by "Common Background" if any of these are true: a. Both phone numbers are business numbers and are from the same company; b. Both phone numbers are residential numbers and are from the same residential address; or c. Both email addresses share the same internet domain, unless the domain is associated with an email or internet service provider.
11 6544/53735 • "Common background with Recipient's contacts" Affinity rule: This rule applies the criterion set forth in the above "Common Background" rule to infer an affinity relation from contact relations, if any, between the initiator and any of the recipient's Related, Trusted or Familiar contacts. 3. a.2. Bona Fide Initiator Identification
A second aspect of initiator identity profiling is to check if the initiator is associated with a bogus identity or bona-fide identity (e.g., phone number, email address, etc.). An initiator identity can be a phone number, an email address or any other suitable identification. This check is especially important for the unified message type of emails. Since the bulk of email messages are not authenticated, forgery of the "From" address is a particularly common practice among email spammers. An illustrative example of computing the bona-fide relation is as follows:
• Bona-Fide Identity rule: This rule accesses the user profile database 33 to retrieve all contacts associated with the initiator. If the initiator has at least 3 Trusted contacts or 10 Familiar contacts, the initiator is marked as Bona-Fide. The actual thresholds used can be varied and fine-tuned. One variation is to permit user programmable thresholds. Another is to adapt the thresholds based on actual system performance. 3. a.3. Identity Profile Database
A third aspect of the identity profiling is the maintenance of a database that logs all previously computed identity profiles. This provides a system memory for remembering initiators, and reduced redundant processes associated with computing initiator identity profiles. Hence this database is designed for efficient access. Likewise every new initiator identity profile computed is also logged into the database 82. 3.b. Message Content Profile
In one embodiment, initiator context module 13 computes a content profile for the message to determine the Ukelihood that the message is a bulk message or SPAM sent by an initiator, alien not only to this recipient but also
12 6544/53735 to almost all of its recipients. This process also accesses message content database 86 storing previously computed message content profiles.
An illustrative example of processing message content profiles generally comprises the following steps: • Compute a message signature: A representation of the message is computed that is more suitable for processing in subsequent steps. As an illustrative example, a telephone call can be processed through an automatic speech-to-text recognition processor (such as is available from companies such as Nuance, SpeechWorks, etc.) to obtain the electronic digital version of the message. The electronic digital versions of the message are then stored in a form for efficient processing. As an illustrative example, an email can be stored as a word-frequency vector (a string of words together with their frequency counts in the message), a representation commonly used in information retrieval applications. • Normahze the message signature. This processing further abstracts the message signature to capture the essential parts of the message and ignore the minor variations of the same message. An illustrative example is the removal of commonly-occurring words (known as stop words in information retrieval applications). Another illustrative example is the removal of all number sequences in the message. Another illustrative example is to store only representations of selective fields in structured messages, such as ignoring the FROM, TO, SUBJECT, and DATE fields and representing only the message BODY. Another illustrative example is to identify and extract contact identities (phone numbers or email addresses) contained in the message.
• Compute a unique identification for the message signature. This processing step computes a highly likely unique identification for a given normalized message signature. An illustrative example is the application of the widely used message digest algorithm used in digital signature applications. MD5 processing that takes a string and returns a 128-bit
13
6544/53735 fingerprint or message digest of the string that can serve as the message's unique identification.
• The content profile of a message, in one embodiment, comprises a unique message identification, a normalized message signature, and a message count), where the message count keeps track of the number of minor variations of the same message encountered by the system, as represented by the normalized message signature.
• A message content profile database 86 allows for tracking the number of similar messages encountered by a system of the present invention. The unique message identification is used to index the message content profiles, and can be used as a primary key into a database storage, or as a key to a hash table. In one embodiment, if the message of an unknown initiator has a normalized email signature that has a high count, the message is deemed to match a spam content profile.
3.c. Overall Process Flow for Computing Initiator Context In reference to Figure 4, the process flow of computing an initiator's context begins with accessing initiator identity profile database 82 to determine the contact relation type, if any, between the initiator and the recipient (step 91). If a computed contact relation type already exists for the initiator (step 92), the contact relation type is retrieved and the process exits. Otherwise, initiator context module 13 creates an initiator identity profile in initiator identity profile database 82 (step 93) and applies the checks discussed above. If the profile fits an Affinity profile (94), the corresponding entry in initiator identity profile database 82 is updated to reflect this new initiator- affinity pair (95), the profile is marked "Affinity" and the process exits. If the profile fits a Bona-Fide profile (96), the identity profile database is updated to reflect this new initiator-profile pair, the profile is marked "Bona-Fide" and the process exits. If the profile is neither an Affinity nor a Bona-Fide, the content profile of the message is computed and the count of the matching content profile is incremented (97), and the results checked. If
14 6544/53735 the profile fits a Spam content profile (98), the profile is marked "Spammer" and the process exits. Any messages left are marked with the profile "Unknown" and the process exits.
5 4. Auto-Interaction Module
In reference to Figure 1, auto-interaction module (15) provides a means for the system of the present invention to autonomously interact with an initiator, using the same message type used by the initiator, to send, receive and process information. Information gathered by auto-interaction module
10 15, by interacting directly with the initiator, provides further criterion for establishing the relevance of a given message.
As an illustrative example, auto-interaction module 15 allows a system of the present invention to interact directly with message initiators over a wired or wireless telephone. In a preferred embodiment, this can include
15 VXML-based speech interface technologies that allows queries from the system to be transformed into appropriate speech for voice-based communication to the caller using text-to-speech conversion. Likewise automated speech-to-text recognition software can be employed to capture inputs relayed by the caller to the system for processing. A further variation
20 is the additional use of DTMF processing to allow user input through keying of characters rather than speaking.
Such a system can be employed for numerous applications within the system of the present invention. In one preferred embodiment related to a known caller, auto-interaction module 15 can interact with calendar database
25 34 to inform the initiating caller about the recipient's current context (e.g., he is in a meeting until 4pm). In another embodiment, auto-interaction module 15 can help initiating callers schedule a time for callback, by presenting the recipient's open time slots and offering the caller to select a slot. In yet another embodiment, auto-interaction module 15 can select from a user-
30 definable library of voice templates for use in text-to-speech interface, to allow for the recipient to personalize the interactions with different initiators.
15 6544/53735 As another illustrative example, auto-interaction module 15 can also allow a system of the present invention to interact directly with initiators of email. Auto interaction module 15 can automatically process an email to reply to the initiator with an appropriately worded message. Such a system can be employed for numerous applications. In one preferred embodiment related to a known initiator, auto-interaction module 15 can include information providing the recipient's contextual information (e.g., he is out of town and won't check email until next Monday). In another embodiment related to an unknown initiator, auto-interaction module 15 can request further actions from the initiator to verify an affinity relationship to the recipient or to determine whether the initiator's identity is bona fide. For example, typical email spamming applications do not respond to email messages. In one embodiment, if auto-interaction module 15 does not receive a responsive email within a threshold period of time, the initiator identification is assumed to be bogus.
5. Computing Relevance of Incoming Unified Messages
For a given unified message from an Initiator, relevance engine 14, in one embodiment, computes the relevance measure of the message based on the Recipient's and Initiator's contexts provided above. In one embodiment, relevance engine 14 receives a message and sends it to recipient context module 12 to compute the recipient's context comprising at least the contact relation type between initiator and the recipient and, potentially, an interest level. An optional further processing step involves sending the message to initiator context module 13 to compute the Initiator's context. Another optional further processing step involves accessing the auto-interaction module 15 for the system to autonomously interact with the initiator directly on the recipient's behalf to establish relevance of the message. Upon processing these inputs, relevance engine 14 prioritizes the message into a number of contextually prioritized folders.
16
6544/53735 Figure 5 is a process flow diagram illustrating the computation of a relevance measure. As figure 5 shows, recipient context module 12 computes the recipient's context relative to a received message (step 111). The computed recipient-initiator profile is tested (step 112). If the initiator is known to the recipient, the interest level is checked to see if the message is urgent (step 113). Urgent messages are processed in PI (step 114) and prioritized into the "Urgent" folder (115). Non-urgent messages are processed in P2 (step 116) and prioritized into one of possibly many folders for known initiators (117). If the recipient-initiator contact relation type is Unknown and hence the recipient does not know the initiator (step 112), the Initiator's context is computed (step 118). The computed identity profile is tested (step 119). If the profile fits that of a spammer, the spamming message is processed in P3 (step 120) and prioritized into a "Spam" folder (121). Otherwise, if the initiator identity profile is bona fide or is associated with an affinity relation (step 122), then the message is processed as a credible message (step 123) and the message is prioritized into one of possibly many folders for unknown but probably interesting folders (124), or possibly into a "Questionable" folder (126). The remaining messages from truly unknown initiator are processed in P5 (step 125) and the results prioritized into a "Questionable" folder (126), or possibly one of the unknown but interesting folders (124).
6. Exemplary Process Flow for Telephone Call
Figure 6 shows an illustrative example of a process flow for handling a unified message of the type telephone call by a system configured according to an embodiment of the present invention. For this embodiment, it is assumed that the communication logs 38 and the daily schedule or calendar 36 of the subscribers to the service are available. It is further assumed that the telecommunications service provider has necessary provisioning systems in place to detect if a recipient is a subscriber to this service, and to route only
17 6544/53735 calls to subscribers to the contextualized prioritization system of the present invention.
A call made by the initiator to the recipient is received by the telecommunications network 10 where information about the call, such as the caller and recipient identification number, is accessible. A further variation of the present inventive system is to perform a check here to see if the recipient has set the call-screening mode to be on or off (step 131). If call screening is off, then calls are treated as per normal (step 132) and not routed through to the present inventive system. Otherwise, the call information together with the call is then routed to message handler 11.
Processing of the call begins with passing the caller and recipient identification number (either a phone number or "unlisted" marking) to recipient context module 12 to compute the recipient's context (step 133). The resulting computed contact relation type is checked (step 134). If the caller is known, the auto-interaction module 15 is invoked to interact on behalf of the recipient to enquire of the caller as to the urgency of the call (step 135). As an illustrative example, auto-interaction module 15 can prompt the user with the message "Hi I'm sorry John is in a meeting right now. Do you want me to interrupt him? Please say yes or no". Using automatic speech recognition or DTMF interface, auto-interaction module 15 captures the user's input (Yes or No). A further variation of this example is to restrict this urgency checking to only those callers with higher priority levels, for example, to callers whose contact relation types are Related or Trusted, but not for callers whose contact relation types are Familiar or Known.
If the caller responds that the call is urgent (step 136), the call is put through to the recipient regardless of the screening mode. In the event the call is not connected (e.g., because the recipient did not pick up the phone), a voice message is taken and the missed call is placed into the urgent message folder (137), which is accessed by the message interface 16 to notify the recipient of the new message. Otherwise, calls from known callers but which
18 6544/53735 are not sufficiently important to interrupt the recipient, are contextually prioritized. In this illustrative example, auto-interaction module 15 is invoked to contextually prioritize calls by scheduling a callback appointment with the caller, using the recipient's daily schedule as a context (step 138). 5 An exemplary prompt by auto-interaction module 15 is "Hi, John is available today for a 15 min call at, option 1, 12:30pm, option 2, 5pm, or option 3, leave a message. Please select an option." As a result, calls from known callers are now prioritized using the schedules of both the recipient and the initiator as contexts. The scheduled callbacks, together with voice messages if any, are
10 marked by their times and placed into a prioritized missed call folder (step 139) which is accessed by message interface 16 to allow for message retrieval by the recipient.
A further variation of this example is to restrict this call scheduling prioritization to only those callers with higher priority levels, for example, to
15 callers whose contact relation types are Related or Trusted or Familiar, but not for callers whose contact relation types are Known, who are permitted only to leave voice messages.
Another variation of step 138 is to prompt the caller for the times slots when the recipient can call back, rather than presenting the open slot options
20 of the recipient. An exemplary prompt by auto-interaction module 15 might be "When would you like John to call you back. Please specify a time followed by am or pm." Another variation of step 138 is to prioritize missed calls by the initiator's profile; for example, calls from Related callers are ranked before calls from Trusted callers, which are placed before calls from Familiar callers,
25 etc.
If, however, the caller is unknown to the recipient (step 134), the caller's identification number (either a phone number or "unlisted" marking) is passed to the initiator context module 13 to compute the initiator's context (step 140). The resulting computed initiator identify profile is checked (step
30 141). If the computed identity profile matches that of a Spam profile (step 141), then the call is not connected and is placed into a "Spam" folder (step
19 6544/53735 137), which is accessed by message interface 16 to notify the recipient and allow for message retrieval by the recipient.
If the computed identity profile is bona fide or is associated with an affinity relation (step 143), the caller is deemed an unknown but credible caller. The call is then treated as a call from a known caller, and, in one embodiment, re-routed to step 135. The remaining calls are deemed to be from unknown callers who do not match Spammers nor Bona-fide profiles. Such calls cannot be simply ignored, since many calls can be made by close contacts from public phones, new office locations or borrowed phones, etc. In one embodiment, processing of these calls involves the use of auto-interaction module 15 to prompt the caller to provide an equivalent identity by supplying a contact or initiator identity previously used to communicate with the recipient (step 144). An exemplary prompt by auto-interaction module 15 might be "Hi, I'm sorry I do not recognize you. To proceed, please enter a phone number or email that you have used to contact John before." The contact provided by the user is passed to the recipient context module 12 for re-computation (step 145) and the resulting contact relation type is checked (step 146). If the profile indicates the caller is known to the recipient, the call is treated as a call from a known caller, and re-routed to step 135. Otherwise the call is from a truly unknown caller, and the caller is prompted to leave a voicemail message, which is placed into the "voicemail" folder (step 147).
7. An Exemplary Process Flow for Electronic Mail
Figure 7 illustrates a process flow for handling an email by a system according to an embodiment of the present invention. As above, it is assumed that the communication logs and the daily schedule of the subscribers to the service are available.
Emails sent by the sender (the initiator) to the recipient contain header information such as sender's email address in the FROM field, the recipient's email address in the TO field, date and time the email is sent in the DATE field, the SUBJECT field and the BODY field. The email is routed through
20 6544/53735 the communications network to message handler 11. Once the message's relevance is computed and prioritized into a folder, the message interface notifies the email recipient of presence of urgent emails, and permit perusal of the emails by the recipient according to the prioritized folders in the user's inbox.
Processing of the email message begins with passing the email together with the header information to recipient context module 12 to compute the recipient's context (step 151). The resulting contact relation type is checked (step 152). If the sender is known, any interest level computed by recipient context module 12 in step 151 is checked to see if the email is urgent (step 153). If so, the email is passed into a notifier module that can provide more timely and immediate means for alerting the recipient (step 154). Illustrative examples notification functionality include pagers, mobile phone alerts, Short Message Service or Instant Messaging. The email is then placed into the urgent message folder (step 155), which is accessed by message interface 16 for retrieval by the recipient.
Otherwise, non-urgent emails from known senders are contextually prioritized (step 156) according to the contact relation profiles and interest levels computed in step 151. As illustrative examples, emails can be prioritized into folders based on the sender's profile priority levels, such as "Very Important" folder for emails from Related or Trusted senders, "Important" folder for emails from Familiar senders and "Regular" folder for emails from Known senders. A variation is to further differentiate emails from senders of a given profile priority by the recentness of communication, so the more recent communications the higher the prioritization.
In one embodiment, email messages are prioritized based on a combination of the computed contact relation sender profiles and interest levels, such as using a "Important Senders" folder for emails from Related or Trusted senders, a "Time sensitive" folder for email marked with "Returning Call", "Meeting Soon" and "Meeting Canceled" interest levels, a "Location sensitive" folder for emails containing information specific to where the
21 6544/53735 recipient is and a "By Interest" folder for emails whose content matches the recipient's interest profiles (e.g. email discussion threads related to a project, or emails related to a recipient hobby interest).
If the sender is unknown to the recipient (step 152), the email together with its header information is passed to the initiator context module 13 to compute the initiator's context (step 158). The resulting computed initiator identify profile is checked (step 159). If the computed identity profile matches a Spam profile, then the email is placed into a "Spam" folder (step 160) which is accessed by message interface 16 and presented to user when he or she accesses the system.
If the computed identity profile matches an Affinity or Bona-Fide profile (step 161), the sender is deemed an unknown but credible caller. The email is then prioritized (step 162), based on the profiles computed in step 158. As illustrative examples, emails can be prioritized into a "Possible Friend" folder for emails from senders who communicate regularly with the recipient's regular contacts, a "Possible Colleague" folder for emails from senders who likely work at the same business as the recipient, a "Credible sender" folder for emails from senders who are likely bona-fide senders (as opposed to automated services and spammers). The remaining emails are deemed to be from truly unknown senders who do not match Spammers or Affinity profiles. In one embodiment, processing of these emails involves the use of auto-interaction module 15 to prompt the sender to provide an equivalent identity by supplying a contact previously used to communicate with the recipient (step 163). An exemplary email prompt by auto-interaction module 15 might be "Hi, I'm sorry I do not recognize you. If this is an urgent email, please enter a phone number or email that you have used to contact John before, or enter the phone number or email of the person who referenced you to John. Otherwise this will be marked as an email from an unknown sender." In one embodiment, the message is sent as a reply to the sender's email. Any reply from the sender is scanned for contact information which is
22 6544/53735 then passed to the recipient context module 12 for re -computation (step 164) and the results checked in (step 165). If the supplied contact's profile is known to the recipient, the email is added to the Affinity folders, such as the "Credible Sender" folder, in (step 162). Otherwise the email is placed into an "Unknown Sender" folder (step 166)
8. Conclusion
A system and method for computing the relevance of unified messages has been described. The above-described embodiments of the invention are intended to be illustrative only. Numerous alternative embodiments may be devised by those skilled in the art without departing from the spirit and scope of the invention. Accordingly, the present invention has been described with reference to specific embodiments. Other embodiments of the present invention will be apparent to one of ordinary skill in the art. It is, therefore, intended that the claims set forth below not be limited to the embodiments described above.
23 6544/53735

Claims

CLAIMS What is claimed is:
1. A system allowing for the contextual prioritization of messages, comprising a message handler operative to interface with a communications network to receive and send messages for at least one user; a relevance engine operative to compute the relevance of a received message based on the recipient user's context relative to at least one attribute of the received message; and a message interface operative to facilitate the sending and retrieval of messages for the at least one user.
2. The system of claim 1 wherein the relevance engine is operative to categorize the received message into one of a plurality of predefined relevance categories.
3. The system of claim 1 wherein the message interface provides a user interface including a plurality of folders corresponding to the predefined relevance categories.
4. The system of claim 3 wherein the relevance engine is operative to prioritize the message into one of the plurality of folders based on the identified relevance category.
5. The system of claim 1 further comprising a recipient context module operative to compute a recipient user's context in relation to a received message.
24 6544/53735
6. The system of claim 5 wherein the recipient context module is operative to compute the recipient user's context by identifying a contact relation type between the recipient user and the initiator of the received message.
7. The system of claim 6 wherein the recipient context module is operative to categorize the recipient user's context with respect to the received message into one of a plurality of contact relation types relative to the initiator of the received message.
8. The system of claim 6 wherein the recipient context module is further operative to compute the recipient user's interest level for the received message.
9. The system of claim 8 wherein the recipient context module is operative to compute the recipient user's interest level in the received message based on a predefined set of heuristic rules.
10. The system of claim 5 further comprising an inference module and a communications log, wherein the communications log stores data relating to the messages sent and received by at least one user, wherein the inference module is operative, in relation to the at least one user, to make inferences, based on a set of inference rules, from the data stored in the communications log and segregate the at least one user's contacts into a pre-defined set of contact relation types.
11. The system of claim 10 wherein the recipient context module is operative to categorize a received message based on the contact relation type between the recipient user and the initiator of the message computed by the inference module.
25 6544/53735
12. The system of claim 10 further comprising a user profile database storing a plurality of user contact pairs and contact relation types corresponding to the user contact pairs, and wherein the inference module is operative to store user contact pairs and computed contact relation types in the user profile database.
13. The system of claim 12 wherein the recipient context module is operative to access the user profile database to identify a contact relation type between a recipient user and the initiator of a received message.
14. The system of claim 10 wherein the inference module operates in a separate, background process relative to the relevance engine.
15. The system of claim 1 further comprising an initiator context module operative to determine the context of the initiator relative to a received message.
16. The system of claim 15 wherein the relevance engine is operative to pass received messages associated with initiator's unknown to the recipient user to the initiator context module.
17. The system of claim 15 further comprising an initiator identity profile database storing initiator identity profiles computed by the initiator context module.
18. The system of claim 15 wherein the initiator context module is further operative to compute a content profile for received messages.
19. The system of claim 18 wherein the relevance engine is operative to compute the relevance of received messages based on the corresponding
26 6544/53735 initiator's context and content profile computed by the initiator context module.
20. The system of claim 1 wherein the message handler includes unified
5 messaging functionality allowing for the receipt and sending of a plurality of message types.
21. The system of claim 20 wherein the message types comprise at least one of the message types selected from the group consisting of voice calls, voice
10 messages, faxes, text messages, SMS messages, faxes, and emails.
22. A method allowing for the contextual prioritization of messages in a messaging system, comprising receiving a message from an initiator on behalf of a recipient user; 15 computing the recipient user's context relative to the received message; categorizing the received message into one of a plurality of prioritization categories based at least in part on the recipient user's context relative to the received message.
20 23. The method of claim 22 wherein the categorizing step further comprises prioritizing the message into one of a plurality of contextually prioritized folders.
24. The method of claim 22 further comprising
25 maintaining a communications log storing data relating to messages encountered by the messaging system; operating on the data in the communications log to create initiator- recipient contact pairs and determining a corresponding contact relation type for the initiator-recipient contact pairs based on a predefined set of rules; and
30 storing initiator-recipient contact pairs and corresponding contact relation types in a user profile database.
27 6544/53735
25. The method of claim 24 wherein the computing step comprises access the user profile database to retrieve an initiator-recipient contact pair matching the recipient user and initiator associated with the 5 received message.
26. The method of claim 25 further comprising setting the contact relation type to unknown if no matching initiator- recipient contact pair is retrieved. 10
27. The method of claim 26 further comprising computing the initiator's context relative to the received message, if the contact relation type associated with the message is unknown.
15 28. The method of claim 27 wherein computing the initiator's context comprises determining the initiator's identity profile by applying a predefined set of heuristic rules.
20 29. The method of claim 28 wherein the determining the initiator's identity profile comprises testing for one or more affinity relation types between the recipient user and the initiator.
25 30. The method of claim 28 wherein the determining the initiator's identity profile comprises testing whether the initiator is bona fide based on examination of the initiator's contacts with other users.
30 31. The method of claim 28 further comprising
28 6544/53735 computing a content profile for the message and comparing the computed content profile to one or more screening profiles.
32. The method of claim 31 wherein at least one screening profile is adapted to detect spam messages.
33. The method of claim 22 wherein the computing the recipient user's context comprises determining a contact relation type between the recipient user and the initiator; and if the initiator is known to the recipient user, computing an interest level the recipient user may have in the received message.
34. An apparatus allowing for the contextual prioritization of messages, comprising a recipient context module operative to compute a recipient user's context in relation to a received message; an initiator context module operative to determine the context of the initiator relative to a received message; a relevance engine operably coupled to a communications network to monitor the transmission and receipt of messages for at least one user, wherein the relevance engine is operative to compute the relevance of a received message based, at least in part, on the recipient user's context relative to at least one attribute of the received message, wherein the relevance engine is operative to pass received messages to the recipient context module, and wherein the relevance engine is operative to pass received messages associated with initiator's unknown to the recipient user to the initiator context module.
29 6544/53735
35. The apparatus of claim 34 wherein the relevance engine is operative to categorize the received message into one of a plurality of predefined relevance categories.
36. The apparatus of claim 34 further comprising an auto-interaction module operably coupled to the communications network and operative to auto- interact with a message initiator.
37. The apparatus of claim 36 wherein the relevance engine is operative to invoke the auto-interaction module in response to a received message from an initiator unknown to the recipient user.
38. The apparatus of claim 37 wherein the auto-interaction module is operative to query the initiator for information relevant to a determination of a contact relation type between the initiator and the recipient user.
39. The apparatus of claim 38 wherein auto-interaction module is operative to query the initiator for information relevant to a determination of the initiator's context.
40. The apparatus of claim 34 further comprising a message handler operative to interface with the communications network to receive and send messages for at least one user; a message interface operative to facilitate the sending and retrieval of messages for the at least one user.
41. The apparatus of claim 40 further comprising an inference module and a communications log, wherein the communications log stores data relating to the messages sent and received by at least one user, wherein the inference module is operative, in relation to the at least one user, to make inferences, based on a set of inference rules, from
30 6544/53735 the data stored in the communications log and segregate the at least one user's contacts into a pre-defined set of contact relation types.
42. The apparatus of claim 41 further comprising a contacts database storing data relating to the contacts associated with at least one user, wherein the inference module is operative, in relation to the at least one user, to make inferences, based on a set of inference rules, from the data stored in the communications log and the contacts database and segregate the at least one user's contacts into a pre-defined set of contact relation types.
43. The apparatus of claim 42 wherein the recipient context module is operative to categorize a received message based on the contact relation type between the recipient user and the initiator of the message computed by the inference module.
44. The apparatus of claim 43 further comprising a user profile database storing a plurality of user contact pairs and contact relation types corresponding to the user contact pairs, and wherein the inference module is operative to store user contact pairs and computed contact relation types in the user profile database.
45. The apparatus of claim 44 wherein the recipient context module is operative to access the user profile database to identify a contact relation type between a recipient user and the initiator of a received message.
46. The apparatus of claim 42 wherein the inference module operates in a separate, background process relative to the relevance engine.
47. The apparatus of claim 34 further comprising an initiator identity profile database storing initiator identity profiles computed by the initiator context module.
31 6544/53735
48. The apparatus of claim 47 wherein the initiator context module is further operative to compute a content profile for a received message.
5 49. The apparatus of claim 48 wherein the relevance engine is operative to compute the relevance of received messages based on the corresponding initiator's context and content profile computed by the initiator context module.
10 50. The apparatus of claim 40 wherein the message handler includes unified messaging functionality allowing for the receipt and sending of a plurality of message types.
51. The system of claim 50 wherein the message types comprise at least one 15 of the message types selected from the group consisting of voice calls, voice messages, faxes, text messages, SMS messages, faxes, and emails.
32 6544/53735
PCT/US2002/038103 2001-11-30 2002-11-26 Method and system for contextual prioritization of unified messages WO2003048960A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002357029A AU2002357029A1 (en) 2001-11-30 2002-11-26 Method and system for contextual prioritization of unified messages

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US33438801P 2001-11-30 2001-11-30
US60/334,388 2001-11-30

Publications (1)

Publication Number Publication Date
WO2003048960A1 true WO2003048960A1 (en) 2003-06-12

Family

ID=23306968

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/038103 WO2003048960A1 (en) 2001-11-30 2002-11-26 Method and system for contextual prioritization of unified messages

Country Status (3)

Country Link
US (1) US20030105827A1 (en)
AU (1) AU2002357029A1 (en)
WO (1) WO2003048960A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1494409A2 (en) * 2003-06-30 2005-01-05 Microsoft Corporation Use of a bulk-email filter within a system for classifying messages for urgency or importance
WO2005029796A1 (en) * 2003-09-23 2005-03-31 Koninklijke Philips Electronics N.V. Reducing load at a mail server
EP1603066A1 (en) * 2004-06-01 2005-12-07 Microsoft Corporation Email manager
GB2435978A (en) * 2006-03-06 2007-09-12 Motorola Inc Processing of voice messages in a communication system
WO2007123821A2 (en) 2006-04-20 2007-11-01 Cisco Technology, Inc. Techniques for tracking communication frequency across communication modalities
EP1947596A1 (en) * 2007-01-18 2008-07-23 Jubii IP Limited A method for automatically displaying electronic information received by a recipient in a sorted order and a communication system and/or system for exchanging information
US8566413B2 (en) 2000-03-16 2013-10-22 Microsoft Corporation Bounded-deferral policies for guiding the timing of alerting, interaction and communications using local sensory information

Families Citing this family (135)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040073617A1 (en) 2000-06-19 2004-04-15 Milliken Walter Clark Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail
US7243226B2 (en) * 2001-12-12 2007-07-10 Valve Corporation Method and system for enabling content security in a distributed system
US7580972B2 (en) * 2001-12-12 2009-08-25 Valve Corporation Method and system for controlling bandwidth on client and server
US8108687B2 (en) 2001-12-12 2012-01-31 Valve Corporation Method and system for granting access to system and content
US20030233419A1 (en) * 2002-01-08 2003-12-18 Joerg Beringer Enhanced email management system
US8396926B1 (en) 2002-07-16 2013-03-12 Sonicwall, Inc. Message challenge response
US8924484B2 (en) * 2002-07-16 2014-12-30 Sonicwall, Inc. Active e-mail filter with challenge-response
US7539726B1 (en) 2002-07-16 2009-05-26 Sonicwall, Inc. Message testing
US7908330B2 (en) 2003-03-11 2011-03-15 Sonicwall, Inc. Message auditing
US7788327B2 (en) * 2002-11-28 2010-08-31 Panasonic Corporation Device, program and method for assisting in preparing email
SG151106A1 (en) * 2002-12-03 2009-04-30 Research In Motion Ltd Method, system and computer software product for pre-selecting a folder for a message
US6732157B1 (en) * 2002-12-13 2004-05-04 Networks Associates Technology, Inc. Comprehensive anti-spam system, method, and computer program product for filtering unwanted e-mail messages
US7299261B1 (en) 2003-02-20 2007-11-20 Mailfrontier, Inc. A Wholly Owned Subsidiary Of Sonicwall, Inc. Message classification using a summary
US8266215B2 (en) * 2003-02-20 2012-09-11 Sonicwall, Inc. Using distinguishing properties to classify messages
US7406502B1 (en) 2003-02-20 2008-07-29 Sonicwall, Inc. Method and system for classifying a message based on canonical equivalent of acceptable items included in the message
US20050080857A1 (en) * 2003-10-09 2005-04-14 Kirsch Steven T. Method and system for categorizing and processing e-mails
US20040254990A1 (en) * 2003-06-13 2004-12-16 Nokia, Inc. System and method for knock notification to an unsolicited message
US8489769B2 (en) * 2003-10-02 2013-07-16 Accenture Global Services Limited Intelligent collaborative expression in support of socialization of devices
US20050134938A1 (en) * 2003-12-22 2005-06-23 Perry Brad S. Systems and methods for tracking communication
US8805933B2 (en) * 2003-12-29 2014-08-12 Google Inc. System and method for building interest profiles from related messages
US7818680B2 (en) * 2003-12-29 2010-10-19 International Business Machines Corporation Method for deleting related messages
US7409641B2 (en) * 2003-12-29 2008-08-05 International Business Machines Corporation Method for replying to related messages
US7412437B2 (en) 2003-12-29 2008-08-12 International Business Machines Corporation System and method for searching and retrieving related messages
US7707122B2 (en) * 2004-01-29 2010-04-27 Yahoo ! Inc. System and method of information filtering using measures of affinity of a relationship
US7885901B2 (en) * 2004-01-29 2011-02-08 Yahoo! Inc. Method and system for seeding online social network contacts
US20050171954A1 (en) * 2004-01-29 2005-08-04 Yahoo! Inc. Selective electronic messaging within an online social network for SPAM detection
US7269590B2 (en) * 2004-01-29 2007-09-11 Yahoo! Inc. Method and system for customizing views of information associated with a social network user
US8612359B2 (en) * 2004-01-29 2013-12-17 Yahoo! Inc. Method and system for sharing portal subscriber information in an online social network
CA2457478A1 (en) * 2004-02-12 2005-08-12 Opersys Inc. System and method for warranting electronic mail using a hybrid public key encryption scheme
US6992359B2 (en) * 2004-02-26 2006-01-31 Grandis, Inc. Spin transfer magnetic element with free layers having high perpendicular anisotropy and in-plane equilibrium magnetization
US7496500B2 (en) * 2004-03-01 2009-02-24 Microsoft Corporation Systems and methods that determine intent of data and respond to the data based on the intent
US20050203929A1 (en) * 2004-03-09 2005-09-15 Devapratim Hazarika System, method and computer program product for prioritizing contacts
US20050204009A1 (en) * 2004-03-09 2005-09-15 Devapratim Hazarika System, method and computer program product for prioritizing messages
DE102005009793A1 (en) * 2004-12-30 2006-07-13 Siemens Ag A method for content-based prioritization of voice messages in a communication system
JP4742618B2 (en) * 2005-02-28 2011-08-10 富士ゼロックス株式会社 Information processing system, program, and information processing method
US8077842B2 (en) * 2005-05-25 2011-12-13 Cisco Technology, Inc. System and method for associating due dates with messages
US8412173B2 (en) * 2005-07-01 2013-04-02 Cisco Technology, Inc. Method and system for providing a contact attempt service
US20070047717A1 (en) * 2005-08-25 2007-03-01 Charles Ho Telephone record search system
US8225231B2 (en) 2005-08-30 2012-07-17 Microsoft Corporation Aggregation of PC settings
US7894597B2 (en) * 2005-10-12 2011-02-22 Cisco Technology, Inc. Categorization of telephone calls
US7730141B2 (en) * 2005-12-16 2010-06-01 Microsoft Corporation Graphical interface for defining mutually exclusive destinations
US20070143428A1 (en) * 2005-12-21 2007-06-21 Shruti Kumar Method and system for displaying indications of messages from important persons and from new persons at a high display priority in a gathered threads view of an electronic mail ("email") user interface
US7822846B1 (en) * 2006-01-26 2010-10-26 Sprint Spectrum L.P. Method and system for brokering media files
DE102006004819B4 (en) * 2006-01-27 2007-12-20 Nokia Siemens Networks Gmbh & Co.Kg A multi-party communication method, arrangement, communication management server and communication terminal for carrying out a communication procedure with a plurality of participants
US8006190B2 (en) * 2006-10-31 2011-08-23 Yahoo! Inc. Social namespace addressing for non-unique identifiers
US7958117B2 (en) * 2006-11-17 2011-06-07 Yahoo! Inc. Initial impression analysis tool for an online dating service
US8141133B2 (en) * 2007-04-11 2012-03-20 International Business Machines Corporation Filtering communications between users of a shared network
CN101785284B (en) * 2007-08-13 2013-07-31 日本电气株式会社 Communication device, communication analysis method, and communication analysis program
US8103726B2 (en) * 2007-08-17 2012-01-24 International Business Machines Corporation Analyzing email content to determine potential intended recipients
US9276775B2 (en) * 2007-09-05 2016-03-01 Microsoft Patent Licensing, LLC Identity-based interactive response message
US20090125602A1 (en) * 2007-11-14 2009-05-14 International Business Machines Corporation Automatic priority adjustment for incoming emails
US8364666B1 (en) * 2008-01-02 2013-01-29 Verint Americas, Inc. Method and system for context-aware data prioritization using a common scale and logical transactions
US20090171960A1 (en) * 2008-01-02 2009-07-02 Ziv Katzir Method and system for context-aware data prioritization
FR2929791B1 (en) * 2008-04-04 2010-12-31 Alcatel Lucent METHOD FOR MANAGING ELECTRONIC MESSAGES FROM A MESSAGING CLIENT AND SYSTEM FOR CARRYING OUT THE METHOD
US9635180B2 (en) * 2008-05-14 2017-04-25 International Business Machines Corporation System for managing wait queues in a high volume system
US8086275B2 (en) 2008-10-23 2011-12-27 Microsoft Corporation Alternative inputs of a mobile communications device
US20100105424A1 (en) * 2008-10-23 2010-04-29 Smuga Michael A Mobile Communications Device User Interface
US8411046B2 (en) 2008-10-23 2013-04-02 Microsoft Corporation Column organization of content
US8385952B2 (en) 2008-10-23 2013-02-26 Microsoft Corporation Mobile communications device user interface
US20100211641A1 (en) * 2009-02-16 2010-08-19 Microsoft Corporation Personalized email filtering
US8238876B2 (en) 2009-03-30 2012-08-07 Microsoft Corporation Notifications
US8175653B2 (en) 2009-03-30 2012-05-08 Microsoft Corporation Chromeless user interface
US8355698B2 (en) 2009-03-30 2013-01-15 Microsoft Corporation Unlock screen
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
US8135787B2 (en) * 2009-06-16 2012-03-13 International Business Machines Corporation Instant messaging monitoring and alerts
US20110086623A1 (en) * 2009-10-09 2011-04-14 Mobile Symmetry, Llc Method and system for providing contact information for mobile communication device users
US9183580B2 (en) * 2010-11-04 2015-11-10 Digimarc Corporation Methods and systems for resource management on portable devices
US8713027B2 (en) * 2009-11-18 2014-04-29 Qualcomm Incorporated Methods and systems for managing electronic messages
US7970847B1 (en) * 2010-01-08 2011-06-28 Research In Motion Limited Method and apparatus for processing data on a computing device
US8499048B2 (en) 2010-10-27 2013-07-30 Facebook, Inc. Indexing and organizing messages in a messaging system using social network information
US20120159383A1 (en) 2010-12-20 2012-06-21 Microsoft Corporation Customization of an immersive environment
US20120159395A1 (en) 2010-12-20 2012-06-21 Microsoft Corporation Application-launching interface for multiple modes
US8612874B2 (en) 2010-12-23 2013-12-17 Microsoft Corporation Presenting an application change through a tile
US8689123B2 (en) 2010-12-23 2014-04-01 Microsoft Corporation Application reporting in an application-selectable user interface
US9423951B2 (en) 2010-12-31 2016-08-23 Microsoft Technology Licensing, Llc Content-based snap point
US9423878B2 (en) 2011-01-06 2016-08-23 Blackberry Limited Electronic device and method of displaying information in response to a gesture
US9471145B2 (en) * 2011-01-06 2016-10-18 Blackberry Limited Electronic device and method of displaying information in response to a gesture
US9465440B2 (en) 2011-01-06 2016-10-11 Blackberry Limited Electronic device and method of displaying information in response to a gesture
US9503415B2 (en) * 2011-01-27 2016-11-22 T-Mobile Usa, Inc. Unified notification platform
US9383917B2 (en) 2011-03-28 2016-07-05 Microsoft Technology Licensing, Llc Predictive tiling
US20120304132A1 (en) 2011-05-27 2012-11-29 Chaitanya Dev Sareen Switching back to a previously-interacted-with application
US9104440B2 (en) 2011-05-27 2015-08-11 Microsoft Technology Licensing, Llc Multi-application environment
US9158445B2 (en) 2011-05-27 2015-10-13 Microsoft Technology Licensing, Llc Managing an immersive interface in a multi-application immersive environment
US8893033B2 (en) 2011-05-27 2014-11-18 Microsoft Corporation Application notifications
US9104307B2 (en) 2011-05-27 2015-08-11 Microsoft Technology Licensing, Llc Multi-application environment
US9658766B2 (en) 2011-05-27 2017-05-23 Microsoft Technology Licensing, Llc Edge gesture
US8687023B2 (en) 2011-08-02 2014-04-01 Microsoft Corporation Cross-slide gesture to select and rearrange
US20130057587A1 (en) 2011-09-01 2013-03-07 Microsoft Corporation 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
US9146670B2 (en) 2011-09-10 2015-09-29 Microsoft Technology Licensing, Llc Progressively indicating new content in an application-selectable user interface
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
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
US10692045B2 (en) 2012-05-31 2020-06-23 International Business Machines Corporation Intelligent attention management for unified messaging
US10453030B2 (en) * 2012-06-20 2019-10-22 Wendy H. Park Ranking notifications based on rules
US20140245178A1 (en) * 2013-02-22 2014-08-28 Research In Motion Limited Communication device and method for profiling and presentation of message threads
US9450952B2 (en) 2013-05-29 2016-09-20 Microsoft Technology Licensing, Llc Live tiles without application-code execution
US20150095800A1 (en) * 2013-09-30 2015-04-02 Microsoft Corporation Prioritizing communications based on communication patterns
US9892723B2 (en) * 2013-11-25 2018-02-13 Rovi Guides, Inc. Systems and methods for presenting social network communications in audible form based on user engagement with a user device
EP3126969A4 (en) 2014-04-04 2017-04-12 Microsoft Technology Licensing, LLC Expandable application representation
CN105359055A (en) 2014-04-10 2016-02-24 微软技术许可有限责任公司 Slider cover for computing device
CN105378582B (en) 2014-04-10 2019-07-23 微软技术许可有限责任公司 Calculate the foldable cap of equipment
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
US10592080B2 (en) 2014-07-31 2020-03-17 Microsoft Technology Licensing, Llc Assisted presentation of application windows
US10680988B2 (en) 2014-08-29 2020-06-09 Google Llc Systems and methods for triggering redisplay of a postponed message
US10645046B2 (en) * 2014-08-29 2020-05-05 Google Llc Systems and methods for temporarily postponing messages
US20160071064A1 (en) * 2014-09-06 2016-03-10 Sugarcrm Inc. Context driven task creation and management
US10642365B2 (en) 2014-09-09 2020-05-05 Microsoft Technology Licensing, Llc Parametric inertia and APIs
US9871884B2 (en) * 2014-09-30 2018-01-16 Xiaomi Inc. Method and device for transferring messages
US20160112359A1 (en) * 2014-10-16 2016-04-21 International Business Machines Corporation Group message contextual delivery
WO2016065568A1 (en) 2014-10-30 2016-05-06 Microsoft Technology Licensing, Llc Multi-configuration input device
US9866684B2 (en) * 2015-02-16 2018-01-09 Microsoft Technology Licensing, Llc Process for real-time data exchange between users on a phone call
US10122660B2 (en) 2015-03-27 2018-11-06 MINDBODY, Inc. Contextual mobile communication platform
US20160294891A1 (en) * 2015-03-31 2016-10-06 Facebook, Inc. Multi-user media presentation system
US9953017B2 (en) * 2015-05-05 2018-04-24 International Business Machines Corporation Displaying at least one categorized message
US10360287B2 (en) 2015-05-22 2019-07-23 Microsoft Technology Licensing, Llc Unified messaging platform and interface for providing user callouts
US20160344677A1 (en) 2015-05-22 2016-11-24 Microsoft Technology Licensing, Llc Unified messaging platform for providing interactive semantic objects
US10320737B2 (en) * 2015-06-29 2019-06-11 Avaya Inc. Device and method for temporal correlation of communication types
US10171537B2 (en) 2015-08-07 2019-01-01 At&T Intellectual Property I, L.P. Segregation of electronic personal health information
US9942747B2 (en) 2015-08-07 2018-04-10 At&T Mobility Ii Llc Dynamic utilization of services by a temporary device
US10631192B2 (en) 2015-08-14 2020-04-21 At&T Intellectual Property I, L.P. Policy enforced intelligent persona manager
US10044780B2 (en) 2015-08-26 2018-08-07 At&T Intellectual Property I, L.P. Dynamic segregated secure data connection
CN113093917A (en) 2015-09-28 2021-07-09 微软技术许可有限责任公司 Unified virtual reality platform
WO2017058962A1 (en) * 2015-09-28 2017-04-06 Wand Labs, Inc. User assistant for unified messaging platform
US10652188B2 (en) * 2016-06-03 2020-05-12 Facebook, Inc. Tracking post viewership
CN108632129B (en) * 2017-03-15 2021-07-02 阿里巴巴集团控股有限公司 Message prompting method, message display method and related device
WO2020077305A1 (en) * 2018-10-11 2020-04-16 Project Core, Inc. Systems, methods and interfaces for processing message data
WO2020102349A1 (en) 2018-11-13 2020-05-22 Illumy, Inc. Methods, systems, and apparatus for email to persistent messaging and/or text to persistent messaging
US10848619B2 (en) * 2019-03-07 2020-11-24 At&T Intellectual Property I, L.P. Communications network security for handling proxy voice calls
US11711464B2 (en) * 2021-02-24 2023-07-25 T-Mobile Usa, Inc. Spam telephone call reducer

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4677663A (en) * 1985-07-05 1987-06-30 Melita Electronic Labs, Inc. Telephone answering and call forwarding improvement
US5559860A (en) * 1992-06-11 1996-09-24 Sony Corporation User selectable response to an incoming call at a mobile station
US6005870A (en) * 1996-08-12 1999-12-21 At&T Corp. Method for called party control of telecommunications network services
US6147977A (en) * 1997-12-12 2000-11-14 Motorola, Inc. Method and apparatus for processing messages based on originator and recipient priorities

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB8918553D0 (en) * 1989-08-15 1989-09-27 Digital Equipment Int Message control system
US5812865A (en) * 1993-12-03 1998-09-22 Xerox Corporation Specifying and establishing communication data paths between particular media devices in multiple media device computing systems based on context of a user or users
US6199102B1 (en) * 1997-08-26 2001-03-06 Christopher Alan Cobb Method and system for filtering electronic messages
US6546416B1 (en) * 1998-12-09 2003-04-08 Infoseek Corporation Method and system for selectively blocking delivery of bulk electronic mail
US6351764B1 (en) * 1998-12-31 2002-02-26 Michael Voticky System and method for prioritizing communications messages
US8086672B2 (en) * 2000-06-17 2011-12-27 Microsoft Corporation When-free messaging
WO2002045344A2 (en) * 2000-11-30 2002-06-06 Message Machines, Inc. Systems and methods for routing messages to communications devices

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4677663A (en) * 1985-07-05 1987-06-30 Melita Electronic Labs, Inc. Telephone answering and call forwarding improvement
US5559860A (en) * 1992-06-11 1996-09-24 Sony Corporation User selectable response to an incoming call at a mobile station
US6005870A (en) * 1996-08-12 1999-12-21 At&T Corp. Method for called party control of telecommunications network services
US6147977A (en) * 1997-12-12 2000-11-14 Motorola, Inc. Method and apparatus for processing messages based on originator and recipient priorities

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7565403B2 (en) 2000-03-16 2009-07-21 Microsoft Corporation Use of a bulk-email filter within a system for classifying messages for urgency or importance
US8566413B2 (en) 2000-03-16 2013-10-22 Microsoft Corporation Bounded-deferral policies for guiding the timing of alerting, interaction and communications using local sensory information
EP1494409A2 (en) * 2003-06-30 2005-01-05 Microsoft Corporation Use of a bulk-email filter within a system for classifying messages for urgency or importance
EP1494409A3 (en) * 2003-06-30 2005-04-27 Microsoft Corporation Use of a bulk-email filter within a system for classifying messages for urgency or importance
WO2005029796A1 (en) * 2003-09-23 2005-03-31 Koninklijke Philips Electronics N.V. Reducing load at a mail server
EP1603066A1 (en) * 2004-06-01 2005-12-07 Microsoft Corporation Email manager
GB2435978A (en) * 2006-03-06 2007-09-12 Motorola Inc Processing of voice messages in a communication system
GB2435978B (en) * 2006-03-06 2008-05-14 Motorola Inc Processing of voice messages in a communication system
WO2007123821A2 (en) 2006-04-20 2007-11-01 Cisco Technology, Inc. Techniques for tracking communication frequency across communication modalities
EP2005722A2 (en) * 2006-04-20 2008-12-24 Cisco Technology, Inc. Techniques for tracking communication frequency across communication modalities
EP2005722A4 (en) * 2006-04-20 2009-12-23 Cisco Tech Inc Techniques for tracking communication frequency across communication modalities
EP1947596A1 (en) * 2007-01-18 2008-07-23 Jubii IP Limited A method for automatically displaying electronic information received by a recipient in a sorted order and a communication system and/or system for exchanging information

Also Published As

Publication number Publication date
US20030105827A1 (en) 2003-06-05
AU2002357029A1 (en) 2003-06-17

Similar Documents

Publication Publication Date Title
US20030105827A1 (en) Method and system for contextual prioritization of unified messages
CN101711469B (en) Voicemail filtering and transcription
US7987236B2 (en) Recipient control of source audio identifiers for digital communications
US7924996B2 (en) Concatenated audio messages
CN101730879B (en) Voicemail filtering and transcription
US8054961B2 (en) MeetMe assistant
US7184533B1 (en) Method and apparatus for mixed media contact notification service
EP2005722B1 (en) Techniques for tracking communication frequency across communication modalities
US8189755B2 (en) Call urgency screening
US20090264100A1 (en) Flexible Messaging System For Mobile Phone Users
WO2007149526A2 (en) Group management and messaging
KR20060002796A (en) Source audio identifiers for digital communications
US20040177118A1 (en) System and method for e-mail presence confirmation
US20050276397A1 (en) System and method for providing availability information to a user
WO2005008432A2 (en) System and method for advanced rule creation and management within an integrated virtual workspace
CN101711381A (en) Voicemail filtering and transcription system
US8019051B1 (en) Method and apparatus for ordering communications
EP1662817B1 (en) System and method for providing information on a manner of communicating
US20020071546A1 (en) Method, device and software for processing incoming communications
US8175581B2 (en) Selective message notification system
US20020076024A1 (en) Method, device and software for assessing urgency of incoming communications
WO2023126905A1 (en) Methods, systems and computer program products for optimizing identification of communication device based spamming

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP