Patent Application
20090156171
The present disclosure relates generally to communication systems and more specifically to a system and method of processing messages.
Numerous messaging devices today present messages such as emails, voicemail messages, and faxes in a single level or flat hierarchy. Some email applications such as Microsoft Outlook™ have attempted to improve the message presentation experience by providing a means for users to define rules to manage and organize the storage of email messages. Establishing these rules however requires a level of technical expertise that may be undesirable for some users.
In one embodiment of the present disclosure, a computer-readable storage medium can have computer instructions for recording in an address book a plurality of communication identifiers, associating at least a portion of the plurality of communication identifiers with one or more categories selected from a plurality of categories, detecting a communication session, retrieving from the communication session a communication identifier, comparing the communication identifier with entries in the address book, detecting a match between the communication identifier and an entry in the address book, identifying one or more categories associated with the matched entry, and storing in the identified one or more categories a message received by way of the communication session.
In one embodiment of the present disclosure, a communication device can have a controller to retrieve a communication identifier from a communication session, match an entry in an address book with the communication identifier, and store in one or more categories associated with the matched entry a message received by way of the communication session.
In one embodiment of the present disclosure, a method can involve retrieving a communication identifier from a communication session, identifying a match between the communication identifier and an entry in an address book, and storing in one or more categories associated with the matched entry a message received by way of the communication session.
The UMS 104 can interface to an Internet Service Provider (ISP) 106 to submit messages to fixed and mobile end points 102 over a wireline or wireless interface using for example a cellular network 107. In wireline applications, the messages can be submitted directly to a fixed end point 102 such as a computer capable of processing emails. In mobile applications, the UMS 104 can submit messages to mobile end points 102 such as cellular phones using a Short Message Service (SMS) or Multimedia Message Service (MMS) message format, or like over-the-air messaging services. The UMS 104 can further include a portal 110 that utilizes common web server technology to provide portal services to its subscribers over communication network 101, the ISP 106 and/or the cellular network 107.
The IMS communication devices 201, 211, and the PSTN phone 272 can be a representative embodiment of the calling end point 102 of
To establish a communication session between phones, the IMS network 250 can utilize an originating Serving Call Session Control Function (S-CSCF) 206. The originating S-CSCF 206 can submit queries to the ENUM server 230 to translate an E.164 telephone number to a SIP Uniform Resource Identifier (URI) if the targeted communication device is IMS compliant. If the targeted communication device is a PSTN device such as reference 272, the ENUM server 230 will respond with an unsuccessful address resolution and the originating S-CSCF 206 will forward the call to the MGCF 270 which connects the call through the PSTN network 275 using a common signaling means such as SS7.
In the instance where the ENUM server 230 returns a SIP URI, the SIP URI is used by an Interrogating CSCF (I-CSCF) 207 to submit a query to the HSS 240 to identify a terminating S-CSCF 214 associated with a targeted IMS communication device such as IMS CD 211. Once identified, the I-CSCF 207 can submit the SIP INVITE message to the terminating S-CSCF 214 which then identifies a terminating P-CSCF 216 associated with the targeted communication device. The P-CSCF 216 can then signal the communication device to establish communications. When the targeted IMS communication device is the UMS 104, the ENUM system 230 can be programmed to supply a SIP URI to the originating S-CSCF 206 which then establishes communications between the originating communication device and the UMS.
The UMS 104 can include an application server 104 supporting SIP message processing, and a Voice eXtensible Markup Language (VXML) for interacting with a calling party by way of synthetic speech, and speech and Dual-Tone Multi-Frequency (DTMF) detection serving collectively the function of an Interactive Voice Response (IVR) system application. The UMS 104 can further include a media server that processes real-time packet streams conforming to a Real-time Transport Protocol (RTP), and interacts with the application server using SIP and VXML.
In addition to the aforementioned network elements of the IMS network 250, there can also be a number of application servers 210 which can provide a variety of communication services to IMS subscribers. For example, the application server 210 can be used to perform originating treatment functions on the calling party number received by the S-CSCF 206. Originating treatment functions can include determining whether the calling party number has international calling services, and/or is requesting special telephony features (e.g., *72 forward calls, *73 cancel call forwarding, etc.).
In step 302, the subscriber can record communication identifiers in an address book specifically tailored for the subscriber by the UMS 104. The address book can for example support a number of entries each identified by for example a party's name, job title, company name, business phone number, home phone number, mobile phone number, and email address. In step 302, the subscriber can define a plurality of categories which can be associated in step 305 with at least a portion of the communication identifiers stored in the address book. Prior to step 305, the subscriber can have the option to record an audible rendition of one or more of the categories defined in step 302. The audible renditions can be used by the UMS 104 to match speech commands of the subscriber to the audible renditions as will be described shortly.
Referring back to the creation of categories, the subscriber can create one or more categories to organize incoming messages supplied by calling parties. For example, the subscriber can create a category for family messages. To associate family messages with a family category, the subscriber can associate communication identifiers in the address book with the family category. For instance, the communication identifier 512-111-2222 recorded in an address book entry for Dad can be associated with a category “Messages from Dad”, while the communication identifier 512-111-2223 recorded in another address book entry can be associated with a category such as “Messages from Mom”. The same can be done for siblings, relatives (e.g., uncles, aunts, cousins, etc.), and so on.
A communication identifier in the present context can represent an identifying element of a communication device of a calling party. Communication identifiers can be represented by for example an email address, an E.164 number, a Session Initiation Protocol Uniform Resource Identifier (SIP URI), or an Instant Messaging (IM) address—just to mention a few. A category can be used to label inboxes for storing messages. For example, the inbox “ABC Company” can be used for storing voicemail, faxes, or email messages associated with employees of ABC company.
The category ABC Corporation can be associated with employees by using wild cards in the communication identifiers stored in the address book. For example, the number 512-33X-YYYY can be used to identify calls from ABC Corporation, where 33X represents an exchange ranging from 330 through 339, while the remaining four digits “YYYY” represents any phone number with the area code 512 and exchange 33X. The email address XXX@abc-corp.com can also be used as an identifying element for messages generated by ABC Corporation employees. In instances where the subscriber wants to treat certain employees uniquely, the subscriber can define category labels such as “Employees”, “Management” and “Staff” as sub-category labels for ABC Corporation. In this embodiment messages received by the UMS 104 from ABC corporation management and/or staff can be associated selectively with entries in the address book, while all other messages from ABC Corporation can default to the “Employees” category. With this organization structure, messages from ABC Corporation can be identified, organized and stored in a hierarchy defined by the subscriber (e.g., messages from known and configured management are stored in “Management”, messages from known and configured staff are stored in “Staff”, while all other messages are stored in “Employees”). It will be appreciated that sub-categories of ABC corporation can have their own independent category (i.e., not a sub-category of ABC corporation). For example “my boss” which could be a sub-category of ABC corporation can be defined as its own independent category. In this manner, the subscriber can manage messages of “my boss” independent of an ABC corporation hierarchy.
In step 305, the association between communication identifiers and categories can be accomplished many ways. In one embodiment, the UMS 104 can present the subscriber an overall GUI interface to manage the association of communication identifiers to categories with a drop-down menu next to each communication identifier. The drop-down menu can present the subscriber each of the available categories created by the subscriber to associate to the communication identifier in question. For each communication identifier, the association can take place by selecting by common means each of the categories of interest indicated for example by a checkmark or “X” mark located in a checkbox next to each selection. When selecting more than one category, the subscriber effectively creates a one-to-many association between the communication identifier and select categories. That is messages received from a calling party having a communication identifier that matches an entry in the address book with multiple categories associated therewith will be stored and/or referenced in these categories rather than a single category.
The drop-down menu can have a default setting which is presented at the time the communication identifier is first recorded in the address book. A default setting can represent a state in which no association is made between categories and the communication identifier being recorded. In this embodiment incoming messages can be stored in a default category by the UMS 104 when the message has a communication identifier that is not found in the address book. Similarly, the UMS 104 can store incoming messages in the default category when the message has a communication identifier that is found in the address book but has no association to a category (i.e., the communication identifier was recorded in the address book under a default setting). Thus, each time the subscriber adds a new entry in the address book, the subscriber has the option to associate communication identifier(s) with one or more corresponding categories defined by the subscriber or a default setting.
The above principles can be applied to categories defined by the subscriber for business clients, friends, family or other categories conceived by the subscriber. It should be noted that steps 301-305 can be performed as a background software process independently operated from steps 306-324 as indicated by the dashed line. That is, steps 301-305 represent configuration or provisioning steps taken by the subscriber, while steps 306-324 represent run-time execution/utilization steps.
With these concepts in mind, in step 306 the UMS 104 can be programmed to detect an incoming communication session initiated by a calling party that is targeting the subscriber of the UMS 104. The communication session can be a circuit-switched voice communication session, a packet-switched voice communication session, or a data communication session. In the case of a voice communication, the communication session can be a redirected VoIP or PSTN communication session processed by the UMS 104 when the subscriber does not respond to the call. Alternatively, the communication session can represent a data communication session established by a calling party to direct to the subscriber an email, fax, instant message, or SMS or MMS message.
Upon detecting the communication session, the UMS 104 can retrieve in step 308 by common means from the communication session a communication identifier associated with the session. The communication identifier can be a caller ID (e.g., E.164 number or SIP URI), an email address, or some other means of identifying the calling party or incoming message. In step 312, the UMS 104 can determine if the communication identifier matches an entry in the address book. If a match is not found, the UMS 104 can proceed to step 322 where it stores the message received from the communication session (e.g., voicemail, email, fax, etc) in a default category (as described earlier). In step 324, the UMS 104 can generate a notification identifying the default category which stored the incoming message and any other category with for example one or more unread messages.
For example, the notification might say, “You have received a message in your default inbox. You also have 10 unread messages in 4 other categories. To retrieve your messages contact your messaging service by selecting www.ums.com or directing a phone call to 512.444.5555.” A notification such as this can be transmitted to a communication device of the subscriber in step 326 as an email message with a subject heading with the above message, or by transmitting a paging message such as an SMS or MMS message including the notification and a selectable hyperlink which can be used to automatically call the UMS 104.
Referring back to step 312, if the communication identifier retrieved from the communication session matches an entry in the address book, the UMS 104 proceeds to step 314 where it determines if the communication identifier in the matched entry has an association with one or more categories. If it does not, the UMS 104 proceeds to steps 322-326 as previously described. Otherwise, the UMS 104 identifies the categories in step 316, and in step 318 stores the message and/or a reference to the message in the one or more categories. In step 320, the UMS 104 can then generate a notification that identifies the one or more categories which stored the received message and other categories having one or more unread stored messages.
For example, the notification might say, “You have received a new message in a category labeled Mom. You also have 6 unread messages in 3 other categories (Dad-3, Client A-2, ABC Corporation-1). If you desire to review these messages select the ‘Review Messages’ button provided in this notice.” The “Review Messages” button referred to in the notification can represent for example a GUI element operating as a selectable HTML hyperlink which can invoke a communication session between the communication device of the subscriber receiving the notification and the UMS 104. Step 326 transmits the notification to the communication device of the subscriber as previously described.
You have 20 unread messages and a total of 50 recorded messages. Select any of the following categories to review your unread messages.
1. Family (2)*
2. ABC Corporation (10)
3. Client A (3)
4. Client B (2)*
5. Default (3)
As noted earlier, categories may be hierarchical. For example, the category Family when selected might show: Dad (1), Mom (1), Siblings, Uncles, Aunts, etc. The asterisk next to the categories Family and Client B can also indicate to the subscriber that these categories can be audibly selected by the subscriber with speech commands. In step 406, the subscriber can audibly and/or manually using DTMF signals, or a GUI action such as a mouse button selection via the portal 110 select a category to review messages. In step 408, the UMS 104 can detect the category that matches the audible and/or manual entry. For example, the UMS 104 can match a speech command with the category Family and thereby navigate one level down the hierarchy to present the sub-categories Dad (1), Mom (1), Siblings, Uncles, Aunts, etc. The subcategories can be similarly selected by audible commands if the subscriber has provided an audible rendition of each category. Alternatively, the subscriber can select the category Family by depressing the 1 key on the keypad of a telephone, or selecting it with a mouse pointer when navigating a website of the portal 110.
In step 410, the UMS 104 can present the stored messages in the selected category. The presentation can be an audible presentation of a voicemail message, a text to speech presentation for text messages such as emails, and/or a visual presentation over a display screen of a communication device such as a cellular phone, fixed line telephone, or computer screen. Optionally the subscriber in step 412 can also update categories and/or messages stored therein. Updating a category can represent changing its name, moving it within a hierarchy, or deleting it, while updating messages can represent copying or moving messages to other inboxes or directory folders, or deleting them.
In the case of message updates, the UMS 104 can proceed to step 418 where it determines whether the intended message update is stored across more than one category. As noted earlier in step 305, messages can be stored in categories in a one-to-many format. Thus when a message deletion is requested, for example, the UMS 104 can proceed to step 420 to delete messages across multiple categories and/or query the subscriber whether s/he wants to delete the selected message across all categories in one step, or on a case-by-case basis. If the message to be updated is stored in a single category, the UMS 104 can proceed to step 422 where it performs the requested update without dependencies.
Referring back to step 412, the UMS 104 proceeds to step 414 when it detects a request by the user to update one or more categories. In this step, the UMS 104 can update the category and corresponding messages stored therein as well as duplicate copies of the messages in other categories. For example, if a select category is deleted, the UMS 104 can query the subscriber as to whether s/he desires to delete the messages in the category as well. If the subscriber desires to keep the messages, the UMS 104 can provide the subscriber the option to move the messages to a default category inbox. If the subscriber accepts deletion of the messages, the UMS 104 can determine whether the messages to be deleted are recorded in other categories. If it detects that there are duplicate copies, it can query the subscriber as to whether those messages should be deleted as well (similar to what was described for step 420). In the case where the category update is something other than a deletion (e.g., a renaming of the category), the messages stored in the updated category can remain unchanged.
To synchronize the change of the select category, the UMS 104 proceeds to step 416 where it updates UMS subsystems having a dependency on the affected category. For instance, a change in the name of the category can affect the address book subsystem of the UMS 104. Similarly, a name change can affect the IVR and the portal 110 applications of the UMS 104 in its presentation of messages to the subscriber. By synchronizing subsystems of the UMS 104, the UMS can provide the subscriber a holistic user-friendly experience without forcing the subscriber to address individually all the interdependencies affecting the recording, presentation and processing of messages by the UMS.
Upon reviewing the embodiments disclosed, it would be evident to an artisan with ordinary skill in the art that said embodiments can be modified, reduced, or enhanced without departing from the scope and spirit of the claims described below. For example, method 300 can be adapted so that speech commands of the subscriber can be matched to category labels without requiring a subscriber to provide an audible rendition of the category. To accomplish this embodiment, the IVR application of the UMS 104 can be adapted to use a common speaker-independent speech to text synthesizer to match speech commands to categories without voice training. In yet another embodiment, methods 300 and 400 can be integrated in whole or in part in a communication device of the subscriber (e.g., cellular phone, computer, personal digital assistant or PDA, etc.) having messaging capabilities similar to those of the UMS 104.
Other suitable modifications can be applied to the present disclosure without departing from the scope of the claims below. Accordingly, the reader is directed to the claims for a fuller understanding of the breadth and scope of the present disclosure.
The machine may comprise a server computer, a client user computer, a personal computer (PC), a tablet PC, a laptop computer, a desktop computer, a control system, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. It will be understood that a device of the present disclosure includes broadly any electronic device that provides voice, video or data communication. Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
The computer system 500 may include a processor 502 (e.g., a central processing unit (CPU), a graphics processing unit (GPU, or both), a main memory 504 and a static memory 506, which communicate with each other via a bus 508. The computer system 500 may further include a video display unit 510 (e.g., a liquid crystal display (LCD), a flat panel, a solid state display, or a cathode ray tube (CRT)). The computer system 500 may include an input device 512 (e.g., a keyboard), a cursor control device 514 (e.g., a mouse), a disk drive unit 516, a signal generation device 518 (e.g., a speaker or remote control) and a network interface device 520.
The disk drive unit 516 may include a machine-readable medium 522 on which is stored one or more sets of instructions (e.g., software 524) embodying any one or more of the methodologies or functions described herein, including those methods illustrated above. The instructions 524 may also reside, completely or at least partially, within the main memory 504, the static memory 506, and/or within the processor 502 during execution thereof by the computer system 500. The main memory 504 and the processor 502 also may constitute machine-readable media.
Dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays and other hardware devices can likewise be constructed to implement the methods described herein. Applications that may include the apparatus and systems of various embodiments broadly include a variety of electronic and computer systems. Some embodiments implement functions in two or more specific interconnected hardware modules or devices with related control and data signals communicated between and through the modules, or as portions of an application-specific integrated circuit. Thus, the example system is applicable to software, firmware, and hardware implementations.
In accordance with various embodiments of the present disclosure, the methods described herein are intended for operation as software programs running on a computer processor. Furthermore, software implementations can include, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the methods described herein.
The present disclosure contemplates a machine readable medium containing instructions 524, or that which receives and executes instructions 524 from a propagated signal so that a device connected to a network environment 526 can send or receive voice, video or data, and to communicate over the network 526 using the instructions 524. The instructions 524 may further be transmitted or received over a network 526 via the network interface device 520.
While the machine-readable medium 522 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure.
The term “machine-readable medium” shall accordingly be taken to include, but not be limited to: solid-state memories such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories; magneto-optical or optical medium such as a disk or tape; and carrier wave signals such as a signal embodying computer instructions in a transmission medium; and/or a digital file attachment to e-mail or other self-contained information archive or set of archives is considered a distribution medium equivalent to a tangible storage medium. Accordingly, the disclosure is considered to include any one or more of a machine-readable medium or a distribution medium, as listed herein and including art-recognized equivalents and successor media, in which the software implementations herein are stored.
Although the present specification describes components and functions implemented in the embodiments with reference to particular standards and protocols, the disclosure is not limited to such standards and protocols. Each of the standards for Internet and other packet switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP) represent examples of the state of the art. Such standards are periodically superseded by faster or more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same functions are considered equivalents.
The illustrations of embodiments described herein are intended to provide a general understanding of the structure of various embodiments, and they are not intended to serve as a complete description of all the elements and features of apparatus and systems that might make use of the structures described herein. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Figures are also merely representational and may not be drawn to scale. Certain proportions thereof may be exaggerated, while others may be minimized. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.
The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.
