Patent Publication Number: US-8126017-B1

Title: Method for address translation in telecommunication features

Description:
This application claims the benefit of U.S. Provisional Application No. 60/573,722, filed May 21, 2004, which is incorporated herein by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     This invention relates to telecommunications networks, and more particularly to providing telecommunication features and services in such networks. 
     As new features such as call forwarding, call waiting, or three-way calling have been added to telecommunication systems, it has become increasingly difficult to manage the behavioral complexity of the features and their interactions. In particular, in some instances, the widely varied features offered by today&#39;s telecommunication providers conflict and produce unintended results. This is frequently referred to as the feature-interaction problem. This problem arises primarily from the incremental, feature-by-feature extension of telecommunications system functionality. Specifically, when adding new features, a comprehensive analysis of potential interactions with other features, followed by a redesign of old features to integrate smoothly with the new features, is typically not practical. Thus, as more and more new features are added to these systems, the resulting complexity of system operations in providing features, and the interaction of various features with each other, can potentially damage the quality of the telecommunication network services. 
     Prior attempts have been made to reduce the problems resulting from such feature interactions. For example, U.S. Pat. No. 6,160,883, issued Nov. 23, 2004 and entitled “Telecommunication System and Method,” which is incorporated by reference herein, discloses a network architecture, referred to as a distributed feature composition (DFC) network, for managing the feature-interaction problem. Additionally, pending utility applications, “Routing Extensions For Telecommunications Network System And Method,” Ser. No. 09/644,128, filed Aug. 23, 2000; U.S. Pat. No. 6,822,942, issued Nov. 23, 2004 and entitled “Protocol Extensions For Telecommunications Network Systems and Method;” and, U.S. Pat. No. 6,778,560, issued Aug. 17, 2004 and entitled “Signaling/Media Separation for Telecommunication Network System and Method,” which are incorporated by reference herein, disclosed an enhanced and modified DFC to further address feature interaction problems. 
     As is well known, requests for telecommunication features in DFC and other telecommunication systems, for example originating from a telephone in a PSTN network, typically comprise messages having at least two addresses, a source address and a target address. The source address typically corresponds with the originator of the request, while the target address corresponds with the destination party of the request. As is also well known, as a call is transmitted from the originator to the destination and features are applied to the call, address translation is commonly required by many of the features. Such address translation typically consists of, for example, modifying the communication by changing the source address, target address or both addresses for various purposes. Due to its widespread use, address translation results in a high number of feature interactions in today&#39;s telecommunication networks. Accordingly, many of the feature-interaction problems that occur in telecommunication networks may be traced directly to issues created as a result of such address translation. 
     SUMMARY OF THE INVENTION 
     The present invention is a method for address translation in telecommunication networks that reduces the feature-interaction problems that occur as a result of address translation activities. Specifically, in one illustrative embodiment, a module in a target region of a request chain is constrained in a way such that that module cannot change a source address in a call request. This constraint functions to preserve reversibility of the request chain in, for example, replies to the original request. In a second illustrative embodiment, a source feature module in a source region can only replace a source address with a more abstract address than the one it is replacing. In another embodiment, a target feature module in a target region can only replace a target address with a more concrete address than the one it is replacing. In yet another embodiment, a source feature module in a request chain is constrained from transmitting downstream an alternative source address more concrete than its own address. And in an additional embodiment, a target feature module in a target region of a request chain is constrained from transmitting upstream an alternative target address that is more concrete than its own address. By applying one or more of these constraints, the feature interaction problem associated with the providing of a multitude of features in a communication system may be reduced or substantially eliminated. 
     These and other advantages of the invention will be apparent to those of ordinary skill in the art by reference to the following detailed description and the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows a prior communication request chain; 
         FIG. 2  shows how a prior personal directory feature may interact with a caller ID feature on a telephone; 
         FIG. 3  shows another prior communication request chain involving an anonymous remailer feature module; 
         FIG. 4  shows a prior communication request chain involving a sales group and representative; 
         FIG. 5  shows an illustrative communication chain with abstract and concrete address associated with modules in the chain; 
         FIG. 6  shows an illustrative communication request chain illustrating one constraint to address translation in accordance with the principles of the present invention; 
         FIGS. 7A and 7B  show another illustrative communication request chain illustrating another constraint to address translation in accordance with the principles of the present invention; and 
         FIGS. 8A and 8B  show yet another illustrative communication request chain illustrating a constraint to address translation in accordance with the principles of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     In telecommunication networks, addresses are used to route message traffic between nodes in a network. A particular address may be associated with a device, such as a telephone, with a set of features, or both. As used herein, a device typically functions as an interface to an end user, while a set of features involves interfacing a call with, for example, a computer program to provide features to that call. Telecommunication services and features are typically provided in response to requests for those services and features. As discussed above, such requests typically carry at least two addresses: a source address in a source address field indicating which device or feature is making a request and a target address in a target address field indicating the destination of the request. Since the requesting address is not typically directly connected to the destination address, such requests occur across the telecommunication network in a chain from an address associated with one device or feature set to an address associated with another device or feature set. Routing of such telecommunication requests across a telecommunication network, using illustrative network routers, is well known. 
       FIG. 1  shows an illustrative request chain wherein, for example, computer  101  initiates a request for communications with cellular telephone  108 . Specifically,  FIG. 1  shows that the chain of communications between computer  101  and cellular telephone  108  may involve communications between a plurality of source modules in a source region  109  and a plurality of target modules in a target region  110 . 
     As used herein, a module is defined as either an interface module, which is an interface between a telecommunication network and a device, or a feature module, which allows network traffic to access a telecommunication system feature. Interface modules are the modules through which devices send and receive telecommunications messages to/from the network, respectively, in order to facilitate the use of those devices. As is well-known, it is common for the address of a particular device to have only one interface module to which all requests for communication services are routed and from which all requests for communication are transmitted. Feature modules, on the other hand, are modules through which specific features are accessed in the network. Such features may include the well-known three-way calling feature, caller ID feature, call waiting feature, or any one of the multitude of other well-known features that may be provided in a telecommunication network. 
     For the purposes of the description herein, interface and feature modules may be implemented using programmable computers which are well known in the art. These programmable computers may be implemented as standalone devices or, as may be the case with interface module  102  and interface module  107 , may be incorporated in other devices, such as within computer  101  or cellular telephone  108 , respectively. Similarly, the illustrative programmable computers that host feature modules, such as feature modules  103 - 106 , may each be hosted on one physical computing device or, alternatively, several features may be implemented on a single such computing device. Regardless of the precise hardware architecture, such programmable computers would have the required network interfaces to allow for receiving and transmitting network messages, as well as appropriate software for defining the functioning of the modules. Such software is executed on one or more computer processors which control the overall operation of the modules via execution of such software. The detailed hardware and software configuration of the modules will not be described in further detail herein. One skilled in the art of data networking and computers could readily implement such modules given the description herein. 
     Referring once again to  FIG. 1 , a request for communication services with cellular telephone  108  is sent in  FIG. 1  from computer  101  to interface module  102  and then to source feature module  103  having address s 1 , which is an illustrative source feature module in source region  109  that contains those features applicable to a request chain whose source is address s 1 . The request is then sent, for example, to another source feature module  104  having an address s 2  for the application of one or more other source features. The request is then routed to the target region using well-known routing techniques where it is received by target feature module  105  having address t 2 . The request is then forwarded to target feature module  106  having address t 1  in target region  110  before being passed to the corresponding interface module  107  corresponding to cellular telephone  108  in order to complete the request chain. As is well-understood, the signaling channels between the interface modules and feature modules are illustratively created by the request protocol and requests transmitted among the modules are routed along these channels. 
     One skilled in the art will recognize that the request chain of  FIG. 1  requires address translation in order to route the request to various different modules. For example, in order to transmit the call from source feature module  104  to target feature module  105 , the target address must be changed from s 2 , which was the target address used by source feature module  103  to transmit the request to module  104 , to t 2 , which is the address of target feature module  105 . 
     As discussed above, problems may arise when a multitude of features are available in a telecommunication system in that those features may interact together to produce unintended results. As used herein, the term feature interaction is defined as the way in which a feature or features modify or influence another feature in defining overall system behavior. Since all features in telecommunication systems are modifying or enhancing the same basic communication service (i.e., real-time communication among people), such feature interaction occurs frequently. In some cases, feature interactions are benign or even may be considered advantageous in that they produce desirable results. One illustrative example of such a desirable feature interaction, illustrated in  FIG. 2 , may be found in the interaction between caller ID and some personal directory features. Specifically, if a first user has a personal directory that maps nicknames of contacts to telephone numbers, then when one of the contacts calls the first user, the nickname may appear on the caller ID display as opposed to the contact&#39;s full name. Referring to  FIG. 2 , a cellular telephone  201  may contain a personal directory feature that allows a user to input names and telephone numbers corresponding to those names. Such a personal directory may take the form of personal directory table  202 , which shows nicknames associated with such phone numbers, for example the name “Alice” corresponding to the phone number 973-123-4567. One skilled in the art will recognize that such a personal directory may be actually stored in memory on the cellular telephone or, alternatively, may be stored on a network element of the cellular service provider. In either case, when a request for communication arrives at cellular telephone  201 , for example as signal  203 , the cellular telephone cross references the personal directory by looking up the phone number. If a match is found in the personal directory, the telephone may, for example, advantageously only provide a caller ID display of the nickname “Alice” on display  104 . Thus, the interaction of the caller ID feature and the personal directory feature in the example of  FIG. 2  may be considered desirable. 
     While the above desirable interaction may be considered advantageous, in many other cases the results of feature interaction may be undesirable and, therefore, would be considered disadvantageous.  FIG. 3  shows one example of such an undesirable interaction that can be found in the illustrative interaction between an anonymous remailing feature and an autoresponse feature. Specifically, referring to  FIG. 3 , a user  301  having an address of user 1 @host 1  employs an anonymous remailing feature provided by target feature module  302  in the target region  307 . If an email message  304 , for example, is sent to the address anon@remailer of user  301  from a source address user 2 @host  2  of a caller  303 , that message will first be routed to the remailing feature module  302 . The remailing feature module  302  then reassigns the target address to user 1 @host 1 , maintains the source address as user 2 @host 2 , and forwards the message. 
     User  301  having address user 1 @host 1  may subscribe to an anonymous remailing feature service provided, for example, by target feature module  308 . This service illustratively provides an automatic response feature while, for example, user  301  is on vacation. In such a case, message  304  will be routed through module  308 , and the automatic response feature may automatically respond to the message by sending a message  305  back to caller  303  having a target address of user 2 @host 2  and a source address of user 1 @host 1 . Thus, the anonymity to the caller  303  of the user 1 @host 1  address of user  301  is not preserved. 
     A second example of an undesirable feature interaction is shown in  FIG. 4 . Specifically,  FIG. 4  shows the illustrative situation where a caller  401  places a call to a sales group  402  and a feature for that group provided by a target feature module associated with sales group  402  automatically selects a particular representative  403  to receive the call from the caller  401 . If representative  403  is unavailable, for example, a voice mail feature associated with representative  403  illustratively offers to take a message. However, this may be disadvantageous in that the caller  401  would usually prefer to speak to another representative of the sales group, such as representative  404 , instead of leaving a message. The foregoing examples of undesirable feature interaction are merely illustrative. One skilled in the art will recognize that many such undesirable interactions may occur as the number of features in networks increase. 
     In the above examples of feature interactions, as well as many other examples of such interactions, undesirable results occur as a result of address translation and, more particularly, to a lack of appropriate categorization of addresses that prevents the appropriate prioritization of features requiring address translations. Thus, the principles of the present invention are directed to a method for address translation whereby addresses are categorized relative to other addresses and address translation functions are performed only pursuant to specific constraints related to the categorization of the addresses. 
     More specifically, as discussed above, requests for services typically consist of a chain of requests between interface and feature modules.  FIG. 5  shows a network in which a message flow in accordance with the principles of the present invention may be implemented. Specifically, the addresses associated with interface and feature modules are categorized as to whether they are “abstract” or “concrete” with respect to other addresses. As used herein, addresses that more closely identify a source corresponding directly to, for example, an individual user are referred to as more concrete, while addresses that can be used to potentially identify many users or groups of users are more abstract. Thus, an address associated with a cellular or landline telephone of a sales representative is more concrete than an address of the sales representative, and the address associated with the sales representative is more concrete than an address associated with a group of sales representatives. Similarly, an address associated with an anonymous remailer feature module is more abstract than the telephone or other device of a particular subscriber to the remailer feature. In  FIG. 5 , therefore, addresses are more concrete proportionately to the particularity with which those addresses correspond to an individual user in the source or target region. Thus, for example, address s 2  of source feature module  502  in the source region  501  is less concrete and more abstract than the address s 1  of source interface module  503 . Similarly, address t 2  of target feature module  504  in the target region  505  is likewise more abstract and less concrete than address t 1  of target interface module  506 . Each address in a request chain in a telecommunication network (or other communication network) can be likewise categorized as either abstract or concrete relative to other addresses in the chain. 
     In accordance with an embodiment of the present invention, once addresses are categorized according to the relative abstract or concrete nature of those addresses, constraints are applied that govern the address translation functions required by various features. While many constraints may be applied to address translation, the present inventor has identified several constraints that are particularly advantageous in preventing undesirable interaction between features resulting from such translation. 
     For example, in one embodiment of such a constraint shown in  FIG. 6 , hereinafter referred to as Constraint  1 , a target feature module in a request chain, such as target feature module  604  having address t 2  is not permitted to change the source address of a request. Therefore, for example, referring to  FIG. 6 , when target feature module  604  having address t 2  receives a request from source feature module  602  having source address s 2 , target feature module  604  forwards the request to target feature module  606  having address t 1  by translating the target address from address t 2  to address t 1 . The target feature module  604  is constrained, however, to retain the source address s 2  and not translate the source to address t 2  corresponding to target feature module  604 . Such a constraint functions to preserve the reversibility of a request. Reversibility, as used herein, is the ability to send a request or other message in the reverse direction from a target address back to a source address. More particularly, for example, if target feature module  604  replaced the source address s 2  in a request chain, cellular telephone  608  would not have true source information available in order to send a reply back to the originator of the message. By imposing a constraint that prevents target modules from changing source address, reversibility of the request is preserved. 
     In another illustrative constraint in accordance with another embodiment of the present invention, the relative abstract and concrete categorizations of addresses in a request chain are used as a constraint to address translation. This constraint, hereinafter referred to in general as Constraint  2 , is a function of whether the module at which address translation occurs is a target module in the target region or a source module in the source region. Specifically, in the embodiment of this constraint as applied to the source region (hereinafter referred to as Constraint  2   s ), if a source feature module in a request chain changes the source address of a request, the new source address must be more abstract than the old one. Similarly, in the embodiment of this constraint in the target region (hereinafter referred to as  2   t ), if a target feature module in a request chain changes the target address of a request, the new target address must be more concrete than the old one. 
     Adhering to constraints  2   s  and  2   t  will force an orderly progression of address translation from, in the source region, a more concrete address to a more abstract address and, in the target region, from a more abstract address to a more concrete address. Thus, address translations that would jump from one level of abstraction to a higher level of abstraction and, then, back to a lower level of abstraction are prevented. In practical use, preventing such jumps bounds the number of feature modules that can be accessed in a request chain. Specifically, the number of modules that can be accessed in the source and target regions will be equal to or less than the levels of address abstraction defined in those regions, respectively. Since many undesirable feature interactions can be traced to a requirement to process a large number of features at different levels of abstraction in an inconsistent order, imposing the above constraints on address translations based on abstraction levels functions to reduce the undesirable feature interactions. 
     The above address translation constraints address the problem of translation of addresses primarily in a source address field and/or a target address field of a message. However, as is well known, source and target addresses are also frequently transmitted in signaling information sent along signaling channels. As is frequently the case, these addresses may indicate an alternative source or target address of the chain. Therefore, when such alternative addresses are used, in another embodiment of the present invention, an additional constraint (hereinafter referred to as Constraint  3 ) is imposed upon the address translation of these addresses in order to prevent or at least limit the aforementioned feature-interaction problem resulting from address translation of such alternative addresses. Specifically, in accordance with this embodiment, a constraint is applied to the source region of a message (hereinafter referred to as Constraint  3   s ) wherein a source feature module in a request chain may not transmit downstream (e.g., to a target address) an alternative source address for the chain that is more concrete than its own address. As a corollary, a constraint in the target region (hereinafter referred to as Constraint  3   t ) is applied so that a target feature module in a request chain cannot transmit upstream (e.g., to a source address) any address more concrete than its own address. As one skilled in the art will recognize in light of the teachings herein, Constraints  3   s  and  3   t  will help to, for example, preserve the privacy of any address more concrete than a target or source feature module. 
     The foregoing constraints  1 ,  2   s ,  2   t ,  3   s  and  3   t  when applied to address translation will help to resolve many of the feature interaction problems described above. For example, referring once again to the example of a remailer feature, applying the above constraints may prevent the problem of inadvertent identification of a subscriber of such a feature. Specifically,  FIGS. 7A and 7B  illustrate how address translation could be performed using such constraints. Referring to  FIG. 7A , as was described above in association with  FIG. 3 , illustrative source feature module  701 , here a mail host for user 1 , sends an email message having a source address of user 1 @host 1  and having a target address of an anonymous e-mail address here, illustratively, anon 2 @remailer. This message is routed to the target region  703  and is received by the target feature module  704  providing anonymous e-mail hosting services. As per Constraint  1 , the target module  704  may not change the source address, thus preserving the identity of the original sender  702  as user 1 @host 1 . The target module  704  does, however, change the target address of the message from anon 2 @remailer to the address user 2 @host 2  on mail host feature module  707  to forward the request to user  705 . This translation conforms to Constraint  2   t  because the target address is translated to the more concrete user 2 @host 2  address. 
     When the message is received at the email host  707  of user  705  with the address user 2 @host 2 , if an autoresponse feature is active for user  705  at, for example, user 2 @host 2 , then an automatic response to the email will be generated. A return message chain corresponding to this automatic response is shown in  FIG. 7B . Referring to that figure, the automatic response will initially have a source address of user 2 @host 2  and a target address of user 1 @host 1  corresponding to user  702 . However, as discussed above, it is undesirable to transmit a message directly from the address user 2 @host 2  to user 1 @host 1  because the privacy of the address user 2 @host 2  would be lost. Therefore, the message is forwarded to a source feature module  706  that first checks whether it is desired to respond anonymously to the address user 1 @host 1 . One skilled in the art will recognize that this source feature module  706  may be implemented as a part of the mail host feature module  707  of user  705  or, alternatively, as a separate feature module. Once the source feature module  706  determines that user 1 @host 1  should be responded to anonymously, the feature translates the source address user 2 @host 2  to an address anon 2 @remailer and then forwards the message having this source address and the target address user 1 @host 1  to the source remailer feature module  704  at anon 2 @remailer. This translation conforms to Constraint  2   s  which dictates that no source feature module may forward an address more concrete than its own address, since the address anon 2 @remailer is more abstract than the address user 2 @host 2 . 
     Once the source feature module  706  associated with user 2 @host 2  translates the address to anon 2 @remailer 2 , the message is routed to the remailer feature module  704 . Illustratively, the remailer feature module authenticates the use of the address anon 2 @remailer, for example by referring to an identifying key included in the message from user 2 @host 2 , and then forwards the message to address user 1 @host 1  corresponding to user  701  without any additional address translation. 
       FIGS. 8A and 8B  show another example of how constrained feature address translation in compliance with Constraints  3   s  and  3   t  may be implemented. Specifically,  FIG. 8A  once again presents the situation where a customer  801  calls a sales group, as discussed above in association with  FIG. 4 . However, in this example, the call has called a target address of g associated with the group feature module  802 . The call is routed to the group feature module  802 , which translates the target address g to a target address of p, associated with a particular sales representative  803 , which is more concrete than the address g and therefore this translation does not violate Constraint  2   t . However, in addition, group feature module  802  also sends downstream a signal with a parameter of “nearparty” having a value of address g of group feature module  802 . This parameter is an alternative target address that indicates that any or certain features associated with the call should be performed by the group feature module  802  and not a module associated with the sales representative  803  at address p. As a result, instead of a module associated with sales representative  803  transferring the call to voice mail, the call will be returned to sales group feature module  802  for either rerouting to another sales representative, such as sales representative  804  or for sending to a group voice mail function. While an alternative target address is being transmitted in this scenario, this processing conforms to Constraint  3   t  since the alternative target address g is being sent downstream in the target region associated with the sales group, not upstream. 
       FIG. 8B  shows a more complex example of  FIG. 8A , also illustrating a possible call from a user to a sales group target. Referring to that figure, the caller  801  places a call having a target address g corresponding to a sales group feature module, and also provides signaling information with an alternative target address indicating that the caller&#39;s favorite sales representative is sales representative  803  at address p. The call is forwarded by the sales group feature module  802  to address p and representative  803 . In addition, the near party parameter may be provided once again, as described above, in order to return the call to sales group feature module  802  in the event sales representative  803  is unavailable. The example of  FIG. 8B  is an example of conformance with Constraint  3   s , since an alternative target is provided by the source region, not an alternative source. 
     The constraints described hereinabove each dictate how address translation is to occur in target and source regions. These constraints to address translation control the high number of feature interactions in today&#39;s telecommunication networks. The end result of the application of such constraints is the reduction or elimination of many of the feature-interaction problems that occur in telecommunication networks today and which may be traced directly to issues created as a result of uncontrolled address translation. 
     The foregoing Detailed Description is to be understood as being in every respect illustrative and exemplary, but not restrictive, and the scope of the invention disclosed herein is not to be determined from the Detailed Description, but rather from the claims as interpreted according to the full breadth permitted by the patent laws. It is to be understood that the embodiments shown and described herein are only illustrative of the principles of the present invention and that various modifications may be implemented by those skilled in the art without departing from the scope and spirit of the invention. Those skilled in the art could implement various other feature combinations without departing from the scope and spirit of the invention.