The invention is related to the field of telecommunication devices and services and more specifically, the invention is directed to a method and apparatus for communication request termination routing.
The Public Switched Telephone Network (PSTN) or Plain Old Telephone Service (POTS) was originally developed as a rudimentary “one to one” communication system. That is, it is best suited for connecting a first caller party to a second callee party based solely upon the identifying information associated with the callee (i.e., a destination or callee telephone number). The inherent structure and signaling capabilities of the PSTN do not easily lend themselves to customization of the behavior of communication requests (e.g., incoming telephone calls, text messages, and the like) to a destination or central location having multiple users. As such, a communication request is typically terminated at a universally accepted endpoint associated with the central location (i.e., the primary telephone in a household) where any one of a plurality of members of the central location can accept the request. As such, requests for a first member of the callee central location (i.e., to Daughter from Boyfriend) may be intercepted by a second member of the callee central location (i.e., Father). Similarly, undesirable requests (i.e., Telemarketer calling in the evening) to the central location may keep the communication line unnecessarily busy or unavailable for a period of time.
In an attempt to fulfill the need of providing communications to multiple users at a single location, the concept of the Private Branch Exchange (PBX) was developed and implemented. In this way, multiple users at a central location were able to make and receive communication requests. However, PBX's are still limited in their capabilities because they add bulk and complexity to the central location (i.e., additional central location switching equipment) without providing a direct connection from the caller to the callee based on a single central location telephone number. Typically, in order to reach a callee at a central location having multiple callees associated therewith, the caller must have knowledge of secondary access information such as a PBX extension number or otherwise access a local directory or operator to assist in completing the communication request to the callee. While it is possible to have a direct connection by dialing a callee's direct number of the PBX, this forces the caller to remember or otherwise populate and maintain an ever growing number of individual telephone numbers in order to reach each of said callees at the central location.
These types of communications systems are expensive to purchase and install and are typically a business solution; thus, do not lend themselves as a solution at the individual consumer level having a household of multiple users of a single telephone line. Such methodology for completing communication requests has become inefficient and cumbersome because it relies solely upon callee or destination information to complete the request. Additionally, such solution provides the callee with no control over the behavior of how requests to the central location are terminated.
Therefore, there is need in the art for improved execution of communication requests by exploiting additional information available about the communication request beyond callee information.
Embodiments of the subject invention comprise a method and apparatus for communication request termination routing. According to some embodiments of the subject invention, the method comprises determining one or more characteristics of an incoming communication request, mapping the one or more characteristics to a termination policy, and routing the incoming communication request to a communication device. The incoming communication request is routed to the communication device in accordance with the mapped termination policy. The determining, mapping, and routing steps are performed by a controller computing device as known in the art.
According to some embodiments of the subject invention, the apparatus comprises means for determining one or more characteristics of an incoming communication request, means for mapping the one or more characteristics to a termination policy, and means for routing the incoming communication request to a communication device. The incoming communication request is routed to the communication device in accordance with the mapped termination policy.
So that the manner in which the above recited features of the subject invention are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings.
It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.
The subject invention provides for a method of communication request (i.e., telephone call) processing that does not rely solely on callee information to route the call to a particular terminal. The additional information may include, but is not limited to, information derivable about the caller's identification and the time of day the request is placed. By introducing this additional information into the communication request processing, it is possible to have callers reach multiple users or callees associated with a central location or destination without having to provide additional information about the callee. In one embodiment, relationships between the caller and callee are predefined and stored for future reference. Upon initiation of a communication request, a determination is made as to the existence of a relationship between the caller and callee. The terms “caller” and “callee” are used generally to designate the initiator and recipient of the communication request, respectively. While exemplary embodiments are discussed with respect to telephone calls, one of ordinary skill in the art would recognize the applicability of the present invention to various other types of communication requests. Based on such relationship information, specific instructions for communication request termination (or call flow) are executed so that communication request behavior is tailored to the specific individual associated with the central location.
These types of communication requests are executed using VoIP. Voice over IP (VoIP) is a technological development in the field of telecommunications that is utilized to transmit voice conversations over a data network using Internet Protocol (IP) communications. Entities (either businesses or individuals) use VoIP by purchasing and installing a minimal amount of equipment (a Customer Premise Equipment (CPE) device) to access a VoIP service provider. The VoIP service provider then provides telecommunication service to the entities via a subscription model. After the VoIP service has been subscribed to, and depending on the level of service requested, an entity can make phone calls to other VoIP subscribers or to PSTN customers and access a number of features associated with the VoIP service. As part of the call processing is conducted by non-traditional means (i.e. over a packet-based or VoIP network), signaling and call set up is not performed exclusively by the traditional means governed by ISDN and POTS. In some embodiments, signaling that is conducted in the packet-based network(s) is executed using Session Initiation Protocol (SIP). SIP is a popular communication protocol for initiating, managing and terminating media (e.g., voice, data and video) sessions across packet based networks that typically use the Internet Protocol (IP) of which VoIP is an example. As such, there is increased flexibility in the manner in which requests can be executed and increased features for the customer using VoIP. The details and functionality of SIP can be found in the Internet Engineering Task Force (IETF) Request for Comments (RFC) Paper No. 3261 entitled, “SIP: Session Initiation Protocol” herein incorporated in its entirety by reference. SIP establishes and negotiates a session, including the modification or termination of a session. SIP uses a location-independent address system feature in which called parties can be reached based on a party's name. SIP also supports name mapping and redirection allowing users to initiate and receive communication from any location.
After the request is received, a determination is made at step 104 as to whether the callee that is trying to be reached via the request has a caller information listing (i.e., address book) that is associated with or otherwise maintained by the callee's communication service provider. The address book serves as a main repository of information about callers that the callee has established prior relationships. Information may include name, residential location and one or more telephone numbers or messaging contact identifiers (i.e., email address, chat ID and the like). Additionally, the address book has communication request policy information that governs how communication requests from callers are to be executed. The policy information may include, but is not limited to, time when requests may be sent directly to the callee vs. sent to a secondary location such as a messaging service, a callee whitelist or blacklist designation signifying that the caller is always or never permitted to have requests fulfilled and the like. The time policy may be further refined to denote different policies selected from the group consisting of the time of day and the time of the week when requests are made. If the callee does not have a caller information listing, then the method 100 proceeds to step 106 whereby normal communication request processing occurs by having the request passed to the callee (i.e., “ring through”) without any specific policies on call behavior being invoked. This has the effect of the request being terminated at a universally accepted endpoint associated with the central location (i.e., the primary telephone in a household) where any one of a plurality of members of the central location can accept the request.
If the callee does have a caller information listing, then the method 100 proceeds to step 108 whereby a determination is made as to whether the incoming request has been marked as a private request. A private request would be one that does not specifically identify the caller (i.e., the caller has invoked a blocking function of his information during the request process). As such, this may effect how the callee desires to terminate the request. If the request is identified as private, the method 100 proceeds to step 110 whereby a determination is made as to whether the callee has a preferred private call termination behavior predefined. If there is no such predefined or default private call termination behavior, processing continues by having the request passed to the callee (i.e., “ring through”) at step 106 without any specific policies on call behavior being invoked. If there is a predefined or default private call termination behavior, processing continues by executing the callee's default private call termination behavior at step 112. The default private call termination behavior in one embodiment is selected from the group consisting of “immediately send to voicemail” and “immediately decline request with corresponding message to caller”. Other types of termination behavior are possible based upon callee preferences and are within the scope of the invention.
If the request is not identified as private, the method 100 proceeds to step 114 whereby an information lookup is performed. In one embodiment of the invention, a lookup is performed to determine if a data exists that defines a relationship or desired behavior for communication request termination between the caller and callee. Preferably the data is a subset of data (i.e., data store) that identifies basic callee information, callee address book information and specific caller policy information although additional information may also be used such as timestamps at the time the lookup is performed. In one embodiment of the invention, there is one data store record for each caller that the callee desires to have a specific communication request termination policy. Each data store record is maintained and updated on a regular basis such that at the time of an incoming communication request, the data store record of a particular caller is easily and efficiently retrieved so that a corresponding termination policy can be quickly invoked. If there is no such data store record for the incoming communication request from the particular callee, the method proceeds to step 116 whereby a determination is made as to whether there is a general default termination behavior by which all requests made to the callee are governed. For example, where there is no specific callee termination policy but the caller has a general policy that all incoming calls are forwarded to another telephone number, the callee would be directed to such forwarding number. If no such general default termination behavior is indicated, processing continues by having the request passed to the callee (i.e., “ring through”) at step 118 without any specific policies on call behavior being invoked. If there is a general default termination behavior, processing continues by a time policy lookup is performed at step 124. The time policy lookup further refines the behavior of the general default termination behavior based on the time of day and time of the week that the incoming call request is made. If there is no such time policy data, the method proceeds to step 126 whereby the general default termination behavior is invoked regardless of the time of the request. If there is time policy data, the method proceeds to step 128 whereby the general default termination behavior is invoked based on the time of the request.
If there is a data store record for the incoming communication request from the particular callee, the method proceeds to step 120 whereby a time policy lookup is performed. The time lookup further refines the behavior of the callee request based on the time of day and time of the week that such request is made. If there is no such time policy, the method proceeds to step 130 whereby the callee request is performed regardless of the time of the request. Although for the purposes of the present exemplary embodiment, the time policy lookup step 120 is described as occurring after the caller/callee lookup step 114, one of ordinary skill in the art would recognize that the sequential order of the lookup steps could be altered to result in a different termination policy. For example, a user may wish all calls received after 10:00 pm to go immediately to voicemail, with voicemail box routing occurring based upon a caller/callee lookup 114. In some embodiments the private call check step 108 may also be performed out of the sequence described with respect to the instant example. If there is time policy data, the method proceeds to step 122 whereby the callee request is performed based on the time of the request. Other types of termination behavior are possible based upon callee preferences, time of day/week, messaging preferences and the like and are within the scope of the invention. In one embodiment, the communication request is messaging other than a telephone call and is selected from the group consisting of email, chat sessions, Instant Messaging, and SMS. The method ends by either execution of one of the call flows 112, 122, 126, 128 and 130 or ring through steps 106 and 118.
The system further includes one or more subsystems connected to the inbound voice communication processor 202 to enable various call handling features. For example, a voicemail server and attendant subsystems 216 are connected to the inbound voice communication processor 202. The voicemail server 216 provides functionality to a voicemail feature when the calling party is given an option to respond or otherwise leave a message for the called party. In some embodiments, the voicemail server 216 incorporates multiple server subsystems to provide robustness, scale and capacity to the system 200 and to allow for different features and continuity of service. Such servers and subsystems are well known in the art and in one example is the ASTERISK PBX system offered by DIGIUM, Inc. of Huntsville, Ala.
While the system as disclosed with respect to
Various components are connected to the inbound voice communication processor 202 via a public/private data network 220 such as but not limited to the Internet. An outbound voice communication/registration processor (OB) 206 conducts various functions for the called party devices including but not limited to maintaining their registration on the system 200. Although the outbound voice communication/registration processor 206 is represented as a single network element in
The outbound voice communication/registration processor 206 is connected to the CPE device 208 that a called party operates when accessing the communication network 200. Examples of the CPE device 208 include an analog telephone adapter (ATA) and a voice communication device. One specific, non-limiting example of an ATA is modem model no. VT-2442 manufactured and sold by Motorola, Inc. of Schaumburg, Ill. The voice communication device is the physical component that the caller actually interfaces with when involved in a voice communication session. In one embodiment of the invention, the voice communication device is selected from the group consisting of an analog telephone and an IP phone (having the ATA integrated therewithin). Alternately, the voice communication device is a web-based or “softphone” type of device that operates on a PC with integrated audio transducer devices. Specific, non-limiting examples of such voice communication devices that can exploit the advantages of the subject invention include model no. 2500 analog telephone manufactured and sold by CORTELCO of Corinth, Miss., model no. UIP1869V IP telephone manufactured and sold by UNIDEN of Tokyo, Japan, and the V-phone manufactured and sold by Vonage Holdings Corp of Holmdel, N.J. In some embodiments, such devices incorporate the functionality of the ATA and voice communication device in a single component.
The Feature server 214 provides the supporting infrastructure to execute communication request processing in the manner described and in accordance with the subject invention. In particular, the feature server 214 is capable of storing the data store records 226 of a particular callee (e.g., communication service subscriber) such that when a communication request is received at the IB 202, a determination of the existence of the caller information listing (address book) and data store records 226 governing call termination policy is quickly and easily assessed.
The data store records 226 are a subset of general subscriber data which is stored in the database 218. The connection between the database 218 and the feature server 214 allows for periodic updating of the data store records 226 based on subscriber data. For example, if a subscriber changes a particular feature or call termination policy (e.g., via a web-based interface), those changes are made to the subscriber data and updates are sent to the feature server 214 so that corresponding data store records 226 are updated. In some embodiments, the data store records 226 are stored in a data table mapping certain call characteristics (e.g. caller identity, time of day, day of the week, and the like) to a particular termination policy.
Once the relevant information is retrieved, the feature server 214 generates the appropriate communication request flow in accordance with the determined call termination policy and passes such instructions to the IB 202. The IB 202 will then determine the next appropriate point in the communication network so as to terminate the request in the desired manner. As such, the subject invention allows a destination to be a central point of contact for a set of alternate destinations based on a set of rules stored in a database within the communication network. By way of non-limiting example, one or more of the following plurality of call flows may then occur:
The controller 300 may be one of any form of a general purpose computer processor used in accessing an IP-based network such as the LAN/WAN presented above, a corporate intranet, the Internet or the like. The controller 300 comprises a central processing unit (CPU) 302, a memory 304, and support circuits 303 for the CPU 302. The controller 300 also includes provisions 308/310 for connecting the controller 300 to databases, customer equipment and/or service provider agent equipment and the one or more input/output devices (not shown) for accessing the controller 300 and/or performing ancillary or administrative functions related thereto. Note that the provisions 308/310 are shown as separate bus structures in
The memory 304 is coupled to the CPU 302. The memory 303, or computer-readable medium, may be one or more of readily available memory such as random access memory (RAM), read only memory (ROM), floppy disk, hard disk, flash memory or any other form of digital storage, local or remote. The support circuits 303 are coupled to the CPU 302 for supporting the processor in a conventional manner. These circuits include cache, power supplies, clock circuits, input/output circuitry and subsystems, and the like. A software routine 312, when executed by the CPU 302, causes the controller 300 to perform processes of the subject invention and is generally stored in the memory 304. The software routine 312 may also be stored and/or executed by a second CPU (not shown) that is remotely located from the hardware being controlled by the CPU 302.
The software routine 312 is executed to determine and perform a termination policy for incoming calls. The software routine 312, when executed by the CPU 302, transforms the general purpose computer into a specific purpose computer (controller) 300 that controls the communication request termination process of, for example,
At step 406, the method maps the determined call characteristics to a termination policy. In some embodiments, the method determines a termination policy in accordance with the caller identity and the date/time, such as by the method discussed above with respect to
At step 408, the method routes the incoming call using the mapped termination policy determined during step 406. The method ends at step 410 when the call has been routed in accordance with the termination policy.
While foregoing is directed to embodiments of the subject invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof.
This application claims priority to U.S. Provisional Patent Application Ser. No. 61/178,007, filed May 13, 2009, which is incorporated by reference herein in its entirety.
Number | Date | Country | |
---|---|---|---|
61178007 | May 2009 | US |